本文作者:何文强 — CODING 高级解决方案架构师 具有一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经历,历任 Java 开发高级工程师、DevOps 技术专家、高级研发经理等职,对微服务、敏捷、DevOps、容器技术有深刻的理解和丰富的实践。
2013 年容器技术 Docker 开源,2014 年容器编排工具 Kubernetes 开源。2015 年,云原生计算基金会(CNCF)成立,标志着应用进入云原生时代, 2016 年 9 月 14 日,Envoy 的开源标志着应用技术架构进入到服务网格(Service Mesh)时代,2017 年 5 月 24 日,Google、IBM、Lyft 共同宣布 Istio 开源标志着进入由控制面和数据面组成的服务网格成为主流。Istio 是当前最受欢迎的服务网格技术。
在微服务时代,就出现代理组件(Sidecar)承担部分 NFR 和中间件依赖的能力,例如 Netflix 的 Prana、唯品会的 OSP local proxy。
2016 年 1 月 15 日,Buoyant 初次发布 Linkerd,2016 年 9 月,Service Mesh 在 Buoyant 的一次关于微服务的分享会上提出,Linkerd 成为第一代 Service Mesh 产品;同在 2016 年 9 月,网格服务代理 Envoy 1.0 发布。
2017 年 5 月,Google、IBM、Lyft 宣布新一代服务网格(Service Mesh)Istio 开源,自带光环和身披重大使命的 Istio 得到极大关注和发展,迅速成为 Service Mesh 的主流框架。
2018 年,Istio 1.0 的发布,标志着 Istio 进去成熟的发展阶段,可在生产环境中使用。
ServiceMesh 架构
Linkerd:背后公司是 Buoyant,开发语⾔使用 Scala,2016 年 1 ⽉ 15 日初次发布,2017 年 1 ⽉ 23 日加入 CNCF,2018 年 5 ⽉ 1 ⽇发布 1.4.0 版本。
Envoy:背后公司是 Lyft,开发语言使用 C++ 11,2016 年 9 月 13 日初次发布,2017 年 9 ⽉ 14 日加⼊ CNCF,2018 年 3 月 21 日发布 1.6.0 版本。
Istio:背后公司是 Google 和 IBM,开发语言使用 Go,2017 年 5 月 10 日初次发布,2018 年 3 ⽉ 31 日发布 0.7.1 版本。
Conduit:背后公司也是 Buoyant,开发语言使用 Rust 和 Go,2017 年 12 月 5 日初次发布,2018 年 4 ⽉ 27 日发布 0.4.1 版本。
Linkerd 的核心组件就是一个服务代理,因此只要理清它的请求处理流程,就掌握了它的核心逻辑:
动态路由:根据上游服务请求参数,确定下游目标服务;除了常规的服务路由策略,Linkerd 还可以通过这一层动态路由能力,支持灰度发布、A/B 测试、环境隔离等非常有价值的场景。
服务发现:确定目标服务后,下一步就是获取对应的实例的地址列表(e.g. 查询service registry)。
负载均衡:如果列表中有多个地址,Linkerd 会通过负载均衡算法(e.g. Least Loaded、Peak EWMA)选择其中⼀个合适的低延迟实例。
执行请求:发送请求到上一步所选择的实例,并记录延迟和响应结果。
重试处理:如果请求未响应,则选择另⼀个实例重试(前提:Linkerd 知道该请求是幂等的)。
熔断处理:如果发往某个实例的请求经常失败,则主动从地址列表中剔除该实例。
超时处理:如果请求超期(在给定的 deadline 时间点之前仍未返回),则主动返回失败响应。
可观测性:Linkerd 会持续收集和上报上述各种行为数据,包括 Metrics 和 Tracing。
Envoy 是一个高性能的 Service Mesh 软件,主要包含如下特性:
高性能:基于本地代码(C++ 11)实现;相比之下,Linkerd 是基于 Scala 编写,性能延时较为突出。
可扩展:L4 和 L7 层代理功能均基于可插拔的 Filter Chain 机制(类比 netfilter、servlet filter)。
协议升级:支持双向、透明的 HTTP/1 to HTTP/2 代理能力。
其他能力:服务发现(符合最终一致性)、负载均衡(支持区域感知)、稳定性(重试、超时、熔断、限速、异常检测)、可观测性(统计/日志/追踪)、易于调试等。
Conduit 是由 Buoyant 公司出品的下一代 Service Mesh。作为 Istio 的挑战者,Conduit 的整体架构与 Istio 类似也明确区分了管控平面和数据平面,但同时它还具备如下关键特性:
轻量快速:Conduit 的数据平面是基于原生的 Rust 语言编写,非常轻量、快速和安全(Rust 相比 C/C++ 的最大改进点就是安全性)。单个代理的实际内存消耗(RSS)小于 10mb,延迟的 p99 分位点小于 1ms,基本相当于能为应用程序提供免费(无额外开销)的 Service Mesh 功能。
安全保障:Conduit 构建之初就考虑了云原生环境的安全性,包括 Rust 语言内存安全性、默认 TLS 加密等。
端到端可见性:Conduit 可以自动测量和聚合服务的成功率、延迟与请求容量数据,让开发者在无需变更应用代码就能获取到服务的完整行为视图。
Kubernetes 增强:Conduit 为 K8s 集群添加了可靠性、可见性和安全性,同时给予了开发者对自己应用程序运行时行为的完全控制。
Istio 是一个开源服务网格,它透明地分层到现有的分布式应用程序上。Istio 强大的特性提供了一种统一和更有效的方式来保护、连接和监视服务。Istio 是实现负载平衡、服务到服务身份验证和监视的路径——只需要很少或不需要更改服务代码。它强大的控制平面带来了重要的特点,包括:
Istio 服务网格从逻辑上分为数据平面和控制平面。
由一组智能代理(Envoy)组成,被部署为 Sidecar。这些代理负责协调和控制微服务之间的所有网络通信。它们还收集和报告所有网格流量的遥测数据。
Envoy
Istio 使用 Envoy 代理的扩展版本。Envoy 是用 C++ 开发的高性能代理,用于协调服务网格中所有服务的入站和出站流量。Envoy 代理是唯一与数据平面流量交互的 Istio 组件。
Envoy 代理被部署为服务的 Sidecar,在逻辑上为服务增加了 Envoy 的许多内置特性,例如:
这种 Sidecar 部署允许 Istio 可以执行策略决策,并提取丰富的遥测数据,接着将这些数据发送到监视系统以提供有关整个网格行为的信息。Sidecar 代理模型还允许向现有的部署添加 Istio 功能,而不需要重新设计架构或重写代码。
由 Envoy 代理启用的一些 Istio 的功能和任务包括:
管理并配置代理来进行流量路由。
Istiod
在 Istio 1.0 架构中,控制平面主要由 Pilot、Mixer、Citadel 组成。控制平面与 Kubernetes 强绑定,这三个组件都需要访问 Kubernetes 的 API Server,以获取服务的注册信息和配置信息,包括 K8s 原生资源和 Istio 自定义 CRD,造成代码的大量冗余及组件的测试困难。另外,在 1.0 架构中,Mixer 作为控制平面的一个组件,采用 In-Process Adapter(进程内适配器,即 Adapter 与 Mixer 在同一个进程内)的方式,所有的 Adapter 的实现都需要与 Mixer 进行直接绑定,当 Adapter 需要更新时,会更新整个 Mixer,给 Adapter 的升级和维护带来极大的不变。
在 Istio 1.1 架构中,首先解决的是 Mixer 耦合的问题。Istio 1.1 将 Mixer 作为独立的进程,采用 Out-Of-Process Adapter,实现 Adapter 与 Mixer 的彻底解耦。Mixer 只需要做好接口的规范和定义,由各个 Adapter 去实现,解决了 Adapter 与 Mixer 强耦合的问题。但是这也带来了一个性能问题,通过独立进程解耦后,Adapter 与 Mixer 的通信由 Istio 1.0 的进程内的本地方法调用变成了 Istio 1.1 中的远程过程调用,将原本性能不太好的 Istio 雪上加霜。
在 Istio 1.5 架构中,Istio 架构发生了重大变化,Istio 的控制平面以回归单体的形式进行了架构的重建,将控制平面的多个组件整合成一个单体结构 istiod。在 1.5 之前,Istio 的控制平面组件间(Pilot、Galley、Citadel)的通信都是进程间的通信(RPC),网络性能一直没有得到较好的解决,同时维护多个独立的控制平面的组件不利于 Istio 控制平面的部署和维护,istiod 有效降低了复杂度。同时 Istio 在 1.5 中废弃了诟病已久的 Mixer,将 Mixer 能力移到 Proxy(Envoy)中 HTTP 遥测默认基于 in-proxy Stats filter,在 Istio Sidecar(基于 Envoy)上完成所有的遥测能力,有效节省了服务器资源,提升了网络性能和通信效率。
作为 ServiceMesh 技术的主要框架,Istio 有着活跃的社区和广泛的参与者,目前 Istio 仍然处于快速发展阶段,架构和能力都以较高的速度在变化,写本文时 Istio 最新的版本是 1.12。
Istio 的流量路由规则可以让您轻松地控制服务之间的流量和 API 调用。Istio 简化了服务级别属性(如断路器、超时和重试)的配置,并使设置重要任务(如 A/B 测试、canary 部署和基于百分比的流量分割的分阶段部署)变得容易。它还提供了开箱即用的故障恢复特性,帮助您的应用程序更健壮地应对依赖服务或网络的故障。
Istio 为服务网格内的所有通信生成详细的遥测数据。这种遥测技术提供了服务行为的可观测性,使运营商能够排除故障、维护和优化其应用。更好的是,它不会给服务开发人员带来任何额外的负担。通过 Istio,操作人员可以全面了解被监视的服务如何与其他服务以及 Istio 组件本身交互。
微服务有特殊的安全需求,包括防止中间人攻击、灵活的访问控制、审计工具和相互的 TLS。Istio 包括一个全面的安全解决方案,使运营商能够解决所有这些问题。Istio提供了强大的身份、强大的策略、透明的 TLS 加密,以及验证、授权和审计(AAA)工具来保护您的服务和数据。
优势
不足
ServiceMesh 同时支持基于 VM 和 K8s 的服务运行环境(Istio1.9 smartDNS 已支持),在这两个环境下服务可以相互访问。
图片来源:
https://istio.io/latest/docs/examples/virtual-machines/
混合云和多云是目前企业上云的一个主流方向,Servicemesh 想要获得更大的发展前景和提升企业的接受程度,需要能够对混合云和多云进行友好的支持。
图片来源:
https://www.helloworld.net/p/8322781473
下图是 Google Traffic Director 给出的一个应用改造示例:从单体结构转为微服务架构,从私有云转为公有云加私有云的混合云模式。
Service Mesh 毫无疑问是实现上述转型并提供混合云和多云支持的一个非常理想的解决方案。
图片来源:
https://www.helloworld.net/p/8322781473
Service Mesh 技术和 Serverless 技术是工作在不同纬度的两个技术:
理论上 Service Mesh 技术和 Serverless 技术并没有冲突的地方,可以结合使用。事实上目前业界也开始出现这个趋势,而融合的方式有两种:
对于 Serverless 和 Service Mesh 的结合,我们展望未来形态:未来应该会出现一种新型服务模式,Serverless 和 Service Mesh 合二为一。只要将服务部署上来,就自动可以得到 Service Mesh 的服务间通讯能力和 Serverless 的无服务器运维。在蚂蚁金服,我们将这理解成为是未来云原生应用的终态之一,正在积极探索其落地的实际方式。
《数字化 IT 从业者知识体系》背景
数字化和可持续发展是中国企业未来发展的两大主题,掌握数字化知识,具备数字化能力,应用数字化技术是我们 IT 从业者未来核心竞争力所在。《数字化 IT 从业者知识体系》的初衷是为 IT 从业者提供的系统性的数字化知识体系,内容涵盖管理实践、工程实践、技术实践三个层次,涉及软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四大方面。
在接下来的《数字化 IT 从业者知识体系》系列文章,何文强将从软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四个方面,为大家进行逐一分享介绍:
1. 软件开发方法主要包括瀑布、敏捷、精益等;
2. 应用技术架构主要包括微服务架构、服务网格架构、无服务器架构、分布式多运行架构等;
3. 应用部署与管理主要包括但不限于虚拟化技术、容器技术与容器编排等;
4. 软件交付与协作主要包括但不限于 CMMI、ITIL、DevOps 等。
相信该知识体系有利于 IT 从业者构建丰富的技术体系、全面的技术视野和系统的能力建设。欢迎大家前往《数字化 IT 从业者知识体系》话题进行详细阅读。