标签：问题： 带来 演进 系统 准备 集群 下一代 而不是 ice
SM，第一篇
服务网格（ServiceMesh）这两年异常之火，号称是下一代微服务架构，接下来两个月，准备系统性的写写这个东西，希望能够让大家对最新的架构技术，有个初步的了解。
画外音：我的行文的风格了，“为什么”往往比“怎么样”更重要。
互联网公司，经常使用的是微服务分层架构。
画外音：为什么要服务化，详见《服务化到底解决什么问题？》。
随着数据量不断增大，吞吐量不断增加，业务越来越复杂，服务的个数会越来越多，分层会越来越细，除了数据服务层，还会衍生出业务服务层，前后端分离等各种层次结构。
画外音：分层的细节，详见《互联网分层架构演进》。
不断发现主要矛盾，抽离主要矛盾，解决主要矛盾，架构自然演进了，微服务架构，潜在的主要矛盾会是什么呢？
引入微服务架构，一般会引入一个RPC框架，来完成整个RPC的调用过程。
如上图粉色部分所示，RPC分为：
不只是微服务，MQ也是类似的架构：
如上图粉色部分所示，MQ分为：
框架只是第一步，越来越多和RPC，和微服务相关的功能，会被加入进来。
如果要扩展多种负载均衡方案，例如：
如果要对RPC接口处理时间进行收集，来实施统一监控与告警，也需要对RPC-client进行升级。
画外音，处理时间分为：
服务新增一个实例，通知配置中心，配置中心通知已注册的RPC-client，将流量打到新启动的服务实例上去，迅猛完成扩容。
如果要做全链路调用链跟踪，RPC-client和RPC-server都需要进行升级。
下面这些功能：
理想很丰满，现实却很骨感，由于：
往往会面临以下一些问题：
一个思路是，将服务拆分成两个进程，解耦。
这样就实现了“业务的归业务，技术的归技术”，实现了充分解耦，如果所有节点都实现了解耦，整个架构会演变为：
架构演进，永无穷尽，痛点多了，自然要分层解耦。希望大家有收获，后续再细聊SM的设计与架构细节。
思路比结论更重要。
架构师之路-分享技术思路
相关文章：
《服务化到底解决什么问题？》
《互联网分层架构演进》
《离不开的微服务架构，脱不开的RPC细节》
《MQ，互联网架构解耦神器》
调研：
贵司推广一个“底层技术”，周期大概多长，业务侧要配合升级么？
标签：问题： 带来 演进 系统 准备 集群 下一代 而不是 ice
原文地址：https://blog.51cto.com/jyjstack/2548778
