2019獨角獸企業(yè)重金招聘Python工程師標準>>>

Service Mesh（服務(wù)網(wǎng)格）會是今年微服務(wù)生態(tài)的主角嗎？從趨勢來看，眾多企業(yè)正在將這項理微服務(wù)復雜性的技術(shù)/工具，搬進他們的IT“火藥庫”之中。

什么是Service Mesh？

根據(jù)Linkerd CEO William Morgan定義，Service Mesh是用于處理服務(wù)間通信的基礎(chǔ)設(shè)施層，用于在云原生應(yīng)用復雜的服務(wù)拓撲中實現(xiàn)可靠的請求傳遞。在實踐中，Service Mesh通常是一組與應(yīng)用一起部署，但對應(yīng)用透明的輕量級網(wǎng)絡(luò)代理。

Service Mesh與傳統(tǒng)基礎(chǔ)設(shè)施層不同之處在于，它形成了一個分布式的互連代理網(wǎng)絡(luò)，以sidecar形式部署在服務(wù)兩側(cè)，服務(wù)對于代理無感知，且服務(wù)間所有通信都由代理進行路由。

為什么需要Service Mesh？

“Smart endpoint and dumb pipes”是微服務(wù)架構(gòu)在集成服務(wù)時采用的一個核心理念，這一理念改變了過去臃腫集中的ESB（企業(yè)服務(wù)總線），無疑是正確方向上的一大進步，但同時也給我們出了一些難題——多智能才不會過于智能，而服務(wù)輕重大小的程度如何拿捏？我們應(yīng)該如何處理微服務(wù)系統(tǒng)中服務(wù)間交互的復雜性？放在服務(wù)內(nèi)部還是外部？如果是內(nèi)部，如何處理業(yè)務(wù)邏輯關(guān)系，或者應(yīng)該與基礎(chǔ)設(shè)施更為相關(guān)？如果是外部，如何避免重蹈ESB的覆轍？

皮的不談，先來看看處理服務(wù)間通信時需要關(guān)注的點：

• 服務(wù)發(fā)現(xiàn)
• 負載均衡
• 路由
• 流量控制
• 通信可靠性
• 彈性
• 安全
• 監(jiān)控/日志

似乎都是老生常談，存在于任何需要處理網(wǎng)絡(luò)的分布式系統(tǒng)之中，區(qū)別在于，當所涉及微服務(wù)數(shù)量呈指數(shù)級增加，這些問題也會被相應(yīng)放大。

一個已經(jīng)被廣泛應(yīng)用的解決方案是利用api網(wǎng)關(guān)來處理服務(wù)外部和服務(wù)之間的請求，提供例如服務(wù)發(fā)現(xiàn)、路由、監(jiān)控、流量控制等。

然而，api網(wǎng)關(guān)有一個比較致命的缺陷，它容易出現(xiàn)單點故障并且實踐不當很有可能會變得異常臃腫。另一方面，api網(wǎng)關(guān)核心是面向用戶，也就是說它可以解決從用戶到微服務(wù)的流量問題，但不能解決所有問題，而我們需要的是一個完整的方案，或者至少是一些能夠與api網(wǎng)關(guān)互補的方案和工具。

另一種選擇是在網(wǎng)絡(luò)堆棧的較低層級（4/3）進行可靠性、監(jiān)控、流量控制等方面處理。這種選擇的問題是，在較低較低的操作難易滿足應(yīng)用層的問題。聯(lián)想end-to-end（端到端）的理論，我們前面提到的那幾個關(guān)注點實際上還是集中在應(yīng)用層，也只能在應(yīng)用層成功實現(xiàn)。

像Netflix、Twitter等SOA/微服務(wù)的早期采用者，他們通過建立內(nèi)部庫的方式處理這些問題，然后提供給所有服務(wù)使用。這種方法的問題在于，把庫擴展到成百上千個微服務(wù)中難度極高，而且這些庫相對來說是比較”脆弱“的，我們很難保證他們可以適應(yīng)所有的技術(shù)堆棧選擇。

程度上來說，Service Mesh與這些庫很類似，但Service Mesh是與服務(wù)相鄰的獨立進程。服務(wù)連接到代理，代理反過來又與其他代理（HTTP1.1/2、GRPC）進行通信。它們是相對獨立的進程，在應(yīng)用層或應(yīng)用層之下分布和運行，進而解決了上述兩個方案存在的缺陷。

Service Mesh架構(gòu)

Service Mesh由data plane構(gòu)成，其中所有服務(wù)通過sidecar代理進行服務(wù)通信。（所有代理相互連接形成一個Mesh，Service Mesh由此得名）網(wǎng)格同時包含一個control plane——可以將所有獨立的sidecar代理連接到一個分布式網(wǎng)絡(luò)中，并設(shè)置網(wǎng)格還包括一個控制平面——它將所有獨立的sidecar代理連接到一個分布式網(wǎng)絡(luò)中，并設(shè)置由data plane指定的策略。

Control plane定義服務(wù)發(fā)現(xiàn)、路由、流量控制等策略。這些策略可以是全局的，也可以是限定的。Data plane負責在通信時應(yīng)用和執(zhí)行這些策略。

最后

總結(jié)來說，Service Mesh是“時間的產(chǎn)物”，Docker、Kubernetes等容器技術(shù)直接推進了對于Service Mesh的需求，讓復雜的系統(tǒng)可以被輕松部署和管理。

未來Service Mesh將如何發(fā)展還未可知，或許會像TCP/IP一樣形成標準，或許不同工具和平臺會獨具一格……但有一點是確認的，Service Mesh對于微服務(wù)生態(tài)的價值令人難以忽視，能夠?qū)⒎敝氐姆?wù)治理工作變得簡單高效，何樂而不為？

---

相關(guān)閱讀

• 技術(shù)解讀Rainbond ServiceMesh微服務(wù)架構(gòu)_開源PaaS Rainbond 2018/05/15

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

轉(zhuǎn)載于:https://my.oschina.net/zhouyq/blog/1818003

總結(jié)

以上是生活随笔為你收集整理的Service Mesh服务网格：是什么和为什么的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。