简介： 过来一年，阿里巴巴在 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 的序列化协定存在 Hessian2、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。

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。