5分鐘帶你快速了解ServiceMesh的前世今生
本文轉載自微信公眾號「愛笑的架構師 」，作者雷架 。轉載本文請聯系愛笑的架構師 公眾號。
原始時代
1969年11月，為了便于高校間共享資源，美國國防部高級研究計劃管理局建立一個名為阿帕網絡ARPAnet，起初只有四個節點。
阿帕網起源
一年后阿帕網的節點數量增至15個，此后平均每隔二十天就有一臺大型計算機接入。
隨著網絡在世界范圍不斷擴大，不同國家不同地區各自形成了一個網絡，操著不同方言彼此間互不相通，諸侯割據格局已經形成。
隔離的阿帕網
這個時候機器與機器之間通信是靠彼此約定的方式進行。
計算機靠方言通信
機器需要自行處理網絡通信過程中遇到的丟包、亂序、重試等問題。
青銅時代
為了解決各國家各地區網絡不能互通的問題，1973年兩位年輕的小伙子開始發力了，致力于研究一種通訊方法，能夠解決不同機器型號的計算機互相通信，簡單說就是用普通話替代方言，這就是大家熟知的“TCP/IP”協議。
鮑勃·卡恩(左)與溫頓·瑟夫(右)
隨著 TCP/IP 協議逐漸普及后，一張大的 Internet 網絡由此形成。
Internet
這個時候機器與機器之間通信的問題已經解決，TCP/IP 可以保證信息可靠性傳輸，我們只用關系業務邏輯即可。
依賴 TCP/IP協議實現機器間傳輸
黃金時代
在 TCP/IP 協議剛興起時，計算機上的應用還很貧乏，機器與機器之間通信一般用來簡單的數據傳輸。
隨著 WEB 互聯網技術興起，基于 TCP/IP 協議出現了很多應用層協議，國內出現了一批優秀的互聯網公司如騰訊、新浪、搜狐、淘寶等。
當時訪問量并不大，采用單體架構基本就可以滿足。
單體應用之間調用
服務的數量不多，每個服務都有一個唯一的IP 地址，服務與服務之間交互通過 IP尋址。
鉑金時代
網民數量越來越多，單個實例扛不住日益增長的訪問量。通常會在一個機器上部署多個實例組成集群，服務1訪問服務2不再是之前的點到點了，現在變成了點到多點，中間會加一個負載均衡解決流量均衡問題。
單體應用集群之間調用
鉆石時代
隨著互聯網業務訪問量井噴，通過橫向擴展服務實例的方法也開始遇到瓶頸了，單個服務越來越大，代碼模塊耦合嚴重，修改一行代碼可能影響整個系統。
問題來了，解決方案也隨著而來，“微服務”橫空出世了。將一個業務服務按功能模塊切分為多個微服務，比如將 Service1 切分為 Micro Service1，Micro Service2，Micro Service3。
在單體服務中Micro Service1調用Micro Service2可能就是一個模塊調用另外一個模塊，調用一個公開的函數就能搞定，拆為微服務之后就變成了兩個微服務直接的調用，這種調用是要通過網絡通信實現。
微服務間調用
星耀時代
隨著業務擴張，對系統的高可用要求越來越高，一些重點微服務如訂單、賬單等可能會部署成百上千個實例，運維人員的負擔也在逐漸加大，如果機器掛了要手動刪除，如果遇到重大活動如雙十一可能要擴展幾千個實例，運維人員需要手工添加，人工干預越多出錯的概率越大。
第一代微服務技術應運而生。
代理內嵌
每個微服務內嵌一個代理用來處理服務注冊和發現的邏輯，國內以阿里的 Dubbo，微博的 Motan 為代表。這類框架不足的地方很明顯：微服務與代理耦合、不支持多語言。
王者時代
針對第一代微服務框架的不足，大家在紛紛探索下一代微服務框架。
在每一個主機上單獨部署一個代理進程，多個微服務共用一個代理進程，實現服務發現和負載均衡。
代理進程
這種模式通常被大家稱為“sideCar”，也就是“邊車模式”。
什么叫“邊車”，在早期有一種摩托車，駕駛位置旁邊掛著一個拖斗，對比微服務旁邊掛一個代理進程，所以形象地稱為“邊車模式”。
摩托車拖斗
在新一代的 ServiceMesh 架構中，服務消費者和服務提供者都會部署SideCar。
SideCar 模式
服務與服務之間是靠 sideCar 連接起來，sideCar 用來處理與業務無關的注冊、發現、熔斷、限流等治理能力。
略去業務服務和其他無關的東西，將所有的 sideCar 連接起來可以得到下面這張圖：
服務網格
是不是長得像網格，服務網格(service mesh)由此得名。
維基百科是這樣定義服務網格：
服務網格是一個基礎設施層，用于處理服務間通信。云原生應用有著復雜的服務拓撲，服務網格保證請求在這些拓撲中可靠地穿梭。在實際應用當中，服務網格通常是由一系列輕量級的網絡代理組成的，它們與應用程序部署在一起，但對應用程序透明。
總結
ServiceMesh(服務網格)的特點：
- 場景：用于微服務間的服務通信和服務治理
- 方案：邊車模式
- 定位：基礎設施層
服務網格是一種比較新的架構風格，大家在技術選型時不要盲目追新，適合當前業務發展的技術才是最好的技術。大家學會了嗎?
