Service Mesh技术演进之路

有一篇非常著名的文章叫《Servich Mesh模式》它详细的介绍了它如何从最初的原始的状态一步一步的演进成现在的这种形态的，我们对网络控制相关的逻辑是没有一个清晰的概念，通常都是通过突发问题的解决，来引入相关的控制逻辑，来看下面这张图
第一阶段：控制逻辑和业务逻辑耦合
云原生技术专题-Service Mesh-技术演进之路（二）_第1张图片
在这张图上服务A它的业务逻辑和下面的两个流控相关的逻辑是耦合在一起的，也就是熔断和服务发现，这种模式有什么问题？最大的问题就是耦合，不得不在你的业务代码中添加很多的网络控制相关的逻辑，向下面这个for循环
云原生技术专题-Service Mesh-技术演进之路（二）_第2张图片
里面通过一个HTTP或者RPC的请求去调用另外一个业务模块，然后当出现错误的时候，要重试两到三次，最后退出，那么这样的一些所谓的控制逻辑，完全跟你的业务逻辑耦合在来一起，使你的业务逻辑变得凌乱不堪，维护的成本也会很高，并且也会很难去理解，为了解决上面出现的问题就发展到了第二阶段
第二阶段：公共库
解藕
消除重复
成本
语言绑定
仍有侵入
云原生技术专题-Service Mesh-技术演进之路（二）_第3张图片

公共库意思就是说把这些控制逻辑全都集中在一起，形成一个公共的工具包，来单独部署，这样的话就可以把你的网络流控相关的逻辑和业务逻辑分开来，保证你的业务逻辑清晰和明确，这些公共库市面也有很多产品，比如说Twitter的Finagle，比如说Spring cloud的一些组件，以及Netflix开源的一些产品，都是类似的公共库，那么公共库最大的好处毫无疑问就是进行了节藕，可以不用在每个服务里面去重复的去编写刚才我们说的for循环的逻辑，它最大的优点就是消除了重复，但是公共库同样部署完美的，它依然还有其他的问题，比如最大的问题就是成本问题，那么这个成本包括两部分，一个是人力的成本，一个是时间上的成本，所谓人力成本，通常来说一个公共库都是比较复杂的，需要去花费一定的时间进行学习，所以不得不安排一些专人去负责，这样的类库或者是工具，另外一个成本就是我们的部署和维护的成本，不得不去部署和维护它，比如说当你的公共库进行了升级以后，不得不去重新的去部署一份，另外公共库一般都是语言绑定的，它并不是完全的和平台无关，所以就导致很可能需要在你原有的基础上，引入新的语言或者是技术栈，同时维护两套不同的技术栈，这也是会带来更多的成本，虽然公共库可以消除重复，但是本质上它依然是和你的应用程序同时运行在同一个进程中，依然是对你的应用有侵入的，因此公共库依然不是一个完美的解决方案，那么这时候就有一些实践，接下来有的实践者就考虑，依然公共库有依赖，我们能不能把它独立成一个单独的代理，通过代理来解决网络控制相关的能力，这就是第三阶段模式

第三阶段： 代理
功能简陋
思路正确
云原生技术专题-Service Mesh-技术演进之路（二）_第4张图片
从这个图我们可以看到一些细微的差别我们的公共库不再和现在的业务逻辑部署在一起了，而是单独的抽出了一个模块，这个模块就是代理，由代理去包含相应的控制逻辑，这样就完全和你的应用解偶了，那么代理模式由一个最大的问题就是功能比较简陋，比如我们的nginx apache，当需要做一个路由功能的时候需要在upstream这样的配置文件中进行一些编码，它的功能是非常简陋的，没有办法的满足我们现有的需要，但是不得不说代理这种思路，它的方向是正确的，因此就发展出了代理版的进化版，就是下一个阶段的sidecar模式，也叫边车模式

第四阶段：边车模式（sidecar）
什么是边车模式，维基百科说是一个单轮的工具附着在一个摩托车或者自行车上共同组成了一个三轮的交通工具，这就是所谓的sidecar，在下面可以看到所谓的sidecar
云原生技术专题-Service Mesh-技术演进之路（二）_第5张图片

下面这张图可以看到我们在应用旁边部署一个sidecar，由这个sidecar来去处理所有的网络请求，最后处理完成之后，再把请求转发给应用本身，这就是一个典型的sidecar
云原生技术专题-Service Mesh-技术演进之路（二）_第6张图片
其实sidecar的这种模式早就出现了，比如我们在一个k8s的pod里面部署多个容器，其中一个容器比如是用来处理日志的filebeat，它本质上就是一个sidecar,只不过我们现在是部署了一个用来处理网络请求的sidecar,sidecar这种模式实际上就非常接近我们现阶段的service mesh

第五阶段：Service Mesh的出现
云原生技术专题-Service Mesh-技术演进之路（二）_第7张图片

一个pod可能有两个不同的container组成，一个是微服务，另外一个就是sidecar,当然一个应用中也有可能会包含很多不同的微服务，而这些微服务都伴有多个sidecar,这些sidecar组合起来一个的一个网络，就可以把它理解为service mesh。
云原生技术专题-Service Mesh-技术演进之路（二）_第8张图片

发展历程
云原生技术专题-Service Mesh-技术演进之路（二）_第9张图片
大家并未对网络策略控制逻辑有完整的思路，因此总是在业务逻辑中去添加一些网络控制逻辑，导致了逻辑的耦合，使得代码很难维护，未了解决这个问题就出现了公共库，公共库把这些网络管控的功能整合成一个单独的工具包，单独的去部署，解决了耦合，但是同时因为它的复杂性，以及语言绑定，以及应用侵入的问题，导致它并不是一个完美的方案，接下来就出现了代理的这些思路，代理这种思路虽然方向正确，彻底和你的应用进行了节藕，但它的功能还是比较简陋的，很难满足我们的需求，然后代理向下发展，就会出现下一个阶段的sidecar模式，sidecar模式早在13年就出现了，随着它的发展，慢慢演进成了我们的service mesh, service mesh可以简单的理解为就是sidecar的网络拓扑组合，到了18年以后，为了去管理整个sidecar网络，在产品上又增加了控制平面，就形成了我们常说的第二代service mesh