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