目前在微服务领域最火的莫过于 service mesh，这篇文章主要说说 service mesh 是什么，他的价值是什么，别人都怎么使用它。

什么是service mesh?

简单来说，service mesh 就是一个微服务里面的一个代理层

1. rpc 的 downstream 和 upstream 都需要经过他。
2. 他完成一些通用的监控，trace，服务发现等功能
3. 对业务方透明

这里盗链一张图

service mesh 的价值

这里列举一张表，对于不同阶段的业务使用 service mesh 的价值。

对于刚接入微服务，并且处于上升期的小公司来说，价值很大。

但对于比较成熟的，配套比较完善的阶段来说，收益就并不大了。一般做mesh化的改造，是为了某些目的的。

别人都怎么使用 service mesh

这里总结一下几个大厂的 service mesh 的设计，以及原因。

weibo mesh

官方ppt地址

官方文章

对比 istio，主要支持了

1. 协议转换（motan2 - Http）

注意： 他们的协议转换，导致了在sidecar层需要比istio 额外多一道序列化反序列化body的成本。而istio只解析header。

服务端代码在此

他们的主要目的是为了

1. 支持内部的小语言的治理
2. 通用的 http 转 motan 协议

sofa mesh

蚂蚁的 sofa 在他们的官网文章很多，但只有这篇才是最贴近他们内部的真实情况。

官方文章

他们和 istio 本质上区别不大。自研的目的是为了最大限度复用现有的基础设置(注册中心/配置中心)，并能平滑迁移。

proxy做了特别的协议扩展，便于支持他们的去中心化网关

唯品会 mesh

他们的代码没有开源，相关资料如下。

相关资料

从资料来看和istio大不相同。核心目的是为了支持小语言

比起sidecar 的模式，更像是一个代理模式。

主要特色

支持一个协议转换，能将http转为 thrift 协议。
ps：内部应该是将接口的schema也存储到注册中心了

美团 octo mesh

美团内部的mesh化方案。

相关资料

从资料来看，他尽可能的贴近istio的方式进行改造。

特点就是复杂，非常复杂。

从文章可以看到，他的初衷是

1. 美团内部的子公司/部门很多，每个子公司/部分 内部可能都用的不是一套服务治理体系。然后他想用 service mesh 的方式把他们整合为一个系统。
2. 尽量贴近istio社区的理念，可以跟进社区。

想法是好的，但是从文章看来，实现很复杂。

举一个例子，光从注册中心的逻辑来说，为了减少拉模式，流量很大的弊端，所以维护了一个注册信息的 snapshot 模块，便于推送增量消息。