歡迎光臨
每天分享高質量文章

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

 

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應該會對這個領域產生重大影響。
相關鏈接:
  1. https://kublr.com/blog/implementing-a-service-mesh-with-istio-to-simplify-microservices-communication/

  2. 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
赞(0)

分享創造快樂