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

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

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

微服务架构概述

微服务架构堪称是以后软件开发畛域的技术热点，在各种博客、社交媒体和会议演讲上的出镜率十分之高，无论是做基础架构还是做业务零碎的工程师，对微服务都相当关注，而这个景象与热度到目前为止，曾经继续了近 5 年之久。

尤其是近些年来，微服务架构逐步倒退成熟，从最后的星星之火到当初的大规模落地与实际，简直曾经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在做微服务架构的落地和推广。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。

而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架十分遍及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的利用零碎在享受其劣势的同时，痛点也越加显著。这些痛点包含但不限于以下几点：

• 侵入性强。想要集成 SDK 的能力，除了须要增加相干依赖，往往还须要在业务代码中减少一部分的代码、或注解、或配置；业务代码与治理层代码界线不清晰。
• 降级老本高。每次降级都须要业务利用批改 SDK 版本，从新进行性能回归测试，并且对每一台机器进行部署上线，而这对于业务方来说，与业务的疾速迭代开发是有抵触的，大多不违心停下来做这些与业务指标不太相干的事件。
• 版本碎片化重大。因为降级老本高，而中间件却不会进行向前倒退的步调，长此以往，就会导致线上不同服务援用的 SDK 版本不对立、能力参差不齐，造成很难对立治理。
• 中间件演变艰难。因为版本碎片化重大，导致中间件向前演进的过程中就须要在代码中兼容各种各样的老版本逻辑，带着“桎梏”前行，无奈实现疾速迭代。
• 内容多、门槛高。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