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