Service Mesh服務網格：是什麼和爲何

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/二、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 Rainbond 2018/05/15

開源PaaS Rainbond原生支持Service Mesh，在線體驗請註冊公有云（新用戶7天免費）