service mesh演进过程

第一阶段：控制逻辑和业务逻辑耦合

此方式耦合严重，不得不在业务逻辑中加入网络控制逻辑代码

以下：

控制逻辑和业务逻辑彻底耦合在了一块儿，使得业务代码凌乱不堪，代码难以理解和维护

第二阶段：公共库

把控制逻辑所有集中在一块儿组成一个公共的工具包，这样就能够把网络控制逻辑和业务逻辑分开，保证业务逻辑的清晰和明确，这些公共库如Spring Cloud的Netflix组件。

公共库的好处：

• 解耦
  业务代码和网络控制逻辑代码解耦
• 消除重复
  不用每一个微服务都编写网络控制代码

公共库的缺点：

• 侵入性
  以Spring Cloud/Dubbo为表明的传统微服务框架，是以类库的形式存在，经过重用类库来实现功能和避免代码重复。但在以运行时操做系统进程的角度来看，这些类库仍是渗透进了打包部署以后的业务应用程序，和业务应用程序运行在同一进程
• 跨语言
  框架和类库是语言强相关的，当修改公共库时须要修改对应不一样语言的版本，开发和维护成本太大

第三阶段：代理

公共库和业务代码不是部署在一块儿了，而是单独部署一个代理服务，由代理服务去包含网络控制逻辑，这样就彻底和应用解耦，如Nginx、Apache等HTTP反向代理。

可是这些Proxy的功能很是简陋，好比服务发现甚至是经过配置文件来实现。功能不够，可是思路和想法颇有参考意义：客户端和服务器端应该隔离，部分功能下沉到中间层来实现请求转发。Proxy模式的探索为往后Service Mesh的出现奠基了基础。

第四阶段：边车模式（sidecar）

什么是边车？
维基百科定义：一个单轮的工具附着在自行车上共同组成了一个三轮的交通工具

在业务旁边部署一个Sidecar,由这个Sidecar来处理全部的网络请求，处理完成以后再把请求转发给应用自己

第五阶段：Service Mesh

一个pod由应用程序和Sidecar组成

一个系统由不少微服务组成，而每一个微服务都伴随这一个Sidecar,这些Sidecar组合起来一个网络就是service mesh