服務網格是一種眾所周知的整合微服務和遷移到雲端基礎架構的架構模式。 如今，在雲端容器世界中，沒有它是非常困難的。 市場上已經有幾種開源服務網格實現，但它們的功能、可靠性和安全性並不總是足夠，特別是當涉及到全國大型金融公司的要求時。 這就是為什麼我們 Sbertech 決定客製化 Service Mesh，並想談談 Service Mesh 的優點、缺點以及我們將採取的措施。
隨著雲端技術的普及，Service Mesh 模式越來越受歡迎。 它是一個專用的基礎設施層，可以簡化不同網路服務之間的互動。 現代雲端應用程式由數百甚至數千個此類服務組成，每個服務可以有數千個副本。
這些服務之間的互動和管理是Service Mesh的關鍵任務。 事實上，這是一個由許多代理組成的網路模型，集中管理並執行一組非常有用的功能。
在代理層級（資料平面）：
- 分配和分發路由和流量平衡策略
- 金鑰、憑證、令牌的分發
- 收集遙測數據，產生監控指標
- 與安全和監控基礎設施集成
在控制平面層面：
- 應用路由和流量平衡策略
- 管理重試和逾時、偵測「死」節點（熔斷）、管理注入故障並透過其他機制確保服務彈性
- 呼叫認證/授權
- 刪除指標（可觀察性）
對這項技術的開發感興趣的用戶範圍非常廣泛——從小型新創公司到大型網路公司，例如 PayPal。
為什麼企業部門需要 Service Mesh？
使用服務網格有許多明顯的好處。 首先，它對於開發人員來說只是方便：用於編寫程式碼 技術平台出現，由於傳輸層與應用程式邏輯完全隔離，因此顯著簡化了與雲端基礎架構的整合。
另外， 服務網格簡化了供應商和消費者之間的關係。 如今，API 供應商和消費者可以更輕鬆地自行就介面和合約達成一致，而無需涉及特殊的整合中介和仲裁者（企業服務總線）。 這種方法顯著影響兩個指標。 將新功能推向市場的速度（上市時間）加快了，但同時解決方案的成本也增加了，因為整合必須獨立完成。 業務功能開發團隊使用 Service Mesh 有助於保持平衡。 因此，API 提供者可以專注於其服務的應用程式元件，並將其簡單地發佈在 Service Mesh 中 - API 將立即可供所有客戶端使用，並且整合的品質將是生產就緒的，並且不需要單個行附加程式碼。
下一個優點是 使用 Service Mesh 的開發人員僅專注於業務功能 ——關於產品而非其服務的技術組成部分。 例如，您不再需要考慮這樣的事實：在透過網路呼叫服務的情況下，某個地方可能會發生連線失敗。 此外，Service Mesh 有助於平衡相同服務副本之間的流量：如果其中一個副本“死亡”，系統會將所有流量切換到剩餘的即時副本。
服務網格 - 這是創建分散式應用程式的良好基礎，它向客戶端隱藏了提供內部和外部服務呼叫的詳細資訊。 使用 Service Mesh 的所有應用程式在傳輸層級都與網路和彼此隔離：它們之間沒有通訊。 在這種情況下，開發人員可以完全控制其服務。
應當指出的是 在服務網格環境中更新分散式應用程式變得更加容易。 例如，藍/綠部署，其中有兩個應用程式環境可供安裝，其中一個應用程式環境未更新且處於待機模式。 發布不成功時回滾到之前的版本是透過一個特殊的路由器來執行的，Service Mesh 的作用很好地應對. 要測試新版本，您可以使用 金絲雀發布 — 僅將來自試點客戶群組的 10% 的流量或請求切換到新版本。 主要流量流向舊版本，沒有任何中斷。
還 Service Mesh 為我們提供即時 SLA 控制。 當其中一個客戶端超過分配給它的配額時，分散式代理系統將不允許服務失敗。 如果 API 吞吐量有限，那麼沒有人能夠用大量交易壓倒它：Service Mesh 站在服務前面，不允許不必要的流量。 它只會在整合層進行反擊，而服務本身將繼續工作而不會注意到它。
如果公司希望降低整合解決方案的開發成本，Service Mesh 也可以幫助： 您可以從商業產品切換到其開源版本。 我們的企業服務網格是基於服務網格的開源版本。
另一個優點—— 提供一套完整的整合服務。 因為所有整合都是透過這個中間件建構的，所以我們可以管理構成公司業務核心的應用程式之間的所有整合流量和連接。 非常舒服。
最後 服務網格鼓勵公司轉向動態基礎設施。 現在許多人都在尋求貨櫃化。 將整體架構切割成微服務，完美地實現這一切——這個主題正在興起。 但當你嘗試將一個已經生產多年的系統轉移到一個新平台時，你立即會遇到許多問題：將其全部推入容器並部署到平台上並不容易。 而這些分散式元件的實作、同步和互動又是另一個非常複雜的議題。 他們將如何相互溝通？ 會不會有連鎖故障？ Service Mesh 可以幫助您解決其中一些問題，並且方便從舊架構遷移到新架構，因為您可以忘記網路交換邏輯。
為什麼需要Service Mesh定制？
在我們公司，數百個系統和模組共存，運行時負載非常大。 因此，一個系統呼叫另一個系統並接收回應的簡單模式是不夠的，因為在生產中我們需要更多。 您還需要企業服務網格提供什麼？
事件處理服務
讓我們想像一下，我們需要進行即時事件處理——一個即時分析客戶行為並可以立即向他提供相關報價的系統。 若要實現類似的功能，請使用 稱為事件驅動架構 (EDA) 的架構模式。 目前的服務網格本身都不支援此類模式，但這非常重要，尤其是對於銀行而言！
比較奇怪的是，Service Mesh 所有版本都支援遠端過程呼叫（RPC），但對 EDA 並不友善。 因為Service Mesh是一種現代分散式集成，而EDA是一種非常相關的架構模式，可以讓你在客戶體驗方面做獨特的事情。
我們的企業服務網格應該可以解決這個問題。 此外，我們希望看到它使用各種過濾器和模板來實現保證的交付、串流媒體和複雜的事件處理。
文件傳輸服務
除了 EDA 之外，如果能夠傳輸文件就好了：在企業規模上，通常只能進行文件整合。 特別是使用了 ETL（提取、轉換、載入）架構模式。 通常，每個人都專門交換文件：使用大數據，推送單獨的請求是不切實際的。 企業服務網格中原生支援文件傳輸的能力為您提供了業務所需的靈活性。
編排服務
大型組織幾乎總是有不同的團隊生產不同的產品。 例如在銀行，有的團隊做存款，有的團隊做貸款產品，這樣的案例還不少。 這些是不同的人、不同的團隊，他們製造自己的產品、開發自己的 API 並將其提供給其他人。 通常需要組合這些服務，並實作順序呼叫一組 API 的複雜邏輯。 為了解決這個問題，您需要整合層中的一個解決方案來簡化所有這些複合邏輯（呼叫多個 API、描述請求路由等）。 這是企業服務網格中的編排服務。
人工智慧和機器學習
當微服務透過單一整合層進行通訊時，服務網格自然知道有關每個服務呼叫的所有資訊。 我們收集遙測數據：誰打電話給誰、何時、多久、多少次等等。 當有數十萬個這樣的服務和數十億次呼叫時，所有這些都會累積並形成大數據。 可以使用人工智慧、機器學習等來分析這些數據，然後可以根據分析結果做一些有用的事情。 將整合到服務網格中的所有網路流量和應用程式呼叫的控制權至少部分移交給人工智慧是合適的。
API網關服務
通常，服務網格具有在可信任範圍內相互通訊的代理和服務。 但也有外部交易對手。 這群消費者對暴露的 API 的要求要嚴格得多。 我們將這個任務分為兩個主要部分。
- 安全。 與 ddos、協定漏洞、應用程式、作業系統等相關的問題。
- 規模。 當需要提供給客戶的API數量達到數千甚至數十萬時，就需要某種針對這組API的管理工具。 您需要不斷監控 API：它們是否正在運作、它們的狀態是什麼、有哪些流量、有哪些統計資料等。 API 閘道應該處理此任務，同時使整個流程易於管理且安全。 借助此元件，企業服務網格學會輕鬆發佈內部和外部 API。
針對特定協定和資料格式的支援服務（AS網關）
目前，大多數服務網格解決方案只能在本機上使用 HTTP 和 HTTP2 流量，或在 TCP/IP 層級以簡化模式運作。 企業服務網格與許多其他非常具體的資料傳輸協定一起出現。 有些系統可能使用訊息代理，其他系統則在資料庫層級整合。 如果公司有SAP，那麼它也可以使用自己的整合系統。 而且，所有這些都是有效的，並且是業務的重要組成部分。
你不能只是說：“讓我們放棄遺留系統並創建可以使用 Service Mesh 的新系統。” 為了將所有舊系統與新系統連接起來（在微服務架構上），可以使用 Service Mesh 的系統將需要某種適配器、中介、網關。 同意，如果它和服務一起裝在盒子裡就好了。 AC 網關可以支援任何整合選項。 想像一下，您只需安裝 Enterprise Service Mesh，它就可以與您需要的所有協定進行互動。 這種方法對我們來說非常重要。
這大致上就是我們想像的企業版Service Mesh（Enterprise Service Mesh）。 所描述的客製化解決了嘗試使用整合平台的現成開源版本時出現的大部分問題。 服務網格架構僅在幾年前推出，目前仍在不斷發展，我們很高興能夠為其發展做出貢獻。 我們希望我們的經驗對您有用。
來源： www.habr.com