服務網格是如何輔助微服務管理的？-知識星球

IT在資料化轉型旗幟下的一個重大轉換就是將大型的、整體的應用架構分拆成為細小獨立的，功能級的微服務架構。這些微服務軟體包執行在容器內，同時封裝了服務的所有程式碼和依賴關係，可以獨立執行，並輕易地在伺服器環境之間遷移。

也是受益於容器化架構可以輕易在雲環境上執行和擴充套件，個體微服務同樣可以快速部署和迭代更新。然而，隨著應用中微服務數量，同一微服務的並行數不斷增長，使得微服務之間的通訊變得難以想象的複雜。這就需要架構上有一種方式可以動態地連線所有的微服務，從而減少管理和程式設計開銷，於是，新興的服務網格便應運而生了。

服務網格定義

從廣義上講，服務網格正如Red Hat所描述“一種控制應用程式內的不同模組相互共享資料的方法”。不過，這個描述涵蓋了很多不同的內容。實際上，對於熟悉C/S應用的大多數開發人員來講，這個描述聽起來更像是中介軟體。

但服務網格的獨特之處在於，它是為適應分散式微服務環境的獨特特性而構建的。在微服務構建的大型應用中，任何給定服務都可能是執行在本地或雲端的多個實體上。這種動態的架構顯然很難做到，隨時讓單個微服務與所需要的其他服務建立通訊。服務網格則能夠自動地實現微服務的瞬間發現和相應服務的連線。讓軟體開發人員和單個微服務無需考慮這方面的功能和實現。

我們可以將服務網格的作用類比為OSI網路模型中第7級的軟體定義網路（SDN）。SDN建立了一個抽象層，使網路管理員不必處理物理網路連線，服務網格則是將應用程式的底層基礎設施與軟體所互動的抽象體系結構進行瞭解耦。所以，當開發人員真正開始面對龐大複雜的分散式體系結構的問題的時候，服務網格的概念就自然而然地產生了。代表性的專案有：首個服務網格專案Linkerd，它是Twitter內部專案的一個分支。以及另一個流行的服務網格專案Istio，它起源於Lyft，得到了許多大企業的支援。（稍後詳細地介紹）

服務網格負載均衡

服務網格提供的一個關鍵功能就是負載均衡。我們通常認為負載均衡是網路功能，因為它提供按規則的資料包路由轉發，從而防止任何單臺伺服器或網路連結的流量過載。借用Twain Taylor的描述，服務網格就是在應用級別上做了類似的事情，我們可以將它理解為應用程式層的軟體定義網路。

本質上，服務網格的一個主要工作是對分佈在基礎設施中的各種微服務的實體，進行健康狀態的持續跟蹤。它可能會輪詢這些實體的請求處理狀態，或者跟蹤服務請求響應較慢的實體，然後將後續請求傳送給其他的實體。類似於網路路由，它還會關註訊息到達目的地消耗時間過長的請求，並調整後續路由來補償。這些用時過長可能是由於底層硬體的問題，或者僅僅是由於服務被請求過載或處理能力不足造成的。但重要的是，服務網格可以找到相同服務的其他實體來接替請求處理，從而最有效地利用整個應用程式的處理能力。

服務網格 vs Kubernetes

對容器化體系結構有所瞭解的人，可能想知道Kubernetes（開源容器編製平臺）在服務網格方面的情況。況且，Kubernetes的核心意義就是管理容器之間的通訊。正如Kublr團隊在其公司部落格[1]上指出的，您可以將Kubernetes的“Service”資源看作是一種非常基本的服務網格，它提供了服務發現和請求的均衡輪詢能力。但是專用的服務網格產品能夠提供更多的功能，例如安全策略管理、加密、對疑似響應慢實體的請求的“斷路”掛起、請求的負載均衡等等。但需要始終牢記一點，大多數服務網格實際上都需要像Kubernetes這樣的編排系統。服務網格提供的應該是功能的擴充套件，而不是功能替代。

服務網格 vs API閘道器

每個微服務都將提供一個應用程式程式設計介面（API），用於與其他服務的通訊。這就引出了服務網格與傳統的API管理形式（如API閘道器）之間的差異比較。借用IBM的解釋，API閘道器是位於一組微服務和應用“外部”之間，根據需要路由服務請求，讓請求者無需知道它所訪問的應用程式是基於微服務架構的。但服務網格不僅有上述能力，它還在應用程式“內部”的微服務之間協調請求，且各個元件完全瞭解整個應用內部的環境。另一種看法就如Justin Warren在《福布斯》[2]中所寫的，服務網格用於叢集內的東西流量，而API閘道器用於叢集內外的南北流量。

但目前，整個服務網格的概念還是處於很早期和不斷變化之中。包括Linkerd和Istio在內的許多服務網格也能夠提供南北流量的管理功能。

服務網格的架構

由於服務網格的概念是在最近幾年才剛剛提出的，所以對於服務網格所解決的問題，例如管理微服務間通訊等存在多種不同的實現方法。其中，對於服務網格建立的通訊層應該位於架構的位置，Aspen Mesh的Andrew Jenkins就提出了三種可能的選擇，即：

作為一個Lib庫，讓每個微服務可匯入。
部署在節點的代理服務中，為所在節點的全部容器提供服務。
與應用容器相並行，運作在一個獨立的sidecar容器內。

其中，基於sidecar樣式是目前最流行的服務網格樣式，以至於在某種程度上講，它已經成等同於服務網格的樣式。雖然這樣表達不準確，但是sidecar方法已經得到了非常多的關註，我們也將詳細地討論一下這種架構方法。

服務網格的Sidecar 樣式

在應用容器旁邊執行一個sidecar容器意味著什麼呢？紅帽有一個很好的闡述：服務網格中的每個應用微服務容器都有一個對應匹配的代理容器。服務到服務的通訊所需的所有邏輯請求都從微服務中抽象出來，放到了sidecar中處理。

這看起來可能很複雜，實際上，sidecar樣式還使得應用程式中的容器數量翻了一倍！但這種設計樣式也是簡化分散式應用的關鍵所在。透過將所有網路和通訊程式碼放到一個單獨的容器中，使其成為基礎設施的一部分，並使開發人員不必將如上的內容視為應用程式的一部分而投入精力處理。

從本質上說，抽象後剩下的也是一個微服務，但它可以非常專註於其業務邏輯。在微服務所執行的複雜環境中，它不需要知道如何與其他的任何微服務實現通訊的問題，它只需要知道如何與sidecar通訊，然後由sidecar負責餘下的工作就可以啦。

服務網格產品：Linkerd、Envio、Istio、Consul

目前，服務網格還沒有現成的商業產品，大多數都是開源專案，在部署應用上，需要一定的實施技巧和技術經驗。比較有知名度的產品有:

Linkerd（讀作“link-dee”）：2016年釋出的元老級專案。Linkerd最初是從Twitter開發的一個庫中分離出來的，在領域內的另一個重量級專案Conduit加入後，便形成了Linkerd 2.0的基礎。
Envoy：由Lyft建立，Envoy充當服務網格的“資料平面”，與“控制平面”相匹配，提供比較完整的服務網格服務。
Istio：由Lyft、IBM和谷歌聯合開發而成，是服務於Envoy等代理的“控制平面”。雖然預設是與Envoy成對匹配，但是它們都可以與其他平臺配對使用。
HashiCorp Consul：在 Consul 1.2版本後，推出了名為Connect的功能，這個功能為HashiCorp的分散式系統的服務發現和配置部分，添加了服務加密和基於身份的授權的功能。這個使得使HashiCorp Consul成為非常完整的服務網格。

如何選擇適合自己的服務網？這個問題的答案顯然超出了本文的範圍，但可以肯定的是，上面提到的所有產品都已經在大型和高要求的環境中得到了驗證。Linkerd和Istio擁有最廣泛的特性集，如果對具體特徵有興趣，建議您可以看看George Miranda對Linkerd、Envoy和Istio特性的分析。由於軟體演化迭代迅速，所以請留意他的文章是在Conduit和Linkerd聯合之前寫的。

同時還需要註意，服務網格是一個新的領域，新的競爭者隨時都可能出現。例如，2018年11月，亞馬遜就提供了AWS的服務網格App Mesh的公開預覽，考慮到AWS的眾多零售客戶，估計AWS APP Mesh應該會對這個領域產生重大影響。

相關連結：

https://kublr.com/blog/implementing-a-service-mesh-with-istio-to-simplify-microservices-communication/
https://www.forbes.com/sites/justinwarren/2018/12/19/service-mesh-is-super-hot-why/#f0439b3544b8

原文連結：https://www.infoworld.com/article/3402260/how-a-service-mesh-helps-manage-distributed-microservices.html

釋出到看一看

</div><br />
<p><span class=”like_comment_msg” id=”js_b_like_comment_msg” style=”visibility: hidden;”>最多200字，當前共<span id=”js_b_like_current_cnt”/>字</span><br />
</div><br />
</div><br />
<div class=”like_comment_primary_mask” id=”js_mask_2″/><br />
</div><br />
<div id=”js_loading” style=” display: none;”><br />
<div class=”weui-mask_transparent”/><br />
<div class=”weui-toast”><br />
<i class=”weui-loading weui-icon_toast”/></p><br />
<p class=”weui-toast__content”>傳送中</p><br />
</div><br />
</div><br />
<div class=”weui-desktop-popover weui-desktop-popover_pos-up-center weui-desktop-popover_img-text” id=”js_pc_weapp_code” style=”display: none;”><br />
<div class=”weui-desktop-popover__content”><br />
<div class=”weui-desktop-popover__desc”><br />
<img id=”js_pc_weapp_code_img”/><br /><br />
            微信掃一掃<br/>使用小程式<span id=”js_pc_weapp_code_des”/> </div><br />
</div><br />
</div><br />
<div id=”js_minipro_dialog” style=”display:none;”><br />
<div class=”weui-mask”/><br />
<div class=”weui-dialog weui-dialog_link”><br />
<div class=”weui-dialog__bd” id=”js_minipro_dialog_name”/><br />
<div class=”weui-dialog__ft”><br />
<a class=”weui-dialog__btn weui-dialog__btn_default” href=”javascript:void(0);” id=”js_minipro_dialog_cancel”>取消</a><br /><br />
<a class=”weui-dialog__btn weui-dialog__btn_primary” href=”javascript:void(0);” id=”js_minipro_dialog_ok”>允許</a><br />
</div><br />
</div><br />
</div><br />
<div id=”js_link_dialog” style=”display:none;”><br />
<div class=”weui-mask”/><br />
<div class=”weui-dialog weui-dialog_link”><br />
<div class=”weui-dialog__bd” id=”js_link_dialog_name”>即將開啟一個新頁面</div><br />
<div class=”weui-dialog__ft”><br />
<a class=”weui-dialog__btn weui-dialog__btn_default” href=”javascript:void(0);” id=”js_link_dialog_cancel”>取消</a><br /><br />
<a class=”weui-dialog__btn weui-dialog__btn_primary” href=”javascript:void(0);” id=”js_link_dialog_ok”>允許</a><br />
</div><br />
</div><br />
</div><br />
</div><br />

服務網格是如何輔助微服務管理的？

朋友會在“發現-看一看”看到你“在看”的內容

朋友將在看一看看到

釋出到看一看

相關推薦

熱門標籤

熱門文章

分享創造快樂