Service Mesh解讀:新一代微服務技術新秀

本文轉自微信號EAWorld。掃描下方二維碼,關注成功後,回覆“普元方法+”,將會獲得熱門課堂免費學習機會!本文轉自微信號EAWorld。

Service mesh是一個專用的基礎設施層,功能在於提供安全、快速、可靠的服務間通訊(service-to-service)。一個雲原生應用(cloud native application)的構建離不開Service mesh。

在過去的一年裏,Service mesh已悄然興起,併成爲雲堆棧的一個重要組件。 像Paypal、Lyft、Ticketmaster和Credit Karma 這樣的高流量公司都在他們的產品應用中添加了Service mesh。 今年1月,Linkerd,作爲一個面向雲原生應用的開源Service mesh,成爲了雲原生計算基金會(CFCF)的官方項目。但到底什麼是Service mesh? 爲什麼突然受到如此大的關注?

在本文中,我將詳細介紹Service mesh的定義,並通過過去10年裏它在應用程序架構中的變化和大家追溯一下Service mesh的發展歷程。

首先,我將把Service mesh與API網關、邊界代理edge proxies和企業服務總線的相關但又截然不同的概念區分開來。 然後,我將介紹Service mesh的發展方向,以及在雲原生時代, 新一代的微服務開發技術Service mesh將帶給我們什麼樣的期待與變化。

1、什麼是Service mesh?

Service mesh是用於處理服務間通訊的專用基礎設施層。它負責通過複雜的拓撲結構服務來提供可靠的請求傳遞,這些服務構成了新一代雲原生應用程序。事實上,Service mesh通常是作爲一組輕量級高性能網絡代理實現的,這些代理與應用程序代碼部署在一起,但應用程序本身不需要關心這些。(不過,外界對此尚存在異議)

Service mesh作爲單獨層的概念與雲原生應用程序的大規模普及有關。 在雲原生模型中,單個應用程序可能包含數百個服務; 每個服務可能又包含數千個實例;並且這些實例中的每一個都可能處於不斷變化的狀態,因爲它們是由像Kubernetes這樣的服務協調程序動態調度的。世界上的服務通訊不僅極其複雜,而且是運行時行爲(runtime behavior)的一個普遍和基本的組成部分。管理好它對於確保端到端性能和可靠性是至關重要的。

2、Service mesh是一個網絡模型嗎?

Service mesh是一個網絡模型,它是位於TCP/IP之上的抽象層。它假定底層的L3/L4網絡是真實存在的,並且能夠點對點地傳遞字節。(它還假定了這個網絡像運行環境的其他方面一樣,是不可靠的; 因此,Service mesh必須能夠處理網絡故障。)

Service mesh在某些方面其實是類似於TCP/IP。就像TCP棧抽象出了網絡端點之間可靠傳遞字節的機制一樣,Service mesh在服務之間可靠地傳遞請求的機制也是抽象的。與TCP相同的是,Service mesh並不關心實際的有效負載,也不關心它的編碼問題。應用程序有一個高級目標(“從A到B發送一些數據”), Service mesh的職責,和TCP一樣,是在這個數據的發送過程中解決故障並圓滿完成數據發送。

但與TCP不同的是,Service mesh具有更高的性能,它的使命超越了“僅僅讓它可以工作”, 並且有一個更重要的目標: 它提供了統一的、應用廣泛的觀點,應用程序在運行操作時具有可視性和可控性。Service mesh的明確目標是將服務通訊從不可見的、隱含的基礎設施中抽離出來,在雲原生系統中扮演重要的一級成員的角色,從而可對系統進行監控,管理和控制。

3、Service mesh/服務網格具體能做什麼?
在雲原生應用中可靠地傳遞請求可能非常複雜。 像Linkerd這樣的Service mesh,通過一系列強大技術來管理這種複雜性: 鏈路熔斷、延遲感知、負載均衡,eventually consistent (“advisory”) 服務發現,服務續約及下線與剔除。這些功能必須協同工作,而這些功能與它們所操作的複雜環境之間的交互作用是非常微妙的。

例如,當通過Linkerd工具處理某個服務的請求時,簡化的事件時間表如下:

  1. Linkerd應用動態路由規則來確定請求者所需要的服務。應該將請求發送到生產或Staging的服務中嗎?還是到本地數據中心或雲平臺服中?

還是到正在進行測試的最新版本的或已通過審覈的舊有版本的服務中? 所有這些路由規則都是動態可配置的, 並且可以應用到整個系統和任意的流量段中。

  1. 找到了正確的目標之後,Linkerd從相關的服務發現節點中檢索相應的實例池(這其中可能有好幾個)。 如果這些信息與Linkerd在實踐中所觀察到的有所背離,Linkerd就會決定選擇相對正確的信息來源。

  2. Linkerd根據各種因素選擇最有可能返回快速響應的實例,包括所觀察到的最近請求的延遲。

  3. Linkerd嘗試將請求發送到實例,記錄結果的延遲和響應類型。

  4. 如果實例關閉,無響應或無法處理請求,Linkerd會在另一個實例上重新嘗試該請求(但只有它知道請求是冪等的情形下-即不管操作多少次結果都不變的性質)。

  5. 如果一個實例連續地返回錯誤,Linkerd會將其從負載均衡池中擇出去,然後再進行週期性的重新嘗試(例如,一個實例可能正在經歷一個暫時性的失敗)。

  6. 如果請求的截止時間已過,Linkerd將主動取消請求,不會通過進一步的重新嘗試進行加載。

  7. Linkerd以metrics和分佈式跟蹤的形式捕捉了上述行爲的各個方面,這些都被髮送到一個集中的metrics系統。

當然, 這只是Linkerd的簡化版本,Linkerd還可以發起和終止TLS,執行協議升級,動態轉移流量,並在數據中心之間進行失效轉移!

圖片描述

Linkerd Service mesh管理服務到服務間的通訊,並將其與應用程序代碼進行剝離。

需要注意的是,這些功能旨在兼顧應用實例(Point)的快速恢復能力和應用(application)的快速恢復能力。對於大型分佈式系統來說,無論其架構如何,都有一個典型的特徵:很容易出現局部的小故障,這些小故障最終可能會演變爲整個系統的災難性故障。 Service mesh必須被設計成能夠通過減少負載和在底層系統接近其極限時讓其快速失效來防止這些惡化演變。

4、爲什麼說使用Service mesh是非常有必要的?

Service mesh最終並不是引入一項新功能,而是功能定位的轉變。Web應用程序總是必須管理服務間通信的複雜性。要想了解Service mesh模型的起源, 我們可以追溯過去15年以來的這些應用程序的發展歷程。

你可以思考下2000年的中型web應用程序的典型架構: 三層應用程序。 在這個模型中,應用程序邏輯、web服務邏輯和存儲邏輯都是單獨的一層。 層之間的通信雖然複雜,但這種複雜性是限定在一定範圍內,因爲畢竟只有兩個跳轉。這裏沒有“網格”,但是在每個層的代碼中處理的跳轉之間有通信邏輯。

當這種架構方式在面對應用程序內部邏輯越來越複雜化的情形時,它就開始崩潰了。 像Google、Netflix和Twitter這樣的公司無時無刻都面臨着巨大的流量需求,它們實現了雲原生方案的前身: 應用層被分解成許多服務(有時稱爲“微服務”),層級間則形成了一個拓撲結構。 在這些系統中,廣義的通訊層突然變得相關起來, 但通常以“胖客戶端”的庫集(library)形式出現, 比如twitter的Finagle,Netflix的Hystrix,以及Google的Stubby就是這樣的例子。

從很多方面上來講,像Finagle, Stubby和Hystrix這些庫集其實是Service mesh的雛形。雖然它們受其周圍環境的細節影響,並且需要使用特定的語言和框架,但是它們是用於管理服務到服務間通信的專用基礎設施,並且(在開源Finagle和 Hystrix庫集的情形下)可以在其公司之外使用。

到了雲原生應用時期, 雲原生模型本身結合了許多小型服務的微服務方法和兩個額外的因素:容器(例如Docker),它提供了資源隔離和依賴關係管理,以及一個編排層(例如Kubernetes),它將底層硬件抽象出了一個同質池。

這三個組件支持應用程序在負載下可彈性伸縮的自然機制, 並能夠處理雲平臺環境中存在的部分故障。

但面對數百個服務或數千個實例,和隨時在重新安排實例的編排層,單個請求經由服務拓撲的路徑可能非常複雜, 而由於容器使每個服務用不同的語言寫入處理變得更容易了,庫集方法也就不再可行了。

這種複雜性和關鍵性的結合,激發了對服務到服務間通信的專用基礎層的需求,這個專用層與應用程序代碼分離出來,並能夠捕捉底層環境的高度動態特性。就是這一專用層我們稱之爲Service mesh。

5、Service mesh的未來發展

在雲原生系統中,Service mesh的運用正在迅速增長,而未來,還有一條廣闊的,令人興奮的發展路線圖等着我們去探索。無服務器計算(例如亞馬遜的Lambda)的要求直接適用於Service mesh的命名和鏈接模型,並且是它在雲原生系統中角色的自然擴展。

服務身份和訪問策略的作用在雲原生環境中仍然很新鮮,Service mesh在此很好的扮演着重要的角色。最後,Service mesh,就像在它之前的TCP/IP一樣,將繼續被推進運用到底層基礎設施層中。 正如Linkerd從Finagle這樣的系統演化而來,Service mesh的當前化身是一個獨立的用戶空間代理,必須明確地添加到雲堆棧中,並且將繼續發展。

6、小結

Service mesh是雲堆棧的一個關鍵組件。 Linkerd發佈至今雖然才一年多點,但已成爲雲原生計算基金會(CFCF)的主要成員,並擁有一個活躍的用戶羣體。其中的用戶包括像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/

關於EAWorld
微服務,DevOps,元數據,企業架構原創技術分享,EAii(Enterprise Architecture Innovation Institute)企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼,關注成功後,回覆“普元方法+”,將會獲得熱門課堂免費學習機會!
微信號:EAWorld,長按二維碼關注。

圖片描述

發佈了35 篇原創文章 · 獲贊 15 · 訪問量 3萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章