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

Service Mesh 是什麼,我們為什麼需要它?

 

Service Mesh 是一個專門使服務與服務之間的通訊變得安全、快速和可靠的的基礎設施。如果你正在在構建一個雲原生( Cloud Native )應用,那麼你一定需要 Service Mesh 。
在過去的一年中, Service Mesh 成為了雲原生技術棧的關鍵元件。像 PayPal , Ticketmaster 和 Credit Karma 這樣的大廠,已經將 Service Mesh 加入到他們的應用中。並且在 2017 年 1 月,開源的 Service Mesh 軟體 Linkerd 加入雲原生基金會( CNCF ),成為雲原生基金會(CNCF)的官方專案。但是什麼是真正的 Service Mesh?它又為何突然變的如此重要?
在這篇文章,我會講解 Service Mesh 的定義,並透過應用服務架構過去十年的發展追溯其起源。並將 Service Mesh 與其他相似的概念,包括 API 閘道器,邊緣代理以及 ESB (enterprise service bus)進行區分。最終,將會描述 Service Mesh 的發展方向,以及隨著雲原生概念的普及,Service Mesh 發生的變化。

 

什麼是 Service Mesh

 

Service Mesh 這個服務網路專註於處理服務和服務間的通訊。其主要負責構造一個穩定可靠的服務通訊的基礎設施,並讓整個架構更為先進和 Cloud Native。在實踐中,Service Mesh 基本來說是一組輕量級的服務代理和應用邏輯的服務在一起,並且對於應用服務是透明的。
Service Mesh 作為獨立層的概念與雲原生應用的興起有關。在雲原生樣式,單個應用可能有數百個服務組成,每個服務又可能有上千個實體,而每個實體都有可能被像 Kubernetes 這樣的服務排程器不斷排程從而不斷變化狀態。而這些複雜的通訊又普遍是服務執行時行為的一部分,這時確保端到端的通訊的效能和可靠性就變的至關重要。

 

Service Mesh 就是一個網路模型嗎?

 

Service Mesh 是一個位於 TCP/IP 上的抽象層的網路模型。它假定底層 L3/L4 網路存在並且能夠從一點向另一點傳輸資料。(它還假定這個網路和環境的其他方面一樣不可靠,所以 Service Mesh 也必須能夠處理網路故障。)
在某些方面,Service Mesh 就像是網路七層模型中的第四層 TCP 協議。其把底層的那些非常難控制的網路通訊方面的控制面的東西都管了(比如:丟包重傳、擁塞控制、流量控制),而更為上面的應用層的協議,只需要關心自己業務應用層上的事了。
與 TCP 不同的是, Service Mesh 想要達成的目的不僅僅是正常的網路通訊。它為應用提供了統一的,視覺化的以及可控制的控制平面。Service Mesh 是要將服務間的通訊從無法發現和控制的基礎設施中分離出來,並對其進行監控、管理和控制。

 

Service Mesh 實際上做了什麼?

 

在雲原生應用中傳遞可靠的請求是十分複雜的。而 Linkerd 提供了服務熔斷、重試、負載均衡、熔斷降級等功能,透過其強大的功能來管理那些必須執行在複雜環境中的服務。
這裡列舉一個透過 Linkerd 向服務發出請求的簡單流程:
  1. 透過 Linkerd 的動態路由規則來確定打算連線哪個服務。這個請求是要路由到生產環境還是演示環境?是請求本地資料中心的服務還是雲上的服務?是請求正在測試的最新版的服務還是已經在生產中經過驗證的老版本?所有的這些路由規則都是動態配置的,可以全域性應用也可以部分應用。

  2. 找到正確的目的服務後,Linkerd 從一個或幾個相關的服務發現端點檢索實體池。如果這些資訊與 Linkerd 的服務發現資訊不同, Linkerd 會決定信任哪些資訊來源。

  3. Linkerd 會根據觀察到的最近的響應延遲來選擇速度最快的實體。

  4. Linkerd 傳送請求給這個實體,記錄延遲和響應型別。

  5. 如果這個實體掛了、無響應或者無法處理請求, Linkerd 會再另一個實體上重試這個請求(但只有在請求是冪等的時候)。

  6. 如果一個實體一直請求失敗, Linkerd 會將其移出定時重試的負載均衡池。

  7. 如果請求超時, Linkerd 會主動將請求失效,而不是進一步重試從而增加負載。

  8. Linkerd 會記錄指標和分散式的追蹤上述行為的各個方面,將他們儲存在集中的指標系統中。

     

以上只是簡化版的介紹, Linkerd 還可以啟動和重試 TLS ,執行協議升級,動態切換流量,甚至在故障之後資料中心的切換。
值得註意的是,這些功能旨在為每個實體和應用程式提供彈性伸縮。而大規模的分散式系統(無論是如何構建的)都有一個共同特點:都會因為許多小的故障,而升級為全系統災難性的故障。Service Mesh 則被設計為透過快速的失效和減少負載來保護整個系統免受這樣災難性的故障。

 

為什麼 Service Mesh 是必要的?

 

Service Mesh 本質上並不是什麼新技術,而是功能所在位置的轉變。Web 應用需要管理複雜的服務通訊,Service Mesh 樣式的起源和演變過程可以追溯到15年前。
參考2000年左右中型 Web 應用的典型三層架構,在這個架構中,應用被分為三層:應用邏輯、Web 服務邏輯、儲存邏輯。層之間的通訊雖然複雜,但是畢竟範圍有限,最多隻有 2 跳。這裡並不是 “Mesh” 的,但在每層中處理跳轉的程式碼是存在通訊邏輯的。
當這種架構向更大規模發展的時候,這種通訊方式就無以為繼了。像 Google、Netflix 和 Twitte ,在面臨巨大的請求流量的時候,他們實現了雲原生應用的前身:應用被分割成了許多服務(現在稱作“微服務”),這些服務組成了一種網格結構。在這些系統中,通用通訊層突然興起,表現為“胖客戶端”的形式——Twitter 的 Finagle,Netflix 的 Hystrix 和 Google 的 Stubby 都是很典型的例子。
現在看來,像 Finagle 、Stubby 和 Hystrix 這樣的庫就是最早的 Service Mesh。雖然它們是為特定環境、語言和框架定製了,但都是作為基礎設施專門用於管理服務間的通訊,並(在 Finagle 和 Hystrix 開源的情況下)在其他公司的應用中被使用。
這三個元件都有應用自適應機制,以便在負載中進行拓展,並處理在雲環境中的部分故障。但是對於數百個服務或數千個實體,以及不時需要重新排程的業務層實體,單個請求透過的呼叫鏈可能變的非常複雜,而且服務可能由不同的語言編寫,這時基於庫的解決方案可能就不再適用了。
服務通訊的複雜性和重要性導致我們急需一個專門的基礎設施層來處理服務間的通訊,該層需要與業務程式碼解耦,並且具有捕獲底層環境的動態機制。這就是 Service Mesh。

 

Service Mesh 的未來

 

Service Mesh 在雲生態下迅速的成長,並且有著令人激動的未來等待探索。對無伺服器計算(Serverless, 例如 Amazon 的 Lambda)適用的 Service Mesh 網路模型,在雲生態系統中角色的自然拓展。Service Mesh 可能成為服務身份和訪問策略這些在雲原生領域還是比較新的技術的基礎。最後,Service Mesh,如之前的TCP / IP,將推進加入到底層的基礎架構中。就像 Linkerd 是由像 Finagle 這樣的系統發展而來,Service Mesh 將作為單獨的使用者空間代理新增到雲原生技術棧中繼續發展。

 

結語

 

Service Mesh 是雲原生技術棧的關鍵技術。Linkerd 成立僅 1 年就成為了雲原生基金會(CNCF)的一部分,擁有蓬勃發展的社群和貢獻者。使用者從像 Monzo 這樣顛覆英國銀行業的創業公司,到像 PayPal、 Ticketmaster 和 Credit Karma 這樣的網際網路大廠,再到像 Houghton Mifflin Harcourt 這樣經營了數百年的公司。
使用者和貢獻者每天都在 Linkerd 社群展示 Service Mesh 創造的價值。我們將致力於打造這一令人驚嘆的產品,並繼續發展壯大我們的社群。
原文連結:https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/

贊(0)

分享創造快樂