正经公司谁用service mesh

Why service mesh 在上篇关于RPC框架的文章中，提到了使用RPC框架很重要的一个原因是服务治理功能集成。这些功能都是业务无关的，但是以SDK的形式集成在业务代码里。这些SDK一般由基础设施团队开发，在升级和维护时就需要业务方配合，但是业务方是没有动机去积极配合的。WEB形式的程序能爆发的一个原因是发版权掌握在开发方手里，不需要强制用户去升级客户端，用户体验丝滑。回到SDK，如果是单语言技术栈，工作量看起来还好。如果真的践行了微服务的理念，玩多语言技术栈，同样的功能就需要实现多次，KPI就上来了？ 假设已经面对这样的局面，service mesh就是给出的解答。SDK服务化，让业务专注于业务逻辑开发，基础设施团队方便升级和维护。前面谈的是数据面，至于控制面带来的集中式管理暂且不谈。 How implement 实现思路上，业界做法是七层Proxy，感知client与server的交互协议（与其说是side car不如说是偷窥狂）。但是应用层协议是丰富多彩的，HTTP，gRPC，Redis，MySQL等等。Redis还可以细分主备，集群模式，现在的client是越来越smart了。要想做到业务程序层面的简化，不可避免的Proxy会很复杂。这种情况我称之为“复杂度守恒定律”，分层和抽象只是简化的上层使用者的理解和使用成本，考虑整个技术栈，复杂度并没有减少。 但是有了Proxy后可以做到很多有趣的事，比如熔断限流是为了保护服务不被突发流量压垮，我认为Redis和MySQL这样的关键共享资源更有必要被保护起来。而Redis和MySQL又不可能接入SDK，Client端的SDK一般又没有实现熔断等功能。有了Proxy就可以轻松地，甚至是无感知式地实现这些功能。 Who need 前面提到了service mesh解决的场景，多语言技术栈，和实现上的复杂度，那我想办法避免不就行了。至于service mesh带来的一些优势，SDK又不是不能用。那么到底是谁需要service mesh呢？谷歌阿里没事找事秀肌肉么？答案是：云厂商。 发展长久的大公司因为历史原因可能会积累多语言技术栈，但是这些问题中小公司都是可以避免的，特例需求并不能成为社区的共性需求，不是共性需求没有大力投入的价值。但是云厂商不一样，上云的企业技术栈就是五花八门的，而云厂商的使命就是加速中小企业的业务开发迭代。云厂商说来吧，服务治理啥都是现成的，业务代码无侵入，有没有吸引力？所以这也能解释为什么gRPC的Roadmap里有那么多Envoy+Istio的东西。利益相关，gRPC和Istio都是谷歌的东西，众所周知谷歌也做公有云。 总结 call back标题党，“正经公司”不需要service mesh，service mesh解决的不是中小公司的生死攸关的问题，完全可以等到云厂商实践成熟service mesh后直接享受，自建探索最佳实践技术要求和成本太高。