下载掌阅APP，畅读海量书库
立即打开
分布式关系日益复杂还不仅体现在调用关系上，随着多语言、前后端分离等思想的发展，在架构中呈现编程语言多元化的趋势，例如 NodeJS、Golang（近期非常热的配置中心 etcd 就是用其编写的）、Scala（大名鼎鼎的 Kafka 就是用其编写的）等。
本来仅维护调用关系就已经让工程师们焦头烂额了，现在还需要对多语言进行支持（熟练掌握一门语言及其生态还是需要一些时间的），并且不同的语言还有不同的编程风格，所以多语言支持真的不容易。再者，由于多语言客户需要侵入上层业务代码，开发人员就不得不在学习（至少了解）整个服务架构后，才能较正确地做出是否能够接入那些客户端的判断。
业务需求不断升级会导致系统复杂度呈指数级增长，工程师们经常遇到这样的现象：同一段时间内，一个产品可能有好几个需求在并行开发，而开发环境却有限；某些应用包含敏感数据，并不希望将接口完全公开；隔三岔五的产品活动，对系统稳定性有很高的要求，测试希望能将压测常态化，最好还不影响线上应用。整体系统复杂度并不像最初预估的那样呈线性增长，其往往呈指数级增长。这一点，从图1.9中每年双十一的销售额就可以看出来。
所以这时“多版本、多权限、动态限流降级”等一系列针对链路的高级功能需求被陆续提了出来。为了满足上述要求，工程师们不得不编写更多的系统，有针对“分布式锁”的，有针对“分布式鉴权”的，有针对“多版本”的，等等。这使得分布式系统本身愈加复杂与笨重。事实上，仅搭建与维护一套分布式架构至少都需要一个专业的团队支持（通常这个团队叫“平台架构”或者“中间件”团队），每个产品至少需要半个专业的工程师来维护，理解这些概念对于非专业的业务工程师来说负担可就更重了。
表1.9 “双十一总销售额与系统复杂度关系”
“微服务”虽然强调轻量化框架，但仍然无法避免系统愈加繁多的问题，服务细化得越厉害，只能让逻辑越轻量并解耦；但服务分得越细，数量就越多，维护成本自然就越高，这并不能解决维护成本问题。
到了 2015 年，一家名为 Buoyant的公司向外界公布了一种架构空前的产品，其为每个服务分配了一个专用的称为“边车网关（Sidecar）”的系统，并将其与“服务发现”的公共服务相连，服务地址及控制信息便通过“服务治理系统”统一下发，其系统概念如图1.10所示：
图1.10 “Linkerd 系统基本架构”
如此一来，随着接入应用的添加，网关之间便形成了一个特殊的大网（如图1.11所示），其承载着链路请求的路由、治理及其他任何与链路相关的工作。由于网关独立于业务应用而存在，因此其与业务逻辑是完全解耦的，并且开发人员是无感知的。Linkerd 巧妙地向上层应用统一屏蔽了分布式架构，让业务开发变得更简单、纯粹了。
图1.11 “随着应用的添加
可是Linkerd 在 2015 年推出后并没有受到业界的关注，主要原因是 Linkerd 为每个服务部署一个网关的想法在传统运维体系中实在是太难实现了——部署、维护工作几乎多了一倍。
但是到了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 的配置。
这之后 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）”。
由于 Istio 是 Google 巨人主导的，很有说服力，所以各大厂商愿意跟进研究并投入试用，本书中所讲解的 Service Mesh 大部分内容也都基于 Istio。其实除了国外研发的开源产品，国内很多团队也已经在着手研究了，这些团队主要分为四类体系。
○ 以蚂蚁金服为首的开源系： 蚂蚁金服自研的 SOFA（Scalable Open Financial Architecture）Mesh 在开始的时候走的就是开源路线，他们参考了 Istio 及 Envoy 的设计思想，重新实现了自己的 Service Mesh 系统，旁路网关（Sidecar）基于 Go 语言，该系统的前身是已经开源的 SOFA RPC 框架。蚂蚁金服于 2018 年 7 月正式将其开源，正式的可以用于生产的框架可能还需要一些时间。
○ 以华为为代表的自研系： 华为可能在 Service Mesh 概念出来前就已经有类似的想法了，只是没有抽取出一个公共的概念。无论是华为早期的 HSA 还是之后出现的 CSEMesher，都是对 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 正式版本之后，基本上就已成为唯一一个可以实际用于生产环境的开源框架。
服务网格是一个全新的概念，各大公司在争相研究与实践，我相信服务网格将来必然是云服务的重要根基之一。