Service Mesh：调度千军万马微服务，2.0妥妥的

过去一年，继Kubernetes风靡，Service Mesh已成功上位变成当之无愧的技术网红。

TA不但可以极大简化用户使用体验，还将大中型企业的Kubernetes落地引向“实处”。

对于绝大多数使用容器的企业来说，似乎一夜之间，Service Mesh就成长为完善容器部署的功能担当，不容小觑。

并被一度当作云原生技术栈的关键组件之一，人称“新一代微服务架构”，即2.0版本。

从逻辑出发，如果想聊透Service Mesh，还是要先谈谈微服务的。

用维基百科的话说，所谓微服务，可被定义为一种软件架构风格。

这个风格比较专注单一责任与功能的小型区块，利用模块化的方式组合出复杂的大型应用程序。

在此过程中，各功能区块的使用与语言无关的API集达成相互通信。

简单来说，在云原生微服务的模式下，哪怕是单个应用也可能由数百个服务组成。

此基础上，每个服务又包含多达上千个实例。

如果你真想抽丝剥茧一下下，其实每个实例又很有可能被像 Kubernetes 这样的服务调度器不断调度，而产生千变万化的形态。

尽管形态复杂多样，但端到端通信的可靠性与性能优势却始终至关重要。

这时候Service Mesh就派上了用场。

本质上就是将服务间的通信从无法发现与控制的基础设施中分离出来，并达成监控、管理与控制的目标。

显而易见，关于Service Mesh的定义，广泛被接受的一种，是控制应用程序不同部分彼此共享数据的方式。

作为一个专门让服务与服务之间的通信变得安全、快速以及可靠的基础设施，Service Mesh确实可以做到通过服务通讯，让整个架构更为先进和Cloud Native。

在某些方面，这有点儿像网络七层模型中的第四层 TCP 协议。

但与TCP不同的是， TA想要达成的目的不仅仅是正常的网络通讯。

还着力为应用提供了统一的，可视化的以及可控制的控制平面。

如果追根溯源，Service Mesh 并不算是什么新技术；如果一定要说创新的话，更多则是功能所在位置的改变。

实践证明，Service Mesh确实可高效做到屏蔽分布式系统通信的复杂性，只关注业务逻辑。

对于服务语言没有限制，只需和Service Mesh通信即可。

更重要的是，对应用透明，组件可单独升级。

止步于开源，那些鼎鼎大名的service mesh项目数一数

从2016年1月，业内第一个开源项目Linkerd发布，“Service Mesh”首次在公开场合被使用；到控制平面概念及作用被人们认可并接受以至于到今天。

我们发现热闹归热闹，虽然如火如荼，但还尚未出现完全现成的商业产品。

大部分的Service Mesh仅仅止步于开源项目，例如现在比较知名的Linkerd、Istio 等。

1、2、3，那就从Linkerd说起吧！

Linkerd最初是由Buoyant团队在2016年打造的一个服务网格项目。

从Twitter开发的library中分离出来并由Scala语言编写，设计理念是支持基于主机（物理主机或者虚拟节点）的部署模式，算是开源项目中资历比较深厚的。

有关资料显示，Conduit，也是该领域另一位颇具影响力的选手，多年前已成功合并到Linkerd项目，并在2018年7月发布为Linkerd 2.0 版本。 

关于Conduit的研发初衷，很多人总结为是由于最初版本的内存占用问题广受诟病，所以Conduit确实表现更加轻量级，为Kubernetes定制，用Rust和Go语言编写，但与当下广泛提及的Istio相比，依旧不在一个数量级别上。

但更多人认为，Buoyant 是意识到继续同时支撑 Linkerd1.x 和 Conduit 两条产品线已经不合时宜，此外Linkerd1.x无论是在数据平面还是控制平面上表现都很堪忧。

所以，合并产品线并保持品牌效力更关键。

可喜的是，从1到2，我们发现Linkerd 2.x 主要基于Kubernetes，而Linkerd 1.x 则可以基于节点模式部署，当面临复杂环境的场景时，开发者完全有更灵活的选择方向，对部署更是恰到好处。

就在2018 年 12 月，Linkerd 2.1 也顺势被发布，推出了路由级的遥测能力。

更重要的是，此次发布率先提出了 Service Profile 概念，以服务为中心，将服务相关的大量 CRD 聚合统一，这对服务网格的管理助力不小。

伴随发展，2017 年 1 月，开源的 Service Mesh 软件 Linkerd 就正式加入了云原生基金会，成为云原生基金会的官方项目并至今影响深远。

但从近些年掌握的发展情况来看，面对出身豪门的网红 Istio 以及在数据平面上表现优越的Envoy，Linkerd更多是力不从心，想要改变其现状，恐怕还需在战略敏感度以及技术升级上做做功课。

如果说Linkerd是服务网格的开山鼻祖，那Istio可谓是目前这个领域实实在在的“流量大花”。

由Lyft、IBM与google联合开发的Istio，相比 Linkerd、Envoy这些典型的服务网格，提供了一个更加完整的解决方案，包括行为洞察以及操作控制在内，主要用来满足微服务应用程序的多样化需求。

所以，Istio是一个服务网格没错，但又不仅仅是服务网格那么简单。

具体来说，TA可以做到在不修改微服务源代码的前提下，轻松为其添加负载均衡、身份验证等强功能，并通过控制Envoy等代理服务来控制所有流量，其中Istio基于Envoy代理并以之为数据层（data plane）。

另外，Istio还提供了容错、金丝雀部署、A/B测试、监控等功能，甚至可以支持自定义的组件和集成，对此官方有云：

流量管理：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。

可观察性：了解服务之间的依赖关系以及它们之间流量的本质和流向，从而提供快速识别问题的能力。

策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。

服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。

总之一句话，Istio极大的减少了应用程序代码，底层平台和策略之间的耦合，使微服务更容易实现就对了！

作为各种技术前沿会议中备受瞩目的创新技术，世界范围各主流云平台都对Istio伸出了橄榄枝，比方说IBM Cloud Kubernetes Service以及Red Hat 创建了一个名为 Maistra 的社区项目等。

但不难发现的一点，虽说Istio是如今最炙手可热的服务网格，但实际落地的生产场景并不多，更多是选择在测试环境中试用，其应用价值确实受到某种限制。

对此专业人士持这样的观点：原本使用像Istio这样的服务网格是为了希望能够降低微服务管理或者治理复杂度，更好观测运行状况，更容易完成熔断限流，进行灰度发布等。

但在实际操作中，我们会发现非但没有降低微服务的复杂度，反而是引入了一个同样复杂的技术。

是否应该将一些主线变成单体应用去做统一部署，从而降低service mesh管理控制平面本身的使用和维护的复杂度呢？

事实上，最近数月Istio接连发布了1.5和1.6版本。

相比2018年-2019年度的频繁更新，大多只涉及到错误修复和性能改善，未带来新的特性的情况，目前的1.5版本算是重大变革之一。

该版本似乎回应了社区里关于Istio性能和易用性的诟病，重建了新架构即回归单体。

具体来说，由原来更分散的微服务架构、控制平面做了一些收缩与整合，变为一个更加集中的方式。

将过去一些过于复杂的分散式组件，集中到了Istio核心的控制平面中，从而降低了使用管理的难度系数。

另外，以前的mxier组件，在1.5版本中被移除，该能力通过其他方式来实现，组件删减之后也对性能方面带来显著提升。

总体来说，就是提升性能并降低复杂度，从而让用户能够更容易去采纳这样的新技术。

回顾Istio的一路走来，如何打破叫好不叫座的局面，真正实现生产环境落地的意义，可能是未来很长时间都需要证明自己的事儿。

相比Istio的任重道远，作为Istio中的Sidecar官方标配，Envoy也有很吸睛的表现。 

Envoy，由Lyft创建，为了直击完整的ServiceMesh功能，它牢牢占据了“数据平面”的部分，与其进行匹配。

作为一个面向服务架构的高性能网络代理，Envoy由C++语言实现，拥有较为强大的定制化能力。

主要通过其提供的Filter机制，基本可以对请求转发过程中超过50%的流程做定制化，在性能方面由于其实现参考了Nginx，也处于主流水平。

其作为Sidecar其提供的核心功能可以被简单总结：对业务透明的请求拦截；对拦截请求基于一定规则做校验、认证、统计、流量调度、路由等。

其中对于请求校验规则的多与少、遥测数据的采集精细度、数据统计的维度多样性等算是复杂性需求的展现。

因此最有可能提升Sidecar性能的技术方向，就是对请求的拦截与Sidecar之间通讯协议的高效性。

目前Envoy被越来越多企业使用，不但稳稳占据了 Istio 官配 Sidecar 的位置，还在网络代理、负载均衡器上展露锋芒。

甚至广泛被 Istio 之外的多家企业 Service Mesh 框架项目采用，明显有成为 Service Mesh 的数据平面“风向标”的倾向。 

2017 年 9 月，Envoy 加入 CNCF，成为 CNCF 的第二个 Service Mesh 项目；2018 年 11 月 ，CNCF 宣布 Envoy 毕业，成为继 Kubernetes 和 Prometheus 后，第三个孵化成熟的 CNCF 项目，前景乐观。

当然，除了这些传统的开源项目外，Service Mesh 竞争版图中也陆陆续续迎来了各种企业级的参与者，例如Nginmesh。

来自名声在外的nginx，作为2017 年 9 月对外宣布的一款产品，适用于 Istio 的方案，本质上就是使用 NGINX 作为 sidecar 来替换 Envoy。

另外，Consul 来自 HashiCorp 公司，主要功能是服务注册和服务发现，以及作为一个从 API 网关演变而来的 service mesh 产品，名叫Kong等。

关于Service Mesh 技术，这些大企业代表都有何频频动作？

如上文所言，Service Mesh确已席卷全球，过去一年时间中，已有多家公司竞相推出自己的 Service Mesh 产品和方案，例如AWS，就是引人注目的一家。

去年4月，AWS 震撼宣布了 App Mesh GA。

App Mesh 作为 AWS 推出的 AWS 原生服务网格，与 AWS 完全集成，主要组件包括：网络（AWS cloud map）；计算（Amazon EC2 和 AWS Fargate）以及编排工具（AWS EKS，Amazon ECS 和 EC2 上客户管理的 k8s）。

值得提及的一点，App Mesh的数据平面采用 Envoy，产品同时支持VM和容器并支持多种产品形态。

适用于Amazon ECS、Amazon EKS和Kubernetes on EC2，另外还支持开源Envoy代理，本质上帮助开发人员监控以及控制跨微服务的通信。

具体来说，使用App Mesh来建模的所有微服务的连接方式，都会自动计算并向每个微服务代理发送相应的配置信息。

这样就达成了跨整个应用的程序标准化，以及易用性与流量控制等要求。

相比AWS青睐 Envoy，Google的打法则是围绕 Istio 。

最初，Google在2018年底推出了 Istio on GKE，并提供遥测、日志、负载均衡、路由等能力。

接着又推出了 Google Cloud Service Mesh。

作为Istio的完全托管版本，不仅仅提供开源版本的完整特性，还集成了 Google Cloud上的重要产品 Stackdriver 。

旨在解决企业中增长最快的成本问题之一，即跨混合环境的管理复杂性。

随后，Google拿出了 Traffic Director 的 beta 测试版本，被定义为完全托管的服务网格流量控制平面。

不但支持全局负载均衡，适用于虚拟机和容器，还提供混合云和多云支持、集中式健康检查和流量控制；此外还有一个非常特别的特性，支持基于流量的自动伸缩。

对比Google的高调支持，微软更聚群力，推出了Service Fabric Mesh。

据了解，Azure Service Fabric 是Microsoft的微服务框架，最初设计用于公共云，内部部署以及混合与多云架构。

而 Service Fabric Mesh 是 Azure 完全托管的产品，于2018年8月推出预览版。

此外微软还在 KubeConf 上推出 Service Mesh Interface，作为在 Kubernetes 上运行服务网格的规范。

SMI 定义了由各种供应商实现的通用标准，使最终用户的标准化与创新可以做到兼顾，预期为Service Mesh 带来了灵活性和互通性。

据悉SMI 作为一个开放项目，由微软、Linkerd、HashiCorp、Solo、Kinvolk 和 Weaveworks 联合启动。

并同时得到了 Aspen Mesh、Canonical、Docker、Pivotal、Rancher、Red Hat 和 VMware 等多家的大力支持。

相比之前几家的声势浩大与首屈一指的知名度，服务网格领域另一家值得提及的供应商是Tetrate。

作为一家总部位于旧金山的创业公司，TA与Google渊源颇深，是由Google Istio项目的一些主要工程师组成。

据了解，很长一段时间内他们正在着力开发一个独立的企业级 服务网格，主要为了减轻在混合或者大规模复杂环境中运行微服务带来的管理复杂性。

Tetrate曾承诺将Istio和Envoy的开源产品与企业级功能相结合，允许在复杂的企业环境中运行数据和控制平面，这意味着“企业级可扩展性、可伸缩性和性能”。

“我们正试图简化Istio配置的复杂性。”Tetrate方面表示。

当然，如果放眼国内企业，包括阿里Dubbo Mesh、腾讯的Tencent Service Mesh，华为 Mesher 与 ASM、Rancher 2.3 Preview2版本上开始支持Istio以及网易云轻舟微服务基于开源Istio推出服务网格（Service Mesh）平台等在内的多家企业也分别针对Service Mesh有了个性化的技术尝试。

阿里Dubbo Mesh

Dubbo作为阿里巴巴内部SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于各成员站点。

甚至自2011年开源后，已被许多非阿里系公司使用，最后带来服务治理和SOA的设计理念开始逐渐在国内软件行业中落地并被广泛应用的大风潮，可谓影响深远。

简单理解Dubbo Mesh，就是service mesh作为云原生组织定义的微服务架构解决理念，Dubbo则是实现框架的意思。

有资料显示，目前 Dubbo Mesh 主要包含 Bonder、Pilot、Envoy 三个进程，以及被轻量化的 Thin SDK。

具体来说Envoy 承担了数据平面的角色，所有流量将由它完成服务发现与路由而中转。

Pilot 和 Bonder则共同承担控制平面的角色，实现服务注册、进程拉起与保活、集群信息和配置推送等功能。

Thin SDK 是 Fat SDK 经过裁剪后只保留了对 Dubbo 协议进行编解码的能力。

迄今为止，Dubbo应该是国内比较受到欢迎的远程服务框架，也是阿里分布式架构相互连通的核心所在。

腾讯Tencent Service Mesh

TSF Mesh 作为腾讯微服务平台 （TSF） 的 Service Mesh 解决方案，从 2018 年 8 月推出首个版本以来，已经陆续在金融、新零售、工业互联网以及公司内部等生产环境落地。

TSF Mesh 整体架构上，其核心能力与开源的 Istio 保持一致，同时对 envoy、Pilot、Mixer、Pilot-agent 组件做了增强，并且新增组件 Apiserver 和 Mesh-dns。其外围能力聚焦在安全性、易用性、可维护性和可观测性。

TSF Mesh 拥抱开源协同，努力跟进 Service Mesh 的技术发展趋势，但就技术发展趋势而言，比如控制面单体化，UDPA（通用数据平面API）的标准化演进，wasm 在 envoy 中扮演的角色以及mixer 下沉，协议扩展，性能优化等都是未来亟待探讨的技术关键。

Rancher2.3

Rancher的理念是Run Kubernetes Everywhere，其中关于Istio的支持创新也正是让该理念实现又大步向前了一个阶段。

据悉，Rancher 2.3 Preview2版本上开始支持Istio，用户可以直接在UI界面中启动Istio并且可以为每个命名空间注入自动sidecar。具体来说，

Rancher内置了一个支持Kiali的仪表盘，简化Istio的安装和配置，这一切让部署和管理Istio变得简单而快速。

“Rancher 严格来说是一个单体应用，我们的server架构，它是一个集中式的，其中有很多不同的服务，比方说Rancher 的UI、Rancher server的核心控制进程、catalog、Container Engine对接基础设施等。将其全部打包到一个镜像中去再进行统一运行的话，管理升级就会变得额外简单。”Rancher方面表示。

网易云轻舟微服务推出的服务网格平台

轻舟微服务基于开源Istio推出服务网格（Service Mesh）平台 ，可以提供完整的微服务生命周期管理、流量管理和非侵入式的服务治理解决方案。

支持熔断、降级、流控、负载均衡、容错、高级路由等服务治理功能，同时摆脱服务开发框架和开发语言的束缚。

具体来说，平台可以通过统一的微服务模型，帮助将现有的微服务架构平滑迁移到服务网格，并针对数据面引入Sidecar导致延时增加的问题，持续优化数据面，相比开源方案服务延时降低100%以上。

支持无侵入的监控数据采集，实时获取健康状态；支持容器化和非容器化的部署，打破服务网格开源版本“偏科”容器的限制。

华为 Mesher 与 ASM

ServiceComb 是一个 java 与 go 语言的微服务编程框架，而华为Mesher则是基于华为开源的 ServiceComb。

从发展目标来看，Mesher 并不只支持 Kubernetes， 而是支持任意的基础设施，包括容器，虚拟机等，这一点类似于网易云的服务网格尝试。

此外，华为云 Istio 团队在生态上投入了很大力量，并基于 Istio 发布了自己的 ASM（Application Service Mesh）， 深度集成华为云容器服务 CCE(Cloud Container Engine)，提供非侵入的智能流量治理解决方案。

蚂蚁金服SOFAMesh+SOFAMosn

蚂蚁金服的 Service Mesh 解决方案主要包括SOFAMesh 以及SOFAMosn。

其中SOFAMesh 是蚂蚁金服推出的 Service Mesh 开源产品，可以简单理解为是 Istio 的落地增强版本。

作为蚂蚁金服 Service Mesh 的控制平面，跟随社区保持同步更新，还提供了多租户的支持。

SOFAMosn，被称为蚂蚁金服新型基础设施和中间件的底层网络通用解决方案，具备多种产品形态，基于 Golang 开发。

在蚂蚁金服 Service Mesh 中承担数据平面的角色，和 SOFAMesh 项目配合使用，兼容 Istio 体系。

Service Mesh 技术在蚂蚁金服的落地，其实先后经历过几个阶段：

预研阶段：2017 年底开始调研并探索，确定方向。

探索阶段：2018 年初，开始用 Golang 开发 Sidecar SOFAMosn，年中开源基于 Istio 的 SOFAMesh。

小规模落地阶段：2018 年开始内部落地，替代 Java 语言之外的其他语言的客户端 SDK，之后开始内部小范围试点。

规模落地阶段：2019 年上半年，作为蚂蚁金融级云原生架构升级的主要内容之一，逐渐拓展到蚂蚁金服内部的业务应用并平稳支撑大促。

全面大规模落地阶段：2019 年下半年，全面铺开并落地规模庞大。

分析各家的DIY情况，我们发现在数据平面上，大多数选择了Envoy；在控制平面上除了自行开发之外，很大程度上依旧依赖Istio 进行扩展和订制。

总体上，国内 Service Mesh 的发展情况呈现出“多方参与，多种落地与探索，都有符合自身特点的 Service Mesh 产品出炉，技术社区反响热烈”等态势。

但从技术层面上，Service Mesh目前也面临不少的问题与挑战。

Service Mesh用起来会面临哪些问题？

首先服务网格是一个平台解决方案，十分排他。

这意味着需要在服从方式与业务考量上进行艰难取舍，前期成本消耗会十分昂贵。

除了在理念上的矛盾之外，服务网格的部署将架构引入不小的复杂性，过程中需要与现有的环境进行整合并反复配置。

例如Service Mesh组件以代理模式计算并转发请求，一定程度上会降低通信系统性能并增加资源开销。

随着网格的扩张和路由表的膨胀，通过一系列代理进行的路由通信将慢的痛苦异常。

此外，由于组件接管了网络流量，因此服务的整体稳定性都会大概率依赖于Service Mesh，额外引入的Service Mesh服务实例，其运维和管理也是挑战之一。

尽管应用艰难且挑战重重，但人们对将服务网格作为基础设施的关键部分，所激发出的兴趣和亟待采用计划，正在迅速赶上甚至超越容器。

无论企业体量大小，未来服务网格的使用迫切度都会显著增长。

在此基础上，Istio之于服务网格会类似于K8S之于容器的地位，一骑绝尘，毕竟纵观生态系统的成熟度，Istio还是非常有竞争力的。

此外，2020年或将出现核心服务网格用例，并将成为下一批使用者实施的参照。

可想而知，如果正在使用服务网格，其价值会越发显现；如果已经考虑入局其中，未来的机会颇多也是意料之中的事儿。

附：文章参考多家平台内容并撰写，包括知乎以及CSDN社区等，主要资源列表如下：

下一代微服务！ ServiceMesh的2018年度总结 | 万字雄文

https://mp.weixin.qq.com/s/5j-1B5U8q2kE7f_DvPrBaw

KubeCon上海 | 云原生服务网格（Istio）企业峰会

https://mp.weixin.qq.com/s/_Ss3HrokTalRgs6R8sR-hA

企业服务网格竞争白热化

https://mp.weixin.qq.com/s/WRlbxt--b81pa1QA5cjipg

Dubbo Mesh 在闲鱼生产环境中的落地实践

https://www.cnblogs.com/yunqishequ/p/10530705.html

腾讯云中间件团队在Service Mesh中的实践与探索

https://mp.weixin.qq.com/s/20UJMs4U5YEUfxV6dS3oJg

谈谈华为微服务解决方案与实践

https://bbs.huaweicloud.com/blogs/110537

蚂蚁金服 Service Mesh 深度实践

https://blog.csdn.net/weixin_44326589/article/details/102928587?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522159237475219724846408250%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=159237475219724846408250&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_ctr_v3-4-102928587.ecpm_v1_rank_ctr_v3&utm_term=%E8%9A%82%E8%9A%81%E9%87%91%E6%9C%8D+SOFAMosn

Dubbo在Service Mesh下的思考和方案

https://zhuanlan.zhihu.com/p/98562980

网易轻舟服务网格产品升级，全面拥抱下一代微服务技术

http://www.soxunwang.com/kjrd/2020/0421/66443.html

浅谈服务治理、微服务与Service Mesh（一）：Dubbo的前世今生

https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/79160126?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522159232931919195265939573%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=159232931919195265939573&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_ctr_v3-3-79160126.ecpm_v1_rank_ctr_v3&utm_term=Dubbo+Mesh

dubboMesh优化总结

https://blog.csdn.net/weishiym/article/details/84922381?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522159232931919195265939573%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=159232931919195265939573&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_ctr_v3-2-84922381.ecpm_v1_rank_ctr_v3&utm_term=Dubbo+Mesh

Service Mesh服务网格：是什么和为什么

https://blog.csdn.net/zyqduron/article/details/80433995