企业网站制作商,php网站开发教程网,中国建筑猎头网,园林景观设计公司有丙级吗目录 一、什么是Service Mesh
二、微服务发展历程
2.1 微服务架构演进历史
2.1.1 单体架构
2.1.2 SOA阶段
2.1.3 微服务阶段
2.2 微服务治理中的问题
2.2.1 技术栈庞杂
2.2.2 版本升级碎片化
2.2.3 侵入性强
2.2.4 中间件多#xff0c;学习成本高
2.2.5 服务治理功…目录 一、什么是Service Mesh
二、微服务发展历程
2.1 微服务架构演进历史
2.1.1 单体架构
2.1.2 SOA阶段
2.1.3 微服务阶段
2.2 微服务治理中的问题
2.2.1 技术栈庞杂
2.2.2 版本升级碎片化
2.2.3 侵入性强
2.2.4 中间件多学习成本高
2.2.5 服务治理功能不全面
三、Service Mash 发展历程
3.1 Service Mash 概述
3.1.1 什么是Service Mash
3.2 Service Mash 演进历史
3.2.1 什么是服务代理
3.2.2 Sidecar部署架构
3.2.3 Service Mesh中的核心概念
四、Service Mash 常用解决方案
4.1 Istio Envoy
4.2 Linkerd
4.2.1 Linkerd 主要功能
4.3 Kong Mesh-Kuma
4.4 Traefik Mesh
4.5 NGINX Service Mesh
五、聊聊Envoy与Istio
5.1 Istio介绍
5.1.1 Istio核心组件
5.2 为什么使用Istio
5.3 Istio 核心特性
5.3.1 流量管理
5.3.2 安全性好 5.3.2 可观测性
5.3 Istio支持平台
5.4 Envoy介绍
5.4.1 Envoy简介
5.4.2 核心功能
5.5 Envoy架构设计
5.5 Envoy的边缘代理模式
5.5.1 HTTP 标头清理
5.5.2 超时控制
5.5.3 连接限制
5.5.4 Envoy使用场景
六、写在文末 一、什么是Service Mesh
Service Mesh即服务网格通俗来讲就是将可配置的代理层和服务部署在一起作为微服务基础设施层接管服务间的流量并提供通用的服务注册发现、负载均衡、身份验证、精准路由、服务鉴权等基础功能。 Mesh 这个词汇我们听到的应该非常多家用路由器领域有 Mesh 组网在智能家居领域有蓝牙 Mesh。之所以叫作 Mesh是因为它们都有一个共同的特征——去中心化。这里讲到的 Service Mesh 同样具有这一特性微服务之间通过 Sidecar 联通网络移除了中心网关的概念。 二、微服务发展历程 2.1 微服务架构演进历史 2.1.1 单体架构
即所有的业务功能汇聚在一个模块中团队中的所有人都在同一个模块中共同协作。 优点 开发效率高能够满足快速迭代上线 团队协作高效配合简单 部署简单灵活运维成本低 资源占用少可以很好的控制资源成本 单体架构主要适用于业务模型简单团队规模较小对开发、上线、部署上线等时效要求较高的场景一般在创业团队初期为了适应市场的快速变化而使用的一种架构模式。 缺点 扩展有限。由于整个应用程序是一个单一的单元如果应用程序需要扩展就需要对整个应用进行扩展而不是某个模块这就限制了模块的扩展性 难以维护可持续性差。随着应用程序不断发展和演化单体架构的代码可能会变得越来越复杂和难以维护。比如各个功能模块共享同一个代码库和数据库一个很小的修改可能会对整个应用程序产生意想不到的影响。 部署升级困难。由于整个应用程序是一个单一部署单元当需要部署新的功能或者升级应用程序时就要停止整个应用程序的运行这可能会导致应用程序的长时间不可用。 架构演进难。当单体应用中的某个模块遇到性能瓶颈如果希望以另外一种语言重新编写此模块或者重构这个模块这时候会发现单体应用完全无法演进。如果要替换语言就得重写整个应用花费的成本可想而知。 程序稳定性问题。单体应用中当某个模块出现 Bug 时比如因为疏忽造成了 OOM (程序内存不足)导致程序 panic这会导致整个网站或者 App 不可用。一个模块的问题导致了整个应用挂掉这在生产环境中是无法接受的。 2.1.2 SOA阶段
随着互联网业务的发展整体业务越来越复杂单体架构带来的问题越来越明显单体服务已经无法应对如此复杂的业务场景了。于是互联网行业也从架构上逐步开始了服务拆分进入了 SOA Service-Oriented Architecture 面向服务的架构时代。 在 SOA 时代比如淘宝网采用了一种 ESB 总线的技术就是所有服务的通信需要通过一个集中式的总线服务可以理解为集中式网关这大大降低了服务的通信效率并且增加了单点风险。但是随着业务进一步扩大 ESB 总线的弊端逐步凸显比如每次服务变更节点都需要人工操作这大大降低了互联网业务的迭代效率。 2.1.3 微服务阶段
随着互联网技术的发展尤其是移动互联网的高速发展对服务端的要求也越来越高一个大家普遍认知的情况就是如何规划服务架构才能与企业未来快速增长的业务模式相匹配。微服务架构的出现不是一蹴而就的而是基于单体架构与SOA的思想基于业务模型划定一定的指标和边界从而形成一系列边界相对清晰的服务单元这些服务单元通过一定的服务治理组件连接并统一对外提供服务能力这就是微服务的核心理念。 微服务是一种架构模式是面向服务的体系结构SOA软件架构模式的一种演变它提倡将单一应用程序划分成一组松散耦合的细粒度小型服务辅助轻量级的协议互相协调、互相配合为用户提供最终价值。 微服务通常具有如下特点 单一职责 微服务架构中每个服务单元高度服务化、独立存在根据业务便捷对外输出服务能力符合高内聚、低耦合原则以及单一职责原则的思想。不同的服务通过“管道”方式灵活组合从而构建出庞大的系统。 独立性 微服务架构中每个服务都是独立的单元对外提供服务与其他服务高度解耦可以完成独立的开发、测试、部署、运维。 进程隔离 在微服务架构中应用程序由多个微服务模块组成共同对外提供服务能力每个服务都是高度自治的独立业务单元。运行在各自独立的进程中以实现高度自治和隔离。进程的隔离能够方便的做到对服务进行动态扩缩容的能力业务高峰期增加服务资源以提升并发能力业务低谷期则可释放服务资源以节省开销。 调用简单 采用微服务架构服务之间可以通过rest接口或RPC框架进行互相调用以实现不同服务之间的轻量级交互和通信。 治理简单 使用微服务架构之后不同的服务模块 组件可以彼此独立地进行扩缩容和治理从而减少了因必须缩放整个应用程序而产生的浪费和成本因为单个功能可能面临过多的负载。 多样化部署 微服务架构下可以针对不同的服务模块采用不同的部署模式私有云、公有云、混合部署甚至容器化部署也是很方便的。 关于微服务发展也离不开微服务技术栈的发展和完善以Java为例伴随着微服务的出现业界出现不少微服务治理的框架以springcloud为首的第一代微服务在国内dubbo也成为很多企业做微服务治理的不错的选择再到后来springcloud-alibaba的微服务治理体系解决方案也逐步占据了不少的市场。 2.2 微服务治理中的问题
经管微服务架构的实践能够应对很多复杂的业务场景并且在实际应用中还有着不错的伸缩性能但是随着业务规模的不断增长微服务模块也随之增加微服务模块的增多意味着系统的复杂性越来越高调用链路到最后就呈现出大家熟知的蜘蛛网结构。 这样一个复杂的调用链路无疑给系统的运维后续的可持续治理带来了极大的挑战以一个简单的A\B\C三个微服务模块的互相调用来说A调BB调CC调A使用微服务框架进行调用时ABC服务至少需要知道相互之间的服务名称然后再在代码或配置中心进行服务寻址最后发起调用综合来说ABC需要通过一种机制定位要调用的服务同时需要集中维护和管理服务地址信息... 综合来说微服务架构下可能面临下面的这些问题 2.2.1 技术栈庞杂
使用过dubbo或springcloud组件做微服务开发的同学应该不陌生一个微服务治理框架并不是单纯的使用springcloud或dubbo自身的框架就可以解决的以springcloud为例有的微服务模块可能只需要集成feign,eureka即可有的模块却需要feignsentinel更有的模块还需要集成消息中间件很难真正意义上做到治理组件的技术栈的统一。技术栈的庞杂给开发团队带来了不小的技术门槛和后期的运维成本。 2.2.2 版本升级碎片化
在实践过程中可以发现微服务架构下各种中间件的版本迭代升级太快了这对于微服务项目本身来说是一个很难绕开却棘手的事情可能在某个高版本中某个组件提供了某个业务场景下的技术解决方案但是目前你的版本并不支持如果要升级面临的将是整个微服务组件的版本升级这样一来你不得不投入大量的时间去解决各种包的版本冲突甚至间接的依赖组件版本也得跟着升级最后的结果就是即便全部升级了版本你得对整个系统进行重新的全面测试这个成本是比较高的。 2.2.3 侵入性强
以springcloud为例想要使用组件进行服务间的调用需要集成服务组件的SDK除了需要添加相关依赖业务代码中需要添加各种依赖、注解、配置等这是一种相当的耦合性造成了一定程度上业务边界的不清晰。 2.2.4 中间件多学习成本高
可以说当你开始使用springcloud这一套微服务框架做服务治理时随着业务的发展需要涉及的组件会越来越多这对于后续加入团队的成员来说是具有相当的学习成本。 2.2.5 服务治理功能不全面
尽管springcloud或dubbo提供了一站式的微服务解决方案但是在具体实际过程中仍然可以发现单独使用springcloud也无法满足所有的要求诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。遇到类似的情况还是需要考虑引入其他的组件或者定制解决方案。 三、Service Mash 发展历程 3.1 Service Mash 概述 3.1.1 什么是Service Mash
Service Mash中文解释为服务网格是一个专门处理服务通讯的基础设施层。在实践中它是一组和应用服务部署在一起的轻量级的网络代理并且对应用服务透明。 通俗解释将服务的网络代理抽象出来统一纳管的一种网络架构 具体来说
Service Mesh主要解决的问题就希望开发⼈员对于业务的聚焦服务发现、服务注册、负载均衡等对于 开发⼈员透明可以更加专注业务逻辑的实现Service Mesh 服务网格是一个用于处理服务和服务之间通信的基础设施层它最重要的变革就是引入了数据面和控制面的概念通过 sidecar模式将原本在SDK中的代码独立出来用控制面代替配置中心的部分功能以透明代理的形式提供安全、快速、可靠的服务间通信同时也能实现微服务所需的基本组件功能实际上Service Mesh 需要的基础组件和传统的微服务并没有太大的差别很多公司选择自研控制面的原因很多就是出于兼容老的微服务的基础组件的考虑你可以把 Service Mesh 看作是分布式的微服务代理。 3.2 Service Mash 演进历史
下图是一张微服务治理过程中从单体服务到service mash时代的演进图从图中不难看出这也是对应着微服务治理的过程。 3.2.1 什么是服务代理
在真正迈向Service Mesh时必须要聊的就是Sidecar服务代理专业解释Sidecar翻译成中⽂是边⻋能够很形象的说明。如下图所展示 3.2.2 Sidecar部署架构
在实际部署微服务的时候服务之间的调用通常是非常频繁的服务间的调用通常涉及到网络通信协议转换路由策略网关配置等信息如果将为微服务提供通信服务的这部分逻辑从应⽤程序进程中抽取出来作为⼀个单独的进程进⾏部 署并将其作为服务间的通信代理可以得到下图所示的架构 当服务规模越来越大的时候很难再单纯通过人力去理清服务之间的调用关系引入Sidecar之后随着服务部署的Sidecar代理之间的连接形成了⼀个如下图所示的⽹格该⽹格成为 了微服务的通讯基础设施层承载了微服务之间的所有流量被称之为Service Mesh服务⽹格 服务⽹格中有数量众多的Sidecar代理如果对每个代理分别进⾏设置这个⼯作量⾮常巨⼤。为了更⽅便对服务⽹格中的代理进⾏统⼀集中控制在服务⽹格上增加了控制⾯组件这个组件即用来管理Sidecar如下图所示 如果我们从一个全局视角来看绿色的为应用服务蓝色的为SideCar就会得到如下部署图 如果我们省略去服务只看Service Mesh的代理边车的网格应该是这样的 外部流量经过时会先被Sidecar拦截之后才放行进入服务所以它就是一个由若干服务代理所组成的错综复杂的网格。 第一代Service Mesh由一系列独立运行的单机代理服务构成为了提供统一的上层运维入口演化出了集中式的控制面板我们称之为控制面control plane。 随着服务架构的继续演进我们需要Sidecar提供更丰富的功能比如策略下发、数据采集、动态路由、配置管理、流量治理、可观测性等那么就需要控制面控制面板与Sidecar进行更多的交互。 服务⽹格⽤来描述组成这些应⽤程序的微服务⽹络以及它们之间的交互。随着服务⽹格的规模和复杂性不断的增⻓它将会变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、度量和监控等。服务⽹格通常还有更复杂的运维需求⽐如 A/B 测试、⾦丝雀发布、速率限制、访问控制和端到端认证。 3.2.3 Service Mesh中的核心概念
服务网格分为控制层和数据层或称之为数据面与控制面
控制层或控制平面control plane是管理组件负责与控制平面中的代理通信下发策略和配置 数据层或数据平面data plane是网络代理直接处理入站和出站数据包转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
数据面特征
通常是按照无状态目标设计的但实际上为了提高流量转发性能需要缓存一些数据因此无状态也是有争议的直接处理入站和出站数据包转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等对应用来说透明即可以做到无感知部署 控制面特征
与控制平面中的代理通信下发策略和配置负责网络行为的可视化不直接解析数据包通常提供 API 或者命令行工具可用于配置版本化管理便于持续集成和部署 四、Service Mash 常用解决方案
随着服务网关开始在生产实践中的使用加上近些年以k8s为代表的容器化编排能力的加强Service Mash 也出现了很多解决方案下面列举几种常用的解决方案。 4.1 Istio Envoy
如今Istio 几乎是 Service Mesh 的代名词了Istio 包含控制面 Istiod 和数据面 Envoy 两个组件。 Istiod 是 Istio 的控制面负责配置校验和下发、证书轮转等工作Envoy 则负责数据代理和流量路由等工作。 准确来说 Istio 实际上只是 Service Mesh 的控制面而 Istio Envoy 才组成整个 Service Mesh 体系这有点像 GNU/Linux通常被简单地称为 Linux。 Istio 包含负责配置下发的 Pilot、负责证书轮转的 Citadel 和负责配置校验的 Galley。在 1.5 版本去除 mixer 后 Istio 已经变得相对简单了它的主要工作就是配置下发。 Envoy 是 C 编写的高性能边缘网关和代理程序支持 HTTP、gRPC、Thrift、Redis、MongoDB 等多种协议代理。当然这里面支持最好的还是 HTTP它几乎具备了 Service Mesh 数据面需要的所有功能比如服务发现、限流熔断、多种负载均衡策略、精准流量路由等。 4.2 Linkerd
Linkerd 是云原生软件公司 Buoyant 开源的 Service Mesh 方案而 Service Mesh 的概念也是 Linkerd 首先提出的。其主要⽤于解决分布式环境中服务之间通信⾯临的⼀些问题⽐如⽹络不可靠、不安全、延迟丢包等问题。Linkerd使⽤Scala语⾔编写运⾏于JVM底层基于Twitter的Finagle库并对其做相应的扩展。最主要的是Linkerd具有快速、轻量级、⾼性能等特点每秒以最⼩的时延及负载处理万级请求易于⽔平扩展经过⽣产线测试及验证可运⾏任何平台的产线级Service Mesh⼯具。 不过由于 Java 的内存占用率等原因并不适合 Sidecar 的编写所以 Linkerd 开发了 2.0 版本数据面使用 Rust 编写控制面基于 Go 语言实现。 4.2.1 Linkerd 主要功能
Linkerd 主要功能如下
mTLSLinkerd 为所有网格内的服务提供双向 TLS 加密认证的功能保证流量传输安全。可观测性提供了 Grafana 的图形界面以及链路追踪功能。协议支持提供了 gRPC、HTTP、HTTP/2 等多种协议支持。负载均衡提供了多种负载均衡功能包括基于当前请求数的 P2C 算法、基于 EWMA 的多种策略的 P2C 算法以及常规的 WRR 和 RR 算法。动态路由功能支持根据 header 设置不同的路由规则支持流量转移功能可以在不同服务之间、相同服务不同版本之间做流量转移。 4.3 Kong Mesh-Kuma
早期 Kong 采用了自研的 Kong 作为数据面Istio 作为控制面的方案但这个方案很快被抛弃了现在 Kong 推出了基于 Envoy 的 Service Mesh 解决方案——Kuma。 Kuma 最大的特点是同时支持 Kubernetes 和 VM 虚拟机这样即便公司存在多种运行环境也可以支持。另外它也支持单一控制面同时控制多套集群由于使用 Envoy 作为数据面所以在核心功能支持上和 Istio 相差不大比较特别的是支持 Kong 作为入口网关层。此外Kuma 采用 Go 语言编写方便二次开发扩展。 4.4 Traefik Mesh
Traefik Mesh 由 Go 语言编写的开源网关系统 Traefik 演进而来与其他提到的 Mesh 解决方案不同Taeafik Mesh 将 Sidecar 部署在了 Kubernetes Node 节点上。这样的好处是在同一个 Node 节点上的 Pod可以共享一个 Sidecar不用为每个 Pod 单独分配 Sidecar 资源从而达到节省资源的目的同时相对于在 Pod 的 Container 里部署 Sidecar这样也方便升级维护。 但这种做法也有缺点资源隔离性不好容易相互影响比如同一个 Node 节点上某个服务出现了问题从而占用了更多的资源其他的 Pod 可能就没有资源可用了。 4.5 NGINX Service Mesh
Nginx 包含一个处理东西流量的 NGINX Plus 数据面和一个用作入口网关南北向流量的NGINX Plus都可以通过控制面进行控制。 控制面专门为 NGINX Plus 开发下发配置用于控制 NGINX Plus 的数据面主要包含以下部分。
Grafana用于收集 Metrics 指标的可视化展示。Kubernetes Ingress Controllers管理入口和出口流量。SPIRE复杂证书轮转。NATS负责下发配置比如路由信息更新等。Open Tracing分布式链路追踪同时支持 Zipkin 和 Jaeger。Prometheus收集 Metrics 信息包括请求数连接数SSL 握手次数等。 要注意的是NGINX Plus 是 Nginx 收费版本并不是开源软件无法进行二次开发。 更多的解决方案大家可以参阅相关的资料还有很多下面列举了常用的一些Service Mesh解决方案有兴趣的同学可以针对每种方案对应的组件进行深入的学习和了解 五、聊聊Envoy与Istio 5.1 Istio介绍
谈到 Service Mesh不得不提及 Istio作为 Google、IBM、lynx 联合推出的 Service Mesh 解决方案Istio 几乎成了 Service Mesh 的代名词但实际上 Istio 仅仅是 Service Mesh 中的控制面它的主要功能是为数据面下发服务治理策略。 Istio 最近在 1.5 版本进行了一次大的变更由早期的微服务架构变成了单体架构。之前版本的Istio 由 Pilot、Citadel、Galley、Sidecar 注入器等多个微服务组成但现在只需要一个 Istiod 的单体服务。 Istio的架构图 5.1.1 Istio核心组件
结合上图Istio核心组件如下
Pilot Istio 控制面中最核心的模块负责运行时配置下发具体来说就是和 Envoy 之间基于 xDS 协议进行的各种 Envoy 配置信息的推送包括服务发现、路由发现、集群发现、监听器发现等。为 Envoy 提供服务发现流量管理和智能路由AB 测试、⾦丝雀发布等以及错误处理超时、重试、熔断功能。Citadel负责证书的分发和轮换为服务之间提供认证和证书管理可以让服务⾃动升级成 TLS 协议使 Sidecar 代理两端实现双向 TLS 认证、访问授权等。Galley配置信息的格式和正确性校验将配置信息提供给 Pilot 使用。Galley 是 Istio 的配置验证、提取、处理和分发组件。它负责将其余的 Istio 组件与从底层平台例如 Kubernetes获取⽤户配置的细节隔离开来。 5.2 为什么使用Istio
通过负载均衡、服务间的身份验证、监控等⽅法Istio 可以轻松地创建⼀个已经部署了服务的⽹络⽽ 服务的代码只需很少更改甚⾄⽆需更改。通过在整个环境中部署⼀个特殊的 sidecar 代理为服务添加 Istio 的⽀持⽽代理会拦截微服务之间的所有⽹络通信然后使⽤其控制平⾯的功能来配置和管理 Istio这包括 为 HTTP、gRPC、WebSocket 和 TCP 流量⾃动负载均衡。通过丰富的路由规则、重试、故障转移和故障注⼊对流量⾏为进⾏细粒度控制。可插拔的策略层和配置 API⽀持访问控制、速率限制和配额。集群内包括集群的⼊⼝和出⼝所有流量的⾃动化度量、⽇志记录和追踪。在具有强⼤的基于身份验证和授权的集群中实现安全的服务间通信。 Istio 为可扩展性⽽设计可以满⾜不同的部署需求。 5.3 Istio 核心特性
Istio以统一的方式提供了许多跨服务网格的关键功能。 5.3.1 流量管理 1、Istio 简单的规则配置和流量路由允许您控制服务之间的流量和 API 调⽤过程。 2、Istio 简化了服务级属性如熔断器、超时和重试的配置并且让它轻⽽易举的执⾏重要的任务如A/B 测试、⾦丝雀发布和按流量百分⽐划分的分阶段发布。 3、有了更好的对流量的可视性和开箱即⽤的故障恢复特性就可以在问题产⽣之前捕获它们⽆论⾯对什么情况都可以使调⽤更可靠⽹络更健壮。 5.3.2 安全性好
安全性对于互任何一款互联网产品来说都至关重要Istio 的安全特性解放了开发⼈员使其只需要专注于应⽤程序级别的安全。 Istio 提供了底层的安全通信通道并为⼤规模的服务通信管理认证、授权和加密。有了 Istio服务通信在默认情况下就是受保护的可以让您在跨不同协议和运⾏时的情况下实施⼀致的策略——⽽所有这些都只需要很少甚⾄不需要修改应⽤程序。 Istio 是独⽴于平台的可以与 Kubernetes或基础设施的⽹络策略⼀起使⽤。但它更强⼤能够在⽹络和应⽤层⾯保护pod到 pod 或者服务到服务之间的通信 5.3.2 可观测性
近些年随着微服务架构的应用逐渐成熟人们对于服务在运行过程中的各种指标监控的可视化需求也越来越高简单来说就是服务运行过程中的各种指标参数应当是可观测的。在这方面Istio提供了较强大的功能。
Istio 健壮的追踪、监控和⽇志特性让您能够深⼊的了解服务⽹格部署。通过 Istio 的监控能⼒可以真正的了解到服务的性能是如何影响上游和下游的⽽它的定制 Dashboard 提供了对所有服务性能的可视化能⼒并让您看到它如何影响其他进程。Istio 的 Mixer 组件负责策略控制和遥测数据收集。它提供了后端抽象和中介将⼀部分 Istio 与后端的基础设施实现细节隔离开来并为运维⼈员提供了对⽹格与后端基础实施之间交互的细粒度控制。 所有这些特性都使您能够更有效地设置、监控和加强服务的 SLO。当然底线是您可以快速有效地检测到并修复出现的问题 5.3 Istio支持平台
Istio 独⽴于平台被设计为可以在各种环境中运⾏包括跨云、内部环境、Kubernetes、Mesos 等等。可以在 Kubernetes 或是装有 Consul 的 Nomad 环境上部署 IstioIstio目前支持 Kubernetes 上部署 基于 Consul 的服务注册 独立虚拟机部署 5.4 Envoy介绍 5.4.1 Envoy简介
Envoy是Istio中的核心控件Envoy 本质上是一个为面向服务的架构而设计的 7 层代理和通信总线。Envoy 基于 C 11 开发而成性能出色、网络控制能力强大、监控能力良好。 Envoy 是专为大型现代 SOA面向服务架构架构设计的 L7 代理和通信总线它既可以作为 Service Mesh 中的数据面使用也可以作为入口网关层使用可以通过 xDS API 控制 Envoy 的监听、路由、负载均衡等行为。 Istio 的流量管理是通过 Pilot 和 Envoy 这两个组件实现的将流量和基础设施进行了解耦。
Pilot 位于控制层负责配置规则并把规则分发到 Envoy 代理去实施Envoy位于数据层按照规则执行各种流量管理的功能比如动态请求路由超时、重试和熔断还可以通过故障注入来测试服务之间的容错能力 5.4.2 核心功能 高性能 采用 C 编写拥有良好的四层、七层代理性能在 8 核的机器上HTTP 代理可以达到 10w 的 QPSgRPC 可以达到 15w QPS完全满足了 Service Mesh 中 Sidecar 的应用场景。 多种协议支持 不仅支持 HTTP 和 HTTP/2随着社区的发展Thrift、gRPC、MongoDB、Redis、MySQL 等多种网络协议都被支持甚至可以使用 Envoy 做 Redis 的 Mesh 方案用来代替流行的 Redis 中间件。 良好的 HTTP/2 支持 随着 gRPC 框架的流行以及边缘层网络性能的要求提升HTTP/2 越来越被重视。Envoy 原生支持 HTTP/2可以在 HTTP 和 HTTP/2 之间做转换。比如在 Sidecar 模式中无论应用协议是 HTTP 还是 HTTP/2Envoy 之间默认使用 HTTP/2 通信这样极大提升了服务性能和稳定性避免了 HTTP 频繁建立连接带来的消耗和不稳定性。 边缘网关 Envoy 本身就是一个高性能的网络代理组件完全可以作为入口网关层使用在 Kubernetes 中也可以作为 Egress 和 Ingress 使用。 服务发现 和其他常见的网络代理软件不同Envoy 默认支持服务发现组件。Envoy 使用了一套xDS 的动态 API获取服务的后端节点并实时更新结合 Envoy 强大的负载均衡器可以做到最终一致性。 Filter 架构 可以在四、七层编写 Filter 以扩展 Envoy 的功能比如监听过滤器、四层网络过滤器以及七层过滤器。不过 Envoy 支持最完善的还是HTTP 过滤器支持了限流、路由转发、故障注入等多种服务治理功能 可观测性 支持强大的统计系统。日志、Metrics、链路追踪都有良好的支持。 Wasm 扩展 Envoy 在最近的 1.17 版本增加了对 Wasm 的支持。Wasm 全称为 WebAssembly最早用在浏览器端用来解决 JavaScript 性能问题和大型项目团队协作问题。近些年它开始在一些后端技术上使用用来代替 Lua作为核心系统的扩展方式。因为 Wasm 可以使用多种语言进行开发所以方便对核心系统进行扩展不用担心语言问题。当然相对于原生的 C 扩展方式它大概有 3 成的性能损耗。 5.5 Envoy架构设计
下图是 Envoy 架构的设计图从这张图我们可以看到入流量经过 Iptables 劫持被转发到了 Envoy 的端口Envoy 通过监听端口创建连接提供七层代理服务。下面具体来看看每部分内容都做了什么工作。 Iptable 通过 Iptable 劫持将入口和出口流量都转发到 Envoy 上达到劫持流量的目的。 Listener Envoy 通过建立多个监听器提供不同的服务。比如通过监听的两个端口分别负责 Sidecar 模式的出流量和入流量Sidecar 多使用这种设计这样可以简化编程逻辑也可以增强 Filter 的通用性。如果提供不同协议Envoy 也会建立不同的端口来提供服务。 Worker 每个 Listener 维护一个对应的 Worker PoolEnvoy 为每个逻辑处理器创建一个 Worker 线程当我们在一个新的端口启动一个新的 server 时Envoy 也会根据 -concurrency 创建对应的 Worker 线程要注意启动太多的 worker 线程并不一定是好事特别是在 Sidecar 模式我们并不会分配过多的逻辑核心给到 Sidecar创建过多的 Worker 线程可能导致每个 Worker 线程维护的连接变多Upstream 压力过大。 Filters 可以理解为中间件通过 Filter可以做到四层和七层的流量过滤支持服务治理需要的限流、熔断等功能。 Cluster Manager 流量经过 Router识别出需要转发的 Cluster通过 Cluster Manager 进行服务发现和负载均衡等功能。 Upstream Upstream 维护了 EndPoint 的连接池通过负载具衡器将流量转发到合适的 EndPoint 上面。 聊完了 Envoy 的架构我们一起看一下 Envoy 作为 Service Mesh 中的数据面也就是 Sidecar 模式下整个数据流转过程。 如上图所示Envoy 作为 Sidecar 使用时需要和服务部署在同一台机器或者 Pod 中用户访问其他服务时流量会被自动劫持到 Envoy 中。 结合上图主要的流程如下
通过 Iptables 对流量进行劫持将 Productpage 访问 Reviews 的流量转发到 Envoy 的出流量 15001 端口上。Envoy 先根据 virtual_hosts 进行匹配再通过路由匹配发现路由对应的 Cluster通过服务发现找到 Cluster 对应的 EndPoint将流量转发到 10.40.0.15:9080 的 Pod 上。Reviews 的 Pod 通过 Iptables 对流量进行劫持将流量劫持到 Envoy 的入流量端口 15006 上。Envoy 将本地流量转发到对应的本地地址 127.0.0.1:9080这里不需要对流量进行识别因为流量被转发到入流量端口 15006 上这个端口的配置用于本地流量的转发。 到这里整个 Sidecar 的流量出入过程就结束了。出入流量都经由 Envoy最终被正确的转发到了 Reviews 的 Pod 上面。 5.5 Envoy的边缘代理模式
Envoy 不仅可以用于 Sidecar 模式也可以用作边缘网关但是用作边缘网关层我们有一些注意事项这些问题不仅在 Envoy 中存在在其他的边缘网关中也应该处理。 5.5.1 HTTP 标头清理
一些外部传入的 header 可能会影响内部行为应该统一做出清理操作比如我们经常会用到的 x-forward-for在反向代理中未经过一层代理都应该将代理的 IP 追加在 x-forward-for 中以保证通过 x-forward-for 可以获取最原始的 IP如果有客户端恶意传输 x-forward-for不做清除操作可能会导致拿到错误的客户端 IP。在 Envoy 中可以通过 use_remote_address 设置为 true 来清理 HTTP 标头。 5.5.2 超时控制
超时控制分为连接超时、流超时和路由超时。这些超时控制不仅在边缘网关模式中需要注意在 Sidecar 模式也需要注意一些不合理的超时可能会引起服务的雪崩。虽然在内网服务调用时一般都会设置默认超时但 Sidecar 应该设置一个默认的超时时间避免服务没有设置有效超时的情况引起的问题。
连接超时 Envoy 为 HTTP 服务提供了空闲连接超时时间的设置空闲超时是指一个连接在接收到请求后会设置 TCP 的 idle Timeout 的参数一段时间内没有收到代理服务的响应请求则会断开连接。Envoy 默认的空闲超时是 1 小时。连接超时对所有流生效连接一旦断开所有流处理也会中断。 流超时 流是 HTTP/2 中的概念在 HTTP/1 中没有流的概念Envoy 通过将 HTTP 连接对应到流模式统一进行处理。HTTP 连接管理器 stream_idle_timeout 默认超时时间为 5 分钟推荐对所有流设置合理的超时时间这个时间就是接收请求到返回数据的处理时间如果没有特殊需求建议设置为 10s默认超时时间偏长。如果触发此超时时间则会出发 504 Gateway Timeout 的错误码。 路由超时 除了设置全局的流超时外还可以设置路由层面的超时为某些请求设置特殊的配置一些请求可能需要更快的响应速度所以要设置较短的超时时间这个时候只要在路由层面设置即可比如针对某些 Path 设置更短的超时时间。 5.5.3 连接限制
Envoy 可以针对全局或者监听器设置连接限制。一般单一服务器可承载的并发连接数有限根据线上的峰值连接运行情况设置合理的连接设置可以避免因服务出问题时响应过慢大量新建 HTTP 连接击垮 Envoy 的情况。 5.5.4 Envoy使用场景
Envoy使用场景主要有两类
作为 Service Mesh 数据面组件选型目前在 Istio 等多种服务网格框架落地作为流量入口代理目前较多的是以 API 网关形式实现如 Gloo、Ambassador 等 Envoy 不仅可以作为 Service Mesh 中的 Sidecar 使用也可以作为边缘网关使用它的本质就是一个反向代理服务器Nginx、HAProxy 能做的事情 Envoy 也可以做得很好。 六、写在文末
随着容器化技术的逐渐成熟与大规模应用加之有众多的成熟的开源组件生态的巩固服务网格作为下一代微服务的趋势从目前行业的布局和实践经验来看一定会在不久的未来成为一个新的微服务形态的制高点因此有必要对其做提前的了解和学习本篇到此结束感谢观看。
