本系列为网上收集转载分布式相关知识点系列文章，并非原创。如果侵权，请联系我删除！！！
服务网格（ServiceMesh）这两年异常之火，号称是下一代微服务架构，互联网公司经常使用的是微服务分层架构。但是网上真正讲清楚这玩意儿是咋回事的文章非常少。
随着数据量不断增大，吞吐量不断增加，业务越来越复杂，服务的个数会越来越多，分层会越来越细，除了数据服务层，还会衍生出业务服务层，前后端分离等各种层次结构。不断发现主要矛盾，抽离主要矛盾，解决主要矛盾，架构自然演进了，微服务架构，潜在的主要矛盾会是什么呢？
引入微服务架构，一般会引入一个RPC框架，来完成整个RPC的调用过程。
如上图粉色部分所示，RPC分为：
-
RPC-client，它嵌在调用方进程里
-
RPC-server，是服务进程的基础
不只是微服务，MQ也是类似的架构：
如上图粉色部分所示，MQ分为：
-
MQ-send-client
-
MQ-server
-
MQ-recv-client
框架只是第一步，越来越多和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的设计与架构细节。
转载自。https://www.cnblogs.com/rinack/p/10754100.html
上面部分是转载的网友文字。相信有上面内容对server mesh到底是怎么玩的心里有个比较清的了解了
下面是我通过各种沟通了解到的已在用的servermesh实现的关键细节：
biz和proxy是怎么通信的呢，最佳方式是：两个进程走回环网卡。这样效率最高
另外 proxy和biz底层，应该把 网络io，数据队列框架都做好，业务此时只需要接个回调，收到消息处理即可，最简单也最高效。
另外，server mesh应该跟docker高度绑定，高度定制化（推荐用k8s），这样框架管理和部署，啥IO，磁盘，内存，CPU这些的负载均衡可以完美的动态调整，性能可以达到最佳，可维护性最好。