Service mesh有啥意义？

大家经常讲ServiceMesh是第三代微服务治理体系，但是在一家公司的服务治理体系向Mesh迁移过程中，会遇到很多现实的问题，比如增加了成本（开发成本、改造成本、抑或其他），最终得到了什么样的收益呢？

首先我觉得意义肯定还是有的，只不过对于不同发展阶段和成熟度的团队意义大小不同。

先从一些业界微服务治理时代比较成熟的公司说下。

比如美团或者微博的mesh解决方案，主要解决以下几个问题：

1. 中间件与业务进程强耦合，彼此制约迭代升级，引入成本问题和稳定性问题；

2. 异构体系难融合，主要是部门、组织服务治理体系不统一，成熟度也不同；

3. 比如美团主要是java技术栈，其他语言的治理能力相对较弱；

微博情况类似，java栈有了motan，但其他语言治理能力还不完善，也比较碎片。

所以这两家推动Mesh主要解决的问题有三个：

1. 推进多服务治理解决方案的统一与标准；

2. 解决多语言问题；

3. 解决中间件升级与业务进程解耦的问题；

剩下的一些通用服务治理能力，比如：降级、染色、灰度、高可用、trace、metric、服务注册与发现、熔断、限流。这些并不是因为引入mesh才具备的，如果原有的服务治理体系比较成熟，这些能力是必须存在的，并不是因为有了mesh这些服务治理能力才有的。

比如美团的Mesh解决方案，其实只需要解决业务进程与服务治理进程之间通信和解耦就可以了，毕竟美团的服务治理体系还是比较完备的，控制面完全自研，数据面做简单的迁移即可。

总结下，对于这些公司我理解mesh主要是解决多语言、多服务治理体系的标准化。

再说下技术层面的事情。

mesh上现在很多服务治理能力，其实在mesh之前的解决方案已经存在了，比如之前可能是在proxy上、agent上。

mesh简单来说是将之前proxy、agent的能力打散成分布式的proxy，这么看确实增加了一些维护成本与通信成本（具体怎么解决这部分成本后面聊）。

如果把原有的中心化proxy的能力打散下放到分布式的proxy里面，其实和我们常用的client、sdk解决方案又有些类似了。

mesh解决方案又跑不掉和k8s、容器做进一步集成。

这就给大家一种想法，既然原有的proxy或者sdk可以解决mesh可以解决的问题，那改造又有一定成本，需要适配到k8s，那mesh是否是一个高投入低产出的事情呢？

我们脱离mesh现状问个问题。

我们是否需要一个开箱即用的服务治理能力？不管这部分能力是以产品、组件、工具的方式承接的。

如果有了这个能力可以帮助我们做好业务进程与服务治理进程的隔离，两者独立升级互不影响。

如果有了这个能力，所有语言或者服务治理体系都可以低成本实现非常高级和精细化的服务治理需求，而无需开发成本。

我相信你一定会说，我想要。

其实我们一直想要的服务治理能力是解耦的、标准化的、低成本的。

• 解耦：服务治理能力与业务处理进程解耦，与语言无关，升级迭代方便；

• 标准化：所有语言、服务治理现状都可以快速达到一个统一的服务治理阶段，协议标准化、metric、日志等标准化；

• 低成本：业务研发不需要关注因为升级、迭代、维护，环境迁移带来的成本（私有化部署、单体、微服务、云原生）；
  

正是因为现在的mesh解决方案没有做到一键搭建或者开箱即用，我们会觉得想要的收益和现有改造的付出不成正比，也就会质疑mesh的价值与意义。

说句题外话，其实我觉得私有化部署和云原生部署对于一款技术产品来说一样重要，云原生很性感，但是我觉得在未来的10年，私有化部署和云原生还是会对半开，因为受限于行业、规范、以及各种法律的出台，有些行业不能用云上产品，本地化的私有化部署一直存在需求，做好本地化部署将是产品的一大卖点。

而且私有化部署其实是一个技术考验，怎么将一个云端多容器具备cicd流水线的产品，快速低成本的部署到一台内网的4c8g的win7系统其实是个技术挑战。

回过头说mesh。

上面提到这些mesh其实是基础的服务治理能力。

有了mesh，很多企业会集成很多个性化的需求。比如流量染色的压测、数据安全的管控，国际化业务如何与国内做好隔离？saas系统之间如何做好不同租户之间的隔离，既可以通过业务层面解决，也可以在mesh层面解决，我个人觉得随着数据安全的要求越来越多，mesh层（流量层）还是要具备兜底能力的。

上面提到了，最开始架构从proxy转变为mesh的过程中，大家会疑惑会不会产生性能问题？

mesh带来的最大的改变是对流量的治理与管控，中间需要两跳（业务进程 -> sidecar -> sidecar），这种延迟问题其实现在慢慢解决了。比如最开始的localhost通信，变成了UDS通信，现在又有了ebpf，性能上来了。sidecar之间可以通过协议优化，比如采用quic/gRpc，长链接、多路复用。但是学习和维护成本其实也是相应的增加了，也就说因为mesh，其实我们又面对了新的问题与新的挑战。

第二个问题是原有的一些proxy类的、SDK的解决方案也不甘落后，也在迭代自己的解决方案了。比如gRPC开始集成Istio的Control Plane了，并命名为Proxyless，也就是说用了gRPC，你就具备了Istio的mesh能力了，那还需要从头到尾做复杂的mesh改造吗？

未必。

service mesh描绘了一种服务治理的终态，但现有的mesh解决方案并不是这种终态，所以mesh的投入与价值确实是一个值得讨论的话题。