雲原生技術專題-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