Service Mesh 为何从“趋势”走向“无聊”？

简介：过去一年，阿里巴巴在 Service Mesh 的探索道路上依旧扎实前行，这种坚决并不是只因坚信 Service Mesh 将来必定是云计算基础技术的关键组成部分，还因须要借这一技术趋势去偿还过去所积累下来的技术债（“技术债”并不是贬义词，是技术发展的固有产物），基于当下的技术思潮和最佳实践面向将来作出技术的新价值和新体验。

做者 | 李云（至简）
来源 | 阿里巴巴云原生公众号

过去一年，阿里巴巴在 Service Mesh 的探索道路上依旧扎实前行，这种坚决并不是只因坚信 Service Mesh 将来必定是云计算基础技术的关键组成部分，还因须要借这一技术趋势去偿还过去所积累下来的技术债（“技术债”并不是贬义词，是技术发展的固有产物），基于当下的技术思潮和最佳实践面向将来作出技术的新价值和新体验。

每当咱们深刻探索和实践一项新技术时，大多情形下会步入一段“无聊”时期，期间天天面对的并不是技术之新如何诠释，而是如何先处理好技术债所带来的羁绊，以及务实地给业务创造新价值和新体验，经过携手业务双赢的方式推进新技术落地。本文总结了过去一年 Service Mesh 在阿里巴巴的建设成果和收获的洞察。

兑现增量业务价值是发展之本

Serivce Mesh 做为一种平台型的新基础技术，发展过程当中必定回避不了兑现（增量）价值这个关键问题。从技术的角度，很容易理解将框架思惟下 SDK 中的易变内容下沉到 Service Mesh 中的 Sidecar 后，将促进中间件技术以业务无感的形式快速演进和升级，以平台化和体系化的思惟替代过去“山头林立”的框架思惟去进一步探索分布式应用构架问题的更优解，背后的价值并不容易被挑战。

从业务的角度，采纳新技术的关键是能解决当下的什么痛点、是否带来机器成本的显著下降、可否让稳定性有明显的提高、运维和研发效率有否变得更高，这些收益被总称为业务价值——业务视角下所看到的收益。发展 Service Mesh 很重要的一点是必须回归兑现（增量）业务价值，围绕不断兑现业务价值去完善新技术，不然很难持续拿到阶段性的成果。对于从事 Service Mesh 这类新技术建设的团队来讲，持续收获阶段性成果对于维持团队士气致关重要，建设者会由于业务价值足够而能体会到“被须要”的感受，进一步强化对本身工做价值的承认。

过去一年，咱们经历了从“先作大规模落再兑现业务价值”到“先兑现业务价值再作大规模”的发展策略调整。在作大规模为先的阶段，落地 Service Mesh 被挑战的主要问题有三个：其一，增量业务价值不足，只是将 Java SDK 中已有的能力挪进了 Service Mesh；其二，资源开销不可忽视；其三，技术成熟度不够，没能让人看到工具化落地的问题定位与排错手段。当确实不能回答好这三个问题时，推进 Service Mesh 在核心应用上的大规模落地就变得很是困难，即使有公司层面由上至下的助推也收效甚微。最终，不得不将发展策略调整为兑现价值为先。

在兑现价值的道路上，刚好某些业务团队也从一开始挑战上面三个问题变成了积极思考如何借 Service Mesh 化此次机会让所在事业部的业务流量治理能力作一次重大升级。思路的转变很快让业务团队锚定了业务痛点，与 Service Mesh 共创出了新的解决方案，最终两个团队的合做关系从甲乙方变成了你中有我、我中有你的战友关系，你们一块儿抱团双赢。

回顾过去一年的经历，能获得的启示是：

• 不管什么新技术，先作出增量业务价值才能更好地落地推广。再先进的技术在没有兑现增量价值以前都只是个愿景，希望景并不那么容易让人买单，技术落地依然要尊重市场规律。此外，新技术的成熟须要时间这是天然规律，技术成熟的过程当中若是没有兑现增量业务价值，则没有业务甘愿只成为纯粹的小白鼠。
• 基础技术的发展不能只依靠基础技术团队的力量，业务团队以积极的心态参与寻求解决业务痛点将成为强劲的新技术“催熟剂”。基础技术团队并无业务体感，而业务团队的全情投入就能很好地弥补这一短板，二者联合所造成的化学反应就能带来双赢的局面，合做关系也将升华至“战友级”。基础技术团队须要特别重视与业务团队合做，避免步入闭门造车的境况。

无侵入方案是关键手段但并不是终态

在技术进化的过程当中，咱们但愿尽量作到兑现价值之时业务没有任何的改形成本，这一点能很好地理解为什么 Istio 推出至今采用了 iptables 作流量劫持。阿里巴巴在探索的过程当中深知无侵入方案的价值，早在内部落地时采用的也是无侵入方案，过去一年更进了一步让无侵入方案支持流量透传功能。

去年初，阿里巴巴内部落地 Service Mesh 的技术方案并无考虑百分百作兼容。由于历史缘由，Dubbo 的序列化协议存在 Hessian二、Java 和其余小众的选择。考虑到 Hessian2 是主流协议，因此 Service Mesh 只对这一协议进行了支持。在落地的过程当中，只要被 mesh 化的应用须要调用使用了不支持序列化协议的应用，就会直接致使该应用没法 Service Mesh 化。进一步，Service Mesh 的总体能力建设依赖这一技术点的突破，经过上量得到更为普遍的场景去兑现价值或为大规模落地打好基础。好比，运维面支持大规模就属于后者。另外，当全部应用都能 mesh 化时，最不济也能在使用了 Hessian2 序列化的链路上兑现价值，而不致于由于应用没法 mesh 化而使得能兑现价值的链路变得更短（价值被弱化）。

为此，Service Mesh 须要全面“支持”全部 RPC 序列化协议。下图示例了进一步的解决方案，图中示例了 A、B 和 C 三个应用，其中 A 是被 mesh 化了的。须要指出，Sidecar（Envoy）在原有的基础上增长了透传功能，对于 Hessian2 以外的协议只收集必要的统计信息后透传。须要补充的背景信息是，Service A 所使用的 RPC SDK 是全功能的，仍然具备服务治理能力。换句话说，SDK 作完路由所发出的包到达 Sidecar 后直接透传就能保证服务的连通性。

长远来看，对于 Dubbo 这种包含服务治理能力的 RPC 协议来讲无侵入方案必定不是终态。缘由在于，Dubbo SDK 须要有能力感知本身是否应工做于 Servcie Mesh 模式，在这种模式下将服务治理等职责下放给 Sidecar 去完成，从而省去 SDK 在这方面的内存和 CPU 开销。

基于此，过去一年阿里巴巴内部围绕终态的云原生方案也投入了至关的力量作建设，让 Service Mesh 能很好地与 Dubbo 3.0 一块儿协同工做。下图示例说明了 Dubbo 3.0 下的 Service Mesh。

在终态方案中，Dubbo 3.0 SDK 有一个重大的变化是针对 Service Mesh 改善了友好度，总体设计考虑了云原生浪潮这一重大技术趋势。与 Service Mesh 相关的主要变化是：

协议头采用基于 gRPC 实现的 Triple 协议。经过将 Sidecar 须要感知或变动的内容放到协议头中，彻底规避须要对消息体作反序列化和序列化的动做，消息体采用什么序列化协议对于 Sidecar 彻底无感。

具有因 Service Mesh 出现故障的容灾能力。Dubbo 3.0 SDK 具有 Thin 和 Fat 两种模式，分别对应于工做于 Service Mesh 和非传统模式。Thin SDK 下 CPU 和内存的开销将降到最低，所节省下来的开销腾出来给 Sidecar 使用。Fat SDK 模式下则具有全面的路由治理能力，当 Service Mesh 出现故障时由 SDK 负责完成服务调用路由。

Service Mesh 模式下服务注册与反注册由 Sidecar 负责代理完成。换句话说，当 SDK 工做于 Service Mesh 模式时，SDK 彻底感知不到后端的注册中心，使得 Service Mesh 能最大程度地屏蔽下面的基础设施细节。

去除了 iptables 作流量劫持，SDK 直接经过本机的进程间通信（TCP/IP 网络 loopback 或 Unix Domain Socket）方式与 Sidecar 通信。流量劫持能力的价值在于，SDK 能够在彻底不升级的情形下由 Service Mesh 完成流量治理并对业务无感，因为 Dubbo 3.0 原本就存在 SDK 升级的问题，为了在稳定性和性能上不引入新的问题而去除了 iptables。

值得强调，SDK 能回切至 Fat SDK 模式承担起 Service Mesh 故障时的服务调用路由的前提假设是：Service Mesh 与 SDK 具备基本的对等能力，确保知足容灾场景下的基本需求。长远来看，Service Mesh 的服务治理演进速度必定比 SDK 更快，若是有些功能与容灾能力相关则须要在 SDK 中再实现。固然，Service Mesh 应当系统性地保障稳定性，将 SDK 的保障能力放在单机维度而非全应用集群维度。

最后，正如前面所提到的，Service Mesh 的发展是须要业务方参与的，经过解决业务痛点去更好地牵引新技术落地。但凡为了解决业务问题，则必定程度地存在业务改造的须要，进一步代表无侵入方案没法从始至终地支撑好业务价值兑现这事。换句话说，准备落地 Service Mesh 的业务方，不该当将引入 Service Mesh 是否存在业务改造看成是一个核心考量点。业务改造历来都不是问题，问题在于改造有没有解决业务痛点、有没有让技术升级到更高的层次为未来业务的发展打好基础，而这一点原本就是业务落地 Service Mesh 时须要认真思考的。固然，就咱们的经验来看，经过无侵入方案让业务无感试水 Serivce Mesh 是很是推荐的实践。对于同行来讲，若是你所在的企业在探索 Service Mesh 或云原生相关技术，同时须要兼顾新老应用的连通和向新技术的渐进式演进，那到无侵入方案会是一个很好的过渡选择。

正在兑现的增量业务价值

刚过去的一年，Service Mesh 在阿里巴巴内部找到了二大增量业务价值兑现点。随着建设工做将在接下来的几个月全面完成，将迎来 十万级应用实例的大规模落地。

增量业务价值兑现点之一，将国际化中台当下的区域化和多租路由治理能力下沉至 Service Mesh，实现流量路由治理统一和应用级机房容灾。过去，国际化中台的 Java 应用是以 Annotation 的形式去指定应运用的路由策略，但凡须要变动路由策略就得作代码修改并从新将应用发布上线，整个过程至关周折。还有，国际化中台的容灾只能作到机房级别，切流时须要将整个机房的流量所有切走。

引入 Service Mesh 后，将 Java 应用中经过 Annotation 指定路由策略的能力彻底去除，经过下放到 Service Mesh 中以配置化的形式实现，使得每一次应用路由策略变动只需动态下发新的 YAML 文件便可，彻底作到了与应用完全解耦。进一步，因为路由策略是应用维度的，能够方便地以应用为颗粒度作机房间切流，提高了容灾的敏捷性和下降了切流风险。

国际化中台做为业务方，与 Service Mesh 团队抱团探索业务价值的过程当中很是积极主动地思考如何最大程度地发挥此次可贵的技术升级机会。将过去存在单点服务治理能力的组件全面放到 Service Mesh 的 Sidecar 中以分布式的形式完成，不只卸下了过往的运维包袱，还让总体的业务稳定性向前迈进了一大步。

增量业务价值兑现点之二，将 Service Mesh 灵活的流量治理能力运用于新零售事业群的开发环境治理，根据开发同窗的须要动态建立相互独立的开发环境。为了支撑好开发工做，阿里巴巴内部的实践是搭建了与生产环境彻底独立的平常环境，将线上的应用部署到两个环境中用于每个应用的开发调试工做。在平常环境中的每个应用均可能由于开发的须要而进行变动，为了解耦应用间的相互影响又进一步在平常环境中又创建了基线环境，每一个应用的开发工做都得基于基线环境所隔离出的开发环境完成开发工做，而不能直接将基线环境用于开发联调。当应用数和开发人员的数量都数以万计、天天的应用变动数数以千计时，如何保障好开发同窗平常所需的开发环境就是颇有挑战和颇有价值的一件事。

因为过去的开发环境隔离技术是基于框架思惟去设计的，须要不一样的流量（好比， RPC、消息、缓存和数据库）从协议层面去对接同一个隔离框架，演进与维护至关困难。当存在多语言场景时，主要围绕 Java 语言构建的能力就使不上劲。另外，在没有 Service Mesh 这样的平台技术出现时，有些隔离场景至关难实现。

Service Mesh 的价值在于，其天生就是为了流量治理而生，动态且灵活地完成流量的隔离与路由是核心能力之一。咱们对 Istio 中的 VirtualService 和 DestinationRule 进行了扩展，抽象出了 TrafficLabel 这一全新的 CRD，经过下发 YAML 文件动态地对流量和应用机器进行打标，Envoy 则基于流量标和机器标进行路由，从而作到灵活又快速地构建出开发同窗所需的开发环境，且能很好地支持多语言应用。下图示例说明了 Service Mesh 下，同时开发 v1.1 和 v1.2 两个版本时的应用部署和流量拓扑。

上图中，须要下发 YAML 文件对特定的流量和应用进行打标。Envoy 则根据流量标将流量导到打了一样标的机器上，当对应的标并无机器时，则运用回退机制让流量回流到基线环境中。好比，开发环境 1 中的应用 B 调用应用 C 时，因为找不到打了 tag1 的机器则直接将流量打到基线环境。

能够预见，Service Mesh 所构建的这一能力为未来探索 Test in Production 打开了一扇门。将来基于 Service Mesh 所构建的流量隔离环境将有助于节约搭建独立开发环境所需投入的机器成本，也为探索新一代的安全生产环境提供了新思路。固然，在这条路上咱们任重而道远。

截止本文完稿之时，阿里巴巴集团内部 Service Mesh 的落地规模已达数万应用实例。数据、控制和运维三大平台的能力建设彻底作到了具有大规模运用水平。

不可忽视的软件生命周期理论

做者借此机会分享本身所理解的软件生命周期理论，但愿在云原生这一可贵的技术浪潮之下该理论有助于读者更好地看待新技术的发展并在这个过程当中抓住机遇。

以静态的思惟看待软件开发，极有可能最终致使所得到的软件是一个臃肿、易出错的包袱。出现这种情况的缘由，是由于没有明白软件是存在生命周期的。软件也象人同样，存在造成、成长、成熟和衰退四大时期（以下图所示）。图中纵座标表明软件对新需求的适应能力，指软件对实现新需求的友好度，背后是概念与概念之间的关系是否清晰、让人对其的认识是否符合直觉与常识，本质是指软件的设计质量。图中的直线也只表明一种趋势，现实中更多地表现为存在波动的曲线。

软件进入成熟期的标志，是其功能实现程度与当初的定位和使用场景契合。进入衰退期是由于业务发展的须要而出现了新的场景，此时软件的概念抽象（又能够称之为“架构”或“主导软件设计”）对于实现新场景下的需求并不友好，致使新开发的代码变成了“贴狗皮膏药”。软件长期处于衰退期的反作用是，软件质量持续变差，开发同窗的编码体验不断降低。

理解软件生命周期的另外一种视角是，软件工程师对于需求的理解是随着时间逐步加深的，很难出现最初的软件设计能知足业务发展的长期须要，毕竟业务也是一每天变得复杂起来的。换句话说，软件进入衰退期是不可避免的，而技术债也是软件发展的天然产物。

走出衰退期的关键是须要让软件进入新一轮的生命周期，而最直接的办法就是“还技术债”，其中包含了重构、或用全新的思路与新技术去解决问题。从小处说来，工程师经过持续重构去还技术债是真正锻炼能力的时候，这个过程会基于个体对业务（或需求）的理解作从新的概念抽象，掌握良好的软件设计能力正是从这些“小处”习得的，也只有具有良好软件设计能力的工程师才有可能驾驭大型软件系统的设计。

软件生命周期理论告诉咱们，一个好软件并不是一直能保持不变，而是能经得起各类改变。固然，各类改变的背后须要以工程能力作支撑，全面经过单元测试、集成测试、系统测试等手段去保障软件的质量，一旦缺失了这些手段就很难创建起对改变的信心，也最终会趋向于固步自封地不变。

对于相似 Service Mesh 这样的平台型技术来讲，都须要很是当心地应对软件生命周期理论。平台思惟是为了解决通用问题，在通用和定制之间找到平衡。当平台技术自身并不能很好地适应技术或业务发展的须要而快速演进时，天然将成为业务发展道路上的阻力而非助力。

结束语

接下来的一年，咱们将持续地探索 Service Mesh 的价值，在兑现 RPC 流量治理价值的同时，完成 RocketMQ 等的 Service Mesh 化，进一步延展 Service Mesh 的流量治理能力并兑现更多的增量业务价值。

咱们致力于解决阿里巴巴内部基础技术的 Service Mesh 化，由于以阿里巴巴自身的业务规模来看更须要 Service Mesh 。接下来，咱们也将与更多业界同仁进行交流，期待经过分享所收获的经验与客户手牵手坚实地进入云原生时代。

若是读者有交流的需求，或者但愿成为阿里巴巴 Service Mesh 的建设者之一，请来信至 zhijian.ly@alibaba-inc.com。

本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。