【微服务进阶】带你搞懂Service Mesh（服务网格）

阅读此文需要掌握微服务架构的相关知识

何为Service Mesh？

Service Mesh是用于处理服务与服务之间通信的专用基础设施层，与应用程序一起部署，但是对应用程序透明。

微服务架构之痛

大规模微服务群，服务治理问题

虽然微服务对应用开发进行了简化，将复杂系统“分而治之”地切分为若干个微服务来分解和降低复杂度，使得这些微服务易于小型开发团队进行开发和维护。但是，复杂度并没有凭空消失。微服务拆分之后，单个微服务的复杂度确实大幅降低，但是由于应用系统被从一个单体拆分为更多的微服务，就带来了更复杂的微服务治理：微服务的连接、管理和监控。对于一个大型应用系统，很难对多达上百个甚至上千个微服务的管理、部署、版本控制、安全、故障转移、策略执行、遥测和监控等。这对整个团队提出了非常高的技术要求。

多语言支持不足

对于稍具规模的团队，尤其是在高速成长的互联网创业公司，多语言的技术栈是常态，跨语言的服务调用也是常态，但目前开源社区上并没有一套统一的、跨语言的微服务技术栈。目前主流的微服务框架SpringCloud、Dubbo都是基于Java所开发，当整个系统同时涉及到多种语言时，这些框架的能力就有些捉襟见肘了。

代码侵入性高

还是以SpringCloud、Dubbo为例，其对于业务逻辑代码都有一定的侵入性，也就是说服务治理相关的代码与业务逻辑有一定的耦合。以阿里巴巴集团为例：RPC 框架由中间件事业部统一开发与维护，以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的，当 SDK 向前演进所增加的特性并不是某些业务方所需要的时，这些业务方就没有动力配合中间件事业部去同步升级自己应用中的 SDK 版本，使得 SDK 在整个集团存在多个版本甚至变成长尾而形成包袱。类似的包袱反过来制约了 RPC 框架自身的演进效率。

Service Mesh 闪亮登场

感性认知

Service Mesh的基本思想十分简单：通过拆分实现解耦——将 微服务框架SDK 中通用性逻辑 与 业务逻辑 分别放到不同的进程中。这样的好处就是可以让开发者专注于业务逻辑的实现，而不用考虑服务治理的相关事项，同时不同语言之间的交互也变得简单。

这种模式从根本上解决了多语言支持不足以及代码侵入性的问题，并且由于服务网格的独立性，业务团队不需要关心服务治理相关的复杂度，可以全权交给服务网格处理

冰冷的定义

Service Mesh价值

Service Mesh现有产品

新浪微博自研的Weibo Mesh(VM) 阿里巴巴的Dubbo Mesh Google,IBM和Lyft联合出品的 Istio