閱讀本文約花費: 17 (分鐘)

Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容：Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。

网上介绍 Service Mesh 的资料不少，但关注这一技术的本质、价值的内容却不多。阿里巴巴高级技术专家李云带领团队在这一领域探索的过程中想清楚了这两点，并在 QCon 2018 上海站分享了阿里巴巴对 Service Mesh 的探索与实践。

大规模分布式应用的挑战

微服务软件架构（microservices）已经被越来越多的企业作为规模分布式软件开发的首选架构。引入该架构之初是将一个单体应用拆解成多个更小粒度的微服务 (micro-service)，通过 HTTP API 或像 Dubbo 这样的 RPC 框架将这些服务组装起来作为整体去提供服务。由于每个微服务足够地小且功能内聚，因此能很好地解决以往单体应用的开发与发布困难的问题。即便如此，随着企业的业务发展和人员规模的壮大，不同业务所形成的微服务群之间的协同却面临新的挑战。

在阿里巴巴内部，RPC 框架由中间件事业部统一开发与维护，以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的，当 SDK 向前演进所增加的特性并不是某些业务方所需要的时，这些业务方就没有动力配合中间件事业部去同步升级自己应用中的 SDK 版本，使得 SDK 在整个集团存在多个版本甚至变成长尾而形成包袱。类似的包袱反过来制约了 RPC 框架自身的演进效率。

当微服务框架是单一编程语言独大（Java 在阿里巴巴就是这样的）、不能同步支持好其他多个主流编程语言时（比如 C++、Go、Node.js 等）, 就会出现非独大编程语言的 SDK 在特性上严重滞后于独大编程语言的，最终影响使用非独大编程语言的业务方以自己最为熟悉的编程语言去发展和探索业务。编程语言独大所带来的好处是多数人的技术栈是一样的而提高了技术层面的协作效率，但却无法收获编程语言多样性所带来的其他好处。即便同步地对多个编程语言的 SDK 进行维护，同样的特性需要用不同的编程语言去实现其成本着实很高。

也许在企业内部统一单一的主流编程语言并不会带来什么劣势，但当企业需要通过收购其他公司来扩充自己的商业版图时就很可能面临技术栈不统一而带来业务无法低风险、高效率共存演进的挑战。当碰到母子公司的技术栈不统一时，在被收购子公司中进行推倒重建基本上是一件业务价值不大的劳命伤财之事。

最后，在微服务软件架构所主张的拆分手法下，确实可以将每个拆分出来的服务从监管控层面做到足够的精致，但这势必会因为概念抽象不同、团队成熟度不一致等原因而使得这些“精致的烟囱”难以高效无缝协同，最终的结果是软件功能的易用性、风险的可控性和适应业务变化的敏捷性无法做到全局最优。

不难想象，采取强有力的团队组织形式、技术规范等手段是很难解决以上挑战的。回归通过技术途径去解决技术挑战才更为有力、有效，这正是 Service Mesh 这一技术可以帮助做好的。

Service Mesh 的形态

Service Mesh 的核心思路与微服务软件架构的思路是一脉相承的，即通过拆分实现解耦——将 SDK 中频繁变更的逻辑与业务逻辑分别放到不同的进程中。下图以 RPC 框架为例示例了这一手法。

拆分之后，服务调用的流量通过技术手段以应用无感的形式导入 sidecar 进程。每个服务进程边上新增的 sidecar 使得完整的服务调用链中客户端和服务端分别增加了一跳，这是享受 Service Mesh 技术所需付出的成本。

Service Mesh 的挑战

第一个挑战来自心智模式需要改变。享受 Service Mesh 所带来的益处是需要付出成本的，这如同单体应用向微服务软件架构转变那样，核心是成本与收益问题。之所以业内仍有不少人纠结于 Service Mesh 的价值，根本原因在于企业的业务规模是否面临 Service Mesh 所致力于解决的那些挑战，如果没有则采纳 Service Mesh 只带来更高的成本而没有收益。

对于那些服务规模还小的企业，确实没有必要引入尚处于探索和普及阶段的 Service Mesh 的必要。他们可以持续关注业务发展与技术的匹配，在合适的时间点去拥抱新技术。

第二个挑战来自于技术层面，即如何做到增加 sidecar 后的“路径无损”。具体说来，如何在引入 Service Mesh 的情形下，最大可能地不增加服务的调用延时和消耗更多的 CPU 资源。这是未来需要持续去突破的技术方向。可以预见，突破的途径无外乎“应用层 + 内核层”或“软件 + 硬件”。

Service Mesh 的本质

无疑，技术发展是服务于业务价值创造的。在单体应用时代，因为软件规模、业务复杂度和参与人员数量的持续增大，使得软件开发和迭代工作因为耦合而举步为艰，这就有了微服务软件架构的出现。那时的业务发展效率问题集中体现于人员协同，在微服务软件架构的需要下产生了 RPC、Messaging 等技术。

当人员的协同问题通过微服务软件架构得以解决时，随着软件规模、业务复杂度和参与人员数量的进一步增大，需要更好地解决多个业务（或服务）之间的协同问题，而这是 Service Mesh 这一技术的本质。

Service Mesh 的价值

在 Service Mesh 的形态下，RPC 框架中容易变更的内容被剥离到了 sidecar 进程，之前的胖 SDK 瘦身为只保留了功能恒定的协议编解码能力。如此一来，与 RPC 框架演进相关的逻辑几乎集中在 sidecar 进程中，这就完全可以做到让使用 RPC 框架的业务方无感知地对之进行升级与维护。最终的结果是，业务与 RPC 框架可以做到独立发展与升级，完全消除了之前胖 SDK 所导致的两者相互制约发展的不利局面。这一解耦所带来的好处是，使用 RPC 框架的业务团队可以更加聚焦于业务开发本身，这正是发挥技术价值应达到的境界。

不难看出，Service Mesh 很好地解决了以往 RPC 框架多语言 SDK 的问题。虽然在 Service Mesh 下仍然需要 SDK，但由于 SDK 中的功能是相当稳定的，不存在应付频繁变更所带来的长期维护成本问题。由于 sidecar 是以进程的形式存在的，因此完全不关心使用 RPC 框架的业务逻辑是用什么编程语言实现的，只需实现一次而没有让人感到无聊的多语言特性对齐问题，将 RPC 框架技术团队的人力释放出来做更有价值的事。

也因为 sidecar 是以独立进程的形式存在，当出现因为公司收购所面临的母子公司技术栈不一致问题时，可以将 sidecar 部署在两个技术栈的衔接处，由 sidecar 通过协议转换等形式完成两个异构服务框架的连接，为异构服务框架的渐进式融合发展提供了可能，很好地缓解了短期高强度技术改造所面临的技术风险和对业务发展的拖累。

服务框架易变的功能剥离到了 sidecar 后，意味全网的服务流量治理能力可以通过 sidecar 进行收口——sidecar 自身的版本全网一致、流量规则与执行策略一致、监控口径一致，等等。诸多的“一致”将实现全网服务治理的体系化监管控，使得 Service Mesh 成为微服务软件架构拆分手法下完成横向连接与约束的强有力技术手段。

如果用一句话来描述 Service Mesh 的话，那就是“层次化、规范化、体系化、无侵入的分布式服务（或应用）治理技术”。

Service Mesh 的终局

延着 Service Mesh 的切分逻辑，不难预见未来 Service Mesh 所形成的终局是一张大网。这个大网是企业统一且唯一的分布式应用治理的基础设施，其上天然地支持多语言应用的开发。当然，sidecar 是包罗万象地支持 RPC、DB、Messaging，还是衍生出 RPC sidecar、DB sidecar、Messaging sidecar 是仍需探索的主题。

Service Mesh 的发展路径

新技术诞生于逻辑上能解决当下所面临的技术或业务挑战，但能否真正落地去最大程度地发挥价值却具有不确定性和模糊性。正因如此，不少新技术出现之时存在各种基于自身立场去解读和挖掘其背后的价值，当然也不乏各种质疑之声。所有这一切让业内对挑战看得更加透彻，对新技术的探索也愈加高效。

根本上，Service Mesh 的出现并非填补了技术空白，不少公司因为曾经有过相似的探索而给人“换汤不换药”的感觉，与今天时兴的云计算在十几、二十年前被称之为分布式计算、网格计算颇有相似之处。当一项新技术不是给人横空出世的感觉时，它的运用与采纳就会经历更多的波折，因为没有它似乎企业的业务发展仍能进行下去。

在经历了一定的思考和市场感知后，发现 Service Mesh 真正发挥价值是需要分布式应用大到一定的规模并面临一开始所提出的那些挑战，这些在阿里巴巴集团内部都满足。最终我将 Service Mesh 的发展划分成三大阶段。

阶段一：撬动。新技术被采纳的关键是它能解决业务当下所面临的痛点，阿里巴巴因为 Java 语言一家独大而使得多语言问题相当突出，这使得小众的编程语言乐于拥抱 Service Mesh 去解决自己维护 SDK 或 SDK 特性老旧的痛点。此外，阿里巴巴不时通过收购子公司扩大自己的商业版图，确实经历了异构服务架构共存演进所带来的挑战。

撬动阶段让新技术得以落地而接触到更多的业务机会并争取到打磨技术的时间窗口，让 Service Mesh 技术团队对于需求的理解和把控更加到位。为进入下一发展阶段提供可能。

阶段二：做透价值渗透。光解决多语言和异构服务架构共存演进并不足以实现大范围的体系化监管控，需要围绕集团内部更为丰富的业务场景去挖掘 Service Mesh 的价值，并在探索的过程中寻求技术突破去降低引入 Service Mesh 的成本。当分布式应用的体量特别大时，成本问题将变得备受关注。一旦 Service Mesh 的价值得以做透，还得考虑无缝迁移等用户体验使之得以更为方便地应用到更多的业务场景。

阶段三：实现技术换代。分布式应用的全局、体系化监管控一定是未来云原生时代的强诉求。进入这一阶段代表技术进入了更高层次的集约发展时期，是偿还过去“跑马圈地”和“野蛮生长”所欠下技术债的重大里程碑。在这一阶段，Service Mesh 将成为企业所有分布式应用的基础设施，通过这一设施强有力地执行流量灰度、流量调度去保障业务的持续性，让安全、稳定性问题得以采用一致性、系统性的方案解决。“生长”在 Service Mesh 之上的所有业务完全可以根据团队的技术栈特长以更为经济和高效的方式去发展和探索。

Dubbo Mesh 的发展思路

Dubbo Mesh 是 Service Mesh 在 Dubbo 生态下的落脚点。其发展不仅立足于在阿里巴巴集团遗留应用场景的包并兼容，还将迎合 Kubernetes 已成计算资源编排王者的大势，让 Service Mesh 在未来以 Kubernetes Way 去提供概念一致、体验一致的技术产品。

整个 Service Mesh 的发展与探索将走“源于开源，反哺开源，集团内外版本一致”的思路。希望探索之路少走弯路、与更多的同行携手前行，成为开源社区的一名积极建设者。

最终的技术选型是采用 Istio 的部分组件（Dubbo Control 控制面）和 Envoy（Dubbo Proxy 数据面）形成阿里巴巴自己的解决方案。Istio 中的 pilot-discovery 对于平台的抽象便于扩展支持阿里巴巴最近开源出来的 Nacos 而方便落地，同时为将来集团全面的 Kubernetes 化做好准备。Envoy 的性能与软件质量在很多生产环境上得到了检验，而采用 C++ 能从性能上得到很好的保证，避免有些语言存在 GC（垃圾回收）而带来的不确定性，也便于将来应用层与 OS 层、软件与硬件的结合发展。

Dubbo Mesh 的进展

目前 Dubbo Proxy 完成了 Dubbo 服务调用统计信息收集的开发工作，这部分代码已合入了 GitHub 上 Envoy 仓库的 master 主干。Dubbo Proxy 全面支持 Dubbo 服务路由的工作正在进行，相信很快这部分代码将出现在开源社区。

在阿里巴巴集团内部，为了快速落地已经完成 Dubbo over HTTP 技术方案的开发，目前已在两个多语言场景业务方的环境中完成部署并开始着手性能测试和调优工作。内部落地方案中，需要考虑通过 Nacos 与集团内部的 VIPServer、ConfigServer 集群进行对接去完成服务发现，这些对接工作开源社区无需关注，因为开源的 Nacos 已包含阿里集团内部的服务注册与发现和配置管理能力。

值得一提，pilot-discovery 目前并非集群化部署，而是与 Dubbo Proxy 一样进行了下沉。未来在合适的时机会再考虑将之上拉并形成独立的部署集群。

ServiceMesh 作为微服务“新贵”在 2018 年火爆异常，未来应该也会有更广阔的应用前景。