阿里云专家详解 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 对应用程序层起支持做用并位于较低级别的部署层之上。<br />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 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”