ServiceMesh这两年很火，被称为下一代微服务架构。在接下来的两个月里，我打算把这个东西系统的写出来，希望能让大家对架构技术有一个初步的了解。理解。画外音：我的文笔风格，“why”往往比“how”更重要。互联网公司往往采用微服务分层架构。画外音：为什么我们要服务至上，详见《服务化到底解决什么问题?》。随着数据量的不断增加，吞吐量不断增加，业务越来越复杂，服务的数量也会越来越多，分层也会越来越细。除了数据服务层，还会衍生出业务服务层。前后端分离等多种层级结构。不断发现主要矛盾，提炼主要矛盾，解决主要矛盾。体系结构自然演变。微服务架构潜在的主要矛盾会是什么？微服务架构的引入一般都会引入一个RPC框架来完成整个RPC调用过程。如上图粉色部分所示，RPC分为：RPC-client，嵌入在调用者进程中RPC-server，是服务进程的基础。不仅仅是微服务，MQ也有类似的架构：如上图粉色部分所示，MQ分为：MQ-send-clientMQ-serverMQ-recv-client框架只是开始，功能越来越多将添加与RPC和微服务相关的内容。例如：负载均衡如果要扩展多个负载均衡方案，例如：roundrobinrandommoduloconsistenthashRPC-client需要升级。例如：数据采集如果要采集RPC接口的处理时间，实现统一监控告警，还需要升级RPC-client。画外音，处理时间分为：client视角的处理时间server视角的处理时间如果要采集后者，RPC-server也需要修改上报。又如：新增服务发现服务实例，通知配置中心，配置中心通知注册的RPC-client，并将流量发送给新启动的服务实例，快速完成扩容。又如：调用链跟踪如果要做全链路调用链跟踪，RPC-client和RPC-server都需要升级。以下功能：负载均衡数据采集服务发现调用链跟踪...其实都不是业务功能，所以互联网公司一般都有类似“架构部”的技术部门，负责相关功能的开发和升级，而技术业务线部门直接使用相关框架、工具和平台，享受各种“黑科技”带来的便利。理想很丰满，但现实很骨感，因为：RPC-client，嵌入调用者进程RPC-server，是服务流程的基础，经常面临以下问题：业务技术团队还需要花时间学习，使用基础框架和各种工具，而不是一心一意专注于业务和产品。客户端需要维护m个版本，服务端需要维护n个版本，兼容性需要测试m*n个版本。如果要支持不同的语言，往往需要开发C-client、Python-client、go-client、Java-client多语言版本。“黑科技”的每一次升级，都需要带动上下游升级。这个周期往往是每季度、半年，甚至更长。整体效率极低画外音：大哥，你们公司推广一个新技术产品需要多长时间？有没有办法解决这些耦合和共同痛点？一种想法是将服务拆分为两个进程并解耦。一个进程实现业务逻辑（无论是调用者还是服务提供者），biz，即上图中的白色方块，一个进程实现底层技术系统，proxy，即上图中的蓝色方块图片。画外音：负载均衡、服务发现与治理、调用链……等等很多基础设施都在这一层实现。biz和proxy同生同灭，在本地相互部署，即上图中biz与proxy之间的虚线框为本地通信，即上图中黑色箭头中所有biz之间的通信是通过proxy完成的，proxy之间是有远程连接的，也就是上图中的红色箭头。这样“业务归业务，技术归技术”，实现了完全解耦。如果所有节点解耦，整个架构会演化为：绿色是biz，蓝色是proxy。整个服务集群变成了一个网格，这就是ServiceMesh服务网格的由来。架构的演进是无止境的，痛点也很多，自然要分层解耦。希望大家有所收获，后面会详细讲到SM的设计和结构细节。想法比结论更重要。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
