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