究竟解决什么问题？

些功能：

• 负载均衡
• 数据收集
• 服务发现
• 调用链跟踪
• …

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

理想很丰满，现实却很骨感，由于：

• 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之间才存在远端连接，即上图红色箭头

这样就实现了“业务的归业务，技术的归技术”，实现了充分解耦，如果所有节点都实现了解耦，整个架构会演变为：

• 色为proxy

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

架构演进，永无穷尽，痛点多了，自然要分层解耦。希望大家有收获，后续再细聊SM的设计与架构细节。

（编辑：揭阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!