SM，第一篇
服務網格（ServiceMesh）這兩年異常之火，号稱是下一代微服務架構，接下來兩個月，準備系統性的寫寫這個東西，希望能夠讓大家對最新的架構技術，有個初步的了解。
畫外音：我的行文的風格了，“為什麼”往往比“怎麼樣”更重要。
網際網路公司，經常使用的是微服務分層架構。
随着資料量不斷增大，吞吐量不斷增加，業務越來越複雜，服務的個數會越來越多，分層會越來越細，除了資料服務層，還會衍生出業務服務層，前後端分離等各種層次結構。
不斷發現主要沖突，抽離主要沖突，解決主要沖突，架構自然演進了，微服務架構，潛在的主要沖突會是什麼呢？
引入微服務架構，一般會引入一個RPC架構，來完成整個RPC的調用過程。
- RPC-client，它嵌在調用方程序裡
-
RPC-server，是服務程序的基礎
不隻是微服務，MQ也是類似的架構：
如上圖粉色部分所示，MQ分為：
ServiceMesh究竟解決什麼問題？ - MQ-send-client
- MQ-server
- MQ-recv-client
架構隻是第一步，越來越多和RPC，和微服務相關的功能，會被加入進來。
例如：負載均衡
如果要擴充多種負載均衡方案，例如： ServiceMesh究竟解決什麼問題？ - 輪詢
- 随機
- 取模
- 一緻性哈希
RPC-client需要進行更新。
例如：資料收集
ServiceMesh究竟解決什麼問題？ 如果要對RPC接口處理時間進行收集，來實施統一監控與告警，也需要對RPC-client進行更新。
畫外音，處理時間分為：
- 用戶端視角處理時間
- 服務端視角處理時間
如果要收集後者，RPC-server也要修改與上報。
又例如：服務發現
ServiceMesh究竟解決什麼問題？ 服務新增一個執行個體，通知配置中心，配置中心通知已注冊的RPC-client，将流量打到新啟動的服務執行個體上去，迅猛完成擴容。
再例如：調用鍊跟蹤
ServiceMesh究竟解決什麼問題？ 如果要做全鍊路調用鍊跟蹤，RPC-client和RPC-server都需要進行更新。
下面這些功能：
- 負載均衡
- 資料收集
- 服務發現
- 調用鍊跟蹤
- …
其實都不是業務功能，是以網際網路公司一般會有一個類似于“架構部”的技術部門去研發和更新相關功能，而業務線的技術部門直接使用相關架構、工具與平台，享受各種“黑科技”帶來的便利。
完美！！！
理想很豐滿，現實卻很骨感，由于：
- 業務技術團隊，仍需要花時間去學習、使用基礎架構與各類工具，而不是全心全意将精力花在業務和産品上
- client要維護m個版本， server要維護n個版本，相容性要測試m*n個版本
- 如果要支援不同語言，往往要開發C-client，Python-client，go-client，Java-client多語言版本
- 每次“黑科技”的更新，都需要推動上下遊進行更新，這個周期往往是以季度、半年、又甚至更久，整體效率極低
畫外音：兄弟，貴司推廣一個技術新産品，周期要多長？
這些耦合，這些通用的痛點，有沒有辦法解決呢？
一個思路是，将服務拆分成兩個程序，解耦。
ServiceMesh究竟解決什麼問題？ - 一個程序實作業務邏輯（不管是調用方，還是服務提供方），biz，即上圖白色方塊
- 一個程序實作底層技術體系，proxy，即上圖藍色方塊
畫外音：負載均衡、監控告警、服務發現與治理、調用鍊…等諸多基礎設施，都放到這一層實作。
- biz和proxy共同誕生，共同消亡，互為本地部署，即上圖虛線方框
- biz和proxy之間，為本地通訊，即上圖黑色箭頭
- 所有biz之間的通訊，都通過proxy之間完成，proxy之間才存在遠端連接配接，即上圖紅色箭頭
這樣就實作了“業務的歸業務，技術的歸技術”，實作了充分解耦，如果所有節點都實作了解耦，整個架構會演變為：
綠色為biz
藍色為proxy
整個服務叢集變成了網格狀，這就是Service Mesh服務網格的由來。
架構演進，永無窮盡，痛點多了，自然要分層解耦。希望大家有收獲，後續再細聊SM的設計與架構細節。
思路比結論更重要。
本文轉自“架構師之路”公衆号，58沈劍提供。