1.5 服务网格（Serüice Mesh）新时期

1.5.1 多语言的困难

分布式关系日益复杂还不仅体现在调用关系上，随着多语言、前后端分离等思想的发展，在架构中呈现编程语言多元化的趋势，例如NodeJS、Golang（近期非常热的配置中心etcd就是用其编写的）、Scala（大名鼎鼎的Kafka就是用其编写的）等。

本来仅维护调用关系就已经让工程师们焦头烂额了，现在还需要对多语言进行支持（熟练掌握一门语言及其生态还是需要一些时间的），并且不同的语言还有不同的编程风格，所以多语言支持真的不容易。再者，由于多语言客户需要侵入上层业务代码，开发人员就不得不在学习（至少了解）整个服务架构后，才能较正确地做出是否能够接入那些客户端的判断。

1.5.2 指数级增加的系统复杂度

业务需求不断升级会导致系统复杂度呈指数级增长，工程师们经常遇到这样的现象：同一段时间内，一个产品可能有好几个需求在并行开发，而开发环境却有限；某些应用包含敏感数据，并不希望将接口完全公开；隔三岔五的产品活动，对系统稳定性有很高的要求，测试希望能将压测常态化，最好还不影响线上应用。整体系统复杂度并不像最初预估的那样呈线性增长，其往往呈指数级增长。这一点，从图1.9中每年双十一的销售额就可以看出来。

所以这时“多版本、多权限、动态限流降级”等一系列针对链路的高级功能需求被陆续提了出来。为了满足上述要求，工程师们不得不编写更多的系统，有针对“分布式锁”的，有针对“分布式鉴权”的，有针对“多版本”的，等等。这使得分布式系统本身愈加复杂与笨重。事实上，仅搭建与维护一套分布式架构至少都需要一个专业的团队支持（通常这个团队叫“平台架构”或者“中间件”团队），每个产品至少需要半个专业的工程师来维护，理解这些概念对于非专业的业务工程师来说负担可就更重了。

“微服务”虽然强调轻量化框架，但仍然无法避免系统愈加繁多的问题，服务细化得越厉害，只能让逻辑越轻量并解耦；但服务分得越细，数量就越多，维护成本自然就越高，这并不能解决维护成本问题。

1.5.3 Linkerd诞生

到了2015年，一家名为Buoyant的公司向外界公布了一种架构空前的产品，其为每个服务分配了一个专用的称为“边车网关（Sidecar）”的系统，并将其与“服务发现”的公共服务相连，服务地址及控制信息便通过“服务治理系统”统一下发，其系统概念如图1.10所示：

如此一来，随着接入应用的添加，网关之间便形成了一个特殊的大网（如图1.11所示），其承载着链路请求的路由、治理及其他任何与链路相关的工作。由于网关独立于业务应用而存在，因此其与业务逻辑是完全解耦的，并且开发人员是无感知的。Linkerd巧妙地向上层应用统一屏蔽了分布式架构，让业务开发变得更简单、纯粹了。

可是Linkerd在2015年推出后并没有受到业界的关注，主要原因是Linkerd为每个服务部署一个网关的想法在传统运维体系中实在是太难实现了——部署、维护工作几乎多了一倍。

1.5.4 第一代服务网格架构

但是到了2017年，随着“微服务”与“容器化”技术的迅速发展，以上问题就非常简单了，只需要将网关程序打包到基础镜像（Image）即可解决。随后Linkerd的想法迅速走红，受到越来越多工程师的青睐。不久后William Morgan（Buoyant co-founder and CEO）在Linkerd官方博客上撰写了一篇名为What's a service mesh?And why do I need one的文章，将Linkerd的构想定义为“服务网格（Service Mesh）”，并做了比较严谨的定义。

Service Mesh是一个“基础设施”层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh保证请求可以在这些“拓扑”中“可靠”地穿梭。在实际应用当中，Service Mesh通常是由一系列轻量级的“网络代理”组成的，它们与应用程序部署在一起，但应用程序“不需要知道”它们的存在。

这里有几个关键点，要强调一下。

○基础设施：Service Mesh是未来云计算中不可或缺的基础框架，就像TPC/IP协议栈一样，虽然开发人员不需要感知，但其中服务路由与治理的基础，为云计算提供服务通道与保障。

○拓扑：Service Mesh所提供的网关组成一个庞大的网格，由此网格统一为应用提供服务，其是对物理网的一层分布式抽象。

○可靠：由于其组成的网格为上层服务提供一层统一的代理，其作为基础设施需要高度可靠，否则上层业务会非常头痛。

○网络代理：其是对所有服务设计的一层透明代理，可以跨言语。

○不需要知道：其是一层服务栈，拥有对上层支撑的全套功能且对业务无侵入，在层次上定义了其存在位置。

从上可以看出，第一代架构是从数据逻辑层面上解决了微服务关系混乱的问题，但它并没有实现控制。Sidecar将各服务连接了起来，并做到请求接管，但是没有一个有效的系统或者设计来管理这些Sidecar的配置。

1.5.5 第二代服务网格架构

这之后Linkerd被Google收编到了CNCF基金中，现在已经作为一个开源软件在发展，但是由于其是使用Scala编写的，在性能上表现不佳（Scala需要JVM作为运行环境，通常在启动的时候就至少占200MB内存），再加上后来Google为了推进Kubernetes在云上的发展，自己另起炉灶发布了Istio，使用的网关是Envoy, Linkerd可以说前途昏暗。

也许是Buoyant自己也感觉到把Linkerd交给社区之后使其思考及发展都受到了严格的限制（在社区由于需要公共参与，每个决定都需要经过较长的时间）,2017年又用Rust研发了Conduit。Conduit号称是一个非常轻量级的Service Mesh方案，不过由于Rust是一种非常小众的语言，再加上这个时候Google的Istio势如破竹般地发展，Conduit现在在业界的接受度也是非常低的，更不要谈大规模实际生产了。

第二代服务网格典型的特点便是同时拥有了数据接管与集中控制能力，Google分别将两个能力对应的系统定义为“数据平面（Data Plane）”及“控制平面（Control Plane）”。

1.5.6 生产应用情况

由于Istio是Google巨人主导的，很有说服力，所以各大厂商愿意跟进研究并投入试用，本书中所讲解的Service Mesh大部分内容也都基于Istio。其实除了国外研发的开源产品，国内很多团队也已经在着手研究了，这些团队主要分为四类体系。

○以蚂蚁金服为首的开源系：蚂蚁金服自研的SOFA（Scalable Open Financial Architecture）Mesh在开始的时候走的就是开源路线，他们参考了Istio及Envoy的设计思想，重新实现了自己的Service Mesh系统，旁路网关（Sidecar）基于Go语言，该系统的前身是已经开源的SOFA RPC框架。蚂蚁金服于2018年7月正式将其开源，正式的可以用于生产的框架可能还需要一些时间。

○以华为为代表的自研系：华为可能在Service Mesh概念出来前就已经有类似的想法了，只是没有抽取出一个公共的概念。无论是华为早期的HSA还是之后出现的CSE Mesher，都是对Service Mesh的探索。CSE Mesher的整个架构都是基于华为自身微服务架构经验研发的，其Sidecar也是用Go语言编写的。如其官方文档所述，其资源占用非常小，常规状态下仅为30MB。

○以腾讯为代表的拿来主义系：腾讯的Tencent Service Mesh对开源的产品（如Istio）进行定制，强化吸收后再加入自身特殊的业务逻辑。腾讯选择的Sidecar是Envoy，使用C++编写，比较符合腾讯的技术栈。其公开的技术并不多，仍然以内部小范围使用为主。

○以UCloud为代表的适配系：主要也是依赖开源方案，但不是完全将其产品引入，只是对其中几个关键部分添加适配器，以适应企业现有产品，以最小的变更成本引入Service Mesh体系。

能够看出，服务网格概念虽然火，但并不是像Spring Cloud及Dubbo那样经过实战考验的、成熟的框架——企业要想拥抱服务网格，通常情况下只能自行研发或改造。虽然Google已经在试图通过Istio来为业界设立一个通用标准，但从现状来看，还有比较长远的路要走。

可以说现在Istio已经独领风骚，在服务网格这个领域确立了坚实的根基，特别是其在2018年8月发布1.0正式版本之后，基本上就已成为唯一一个可以实际用于生产环境的开源框架。

服务网格是一个全新的概念，各大公司在争相研究与实践，我相信服务网格将来必然是云服务的重要根基之一。