云原生技术专题-Service Mesh-技术演进之路（二）

Service Mesh技术演进之路

有一篇很是著名的文章叫《Servich Mesh模式》它详细的介绍了它如何从最初的原始的状态一步一步的演进成如今的这种形态的，咱们对网络控制相关的逻辑是没有一个清晰的概念，一般都是经过突发问题的解决，来引入相关的控制逻辑，来看下面这张图
第一阶段：控制逻辑和业务逻辑耦合

在这张图上服务A它的业务逻辑和下面的两个流控相关的逻辑是耦合在一块儿的，也就是熔断和服务发现，这种模式有什么问题？最大的问题就是耦合，不得不在你的业务代码中添加不少的网络控制相关的逻辑，向下面这个for循环

里面经过一个HTTP或者RPC的请求去调用另一个业务模块，而后当出现错误的时候，要重试两到三次，最后退出，那么这样的一些所谓的控制逻辑，彻底跟你的业务逻辑耦合在来一块儿，使你的业务逻辑变得凌乱不堪，维护的成本也会很高，而且也会很难去理解，为了解决上面出现的问题就发展到了第二阶段
第二阶段：公共库
解藕
消除重复
成本
语言绑定
仍有侵入

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

第三阶段： 代理
功能简陋
思路正确

从这个图咱们能够看到一些细微的差异咱们的公共库再也不和如今的业务逻辑部署在一块儿了，而是单独的抽出了一个模块，这个模块就是代理，由代理去包含相应的控制逻辑，这样就彻底和你的应用解偶了，那么代理模式由一个最大的问题就是功能比较简陋，好比咱们的nginx apache，当须要作一个路由功能的时候须要在upstream这样的配置文件中进行一些编码，它的功能是很是简陋的，没有办法的知足咱们现有的须要，可是不得不说代理这种思路，它的方向是正确的，所以就发展出了代理版的进化版，就是下一个阶段的sidecar模式，也叫边车模式

第四阶段：边车模式（sidecar）
什么是边车模式，维基百科说是一个单轮的工具附着在一个摩托车或者自行车上共同组成了一个三轮的交通工具，这就是所谓的sidecar，在下面能够看到所谓的sidecar

下面这张图能够看到咱们在应用旁边部署一个sidecar，由这个sidecar来去处理全部的网络请求，最后处理完成以后，再把请求转发给应用自己，这就是一个典型的sidecar

其实sidecar的这种模式早就出现了，好比咱们在一个k8s的pod里面部署多个容器，其中一个容器好比是用来处理日志的filebeat，它本质上就是一个sidecar,只不过咱们如今是部署了一个用来处理网络请求的sidecar,sidecar这种模式实际上就很是接近咱们现阶段的service mesh

第五阶段：Service Mesh的出现

一个pod可能有两个不一样的container组成，一个是微服务，另一个就是sidecar,固然一个应用中也有可能会包含不少不一样的微服务，而这些微服务都伴有多个sidecar,这些sidecar组合起来一个的一个网络，就能够把它理解为service mesh。

发展历程

你们并未对网络策略控制逻辑有完整的思路，所以老是在业务逻辑中去添加一些网络控制逻辑，致使了逻辑的耦合，使得代码很难维护，未了解决这个问题就出现了公共库，公共库把这些网络管控的功能整合成一个单独的工具包，单独的去部署，解决了耦合，可是同时由于它的复杂性，以及语言绑定，以及应用侵入的问题，致使它并非一个完美的方案，接下来就出现了代理的这些思路，代理这种思路虽然方向正确，完全和你的应用进行了节藕，但它的功能仍是比较简陋的，很难知足咱们的需求，而后代理向下发展，就会出现下一个阶段的sidecar模式，sidecar模式早在13年就出现了，随着它的发展，慢慢演进成了咱们的service mesh, service mesh能够简单的理解为就是sidecar的网络拓扑组合，到了18年之后，为了去管理整个sidecar网络，在产品上又增长了控制平面，就造成了咱们常说的第二代service mesh