2019年2月18日 | 作者 ServiceMesher | 14400字 | 阅读大约需要29分钟 查看原文 | 归档于 service mesh | 标签 #Service Mesh https://www.servicemesher.com/blog/service-mesh-summary-2018/

前言

回顾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 的主旋律。我们满怀希望，我们拭目以待！

Service Mesh2018年度总结

应InfoQ的邀请，再次撰写Service Mesh2018年度总结。

此次，邀请了Service Mesh社区的一众好友共襄盛举，希望能为Service Mesh2018年的发展做一个系统而全面的总结。特此鸣谢！

预览地址：Service Mesh2018年度总结

参与者名单：

  • 敖小剑
  • 崔秀龙
  • 单家骏
  • 宋净超
  • 田晓亮
  • 徐蓓
  • 张超盟

资料整理

资料按照国内国外分为两大块。

国外部分，目前主要的service mesh产品：

  • Istio：来自Google/IBM/Lyft，目前最主流的Service Mesh项目
  • Istio平台支持：对Istio提供支持的各主流云平台介绍
  • Envoy：来自Lyft的数据平面，也是Istio默认的数据平面
  • Conduit：来自Buoyant，已经转为Linkerd2
  • Linkerd：来自Buoyant，业界第一个Service Mesh项目
  • Linkerd2：来自Buoyant

各家Network厂商也开始尝试Service Mesh：

国外的Service Mesh的衍生产品，底层支撑，或者外围支持：

  • Cillium：可以和Istio/Envoy一起使用的网络解决方案
  • Kiali：Istio的控制台UI
  • SuperGloo：服务网格编排平台

Envoy的衍生产品：

  • Rotor: Envoy的轻量级控制平面，来自Turbine Labs，已经不再维护
  • Ambassador：基于Envoy的API Gateway
  • Gloo：基于Envoy的API Gateway
  • Contour: 基于Envoy的Kubernetes Ingress Controller

国内的Service Mesh产品：

国内的Service Mesh的衍生产品，底层支撑，或者外围支持：