第一阶段：管制逻辑和业务逻辑耦合
此形式耦合重大，不得不在业务逻辑中退出网络管制逻辑代码
如下：
管制逻辑和业务逻辑齐全耦合在了一起，使得业务代码凌乱不堪，代码难以了解和保护
第二阶段：公共库
把管制逻辑全副集中在一起组成一个公共的工具包，这样就能够把网络管制逻辑和业务逻辑离开，保障业务逻辑的清晰和明确，这些公共库如 Spring Cloud 的 Netflix 组件。
公共库的益处：
- 解耦
业务代码和网络管制逻辑代码解耦 - 打消反复
不必每个微服务都编写网络控制代码
公共库的毛病：
- 侵入性
以 Spring Cloud/Dubbo 为代表的传统微服务框架，是以类库的模式存在，通过重用类库来实现性能和防止代码反复。但在以运行时操作系统过程的角度来看，这些类库还是浸透进了打包部署之后的业务应用程序，和业务利用程序运行在同一过程 - 跨语言
框架和类库是语言强相干的，当批改公共库时须要批改对应不同语言的版本，开发和保护老本太大
第三阶段：代理
公共库和业务代码不是部署在一起了，而是独自部署一个代理服务，由代理服务去蕴含网络管制逻辑，这样就齐全和利用解耦，如 Nginx、Apache 等 HTTP 反向代理。
然而这些 Proxy 的性能十分简陋，比方服务发现甚至是通过配置文件来实现。性能不够，然而思路和想法很有参考意义：客户端和服务器端应该隔离，局部性能下沉到中间层来实现申请转发。Proxy 模式的摸索为日后 Service Mesh 的呈现奠定了根底。
第四阶段：边车模式（sidecar）
什么是边车？
维基百科定义：一个单轮的工具附着在自行车上独特组成了一个三轮的交通工具
在业务旁边部署一个 Sidecar, 由这个 Sidecar 来解决所有的网络申请，解决实现之后再把申请转发给利用自身
第五阶段：Service Mesh
一个 pod 由应用程序和 Sidecar 组成
一个零碎由很多微服务组成，而每个微服务都随同这一个 Sidecar, 这些 Sidecar 组合起来一个网络就是 service mesh