数字化 IT 从业者知识体系 | 应用技术架构 —— 服务网格架构

2022-03-16 09:26:19 浏览数 (1)

本文作者：何文强 — CODING 高级解决方案架构师 具有一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经历，历任 Java 开发高级工程师、DevOps 技术专家、高级研发经理等职，对微服务、敏捷、DevOps、容器技术有深刻的理解和丰富的实践。

服务网格（Service Mesh）

2013 年容器技术 Docker 开源，2014 年容器编排工具 Kubernetes 开源。2015 年，云原生计算基金会（CNCF）成立，标志着应用进入云原生时代， 2016 年 9 月 14 日，Envoy 的开源标志着应用技术架构进入到服务网格（Service Mesh）时代，2017 年 5 月 24 日，Google、IBM、Lyft 共同宣布 Istio 开源标志着进入由控制面和数据面组成的服务网格成为主流。Istio 是当前最受欢迎的服务网格技术。

ServiceMesh 发展背景
侵入式微服务的挑战
  • 异构困难：不同语言的复用和集成困难；
  • 流量管理复杂：需要引入大量第三方工具进行流量管理，实现细粒度的流量控制困难；
  • 非功能性需求耦合度高：日志记录和追踪等非功能性需求与与业务代码耦合；
  • 缺乏弹性伸缩：对应用的弹性伸缩支持不足；
  • 安全性不足：对服务通信认证、授权和加密缺乏有力支持。
侵入式微服务的不足
  • 开发测试的复杂性：分布式系统的编程难度更大、测试更复杂；
  • 运维的复杂性：需要成熟的运维团队来管理和组织众多的微服务；
  • 分布式特性：cap理论制约，分布式数据库一致性等；
  • 影响性能：微服务采用rest/rpc等形式进行交互，通信的时延对导致性能不如本地调用。
ServiceMesh 发展历程

在微服务时代，就出现代理组件（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 架构

ServiceMesh 能力
ServiceMesh 应用
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 版本。

ServiceMesh 主要框架之 Linkerd

Linkerd 的核心组件就是一个服务代理，因此只要理清它的请求处理流程，就掌握了它的核心逻辑：

动态路由：根据上游服务请求参数，确定下游目标服务；除了常规的服务路由策略，Linkerd 还可以通过这一层动态路由能力，支持灰度发布、A/B 测试、环境隔离等非常有价值的场景。

服务发现：确定目标服务后，下一步就是获取对应的实例的地址列表（e.g. 查询service registry）。

负载均衡：如果列表中有多个地址，Linkerd 会通过负载均衡算法（e.g. Least Loaded、Peak EWMA）选择其中⼀个合适的低延迟实例。

执行请求：发送请求到上一步所选择的实例，并记录延迟和响应结果。

重试处理：如果请求未响应，则选择另⼀个实例重试（前提：Linkerd 知道该请求是幂等的）。

熔断处理：如果发往某个实例的请求经常失败，则主动从地址列表中剔除该实例。

超时处理：如果请求超期（在给定的 deadline 时间点之前仍未返回），则主动返回失败响应。

可观测性：Linkerd 会持续收集和上报上述各种行为数据，包括 Metrics 和 Tracing。

ServiceMesh 主要框架之 Envoy

Envoy 是一个高性能的 Service Mesh 软件，主要包含如下特性：

高性能：基于本地代码（C 11）实现；相比之下，Linkerd 是基于 Scala 编写，性能延时较为突出。

可扩展：L4 和 L7 层代理功能均基于可插拔的 Filter Chain 机制（类比 netfilter、servlet filter）。

协议升级：支持双向、透明的 HTTP/1 to HTTP/2 代理能力。

其他能力：服务发现（符合最终一致性）、负载均衡（支持区域感知）、稳定性（重试、超时、熔断、限速、异常检测）、可观测性（统计/日志/追踪）、易于调试等。

ServiceMesh 主要框架之 Conduit

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 集群添加了可靠性、可见性和安全性，同时给予了开发者对自己应用程序运行时行为的完全控制。

ServiceMesh 主要框架之 Istio

Istio 是一个开源服务网格，它透明地分层到现有的分布式应用程序上。Istio 强大的特性提供了一种统一和更有效的方式来保护、连接和监视服务。Istio 是实现负载平衡、服务到服务身份验证和监视的路径——只需要很少或不需要更改服务代码。它强大的控制平面带来了重要的特点，包括：

  • 使用 TLS 加密、强身份认证和授权的集群内服务到服务的安全通信；
  • 自动负载均衡的 HTTP，gRPC，WebSocket，和 TCP 流量；
  • 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制；
  • 一个可插入的策略层和配置 API，支持访问控制、速率限制和配额；
  • 对集群内的所有流量(包括集群入口和出口)进行自动度量、日志和跟踪。
Istio 架构简介

Istio 服务网格从逻辑上分为数据平面和控制平面。

数据平面

由一组智能代理（Envoy）组成，被部署为 Sidecar。这些代理负责协调和控制微服务之间的所有网络通信。它们还收集和报告所有网格流量的遥测数据。

Envoy

Istio 使用 Envoy 代理的扩展版本。Envoy 是用 C 开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。Envoy 代理是唯一与数据平面流量交互的 Istio 组件。

Envoy 代理被部署为服务的 Sidecar，在逻辑上为服务增加了 Envoy 的许多内置特性，例如：

  • 动态服务发现
  • 负载均衡
  • TLS 终端
  • HTTP/2 与 gRPC 代理
  • 熔断器
  • 健康检查
  • 基于百分比流量分割的分阶段发布
  • 故障注入
  • 丰富的指标

这种 Sidecar 部署允许 Istio 可以执行策略决策，并提取丰富的遥测数据，接着将这些数据发送到监视系统以提供有关整个网格行为的信息。Sidecar 代理模型还允许向现有的部署添加 Istio 功能，而不需要重新设计架构或重写代码。

由 Envoy 代理启用的一些 Istio 的功能和任务包括：

  • 流量控制功能：通过丰富的 HTTP、gRPC、WebSocket 和 TCP 流量路由规则来执行细粒度的流量控制。
  • 网络弹性特性：重试设置、故障转移、熔断器和故障注入。
  • 安全性和身份认证特性：执行安全性策略，并强制实行通过配置 API 定义的访问控制和速率限制。
  • 基于 WebAssembly 的可插拔扩展模型，允许通过自定义策略执行和生成网格流量的遥测。
控制平面

管理并配置代理来进行流量路由。

Istiod

  • Istiod 提供服务发现、配置和证书管理。
  • Istiod 将控制流量行为的高级路由规则转换为 Envoy 特定的配置，并在运行时将其传播给 Sidecar。Pilot 提取了特定平台的服务发现机制，并将其综合为一种标准格式，任何符合 Envoy API 的 Sidecar 都可以使用。
  • Istio 可以支持发现多种环境，如 Kubernetes 或 VM。
  • 可以使用 Istio 流量管理 API 让 Istiod 重新构造 Envoy 的配置，以便对服务网格中的流量进行更精细的控制。
  • Istiod 安全通过内置的身份和凭证管理，实现了强大的服务对服务和终端用户认证。您可以使用 Istio 来升级服务网格中未加密的流量。使用 Istio，运营商可以基于服务身份而不是相对不稳定的第 3 层或第 4 层网络标识符来执行策略。此外，您可以使用 Istio 的授权功能控制谁可以访问您的服务。
  • Istiod 充当证书授权（CA），并生成证书以允许在数据平面中进行安全的 mTLS 通信。
Istio 架构演进

在 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 能力
  • 流量管理

Istio 的流量路由规则可以让您轻松地控制服务之间的流量和 API 调用。Istio 简化了服务级别属性(如断路器、超时和重试)的配置，并使设置重要任务(如 A/B 测试、canary 部署和基于百分比的流量分割的分阶段部署)变得容易。它还提供了开箱即用的故障恢复特性，帮助您的应用程序更健壮地应对依赖服务或网络的故障。

  • 可观测性

Istio 为服务网格内的所有通信生成详细的遥测数据。这种遥测技术提供了服务行为的可观测性，使运营商能够排除故障、维护和优化其应用。更好的是，它不会给服务开发人员带来任何额外的负担。通过 Istio，操作人员可以全面了解被监视的服务如何与其他服务以及 Istio 组件本身交互。

  • 安全

微服务有特殊的安全需求，包括防止中间人攻击、灵活的访问控制、审计工具和相互的 TLS。Istio 包括一个全面的安全解决方案，使运营商能够解决所有这些问题。Istio提供了强大的身份、强大的策略、透明的 TLS 加密，以及验证、授权和审计（AAA）工具来保护您的服务和数据。

ServiceMesh 特点
  • NFR 能力进一步下沉；
  • 支持多语言异构系统；
  • 非侵入，独立 Sidecar 进程；
  • 丰富的服务治理能力；
  • 安全的通信机制。
ServiceMesh 优势和不足

优势

  • 屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑；
  • 真正的语言无关，服务可以用任何语言编写，只需和 Service Mesh 通信即可；
  • 对应用透明，Service Mesh 组件可以单独升级。

不足

  • Service Mesh 组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销；
  • Service Mesh 组件接管了网络流量，因此服务的整体稳定性依赖于 Service Mesh，同时额外引入的大量 Service Mesh 服务实例的运维和管理也是一个挑战；
  • Service Mesh 完成了和 NFR 的彻底解耦，但是与三方库，特别是中间能力的耦合依然严重。
ServiceMesh 发展趋势
VM 与容器混用
图片来源：
https://skyao.io/talk/201905-servicemesh-development-trend/

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 毫无疑问是实现上述转型并提供混合云和多云支持的一个非常理想的解决方案。

与 Serverless 结合

图片来源：

https://www.helloworld.net/p/8322781473

Service Mesh 技术和 Serverless 技术是工作在不同纬度的两个技术：

  • Service Mesh 技术的关注点在于服务间通讯，其目标是剥离客户端 SDK，为应用减负，提供的能力主要包括安全性、路由、策略执行、流量管理等。
  • Serverless 技术的关注点在于服务运维，目标是客户无需关注服务运维，提供服务实例的自动伸缩，以及按照实际使用付费。

理论上 Service Mesh 技术和 Serverless 技术并没有冲突的地方，可以结合使用。事实上目前业界也开始出现这个趋势，而融合的方式有两种：

  • 在 Serverless 中引入 Service Mesh：典型如 Knative 项目和 Knative 的 Google Cloud 托管版本 Google Cloud Run，通过引入对容器的支持和使用 Istio，Knative 将 Serverless 的支持扩展到 Function 之外，在极大的扩展 Serverless 适用范围的前提下，也将服务间通讯的能力引入到 Serverless。
  • 在 Service Mesh 中引入 Serverless：典型如 Google Traffic Director 产品，在提供 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 从业者知识体系》话题进行详细阅读。

serverless 服务网格 微服务

0 人点赞