阿里云专家详解 2020 服务网格发展趋势

作者 | 王夕宁  阿里巴巴高级技术专家

关注“阿里巴巴云原生”公众号，参与文末留言互动，即有机会获得赠书福利！

本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书，文章从基础概念入手，介绍了什么是服务网格及 Istio，针对 2020 服务网格的三大发展趋势，体系化、全方位地介绍了 Istio 服务网格的相关知识。你只需开心参与公众号文末互动，我们负责买单！技术人必备书籍《Istio 服务网格技术解析与实践》免费领~

有外文指出，2020 年 Service Mesh 技术将有以下三大发展：

• 快速增长的服务网格需求；
• Istio
  很难被打败，很可能成为服务网格技术的事实标准；
• 出现更多的服务网格用例，WebAssembly 将带来新的可能。

什么是服务网格

Gartner 2018 关于服务网格技术趋势分析报告，展示了一系列的服务网格技术，划分服务网格技术的依据是基于应用服务代码是否必须对其服务网格感知及其是否锁定，或锁定的程度。

基于编程框架的网格技术可以帮助开发人员构建一个架构体系良好的服务，但这会导致应用代码与框架和运行时环境的紧密耦合。而基于 Sidecar 代理的服务网格技术不会为开发人员设置这些障碍，并且使其管理和维护更加轻松，能够提供更灵活的方法来配置运行时策略。

在微服务环境中，可将单一应用程序分解为独立的多个组件，并作为分布式服务进行部署，这些服务通常是无状态的、短暂的、动态可扩展的，运行在容器编排系统（如 Kubernetes）中。

服务网格一般由控制平面和数据平面组成。具体来说，控制平面是一组在一个专用的命名空间中运行的服务。这些服务完成一些控制管理的功能，包括聚合遥测数据、提供面向用户的 API、向数据平面代理提供控制数据等。而数据平面则是由一系列运行在每个服务实例旁边的透明代理构成。这些代理自动处理进出服务的所有流量，因为它们是透明的，所以这些代理充当了一个进程外网络堆栈，向控制平面发送遥测数据并从控制平面接收控制信号。

服务实例可以根据需要进行启动、停止、销毁、重建或替换。因此，这些服务需要一个通信中间件来支持服务的动态发现和自我修复连接能力，从而使得这些服务之间能够以安全、动态和可靠的方式相互通信，这就是服务网格所支持的功能。

服务网格是一个专用的基础设施层，使服务到服务之间的通信更加安全、快速、可靠。如果你正在构建云原生应用程序，则需要服务网格。在过去的一年中，服务网格已成为云原生程序的关键组件，它通过包含现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，服务网格通常实现为轻量级网络代理的组合，这些代理与应用程序代码一起部署，不需要知道应用程序是什么。

服务网格作为单独层的概念与云原生应用程序的兴起有关。在云原生模型中，单个应用程序可能包含数百个服务，每个服务可能有数千个实例，并且每个实例可能处于不断变化的状态。这也是为什么像 Kubernetes 这样的协调器日益流行和必要的原因所在。这些服务之间的通信不仅变得越来越复杂，而且也是运行时环境中最为常见的一部分，因此管理这些服务之间的通信对于确保端到端的性能和可靠性至关重要。

服务网格是一种网络模型，位于 TCP/IP 之上的抽象层。它假定底层的三四层网络存在并且能够从一点到另一点传送字节。它还假设该网络与环境的其他方面一样不可靠，因此服务网络也必须能够处理网络故障。在某些方面，服务网格类似于 TCP/IP。正如 TCP 协议栈抽象了在网络端点之间可靠地传递字节的机制一样，服务网格抽象了在服务之间可靠地传递请求的机制。与 TCP 一样，服务网格不关心实际有效负载或其编码方式，只负责完成从服务 A 发送到服务B，并且在处理任何故障的同时实现这一目标。但是，与 TCP 不同的是，服务网格不仅仅具备“使其工作”的能力，还提供了一个统一的应用程序控制点，用于将可见性和控制引入应用程序运行时。服务网格的明确目标是将服务通信从不可见的基础设施领域移出，并转变为生态系统的一部分，可以对其进行监控、管理和控制。

在云原生应用程序中，保证请求具备完整的可靠性并非易事。服务网络通过各种强大的技术来管理这种复杂性，支持熔断、延迟感知的负载均衡、最终一致性的服务发现、重试与超时等机制来尽可能保证可靠性。这些功能必须全部协同工作，并且与其运行的复杂环境之间的相互作用也非常重要。

例如，当通过一个服务网格向服务发出请求时，其交互过程可以大致简化为如下步骤：

• 服务网格组件通过应用动态路由规则来确定请求者想要的服务。请求应该路由到生产还是预发布的服务？是路由到本地数据中心还是云中的服务？是需要灰度到正在测试的服务的最新版本，还是仍然路由到在生产中经过验证的旧版本？所有这些路由规则都是动态可配置的，并且可以全局应用，也可以应用于任意流量片段；

• 找到正确的目的地后，服务网格组件从相关的服务发现端点检索相应的实例池，可能有多个实例。如果这些信息与服务网格组件在实践中观察到的信息不同，那么它会决定要信任哪些信息来源；

• 服务网格组件根据各种因素选择最有可能返回快速响应的实例，包括观察到的最近请求的延迟数据；

• 服务网格组件尝试将请求发送到选择的实例，记录响应结果的延迟和响应类型；

• 如果实例已经由于各种原因宕机，或者请求根本没有响应，或者由于其他任何原因而无法处理请求，服务网格组件则会根据需要在另一个实例上重试该请求，前提是它知道请求是幂等的；

• 如果实例始终返回错误，服务网格组件会将其从负载均衡池中逐出，以便稍后定期重试。这种情况在互联网分布式应用中非常常见，公共网络中的实例非常有可能由于某些原因导致瞬间故障；

• 如果请求的超时点已过，服务网格组件则会主动使请求失败，而不是通过进一步重试来添加负载，以防雪崩发生。这一点对于互联网分布式应用至关重要，否则一个小故障极有可能会引起雪崩式灾难；

• 与此同时，服务网格组件以度量指标和分布式跟踪的形式捕获上述行为的各个方面，并将这些数据发送到集中式的度量系统或者链路跟踪系统。

值得注意的是，这些功能都是在为分布式应用提供逐点弹性和应用程序范围的弹性能力。大规模分布式系统（无论如何构建）都有一个明确的特征：任何小型本地化故障都有可能升级为系统范围的灾难性故障。服务网格必须设计成在基础系统接近其极限时通过减少负载和快速失败来防止这些故障升级。

为什么服务网格是必要的

服务网格本身并不是一个新功能，更像是功能所在位置的转变。Web 应用程序始终必须管理服务通信的复杂性。在过去的十五年中，服务网格模型的起源可以追溯到这些应用程序的演变过程。

在本世纪初，中型 Web 应用程序的典型架构常见的是三层应用程序架构，分为应用程序逻辑层、Web 服务逻辑层和存储逻辑层，都是单独的层。层之间的通信虽然复杂，但范围有限。这个时候的应用架构并没有网格，但是在每个层的代码处理逻辑之间存在通信逻辑。

当网络发展到非常高规模时，这种架构方法开始变得捉襟见肘。特别是一些大型互联网公司，都面临着巨大的流量需求，实现了有效的云原生方法的前身：应用层被分成许多服务，也就是现在通常所知的“微服务”，层之间形成拓扑的通信方式。在这些系统中，通常采用“胖客户端”库的形式，也就是前面讲述过的类似于 Netflix 的 OSS 库，Hystrix 的熔断能力就是很好的例证。这些代码库虽然与特定的环境相关，并且需要使用特定的语言和框架，但它们是用于管理服务之间通信的形式与能力，在当时的情况下是不错的选择，而且也在众多公司里被使用。

进入云原生时代之后，云原生模型有两个重要因素：

• 容器（例如 Docker）提供资源隔离和依赖管理；
• 编排层（例如 Kubernetes）将底层硬件抽象为同质的资源池。

尽管这些代码库组件在一定程度上允许应用程序具备一定的负载扩展能力，并处理云环境中始终存在的部分故障，但是，随着数百个服务或数千个实例的增加，以及存在不时重新调度实例的业务流程层，单个请求通过服务拓扑所遵循的路径可能非常复杂。同时随着容器技术的普及，且容器使每个服务都易于用另一种语言编写运行，程序库式方法在此时此刻就变得捉襟见肘了。

这种复杂性和关键性的诉求，使得应用越来越需要一个服务间通信的专用层，该专用层与应用程序代码分离并且能够捕获底层环境的高度动态弹性能力。该层就是我们需要的服务网格。

服务代理可以帮助我们在云环境服务架构中添加重要功能。每个应用程序都可以拥有自己的要求或配置，以了解代理在给定其工作负载目标时的行为方式。随着应用程序和服务越来越多，配置和管理大量代理可能非常困难。此外，在每个应用程序实例中使用这些代理可以为构建丰富的高级功能提供机会，否则我们将不得不在应用程序本身执行这些功能。

服务代理形成一个网状的数据平面，通过该数据平面处理和观察所有服务间的流量。数据平面负责建立、保护和控制通过网格的流量。负责数据平面如何执行的管理组件称为控制平面。控制平面是网格的大脑，并为网格使用人员提供公开 API，以便操纵网络行为。

Istio 服务网格

Istio 是一个用于连接/管理以及安全化微服务的开放平台，提供了一种简单的方式用于创建微服务网格，并提供负载均衡、服务间认证以及监控等能力，关键的一点是并不需要修改太多服务就可以实现上述功能。Istio 本身是一个开源项目，它提供了一致的方式用于连接、加固、管理和监控微服务，最初是由 Google、IBM 和 Lyft 创建的服务网络的开源实现。Istio 可以帮助你以透明的方式为服务架构添加弹性和可观察性能力。使用 Istio，应用程序不必知道它们是服务网格的一部分。每当应用程序与外界交互时，Istio 将代表应用程序处理网络流量。这意味着如果你正在做微服务，Istio 可以带来很多好处。

Istio 主要提供以下功能：

• 流量管理，控制服务之间调用的流量和API调用，使得调用更可靠，并使网络在恶劣情况下更加健壮；
• 可观测性，获取服务之间的依赖，以及服务调用的流量走向，从而提供快速识别问题的能力；
• 策略执行，控制服务的访问策略，不需要改动服务本身。

服务身份和安全，为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。

Istio 第一个生产可用版本 1.0 于 2018 年 7 月 31 日正式发布，并于 2019 年 3 月发布版本 1.1。之后，社区按照快速迭代的方式，在三个月内接连发布了 10 个小版本。截至本书完稿之际，社区已经发布了 1.4 版本。

Istio 的数据平面默认使用 Envoy 代理，开箱即用，可帮助你配置应用程序以在其旁边部署服务代理的实例。Istio 的控制平面由一些组件组成，这些组件为最终用户和运维人员提供运维 API、代理的配置 API、安全设置、策略声明以及其他更多功能。我们将在本书的后续部分介绍这些控制平面组件。

Istio 最初是为在 Kubernetes 上运行而构建的，但却是从部署平台中立的角度实现代码的。这意味着你可以在 Kubernetes、OpenShift、Mesos 和 Cloud Foundry 等部署平台上利用基于 Istio 的服务网格，甚至可以在虚拟机、物理裸机上部署 Istio 环境。在后面的章节中，我们将展示 Istio 对于包括私有数据中心在内的云组合的混合部署来说有多强大。在本书中，我们将优先考虑在 Kubernetes 上进行部署，在后面更高级的章节中会引入虚拟机等环节。

Istio 在希腊语中的意思是“启航”，而 Kubernetes 在希腊语中可以翻译为“舵手”或“驾驶员”。所以从一开始 Istio 就期望与 Kubernetes 很好地配合，高效地运行分布式微服务架构，并提供安全、连接和监控微服务的统一方法。

通过每个应用程序实例旁边的服务代理，应用程序不再需要具有特定于语言的弹性库来实现熔断、超时、重试、服务发现、负载均衡等功能。此外，服务代理还处理度量标准收集、分布式跟踪和日志收集等。

由于服务网格中的流量流经 Istio 服务代理，因此 Istio 在每个应用程序中都有控制点来影响和指导其网络行为。这允许服务运维人员可以控制路由流量，并通过金丝雀部署、暗启动（Dark Launch）、分级滚动和 A/B 测试来实现细粒度部署。我们将在后面的章节中探讨这些功能。

核心功能

Istio 在服务网络中统一提供了许多关键功能，主要包括流量管理、安全、可观测性、平台支持、集成和定制五个部分。

1.流量管理

通过简单的规则配置和流量路由，Istio 可以控制服务之间的流量和 API 调用。Istio 简化了熔断器、超时和重试等服务级别属性的配置，并且可以轻松设置 A/B 测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。

Istio 有开箱即用的故障恢复功能，你可以在问题出现之前先发现问题，通过优化使服务之间的调用更加可靠。

2.安全

Istio 具备强大的安全功能，使开发人员可以专注于应用程序级别的安全性。Istio 提供底层安全通信信道，并大规模管理服务通信的认证、授权和加密。使用 Istio，服务通信在默认情况下是安全的，允许跨多种协议和运行时一致地实施策略，而关键的是所有这些都很少或根本不需要应用程序更改。

虽然 Istio 与平台无关，但将其与 Kubernetes 网络策略一起使用时，其优势更大，包括在网络和应用层保护 pod-to-pod 或服务到服务通信的能力。后续章节中会讲述如何在 Kubernetes 中结合网络策略与 Istio 来共同保护服务。

3.可观测性

Istio 具备强大的追踪、监控和日志记录能力，可让你深入了解服务网格部署。通过 Istio 的监控功能，可以真正了解服务性能如何影响上游和下游的功能，而其自定义的仪表板可以提供对所有服务性能的可视性，并让你了解该性能如何影响其他进程。

Istio 的 Mixer 组件负责策略控制和遥测收集，提供后端抽象和中介，将 Istio 的其余部分与各个后端基础设施的实现细节隔离开来，并为运维人员提供对网格和后端基础设施之间所有交互的细粒度控制。

所有这些功能可以让你更有效地设置、监控和实施服务上的服务等级目标 SLO。当然，最重要的是可以快速有效地检测和修复问题。

4.平台支持

Istio 是独立于平台的，目标是可以在各种环境中运行，包括跨云、内部部署、Kubernetes、Mesos 等。你可以在 Kubernetes 上部署 Istio 或在具有 Consul 的 Nomad 上部署。Istio 目前支持：

• 在 Kubernetes 上部署的服务；
• 使用 Consul 注册的服务；
• 在各个虚拟机上运行的服务。

5.集成和定制

可以扩展和自定义 Istio 的策略实施组件，以与现有的 ACL、日志记录、监控、配额、审计等解决方案集成。

此外，从版本 1.0 开始，Istio 支持基于 MCP（Mesh Conf?iguration Protocol，网格配置协议）进行配置分发。通过使用 MCP，可以很容易地集成外部系统，例如可以自己实现 MCP 服务器，然后将其集成到 Istio 中。MCP 服务器可以提供以下两个主要功能：

• 连接并监控外部服务注册系统，以获取最新的服务信息（例如 Eureka、ZooKeeper 等系统）；
• 将外部服务信息转换为 Istio
  ServiceEntry 并通过 MCP 资源发布。

为什么要使用 Istio

在从单体应用程序向分布式微服务架构的转型过程中，开发人员和运维人员面临诸多挑战，使用 Istio 可以解决这些问题。随着规模和复杂性的增长，服务网格越来越难以理解和管理，各种需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及更加复杂的运维，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。Istio 提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。

Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，只需要对服务的代码进行一点改动或不需要做任何改动。想要让服务支持 Istio，只需要在你的环境中部署一个特殊的 Sidecar 代理，使用 Istio 控制平面来配置和管理代理，拦截微服务之间的所有网络通信。

此外，面向服务的架构（SOA）的企业服务总线（ESB）与服务网格有一些相似之处，在 SOA 体系架构中 ESB 对于应用程序服务来说是透明的，这意味着应用程序对它无感知。服务网格可以得到类似的行为，服务网格应该对应用程序透明，就像 ESB 那样，简化服务间的调用。当然，ESB 还包括交互协议的中转、消息转换，或者基于内容的路由之类的事情，而服务网格不负责 ESB 所做的所有功能。服务网格确实通过重试、超时、熔断提供服务请求的弹性能力，同时也提供服务发现和负载均衡等服务。复杂的业务转换、业务流程编排、业务流程异常，以及服务编排能力等并不属于服务网格的解决范畴。相对于 ESB 的集中式系统，服务网格中的数据平面高度分布，其代理与应用程序并存，这消除了 ESB 架构中经常出现的单点故障瓶颈问题。

当然，也需要清楚服务网格没有解决哪些问题，像 Istio 这样的服务网格技术通常都提供了强大的基础架构功能，可以触及分布式架构的许多领域，但肯定不能解决你可能遇到的每个问题。理想的云架构能从实现的每个层中分离出不同的关注点。

在基础架构的低层，更加关注基础设施，如何提供自动化部署的基础架构能力。这有助于将代码部署到各种平台上，无论是容器、Kubernetes，还是虚拟机等。Istio 不会限定你应该使用哪种自动化部署工具。

在更高的业务应用级别，应用程序业务逻辑是企业保持核心竞争力的差异化资产。这些代码资产涉及了包括业务功能单一以及需要调用的服务，以何种顺序执行，如何执行这些服务的交互，如何将它们聚合在一起，以及在发生故障时要执行的操作等。Istio 不实现或替换任何业务逻辑，它本身不执行服务编排，也不会提供业务负载的内容转换或者增强，不会针对负载进行拆分或者聚合。这些功能最好留给应用程序中的库和框架来实现。

下图是关于云原生应用程序中的关注点分离，其中 Istio 对应用程序层起支持作用并位于较低级别的部署层之上。
Istio 扮演着部署平台和应用程序代码之间的连接角色。它的作用是促进从应用程序中取出复杂的网络逻辑，可以基于作为请求的一部分的外部元数据（例如 HTTP 标头等）来执行基于内容的路由。也可以根据服务和请求的元数据匹配进行细粒度的流量控制和路由。还可以保护传输和卸载安全令牌验证，或者可以实施服务运维人员定义的配额和使用策略等。

了解 Istio 的能力，与其他系统的相似之处以及它在架构中的位置，可帮助我们像我们过去可能遇到的有前途的技术那样犯同样的错误至关重要。

成熟度和支持级别

Istio 社区针对每个组件功能的相对成熟度和支持级别，提出了不同的功能阶段定义，分别用 Alpha、Beta 和 Stable 来描述各自的状态，如表 1-1 所示。

表 1-2 是我们摘录的 Istio 1.4 版本现有功能中已经达到 Beta 及 Stable 功能阶段的列表。此信息将在每次发布后更新，可参照官方网站获取更新状态。

当然，Istio 仍然有一些功能还处于 Alpha 状态，如 Istio CNI 插件，它能够代替 istio-init 容器完成同样的网络功能，而且无需 Istio 用户额外申请 Kubernetes RBAC 授权；以及在 Envoy 中使用自定义过滤器的能力等等。相信在后续不断完善中，这些功能将逐渐变得越来越稳定且生产可用。

总结

Istio 作为当前业界服务网格领域中最流行的实现，其功能允许你在混合环境中简化云原生服务架构应用的运行和操作。Istio 使开发者专注于使用自己喜欢的编程语言构建服务功能，这有效地提升了开发者的生产力，同时开发者免于将解决分布式系统问题的代码糅合到业务代码中。

Istio 是一个完全开放的开发项目，拥有一个充满活力、开放和多元化的社区，它的目标是赋能开发者和运维人员，使他们在所有环境中都能敏捷地发布和维护微服务，拥有底层网络的完全的可见性，且获得一致的控制和安全能力。在本书的后续部分，我们将展示如何利用 Istio 的功能在云原生世界中运行微服务。

本文摘自于《Istio 服务网格解析与实战》，经出版方授权发布。本书由阿里云高级技术专家王夕宁撰写，详细介绍 Istio 的基本原理与开发实战，包含大量精选案例和参考代码可以下载，可快速入门 Istio 开发。Gartner 认为，2020 年服务网格将成为所有领先的容器管理系统的标配技术。本书适合所有对微服务和云原生感兴趣的读者，推荐大家对本书进行深入的阅读。

推荐阅读：

【1】阿里云服务网格ASM公测来袭系列之一：快速了解什么是ASM

文章链接：https://yq.aliyun.com/articles/748761

【2】阿里云服务网格ASM之扩展能力(1)：在ASM中通过EnvoyFilter添加HTTP请求头

文章链接：https://yq.aliyun.com/articles/748807

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”