火了 2 年的服务网格究竟给微服务带来了什么？

本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，做者罗广明，来自百度。

在过去几年中，微服务成为了业界技术热点，大量的互联网公司都在使用微服务架构，也有不少传统企业开始实践互联网技术转型，基本上也是以微服务和容器为核心。本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。

微服务架构概述

微服务架构可谓是当前软件开发领域的技术热点，在各类博客、社交媒体和会议演讲上的出镜率很是之高，不管是作基础架构仍是作业务系统的工程师，对微服务都至关关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。

尤为是近些年来，微服务架构逐渐发展成熟，从最初的星星之火到如今的大规模落地与实践，几乎已经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在作微服务架构的落地和推广。同时，也有不少传统企业基于微服务和容器，在作互联网技术转型。

而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为表明的微服务开发框架很是普及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的应用系统在享受其优点的同时，痛点也越加明显。这些痛点包括但不限于如下几点：

• 侵入性强。想要集成 SDK 的能力，除了须要添加相关依赖，每每还须要在业务代码中增长一部分的代码、或注解、或配置；业务代码与治理层代码界限不清晰。
• 升级成本高。每次升级都须要业务应用修改 SDK 版本，从新进行功能回归测试，而且对每一台机器进行部署上线，而这对于业务方来讲，与业务的快速迭代开发是有冲突的，大多不肯意停下来作这些与业务目标不太相关的事情。
• 版本碎片化严重。因为升级成本高，而中间件却不会中止向前发展的步伐，长此以往，就会致使线上不一样服务引用的 SDK 版本不统1、能力良莠不齐，形成很难统一治理。
• 中间件演变困难。因为版本碎片化严重，致使中间件向前演进的过程当中就须要在代码中兼容各类各样的老版本逻辑，带着 “枷锁” 前行，没法实现快速迭代。
• 内容多、门槛高。Spring Cloud 被称为微服务治理的全家桶，包含大大小小几十个组件，内容至关之多，每每须要几年时间去熟悉其中的关键组件。而要想使用 Spring Cloud 做为完整的治理框架，则须要深刻了解其中原理与实现，不然遇到问题仍是很难定位。
• 治理功能不全。不一样于 RPC 框架，Spring Cloud 做为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重受权机制、动态请求路由、故障注入、灰度发布等高级功能并无覆盖到。而这些功能每每是企业大规模落地不可获缺的功能，所以公司每每还须要投入其它人力进行相关功能的自研或者调研其它组件做为补充。

以上列出了传统微服务框架的局限性，但这并不意味着它们就一无可取了。在中小企业，采用 Spring Cloud 这样的传统微服务框架已经能够知足绝大部分服务治理的需求，而且借此快速推动微服务化改造。这些痛点每每是技术发展到必定的程度必然要经历的阶段，这些痛点促使技术不断发展、不断前进。

在众多热门技术趋势中，云原生的关注度居高不下，不少开发者都对由此兴起的一众技术十分追捧，众多企业又开始探索云原生架构的转型与落地。这一年，中国的开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。而 Service Mesh 技术也所以愈来愈火热，受到愈来愈多开发者的关注，并拥有了大批拥趸。那么 Service Mesh 是什么呢？它为何会受到开发者的关注？它和传统微服务应用有什么区别？

Service Mesh 定义

Service Mesh 一词最先由开发 Linkerd 的 Buoyant 公司提出，并于 2016 年 9 月29 日第一次公开使用了这一术语。William Morgan，Buoyant CEO，对 Service Mesh 这一律念定义以下：

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

翻译成中文以下：

Service Mesh 是一个专门处理服务通信的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一块儿的轻量级的网络代理，而且对应用服务透明。

以上这段话有四个关键点：

• 本质：基础设施层；
• 功能：请求分发；
• 部署形式：网络代理；
• 特色：透明；

2017 年，随着 Linkerd 的传入，Service Mesh 进入国内社区的视野，而且由国内的技术布道师们翻译成“服务网格”。

服务网格概述

服务网格从整体架构上来说比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理流程组成。代理在服务网格中被称为数据层或数据平面（data plane），管理流程被称为控制层或控制平面（control plane）。数据层截获不一样服务之间的调用并对其进行“处理”；控制层协调代理的行为，并为运维人员提供 API，用来操控和测量整个网络。

更进一步地说，服务网格是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务能够插入这个代理，从而使网络抽象化。在典型的服务网格中，这些代理做为一个 sidecar（边车）被注入到每一个服务部署中。服务不直接经过网络调用服务，而是调用它们本地的 sidecar 代理，而 sidecar 代理又表明服务管理请求，从而封装了服务间通讯的复杂性。相互链接的 sidecar 代理集实现了所谓的数据平面，这与用于配置代理和收集指标的服务网格组件（控制平面）造成对比。

总而言之，Service Mesh 的基础设施层主要分为两部分：控制平面与数据平面。当前流行的两款开源服务网格 Istio 和 Linkerd 实际上都是这种构造。

控制平面的特色：

• 不直接解析数据包。
• 与控制平面中的代理通讯，下发策略和配置。
• 负责网络行为的可视化。
• 一般提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。

数据平面的特色：

• 一般是按照无状态目标设计的，但实际上为了提升流量转发性能，须要缓存一些数据，所以无状态也是有争议的。
• 直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
• 对应用来讲透明，便可以作到无感知部署。

服务网格带来的变革

那么服务网格的出现带来了哪些变革呢？

第一，微服务治理与业务逻辑的解耦。服务网格把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 sidecar 的模式进行部署。服务网格经过将服务通讯及相关管控功能从业务程序中分离并下沉到基础设施层，使其和业务系统彻底解耦，使开发人员更加专一于业务自己。

注意，这里提到了一个词“大部分”，SDK 中每每还须要保留 协议编解码的逻辑，甚至在某些场景下还须要一个轻量级的 SDK 来实现细粒度的治理与监控策略。例如，要想实现方法级别的调用链追踪，服务网格则须要业务应用实现 trace ID 的传递，而这部分实现逻辑也能够经过轻量级的 SDK 实现。所以，从代码层面来说，服务网格并不是是零侵入的。

第二，异构系统的统一治理。随着新技术的发展和人员更替，在同一家公司中每每会出现不一样语言、不一样框架的应用和服务，为了可以统一管控这些服务，以往的作法是为每种语言、每种框架都开发一套完整的 SDK，维护成本很是之高，并且给公司的中间件团队带来了很大的挑战。有了服务网格以后，经过将主体的服务治理能力下沉到基础设施，多语言的支持就轻松不少了。只须要提供一个很是轻量级的 SDK，甚至不少状况下都不须要一个单独的 SDK，就能够方便地实现多语言、多协议的统一流量管控、监控等需求。

此外，服务网格相对于传统微服务框架，还拥有三大技术优点：

• 可观察性。由于服务网格是一个专用的基础设施层，全部的服务间通讯都要经过它，因此它在技术堆栈中处于独特的位置，以便在服务调用级别上提供统一的遥测指标。这意味着，全部服务都被监控为“黑盒”。服务网格捕获诸如来源、目的地、协议、URL、状态码、延迟、持续时间等线路数据。这本质上等同于 web 服务器日志能够提供的数据，可是服务网格能够为全部服务捕获这些数据，而不只仅是单个服务的 web 层。须要指出的是，收集数据仅仅是解决微服务应用程序中可观察性问题的一部分。存储与分析这些数据则须要额外能力的机制的补充，而后做用于警报或实例自动伸缩等。
• 流量控制。经过 Service Mesh，能够为服务提供智能路由（蓝绿部署、金丝雀发布、A/B test）、超时重试、熔断、故障注入、流量镜像等各类控制能力。而以上这些每每是传统微服务框架不具有，可是对系统来讲相当重要的功能。例如，服务网格承载了微服务之间的通讯流量，所以能够在网格中经过规则进行故障注入，模拟部分微服务出现故障的状况，对整个应用的健壮性进行测试。因为服务网格的设计目的是有效地未来源请求调用链接到其最优目标服务实例，因此这些流量控制特性是“面向目的地的”。这正是服务网格流量控制能力的一大特色。
• 安全。在某种程度上，单体架构应用受其单地址空间的保护。然而，一旦单体架构应用被分解为多个微服务，网络就会成为一个重要的攻击面。更多的服务意味着更多的网络流量，这对黑客来讲意味着更多的机会来攻击信息流。而服务网格偏偏提供了保护网络调用的能力和基础设施。服务网格的安全相关的好处主要体如今如下三个核心领域：服务的认证、服务间通信的加密、安全相关策略的强制执行。

服务网格带来了巨大变革而且拥有其强大的技术优点，被称为第二代“微服务架构”。然而就像以前说的软件开发没有银弹，传统微服务架构有许多痛点，而服务网格也不例外，也有它的局限性。

• 增长了复杂度。服务网格将 sidecar 代理和其它组件引入到已经很复杂的分布式环境中，会极大地增长总体链路和操做运维的复杂性。
• 运维人员须要更专业。在容器编排器（如 Kubernetes）上添加 Istio 之类的服务网格，一般须要运维人员成为这两种技术的专家，以便充分使用两者的功能以及定位环境中遇到的问题。
• 延迟。从链路层面来说，服务网格是一种侵入性的、复杂的技术，能够为系统调用增长显著的延迟。这个延迟是毫秒级别的，可是在特殊业务场景下，这个延迟可能也是难以容忍的。
• 平台的适配。服务网格的侵入性迫使开发人员和运维人员适应高度自治的平台并遵照平台的规则。

服务网格的百花齐放

ServiceMesher 社区从成立以来，举办过九场线下 Meetup 以及一场线上 Virtual Meetup，来自蚂蚁集团、网易、阿里集团、新浪、美团、百度等一线互联网公司分别都分享了各自公司关于服务网格的设计、实践与落地挑战，业界知名技术大会，也常常能看到大厂的专家与架构师分享服务网格落地相关的主题。可谓是百花齐放，百家争鸣！这些技术方案不外乎三种：其一，借鉴服务网格通讯代理的思想，基于公司内部服务框架改革而来，强依赖内部 RPC 框架与协议，仅适用于本公司的服务网格技术方案；其二，基于服务网格开源框架 Istio 与 知名数据面开源项目 Envoy 进行改版，以适配公司内部通讯与安全协议，兼容内部注册中心与配置中心，具备必定普适性的企业级服务网格解决方案；其三，自研数据面（如蚂蚁集团的 MOSN），或者彻底自研数据面与控制面，去除外部依赖，支持快速迭代与自由扩展，追求实际业务收益最大化。

然而，各大厂对服务网格的探索有一段时间了，实际的大规模落地案例却很少。咱们不由反思，火了2年的服务网格究竟给微服务带来了什么？咱们很难在此刻去断定上述三个方案的优劣，可是有一点，服务网格做为第二代微服务框架的地位是一向且明确的。此外，无论直接采用开源方案仍是彻底自研，知名开源项目体现出来的架构思想与理念值得全部云原生技术人员学习和参考。固然开源项目也须要你们共建，但愿更多大厂内部的优秀实践能不断反馈到社区里面来，共同促进服务网格的发展与繁荣。

总结

本文介绍了微服务架构的发展，以及服务网格的概念、服务网格相对于传统微服务架构的优缺点，对于后者，须要读者们辩证地去看待。从架构演进路径来看，从最先期的巨石单体（Monolithic）到分布式（Distributed），再到微服务（Microservices）、容器化（Containerization）、容器编排（Container Orchestration），最后到服务网格（Service Mesh）、无服务器（Serverless）。而服务网格正是这一演进路径中，相当重要的一环。

展望将来，Kubernetes 正在爆炸式发展，它已经成为企业绿地应用的容器编排的首选。若是说 Kubernetes 已经完全赢得了市场，而且基于 Kubernetes 的应用程序的规模和复杂性持续增长，那么就会有一个临界点，而服务网格则将是有效管理这些应用程序所必需的。纵使前路漫漫，可是随着服务网格技术的持续发展，其实现产品（如 Istio）的架构与功能的不断优化，服务网格将彻底取代传统微服务架构，成为大小企业微服务化和上云改造的首选架构。

本文做者

罗广明，百度高级研发工程师，开源项目与云原生技术爱好者，ServiceMesher 社区治理委员会核心成员，云原生社区联合创始人，对微服务架构、模型、中间件有深刻研究。

本文来源

本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，在线浏览地址：https://www.servicemesher.com/istio-handbook