【服务网格架构】Envoy 部署类型

简介: 【服务网格架构】Envoy 部署类型

Envoy可用于各种不同的场景,但是在跨基础架构中的所有主机进行网格部署时,它是最有用的。本节介绍三种推荐的部署类型,其复杂程度越来越高。


服务到服务

  • 服务到出口监听器
  • 服务到服务入口监听器
  • 可选的外部服务出口监听器
  • 发现服务集成
  • 配置模板

服务加上前台代理服务

  • 配置模板

服务到服务,前端代理和双重代理

  • 配置模板


服务到服务



上图显示了使用Envoy作为面向服务架构(SOA)内部的所有流量的通信总线的最简单的Envoy部署。在这种情况下,Envoy公开了几个用于本地来源流量的监听器,以及用于服务流量的服务。


服务到服务出口监听器

这是应用程序与基础结构中的其他服务交谈的端口。例如,http:// localhost:9001。HTTP和gRPC请求使用HTTP / 1.1主机头或HTTP / 2:机构头来指示请求发往哪个远程群集。Envoy根据配置中的细节处理服务发现,负载平衡,速率限制等。服务只需要了解当地的特使,不需要关心网络拓扑结构,无论是在开发还是在生产中运行。


此侦听器支持HTTP / 1.1或HTTP / 2,具体取决于应用程序的功能。


服务到服务入口监听器

这是远程特使想要与当地特使交谈时使用的端口。例如,http:// localhost:9211。传入的请求被路由到配置的端口上的本地服务。可能会涉及多个应用程序端口,具体取决于应用程序或负载平衡需求(例如,如果服务同时需要HTTP端口和gRPC端口)。当地的特使根据需要进行缓冲,断路等。


我们的默认配置对所有特使通信都使用HTTP / 2,而不管应用程序在离开本地特使时是否使用HTTP / 1.1或HTTP / 2。HTTP / 2通过长期连接和显式重置通知提供更好的性能。


可选的外部服务出口监听器

通常,本地服务要与之通话的每个外部服务都使用明确的出口端口。这样做是因为一些外部服务SDK不轻易支持覆盖主机头以允许标准的HTTP反向代理行为。例如,http:// localhost:9250可能被分配给发往DynamoDB的连接。我们建议为所有外部服务保持一致并使用本地端口路由,而不是为某些外部服务使用主机路由,为其他服务使用专用本地端口路由。


发现服务集成

建议的服务配置服务使用外部发现服务进行所有群集查找。这为Envoy提供了在执行负载平衡,统计收集等时可能使用的最详细的信息。


配置模板

源代码发行版包含一个服务配置示例服务,与Lyft在生产环境中运行的版本非常相似。浏览此处获取更多信息。


服务加上前台代理服务

上图显示了服务配置,位于用作HTTP L7边缘反向代理的Envoy群集之后。反向代理提供以下功能:


  • 终止TLS。
  • 支持HTTP / 1.1和HTTP / 2。
  • 完整的HTTP L7路由支持。
  • 与服务通过标准入口端口来服务Envoy集群,并使用发现服务进行主机查找。因此,前面的特使主机和任何其他的特使主机一样工作,除了他们没有与另一个服务搭配在一起。这意味着以相同的方式运行并发出相同的统计数据。

配置模板

源码分发包括一个与Lyft在生产环境中运行的版本非常相似的示例前端代理配置。浏览此处获取更多信息。


服务到服务,前端代理和双重代理

上图显示了作为双代理运行的另一个Envoy群集的前端代理配置。双重代理背后的想法是,尽可能地将TLS和客户端连接终止到用户(TLS握手的较短往返时间,较快的TCP CWND扩展,较少的数据包丢失机会等),会更高效。在双重代理中终止的连接然后被复用到在主数据中心中运行的长期存在的HTTP / 2连接上。


在上图中,在区域1中运行的前置Envoy代理通过TLS相互认证和固定证书与在区域2中运行的前置Envoy代理进行身份验证。这允许在区域2中运行的前端Envoy实例信任通常不可信的传入请求的元素(例如x前转的HTTP标头)。


配置模板

源码分发包含一个与Lyft在生产中运行的版本非常相似的示例双重代理配置。浏览此处获取更多信息。

相关文章
|
16小时前
|
SQL 分布式计算 Hadoop
Azkaban【基础 01】核心概念+特点+Web界面+架构+Job类型(一篇即可入门Azkaban工作流调度系统)
【2月更文挑战第6天】Azkaban【基础 01】核心概念+特点+Web界面+架构+Job类型(一篇即可入门Azkaban工作流调度系统)
104 0
|
6月前
|
设计模式 编译器 Go
掌握Go类型内嵌:设计模式与架构的新视角2
掌握Go类型内嵌:设计模式与架构的新视角
31 0
|
6月前
|
设计模式 Cloud Native JavaScript
掌握Go类型内嵌:设计模式与架构的新视角1
掌握Go类型内嵌:设计模式与架构的新视角
43 0
|
7月前
|
存储 Kubernetes Cloud Native
【云原生】k8s组件&架构介绍与K8s最新版部署
【云原生】k8s组件&架构介绍与K8s最新版部署
196 0
|
16小时前
|
监控 负载均衡 数据安全/隐私保护
探索微服务架构下的服务网格(Service Mesh)实践
【5月更文挑战第6天】 在现代软件工程的复杂多变的开发环境中,微服务架构已成为构建、部署和扩展应用的一种流行方式。随着微服务架构的普及,服务网格(Service Mesh)作为一种新兴技术范式,旨在提供一种透明且高效的方式来管理微服务间的通讯。本文将深入探讨服务网格的核心概念、它在微服务架构中的作用以及如何在实际项目中落地实施服务网格。通过剖析服务网格的关键组件及其与现有系统的协同工作方式,我们揭示了服务网格提高系统可观察性、安全性和可操作性的内在机制。此外,文章还将分享一些实践中的挑战和应对策略,为开发者和企业决策者提供实用的参考。
|
16小时前
|
Kubernetes Cloud Native 持续交付
探索云原生架构的未来:如何优化资源管理和服务部署
【5月更文挑战第6天】 随着云计算的快速发展,云原生技术已成为企业数字化转型的关键驱动力。此篇文章深入探讨了云原生架构的核心组件及其在资源管理和服务部署方面的优化策略。通过分析容器化、微服务及自动化管理的实践案例,本文旨在为读者提供一套系统的方法论,以利用云原生技术实现更高效、灵活且可靠的IT基础设施。
28 2
|
16小时前
|
运维 监控 负载均衡
探索微服务架构下的服务网格(Service Mesh)实践之路
【4月更文挑战第30天】 在现代云计算的大背景下,微服务架构以其灵活性和可扩展性成为众多企业转型的首选。然而,随着服务的激增和网络交互的复杂化,传统的服务通信模式已无法满足需求,服务网格(Service Mesh)应运而生。本文通过分析服务网格的核心组件、运作机制以及在企业中的实际应用案例,探讨了服务网格在微服务架构中的关键作用及其带来的变革,同时提出了实施过程中面临的挑战和解决策略。
|
16小时前
|
运维 监控 负载均衡
探索微服务架构下的服务网格(Service Mesh)实践
【4月更文挑战第28天】 在现代云原生应用的后端开发领域,微服务架构已成为一种广泛采用的设计模式。随着分布式系统的复杂性增加,服务之间的通信变得愈加关键。本文将深入探讨服务网格这一创新技术,它旨在提供一种透明且高效的方式来管理、监控和保护微服务间的交互。我们将从服务网格的基本概念出发,分析其在实际应用中的优势与挑战,并通过一个案例研究来展示如何在现有的后端系统中集成服务网格。
|
16小时前
|
消息中间件 监控 微服务
【专栏】随着技术发展,未来将探索服务网格、容器化和云原生技术,以提升微服务架构的效能
【4月更文挑战第27天】本文探讨了构建高效微服务架构的后端开发最佳实践。微服务以服务独立、去中心化、自治和轻量级通信为核心原则,带来可扩展性、独立性、技术灵活性和团队协作优势。实践中,要注意服务拆分粒度、选择合适的通信协议(如RESTful、RPC、消息队列)、处理数据一致性与分布式事务、实施服务治理和监控,以及确保安全性与权限控制。随着技术发展,未来将探索服务网格、容器化和云原生技术,以提升微服务架构的效能。
|
6月前
|
存储 Linux Docker
跨cpu架构部署容器技术点:怎样修改Linux 的内核版本
在使用Docker 进行跨平台部署之后,我们还可以尝试进行跨架构部署。 从X86 架构上移植到 aarch64 上。
203 0