ServiceMesh究竟解决什么问题？

SM，第一篇

服务网格（ServiceMesh）这两年异常之火，号称是下一代微服务架构，接下来两个月，准备系统性的写写这个东西，但愿可以让你们对最新的架构技术，有个初步的了解。

画外音：

个人行文的风格了，“为何”每每比“怎么样”更重要。

互联网公司，常常使用的是微服务分层架构。

画外音：

为何要服务化，详见《 服务化到底解决什么问题？ 》。

随着数据量不断增大，吞吐量不断增长，业务愈来愈复杂，服务的个数会愈来愈多，分层会愈来愈细，除了数据服务层，还会衍生出业务服务层，先后端分离等各类层次结构。

画外音：

分层的细节，详见《 互联网分层架构演进 》。

不断发现主要矛盾，抽离主要矛盾，解决主要矛盾，架构天然演进了，微服务架构，潜在的主要矛盾会是什么呢？

引入微服务架构，通常会引入一个RPC框架，来完成整个RPC的调用过程。

如上图粉色部分所示，RPC分为：

• RPC-client，它嵌在调用方进程里

• RPC-server，是服务进程的基础

画外音：

《 离不开的微服务架构，脱不开的RPC细节 》。

不仅是微服务，MQ也是相似的架构：

如上图粉色部分所示，MQ分为：

• MQ-send-client

• MQ-server

• MQ-recv-client

画外音：

《 MQ，互联网架构解耦神器 》。

框架只是第一步，愈来愈多和RPC，和微服务相关的功能，会被加入进来。

例如：负载均衡

若是要扩展多种负载均衡方案，例如：

• 轮询

• 随机

• 取模

• 一致性哈希

RPC-client须要进行升级。

例如：数据收集

若是要对RPC接口处理时间进行收集，来实施统一监控与告警，也须要对RPC-client进行升级。

画外音，处理时间分为：

• 客户端视角处理时间

• 服务端视角处理时间

若是要收集后者，RPC-server也要修改与上报。

又例如：服务发现

服务新增一个实例，通知配置中心，配置中心通知已注册的RPC-client，将流量打到新启动的服务实例上去，迅猛完成扩容。

再例如：调用链跟踪

若是要作全链路调用链跟踪，RPC-client和RPC-server都须要进行升级。

下面这些功能：

• 负载均衡

• 数据收集

• 服务发现

• 调用链跟踪

• …

其实都不是业务功能，因此互联网公司通常会有一个相似于“架构部”的技术部门去研发和升级相关功能，而业务线的技术部门直接使用相关框架、工具与平台，享受各类“黑科技”带来的便利。

完美！！！

理想很丰满，现实却很骨感，因为：

• RPC-client，它嵌在调用方进程里

• RPC-server，是服务进程的基础

每每会面临如下一些问题：

• 业务技术团队，仍须要花时间去学习、使用基础框架与各种工具，而不是全心全意将精力花在业务和产品上

• client要维护m个版本， server要维护n个版本，兼容性要测试m*n个版本

• 若是要支持不一样语言，每每要开发C-client，Python-client，go-client，Java-client多语言版本

• 每次“黑科技”的升级，都须要推进上下游进行升级，这个周期每每是以季度、半年、又甚至更久，总体效率极低

画外音：

兄弟，贵司推广一个技术新产品，周期要多长？

这些耦合，这些通用的痛点，有没有办法解决呢？

一个思路是，将服务拆分红两个进程，解耦。

• 一个进程实现业务逻辑（无论是调用方，仍是服务提供方），biz，即上图白色方块

• 一个进程实现底层技术体系，proxy，即上图蓝色方块

画外音：

负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施，都放到这一层实现。

• biz和proxy共同诞生，共同消亡，互为本地部署，即上图虚线方框

• biz和proxy之间，为本地通信，即上图黑色箭头

• 全部biz之间的通信，都经过proxy之间完成，proxy之间才存在远端链接，即上图红色箭头

这样就实现了“业务的归业务，技术的归技术”，实现了充分解耦，若是全部节点都实现了解耦，整个架构会演变为：

• 绿色为biz

• 蓝色为proxy

整个服务集群变成了网格状，这就是Service Mesh服务网格的由来。

架构演进，永无穷尽，痛点多了，天然要分层解耦。但愿你们有收获，后续再细聊SM的设计与架构细节。

思路比结论更重要。

                                                            

                                                                       架构师之路-分享技术思路