Service Mesh（服務網格）會是今年微服務生態的主角嗎？從趨勢來看，眾多企業正在將這項理微服務復雜性的技術/工具，搬進他們的IT“火葯庫”之中。
什么是Service Mesh？
根據Linkerd CEO William Morgan定義，Service Mesh是用於處理服務間通信的基礎設施層，用於在雲原生應用復雜的服務拓撲中實現可靠的請求傳遞。在實踐中，Service Mesh通常是一組與應用一起部署，但對應用透明的輕量級網絡代理。
Service Mesh與傳統基礎設施層不同之處在於，它形成了一個分布式的互連代理網絡，以sidecar形式部署在服務兩側，服務對於代理無感知，且服務間所有通信都由代理進行路由。
為什么需要Service Mesh？
“Smart endpoint and dumb pipes”是微服務架構在集成服務時采用的一個核心理念，這一理念改變了過去臃腫集中的ESB（企業服務總線），無疑是正確方向上的一大進步，但同時也給我們出了一些難題——多智能才不會過於智能，而服務輕重大小的程度如何拿捏？我們應該如何處理微服務系統中服務間交互的復雜性？放在服務內部還是外部？如果是內部，如何處理業務邏輯關系，或者應該與基礎設施更為相關？如果是外部，如何避免重蹈ESB的覆轍？
皮的不談，先來看看處理服務間通信時需要關注的點：
- 服務發現
- 負載均衡
- 路由
- 流量控制
- 通信可靠性
- 彈性
- 安全
- 監控/日志
似乎都是老生常談，存在於任何需要處理網絡的分布式系統之中，區別在於，當所涉及微服務數量呈指數級增加，這些問題也會被相應放大。
一個已經被廣泛應用的解決方案是利用api網關來處理服務外部和服務之間的請求，提供例如服務發現、路由、監控、流量控制等。
然而，api網關有一個比較致命的缺陷，它容易出現單點故障並且實踐不當很有可能會變得異常臃腫。另一方面，api網關核心是面向用戶，也就是說它可以解決從用戶到微服務的流量問題，但不能解決所有問題，而我們需要的是一個完整的方案，或者至少是一些能夠與api網關互補的方案和工具。
另一種選擇是在網絡堆棧的較低層級（4/3）進行可靠性、監控、流量控制等方面處理。這種選擇的問題是，在較低較低的操作難易滿足應用層的問題。聯想end-to-end（端到端）的理論，我們前面提到的那幾個關注點實際上還是集中在應用層，也只能在應用層成功實現。
像Netflix、Twitter等SOA/微服務的早期采用者，他們通過建立內部庫的方式處理這些問題，然后提供給所有服務使用。這種方法的問題在於，把庫擴展到成百上千個微服務中難度極高，而且這些庫相對來說是比較”脆弱“的，我們很難保證他們可以適應所有的技術堆棧選擇。
程度上來說，Service Mesh與這些庫很類似，但Service Mesh是與服務相鄰的獨立進程。服務連接到代理，代理反過來又與其他代理（HTTP1.1/2、GRPC）進行通信。它們是相對獨立的進程，在應用層或應用層之下分布和運行，進而解決了上述兩個方案存在的缺陷。
Service Mesh架構
Service Mesh由data plane構成，其中所有服務通過sidecar代理進行服務通信。（所有代理相互連接形成一個Mesh，Service Mesh由此得名）網格同時包含一個control plane——可以將所有獨立的sidecar代理連接到一個分布式網絡中，並設置網格還包括一個控制平面——它將所有獨立的sidecar代理連接到一個分布式網絡中，並設置由data plane指定的策略。
Control plane定義服務發現、路由、流量控制等策略。這些策略可以是全局的，也可以是限定的。Data plane負責在通信時應用和執行這些策略。
最后
總結來說，Service Mesh是“時間的產物”，Docker、Kubernetes等容器技術直接推進了對於Service Mesh的需求，讓復雜的系統可以被輕松部署和管理。
未來Service Mesh將如何發展還未可知，或許會像TCP/IP一樣形成標准，或許不同工具和平台會獨具一格……但有一點是確認的，Service Mesh對於微服務生態的價值令人難以忽視，能夠將繁重的服務治理工作變得簡單高效，何樂而不為？
相關閱讀
技術解讀Rainbond ServiceMesh微服務架構_開源PaaS Rainbond2018/05/15