Service Mesh的2018年度总结

本文做者：敖小剑、崔秀龙、单家骏、宋净超、田晓亮、徐蓓、张超盟

原文地址：skyao/servicemesh2018 

更多 Service Mesh 相关文章请关注 www.servicemesher.com 

前言

在2017年年末，在Service Mesh刚刚兴起之时，应InfoQ的邀请撰写过一篇名为 "Service Mesh年度总结：群雄逐鹿烽烟起" 的文章，对2017年Service Mesh的发展作了一次年度回顾。当时正是Service Mesh技术方兴未艾，各家产品你争我夺之时，一片欣欣向荣的气象。

时隔一年，江湖风云变幻。再次有幸收到InfoQ的邀请，继续进行Service Mesh 2018年的年度总结。本次年度总结将由来自汇集国内ServiceMesh爱好者的 ServiceMesher 社区 的多位嘉宾共襄盛举，但愿能为 Service Mesh 2018年的发展作一个系统而全面的总结。

备注：为了避免重复去年年度总结的内容，咱们将直接从2018年初开始本次年度总结，若是您想了解 service mesh 在2018年前的发展历程，请先参阅2017年年度总结。

为了更有成效的完成总结，咱们将以问答的方式来让下文中陆续出场的各个Service Mesh产品和解决方案提供本身的答案，问题很简单：在2018年，作了什么？

考虑到在2018年，Service Mesh在国内大热，有多家公司推出本身的Service Mesh产品和方案，所以本次Servicemesh 2018 年度总结咱们将分为国际篇和国内篇。

国际篇

2018年，Service Mesh市场的主要竞争者仍是2017年末的出场的几位重量级选手：Linkerd、Envoy、Istio、Conduit等。

Istio

首先来看 Istio，这是 Service Mesh 市场当之无愧的头号网红。

2018年对于Istio来讲是蓄势待发的一年，这一年Istio接连发布了 0.五、0.六、0.七、0.8 和 1.0 版本。

到2018年7月31日 1.0 GA 时，Istio其实已经陆续开发了近两年。1.0版本对Istio来讲是一个重要的里程碑，官方宣称全部的核心功能如今均可以用于生产。1.0版本的到来也意味着其基本架构和API逐渐稳定，那些锐意创新的企业能够开始试用。

咱们以GitHub上的star数量的角度来看一下 Istio 在2018年的受欢迎程度，下图显示的是Istio的GitHub star数量随时间变化曲线。能够看到在2018年，Istio 的star数量增加了大概一万颗，目前已经接近15000颗星，其增加趋势很是平稳。

咱们来按照时间顺序回顾一下2018年Istio的几个重要版本的发布状况，以便对Istio这个目前最受关注的Service Mesh项目在2018年的发展有深刻了解：

• 2018年1月31日，Istio发布0.5.0版本：支持Sidecar自动注入（须要 Kubernetes 1.9及以上版本），增强RBAC支持，尝试修改通讯规则。

• 2018年3月1日，Istio发布0.6.0版本：支持发送自定义Envoy配置给Proxy，支持基于Redis的速率限制，允许为检查和报告分别设置Mixer集群，提供正式的存活以及就绪检测功能。

• 2018年3月29日，Istio发布0.7.0版本：只包含问题修复和性能提高，没有新的功能。初步支持 v1alpha3 版本的流量管理功能。

• 2018年6月1日，Istio发布0.8.0版本：在以前三个平淡无奇的小版本发布以后，Istio 迎来了2018年第一个重大版本0.8.0，这也是 Istio 第一个LTS（长期支持）版本，这个版本带来了大量的更新，架构方面也作了不少改进，主要有：v1alpha3 版本的流量管理功能就绪；缺省使用 Envoy 的 ADS API 进行配置发送；新增 Istio Gateway模型，再也不支持Kubernetes Ingress；支持Helm 安装；支持按需安装Mixer和Citadel模块。另外原有的 API 都通过了重构，CRD 的名字所有更改。

• 2018年7月31日，Istio发布1.0.0版本：这是社区期待已久的版本，也是 Istio 的重要里程碑。不过相对0.8.0版本，主要是修复错误和提升性能，新功能很少。

进入2018年下半年以后，Istio的开发进度明显放缓，1.1版本的发布屡次推迟，直到2018年结束也未能发布（备注：直到本文截稿日的2019年2月10日，Istio最新的版本是1.1-snapshot5）。在1.0版本发布以后的6个月时间，Istio只是以平均每月一个Patch版本的方式陆续发布了1.0.1到1.0.5总共5个Patch版本，这些Patch版本都只有错误修复和性能改善，未带来新的特性。

简单总结 Istio 2018年的发布状况：Istio在上半年经过0.5.0/0.6.0/0.7.0三个小版本陆续进行了小改，在0.8.0版本中进行了惟一一次大改，而后年中发布了2018年最重要的里程碑1.0.0版本，接着是长达6个月的修整期，最后带着迟迟未能发布1.1版本的小遗憾平淡的结束2018年。

与产品演进和版本发布的平淡相比，Istio在市场和社区的接受程度方面表现很是火爆，成为2018年最热门的项目之一，也在各类技术会议上成为备受关注的技术新星。尤为在 Kubernetes社区，更是被视为有望继Kubernetes成功以后的下一个现象级产品。

目前各主流云平台也纷纷提供对Istio的支持：

• NetApp：2018年9月17日宣布收购成立仅3年的云原生创业公司Stackpoint，Stackpoint Cloud 支持建立和管理安全、多云、多region的Istio Service Mesh。

• GKE：做为Istio的主要推进力量，Google天然竭尽全力的支持Istio。在2018年7月Istio 1.0发布以后，Google Kubernetes Engine就提供了对Istio的支持。

• IBM Cloud Kubernetes Service：Istio做为一个开源项目，IBM主要关注流量路由、版本控制和A/B测试方面，Google专一于安全和遥测（来自IBM云计算CTO讲述Istio项目的起源、分工及目标），IBM Cloud 于 2018 年中已提供 Istio 试用。

• Maistra：2018年9月，Red Hat的OpenShift Service Mesh技术预览版上线，基于Istio。Red Hat是Istio项目的早期采用者和贡献者，但愿将Istio正式成为OpenShift平台的一部分。Red Hat为OpenShift上的Istio开始了一个技术预览计划，为现有的OpenShift Container Platform客户提供在其OpenShift集群上部署和使用Istio平台的能力，为此Red Hat建立了一个名为Maistra的社区项目。

在市场一片红红火火之时，咱们不得不指出，到2018年末，Istio 依然在几个关键领域上未能给出足够使人满意的答案，典型如性能、稳定性，Istio 的 1.0 版本并非一个有足够生产强度的稳定版本。Istio 在2018年交出的答案，对于对Istio抱有很是大期待的 Service Mesh 社区来讲，是远远不够的。这直接致使 Istio 目前在生产落地上陷入尴尬境地：虽然试水 Istio 的公司很是多，可是真正大规模的实践不多。

Istio 的2018年年度总结：如期发布了1.0版本，顺利完成了市场布局，扩大了己方阵营，压制了全部竞争对手。

2018年的 Istio 的表现不可谓不成功，可是离社区的期待依然有很是大的距离：关键在于未能真正实现大规模普及。如何打破这一叫好不叫座的僵局，实现真正意义上的生产落地，证实本身，将会是 Istio 2019年面临的最大挑战。

Envoy

相比网红 Istio 在社区的红红火火和产品发布的疲软，另外一位重量级选手 Envoy 则是彻底不一样的表现风格：低调，务实，稳扎稳打，堪称实力派。

在2017年的总结中，咱们称Envoy为"波澜不惊的Envoy"，如下这段内容援引自2017年的年度总结：

在功能方面，因为定位在数据平面，所以Envoy无需考虑太多，不少工做在Istio的控制平面完成就好，Envoy今后专心于将数据平面作好，完善各类细节。在市场方面，Envoy和Linkerd性质不一样，不存在生存和发展的战略选择，也没有正面对抗生死大敌的巨大压力。Envoy在2017年有条不紊地陆续发布了1.二、1.三、1.4和1.5版本，稳步地完善自身，表现很是稳健。

在2018年，Envoy也是一样的波澜不惊，上面这段总结几乎能够一字不变的继续在2018年沿用：只要简单的将版本号变成1.6.0、1.7.0、1.8.0和1.9.0便可。

这是Envoy Github Star的状况。总数7800（只有Istio的一半），其中2018年大体增长了5000个Star，并且增加趋势异常的平稳。

咱们再来细看一下2018年Envoy的版本发布状况，此次咱们换个特别的角度，关注一个细节：Envoy每次版本发布时，都会在Release Note中列出本版本包含的变动列表，很是细致，因此很长很长，每次都是三四页的样子。咱们同时简单计算了一下每次发布包含的commit数量，总体状况以下：

• 2018年5月20日，Envoy发布1.6.0版本：包含392个commit，Release Note 长达四页

• 2018年6月21日，Envoy发布1.7.0版本：包含468个commit，Release Note 长达四页。这个版本是配套Istio 1.0版本做为 Production Ready 的 Service mesh 解决方案。全面支持RBAC鉴权模型, TLS&JWT加密，网络通讯安全性有极大提高。

• 2018年10月4日，Envoy发布1.8.0版本：包含425个commit，Release Note 长达三页

• 2018年12月21日，Envoy发布1.9.0版本：包含414个commit，Release Note 长达三页

若是有兴趣去浏览Envoy在这几回版本发布时的Release Note，就能够发现Envoy在2018年中数量惊人的各类细微改进。咱们也能够简单计算一下，Envoy整年四个版本大概1800次commit，考虑到Envoy在2018年并无大规模的架构改动和特别大的新特性支持，这些commit基本都是各类完善、改进和补充。不得不惊叹于Envoy在这种细致之处刻意打磨的精神，毕竟"细节才是魔鬼"。

Envoy的稳健和成熟，在2018年带来了丰硕成果：

• 被愈来愈多企业使用，不只仅稳稳占据Istio官配Sidecar的位置，并且在网络代理、负载均衡器、网关等领域开始占据传统产品的领地，如nginx、kong。

• 被 Istio 以外的多个公司的 Service Mesh 框架项目采用，如AWS的App Mesh, F5的Aspen Mesh, 微软的 Service Frabric Mesh，国内包括腾讯Tecent Service Mesh，阿里的Dubbo Mesh。Envoy明显有成为 Service Mesh 的数据平面标准的趋势。

• Envoy的xDS API，已经成为Service Mesh数据平面API的事实标准。

Envoy在2018年的成功，还体如今社区开始出现基于Envoy的衍生产品：

• Ambassador：构建于envoy之上的API Gateway，紧追着envoy的新版本，支持与Istio集成，可做为service mesh架构中的ingress gateway。

• Gloo：基于Envoy的Hybrid App Gateway，可做为Kubernetes ingress controller 和API gateway，来自 solo.io。

• Rotor：Envoy的轻量级控制平面，来自Turbine Labs（因为Turbine Labs的公司变更，这个项目已经再也不维护）。

• Contour：基于Envoy的Kubernetes Ingress Controller，来自 Heptio 公司

在2017年的总结中，咱们对Envoy的评价是：

Envoy随后收获了属于它的殊荣：

• 2017年9月14日，Envoy加入CNCF，成为CNCF的第二个Service Mesh项目。

可谓名至实归，水到渠成。做为一个无需承载一家公司将来的开源项目，Envoy在2017年的表现，无可挑剔。

而在2018年，Envoy继续稳健发展，一边伴随Istio一块儿成长，一边在各个领域开疆扩土。Envoy的成功故事在延续，并再次收获属于它的殊荣：

• 2018年11月28日，CNCF宣布Envoy毕业，成为继Kubernetes和Prometheus后，第三个孵化成熟的CNCF项目。

一样的名至实归，一样的水到渠成，Envoy在2018年的表现，一样的无可挑剔。

Envoy 的2018年年度总结，对这位低调的实力派选手，咱们的评价只有一个字：稳！

Buoyant Linkerd系列

做为 Service Mesh 的先驱，Linkerd 和 Linkerd 背后的初创公司 Buoyant 在过去两年间的故事可谓波澜起伏，面对出身豪门的网红 Istio ，Buoyant 在2017年便被逼入绝境，2018年的 Buoyant 几乎是以悲剧英雄的形象在进行各类突围尝试，寻找生路。

Linkerd 1.×

Linkerd的2018年，是突围的一年，做为定义Service Mesh概念的先驱，其Github Star数量在2017年末就已经被Istio超越，虽然一直有平稳增加，已经无力与Istio一较高下了。下面按照时间顺序整理一下 Linkerd1.x 版本在2018年之中的几个关键节点。

• 2018年5月1日，在持续了几个月对1.3.x版本的修修补补以后，发布了1.4.0版本，其中使用了最新版本的Finagle和Netty组件，尝试下降在大规模应用的状况下的内存占用，并开始在可观察性方面的持续改进；

• 2018年6月，宣布成立Linkerd + GraalVM工做组。尝试使用GraalVM提升Linkerd的性能。据笔者观察，其讨论到9月就已经再无更新，而且并未产生可发布的任何进展；

• 2018年7月14日发布的1.4.5中，提供了对Open J9 JVM的支持，声称可能下降40%的内存占用以及大幅下降p99延迟；

• 2018年10月3日，发布了1.5.0，其中有一项很值得注意的变动：Istio特性被标记为deprecated。事实上在8月份的讨论中，已经有人提出，在Linkerd 1.1.1版本以后，对Istio的支持并未进步，同时也没有明确迹象代表有用户对Linkerd数据平面结合Istio控制平面的方案感兴趣，所以Linkerd开始逐步中止对Istio的支持。

能够看到，2018年中，Linkerd的Istio Sidecar方案和GraalVM性能优化方案均已无疾而终，目前硕果仅存的是Open J9 JVM的优化版本，其测试版本还在继续发行。

Conduit

而诞生于2017年末的Conduit，形势稍微乐观一点，可是根据Github star的观察，表现也仅是优于同门的Linkerd，和Istio相比，仍然不在同一数量级，其更新频度很是高，基本作到每周更新，呈现了一种小步快跑的态势。固然，这种快速更新的最重要缘由应该就是其相对稚嫩的状态，和成熟的Linkerd相比，Conduit还只是刚刚起步，下面也根据Release状况看看2018年里 Conduit 项目的进展：

• 2018年2月1日，发布Conduit v0.2.0，提供了TCP和HTTP的支持；

• 2018年2月21日，发布v0.3，宣布进入Alpha阶段，为负载均衡功能提供了负载感知的能力；

• 2018年4月17日，发布v0.4.0，提供了对MySQL和SMTP的透明支持能力；

• 2018年6月5日，发布v0.4.2，支持所有Kubernetes Workload；

• 2018年7月6日，发布最后一个Conduit版本，v0.5.0，提供了Web Socket支持，加入自动TLS支持，改名为Linkerd 2.0；

Linkerd 2.×

很明显，在2018年年中，Buoyant 意识到继续同时支撑 Linkerd1.x 和 Conduit 两条产品线已经不合时宜。并且 Linkerd1.x 的硬伤太过明显：

• 基于Scala/JVM的数据平面，在性能和资源消耗方面，对阵基于 c++ 并且表现异常成熟稳重的 Envoy，毫无优点。在2018年针对 Linkerd 1.× 的各类性能优化无疾而终以后，答案已经很明显：Linkerd 1.× 已经再也不适合继续用来做为数据平面。

• 相对 Istio 强大的控制平面，Linkerd 1.x 在控制平面上的缺失成为关键弱点。尤为 Linkerd 1.x 晦涩难懂的 dtab 规则，面对 Envoy 的 xDS API，在设计和使用上都存在代差。

• 而以 Linkerd 为数据平面去结合 Istio 控制平面的设想，在通过一年多的尝试后无奈的发现：这个方案根本没有市场。

所以，合并产品线，放弃 Linkerd 1.×，将力量集中到 Conduit 这个将来方案就成为天然选择。而 Linkerd 原有的市场品牌和号召力，还有 CNCF 项目的地位也应该保留，所以，Buoyant 选择了在2018年7月，在 Conduit 发布 v0.5.0 时将 Conduit 改名为 Linkerd 2.0。

Linkerd 2.x 版本的目标则具备很明确的针对性：提供一个轻量级、低难度、支持范围有限的Service Mesh方案，9月份宣布GA并获得客户采用，证实这一策略仍是行之有效的。

• 2018年9月18日，Linkerd 2.0宣布被WePay、Hush、Studyo以及JustFootball采用，进入GA阶段；

• 2018年12月6日，Linkerd 2.1发布，推出了路由级的遥测能力。更重要的是，提出了Service Profile的概念，这一律念以服务为中心，将服务相关的大量CRD聚合成统一一个，对服务网格的管理无疑是一个强大助益。

2018年末提出的Service Profile概念，虽然只是一个雏形，目前仅提供了一点监控方面的功能，可是其Roadmap中指出，往后将会把大量特性集成到Service Profile之中，笔者认为相对于Istio的Mixer适配器模型来讲，这一律念可以极大的下降运维工做难度工做量，并有效的简化服务网格的管理工做。

在 Istio 封锁了 Service Mesh 的门以后，通过一年摸索和碰壁，Linkerd2发现了Service Profile的这扇窗，能够说是尚存但愿。

对Buoyant的总结

做为 Service Mesh 的业界先驱，Buoyant 在早期有很是大的贡献和成就，可是在 Istio/Envoy 发起的强力攻势面前，几乎没有招架之力。2018年，若是不是 Istio 由于自身缘由在产品发展上表现疲软留给了 Buoyant 一线生机，Buoyant 几乎无立锥之地。

回顾2017年和2018年 Buoyant 的表现，笔者的见解是 Buoyant 的问题主要体如今对竞争对手和对本身的认知都不够清晰，致使在产品策略上接连犯错：

• 在 Istio 出来以前，面对 Envoy，Linkerd 1.× 系列的劣势就很明显，只是 Linkerd 做为市场上第一个 Service Mesh 类产品，光环太盛，遮挡了社区和客户的视线，可是 Buoyant 本身不该该迷失。面对强力竞争对手，未能及时反思并调整布局，这是 Buoyant 犯下的第一个错误。没能意识到自身的不足，致使后面在数据平面上始终被 Envoy 遥遥领先。

• 在 Istio 出来以后，在原有数据平面对阵 Envoy 已经存在劣势的前提下，控制平面也出现代差，还有 Google 和 IBM 站台致使原来面对 Envoy 的市场宣传和社区支持的优点也荡然无存。此时 Buoyant 就应该完全检讨并给出全新方案，可是 Buoyant 当时的选择是让 Linkerd 做为数据平面去兼容 Istio，而未能在控制平面上及时发力。

• 2017年末，Conduit 的推出原本是一步好棋，2017年年末和2018年年初 Istio 表现糟糕，甚至有些混乱，Conduit 的推出也符合社区但愿存在良性竞争的心态。然而 Conduit 的数据平面采用 Rust 语言，虽然性能表现卓越，可是过于小众，致使来自开源社区的 contributor 数量极其稀少，根本没法从社区借力。

• 2018年，在推出 Conduit 以后，迟迟不愿放弃 Linkerd 1.×，直到2018年年中才在各类尝试无效以后最终选择放弃 Linkerd 1.×。其实这个决定，本能够在更早的时间点作出。

因为 Envoy 在数据平面上的优越表现，和 Buoyant 在产品策略上的接连失误，使得2018年的 Linkerd 1.× 、Conduit 、Linkerd 2.× 一直都 Envoy 的阴影中苦苦追赶，始终没法在控制平面上对 Istio 造成实质性威胁。

2018年对 Buoyant 及旗下的Linkerd系统的总结是：犹豫太多，决心下的太晚，新产品缺少吸引力足够大的亮点，前景很不乐观。

2019年，对 Buoyant 来讲，颇有多是生死存亡的一年，用咱们熟悉的一句话说：留给 Buoyant 的时间已经很少了。

其余产品

在前面的内容中，咱们用了不少的篇幅来总结 Buoyant 面对 Istio + Envoy 组合的种种应对之策，而这个话题，对于任何但愿出如今 Service Mesh 市场的玩家来讲，都是一个避无可避的问题。

接下里咱们将列出，在 Istio、Envoy 和 Linkerd系列这些主要竞争者以外，Service Mesh 市场上陆陆续续出现的来自各家公司的参与者：

• Nginmesh：来自大名鼎鼎的nginx，在2017年9月nginx对外宣布了这一产品，是一款适配Istio的service mesh方案，使用NGINX做为sidecar替换Envoy。但nginx在Nginmesh上的态度摇摆不定：在2017年下半年发布了3个小版本以后就中止开发。2018年从新启动，接连发了几个小版本，可是在2018年7月发布0.7.1版本以后，再次中止开发。

  总结：Envoy 是座大山，是条鸿沟，在数据平面试图正面挑战 Envoy，须要很是大的努力和投入。这本是一个很是严肃的话题，而 nginmesh 一直摇摆不定没有持续投入，在勤勉的 Envoy 面前不会有机会的。

• Consul Connect：Consul来自HashiCorp公司，主要功能是服务注册和服务发现，基于Golang和Raft协议。在2018年6月26日发布的Consul 1.2版本中，提供了新的Connect功能，可以将现有的Consul集群自动转变为Service Mesh。亮点是能够提供自动的双向TLS加密通讯以及基于惟一标识的权限控制。

  总结：Consul 的方案，一直以来社区都没啥反馈。很差评价，让时间说话吧。

• kong：在2017年就有传闻说kong有意service mesh，但一直不见kong的明确动做。在2018年9月，kong宣布1.0发布以后kong将转型为服务控制平台，支持Service Mesh。关于kong到底会不会投身service mesh的悬念也就一直贯穿整个2018年度，直到12月21日，kong 1.0 GA发布时才明确给出：kong能够部署为独立的service mesh proxy，开箱即用的提供service mesh的关键功能，并集成有 Prometheus、Zipkin，支持健康检查，金丝雀发布和蓝绿部署等。

  总结：Kong做为一个从API网关演变而来的 service mesh 产品，背靠成熟的OpenResty，虽然相对 istio + envoy 在功能性上稍显不足，不过胜在简单、可扩展性强，比较适合中小型团队以及之前 kong 的老用户试水 service mesh。考虑到 kong 社区比较活跃，也许能走出一条和 Istio 不一样的道路。

• AWS App Mesh：AWS APP Mesh是AWS今年在re:Invent 2018大会上发布的一款新服务，旨在解决在AWS上运行的微服务的监控和控制问题。它主要标准化了微服务之间的通讯流程，为用户提供了端到端的可视化界面，而且帮助用户应用实现高可用。App Mesh 使用开源的 Envoy 做为网络代理，这也使得它能够兼容一些开源的微服务监控工具。用户能够在 AWS ECS 和 Amazon EKS 上使用 App Mesh。从官网放出的流程图能够看出，App Mesh 是对标 Istio。目前App Mesh提供公开预览。

  总结：AWS APP Mesh 的选择，和 Buoyant 的 Linkerd 系列彻底相反，选择 Envoy 做为数据平面，从而避免和 Istio 在数据平面进行竞争，毕竟 Envoy 珠玉在前，而数据平面又是最为考验技术底蕴和细节完善，费时费力。AWS APP Mesh 能够集中精力主攻控制平面，趁 Istio 还未彻底成熟之时，依托AWS 完善的体系力求在 Service Mesh 领域有本身的一席之地。AWS APP Mesh 支持客户在 EC2 和 Kubernetes 环境下同时部署应用并能实现相互访问，一旦成熟，将有多是一个大卖点。

• Aspen Mesh：来自大名鼎鼎的F5 Networks公司，基于Istio构建，定位企业级服务网格，口号是”Service Mesh Made Easy”。Aspen Mesh项目听说启动很是之早，在2017年5月Istio发布0.1版本不久以后就开始组建团队进行开发，可是一直以来都很是低调，外界了解到的信息很少。在2018年9月，Aspen Mesh 1.0发布，基于Istio 1.0。注意这不是一个开源项目，可是能够在Aspen Mesh的官方网站上申请免费试用。

  总结：这表明着 Service Mesh 市场上的另一种玩法，依托 Istio 进行订制和扩展，提供企业级服务。若是 Istio 能如预期的实现目标，成为新一代微服务，成为链接云和应用的桥梁，则将来极可能会有更多的公司加入这一行列。

• SuperGloo：这是由初创公司 solo.io 发起的开源项目，做为一款服务网格编排平台，目前能够管理Consul、Linkerd和Istio，SuperGloo的目标是在下降服务网格的复杂性的同时最大化采纳服务网格的收益，SuperGloo帮助用户快速得到服务网格的经验，接管服务网格中的一些关键功能，统一了Ingress 流量（南北向）和网格流量（东西向）的管理，为自由组合任何服务网格和Ingress打开了大门。

  总结：这是一个使人瞠目结舌的疯狂想法，在服务网格还在努力证实本身能行，咱们这些先行者还在努力试图说服更多的人接受这一新鲜事物时，SuperGloo 又往前大大的迈进了一步。服务网格编排，咱们暂时没法评论说这是高瞻远瞩，仍是脑洞大开，仍是留给时间和市场吧，或许2019年咱们再次进行年度总结时形势能明朗一些。

从社区的角度，咱们但愿有更多的参与者进Service Mesh市场，以推进Service Mesh的健康发展。可是实际状况是，在Istio的光辉之下，新晋产品的发展前景都不太客观，是和Istio全面对抗？仍是另辟蹊径寻找适合本身的生存空间？是每一个产品都要面对的问题。

国际篇小结

Envoy 和 Linkerd 均可以说是目前 Service Mesh 产品的先驱，然而在刚刚过去的2018年中，其处境差距却不啻云泥：Istio借力Envoy，凭借其强大的号召能力和优秀的整体设计，干净利落的将Linkerd打落尘埃。然而Istio在占领Service Mesh的注意力聚焦以后，在整个2018年中，其发布进度表现出使人印象深入的拖沓。

Service Mesh这一技术的广阔前景，加上Istio的疲弱表现，吸引了更多对此技术具备强烈需求或相关技术储备的竞争者出现，除了 AWS 、 F5这样的公有云方案，以及Consul、Kong等同类软件解决方案，还出现了Solo.io这样的更加激进的跨云方案加入战团。

Service Mesh技术的浪潮已将业界席卷其中，然而这一年来，角逐者有增无减，2019年里，Istio还是关键——除非Istio可以作出符合顶尖项目的水准，不然，Service Mesh技术极可能会以多极化、市场细分的形式落地。

国内篇

2018年，国内在Service Mesh方面也投入了很大的力量，包括蚂蚁金服、腾讯、阿里、华为、微博等都研发了本身的Service Mesh产品。这里简单介绍一下它们的技术选型及在2018年所作的工做。

蚂蚁金服 SOFAMesh+SOFAMosn

蚂蚁金服是目前国内 Service Mesh 领域的领头羊，高度承认 Service Mesh 的前景，脚踏实地的在准备 Service Mesh 的大规模落地，决心和投入都很是大。

蚂蚁金服的Service Mesh解决方案目前主要有两个产品组成：

• SOFAMesh项目：蚂蚁金服 Service Mesh 的控制平面，跟随社区，Fork 自 Istio，保持同步更新。在Istio体系和框架内进行功能补充/扩展/加强/改进，立足于探索并解决 Istio 生产落地，尤为是大规模落地中遇到的实际问题，包括对各类RPC通信协议的支持，对单进程多服务的传统SOA服务的支持。为了知足公有云上对客户提供 Service Mesh 托管服务，还提供了多租户的支持。

• SOFAMosn项目：蚂蚁金服新型基础设施和中间件的底层网络通用解决方案，能够有多种产品形态，2017年末启动，基于Golang开发。在蚂蚁金服 Service Mesh 中承担数据平面的角色，和 SOFAMesh 项目配合使用，兼容 Istio 体系。此外 SOFAMosn 还将用于 Ingress / API Gateway / Serverless Function Gateway 等场景，以及Message Mesh等其余形态的Mesh，成为蚂蚁金服将来Mesh网络的核心组件。

以上两个产品都已经于2018年7月在 GitHub 开源。

通过2018年的开发和小规模落地使用，目前 SOFAMosn 和 SOFAMesh 项目都已经基本成型，2019年即将在蚂蚁金服大规模落地，支撑蚂蚁金服上云的战略目标。其中SOFAMesh还将在蚂蚁金融云上以 Service Mesh 托管服务的形式为客户提供支持，充分结合云和Service Mesh的优点。

新浪微博WeiboMesh

WeiboMesh 是微博内部跨语言服务化解决方案，目前已经在微博多条业务线上获得普遍使用，这其中不乏热搜、话题等核心项目。 2018 年 WeiboMesh 核心方向是从内部场景提炼实际业务需求，推进大规模业务低成本接入 Mesh 体系，其主要工做包括：

• 强化了管理端口，提供了基于不一样维度的 Mesh 管理方式（维护调试、服务管理/Mesh 注册中心等）

• 优化，并丰富了 Mesh 控制平面的功能，提供了 Tracing、熔断，限流等功能

• 提供 HTTPMesh 方案，支持 HTTP 与 RPC 服务之间的交互，进一步下降接入门槛

• 支持了基于 MC 协议的 CacheService，在资源服务化方面迈出重要一步

• 提供了 Python、C++ 语言的支持

华为Mesher与ASM

Mesher基于华为开源的ServiceComb，ServiceComb是一个java与go语言的微服务编程框架， 在2017年末加入的Mesher补充完善了微服务解决方案。

在生产中获得了验证后， 华为在8月份开源了Mesher，以完善ServiceComb开源生态。从发展目标来看，Mesher并不仅支持Kubernetes， 而是支持任意的基础设施，包括容器，虚拟机等。而且让ServiceComb支持异构的注册中心管理，能够统一的在一个service center中发现不一样基础设施，不一样数据中心的微服务，以此来更好的支持混合云场景。

华为云 Istio 团队在 Istio 生态上投入了很大力量，并基于 Istio 发布了本身的ASM（Application Service Mesh），ASM深度集成华为云容器服务CCE(Cloud Container Engine)，提供非侵入的智能流量治理解决方案，包括负载均衡、熔端、限流等多种治理能力。内置金丝雀、蓝绿等多种灰度发布流程，提供一站式自动化的发布管理。基于无侵入的监控数据采集，整合华为云APM能力，提供实时流量拓扑、调用链等服务性能监控和运行诊断，构建全景的服务运行视图。ASM于2018年8月对外公测。

阿里Dubbo Mesh

Dubbo Mesh为阿里自研的服务化框架Dubbo的Service Mesh组件，其技术选型为：

• 数据平面选型Envoy。Envoy所定义的、被普遍接受的xDS协议可以很好地体现了Dubbo对Service Mesh具备“规范化”做用的理解。

• 控制平面选型Istio的Pilot组件。以Istio目前的架构设计和结合阿里巴巴集团已有软件资产的现状，其总体并不足以承载起对Service Mesh的要求。然而，其中的Pilot组件的平台抽象设计、对Envoy xDS协议的实现能很好地加速Service Mesh在阿里巴巴集团生产环境的落地。

接下来，Dubbo Mesh将进一步组合阿里巴巴集团已开源出来的各类组件去加强其监管控能力。好比，经过将Sentinel的能力归入到Dubbo Mesh，能很好地补全限流、降级和熔断的能力。

腾讯Tencent Service Mesh

腾讯service mesh属于腾讯内部的下一代微服务技术中台，在腾讯内部业务如广告平台等获得充分的验证，并随腾讯云微服务平台（TSF）于2018年6月上线内测，随后在9月集成了Istio 1.0并发布了里程碑版本，产品将于2019年1月全面公测。

产品技术选型上，控制面选用了集百家之长的istio，数据面则选用了成熟稳定的高性能边缘代理envoy。

在开源之上，腾讯云根据业务现状及客户诉求作了如下扩展及改造：

• 支持多计算平台集成。能支持虚拟机，物理机的服务自动接入Service Mesh

• 支持多服务框架互通。能同时支持SpringCloud与Service Mesh业务进行互通

• 支持分布式服务寻址。业务能够经过服务名直接接入Service Mesh框架

Service Mesh衍生产品

除了完整的Service Mesh产品以外，国内也出现了一些基于Istio的外围项目，如：

• Naftis：小米武汉研发中心推出的管理Istio任务的Dashboard，用Istio治理服务时须经过istioctl或kubectl，这种方式可能存在一些问题。Naftis经过任务模板的方式来帮助用户更轻松地执行Istio任务。用户能够在 Naftis中定义本身的任务模板，并经过填充变量来构造单个或多个任务实例，从而完成各类服务治理功能。

• Istio-ui：Istio的简易UI，它是jukylin的我的项目，其初衷是线上几百个istio配置文件管理会很麻烦，而官方和社区并无给出解决方案。在此基础上，结合当前服务环境，增长了校验，注入，模板等功能。

国内篇小结

从上面的介绍能够看到，国内在 Service Mesh 领域上和国际靠的很近。

技术社区方面，在Service Mesh诞生不久，国内就出现了 Service Mesh 的爱好者、交流社区、布道师，诞生了 ServiceMesher 这样专业而专一的垂直技术社区，极大的促进了 Service Mesh 技术在国内技术社区的普及和发展。以InfoQ为表明的技术媒体也对 Service Mesh 这一新兴技术给予了高度关注，在 QCon/ArchSummit 等国内顶级技术峰会上常常能够看到 Service Mesh 相关的演讲主题。

在产品方面，以蚂蚁金服、新浪微博、华为、阿里、腾讯等公司为表明的国内互联网公司，以多种方式给出了符合自身特色的 Service Mesh 产品，思路和打法各有不一样。

具体说，在数据平面上有三种流派：

1. 选择 Envoy，如腾讯Tencent Service Mesh、阿里Dubbo Mesh

2. 自行开发，如新浪微博WeiboMesh、华为Mesher

3. 也是自行开发，可是和 Envoy 或者说 Istio 兼容，如蚂蚁金服SOFAMosn

其中，自行开发的数据平面，无一例外的选择了Golang语言，这一点上却是容易理解：c/c++直接用Envoy；Java、Scala等因为JVM的缘由，在资源消耗上不太适合，Linkerd前车可鉴；Rust之类又实在过小众，一样Conduit前车可鉴。

Golang在各方面比较均衡，成为c/c++以外数据平面的最佳编程语言选择。只是，如前所述，Envoy 的优越表现使得 Service Mesh 数据平面的竞争过早的偏向 Envoy，而 Buoyant 在数据平面编程语言的选择上，先有过于保守的Scala，后是过于激进的Rust，错失各方均衡的Golang，使人叹息。

在控制平面上，也是三种流派：

1. 自行开发，如新浪微博WeiboMesh、华为Mesher

2. 依托Istio进行扩展和订制，如蚂蚁金服SOFAMesh，华为ASM

3. 只重用 Istio 的 Pilot 组件，将 Pilot 从 Istio 中剥离出来配合 Envoy 使用，弃用 Mixer 和 Citadel。如腾讯Tencent Service Mesh、阿里Dubbo Mesh。这个选项的存在，一方面和国内 Kubernetes 普及程度不高而 Istio 目前基本绑定 Kubernetes 平台有关，另外一方面也是对 Istio 中 Mixer、Citadel 两大组件的质疑。

2018年国内 Service Mesh 的发展状况，整体上说是多方参与，各类落地和探索，技术社区反应热烈，对于一个新兴技术而言已是很是理想的状态。固然受限于 Service Mesh 的发展阶段，目前还远没有达到全面普及的程度，还有待于当前 Service Mesh 产品的进一步成熟与完善。

总结

Service Mesh 在2018年虽未能如预期的全面走向成熟，未能如Service Mesh 爱好者们所期待的成为 "the year of Service Mesh" ，可是总体上 Service Mesh 的发展势头还算不错：Envoy、Istio日渐成熟，Linkerd 2.× 也在推动，而国内也出现了多个产品，其中蚂蚁金服、华为等的投入还很是可观。对 Service Mesh 来讲，2018年是蓄势待发的一年。

回顾2017年的年度总结，在结尾处展望2018年 Service Mesh 的发展时，这样写到：

2018年对Service Mesh而言，必然不是一路顺风，必然是充满荆棘和坎坷的。如何实现从技术理念到产品落地，如何实实在在地解决实践中遇到的各类问题，将会是这一年中相当重要的事情。

今天，咱们回顾2018年的 Service Mesh，会发现的确如去年预期的，2018年 Service Mesh 市场上的几个主要产品，都还在产品落地和生产实践上努力探索。只是这个过程，比咱们预期的要慢一些，遇到的问题也比预期的要多一些，以致于在2018年结束时，咱们未能看到一个求之不得的完美答案，而不得不将对 Service Mesh 的美好期许，留待2019。

2019年的Service Mesh，将会继续充满艰辛和痛苦，将须要更多的努力与执着。落地，落地，落地，将会是2019年 Service Mesh 的主旋律。咱们满怀但愿，咱们拭目以待！