主持人 > 博客 > 管理 > 什麼是服務網格？

什麼是服務網格？

再次大家好！...在課程開始前夕 《軟體架構師》 我們準備了另一個有用的翻譯。

什麼是服務網格？

服務網格是可設定的低延遲基礎設施層，需要處理應用程式介面 (API) 之間大量基於網路的進程間通訊。 服務網格可以在容器化且通常是臨時的應用程式基礎架構服務之間實現快速、可靠和安全的通訊。 Service Mesh 提供服務發現、負載平衡、加密、透明、可追溯、身份驗證和授權以及自動關閉模式支援等功能（斷路器).
服務網格通常是透過為每個服務實例提供一個代理實例來實現的，稱為 邊車。 邊車 處理服務之間的通信，監視和解決安全問題，即可以從各個服務中抽象化的所有內容。 這樣，開發人員可以在服務中編寫、維護和提供應用程式程式碼，系統管理員可以使用 Service Mesh 並執行應用程式。

來自Google、IBM和Lyft的Istio是目前最著名的服務網格架構。 而最初由 Google 開發的 Kubernetes 現在是 Istio 支援的唯一容器編排框架。 供應商正在嘗試創建 Istio 的商業支援版本。 看看他們能為開源專案帶來哪些新東西將會很有趣。

然而，Istio 並不是唯一的選擇，因為其他服務網格實作正在開發中。 圖案 sidecar proxy 是最受歡迎的實現，可以透過 Buoyant、HashiCorp、Solo.io 等項目來判斷。 還有替代架構：Netflix 技術工具包是透過 Ribbon、Hysterix、Eureka、Archaius 函式庫以及 Azure Service Fabric 等平台實作 Service Mesh 功能的方法之一。

Service Mesh 對於服務元件和功能也有自己的術語：

  • 容器編排框架。 隨著越來越多的容器被添加到應用程式基礎架構中，需要一個單獨的工具來監控和管理容器——容器編排框架。 Kubernetes 牢牢佔據了這個利基市場，甚至其主要競爭對手 Docker Swarm 和 Mesosphere DC/OS 也提供與 Kubernetes 的整合作為替代方案。
  • 服務和實例（Kubernetes Pod）。 實例是微服務的單一運行副本。 有時一個實例就是一個容器。 在 Kubernetes 中，一個實例由一組稱為 pod 的獨立容器組成。 客戶端很少直接存取實例或 Pod；更常見的是，他們存取服務，這是一組相同、可擴展且容錯的實例或 Pod（副本）。
  • 邊車代理。 Sidecar Proxy 適用於單一執行個體或 Pod。 Sidecar 代理程式的目的是路由或代理來自它所使用的容器的流量並返回流量。 Sidecar 與其他 Sidecar 代理程式交互，並由編排框架管理。 許多 Service Mesh 實作使用 Sidecar Proxy 來攔截和管理進出實例或 Pod 的所有流量。
  • 服務發現。 當一個實例需要與另一個服務通訊時，它需要找到（發現）另一個服務的健康且可用的實例。 通常，執行個體執行 DNS 查找。 容器編排框架維護準備好接收請求的實例列表，並提供用於 DNS 查詢的介面。
  • 負載均衡。 大多數容器編排框架在第 4 層（傳輸）提供負載平衡。 Service Mesh在第七層（應用層）實現了更複雜的負載平衡，演算法豐富，流量管理更有效。 可以使用 API 更改負載平衡設置，從而允許您編排藍綠或金絲雀部署。
  • 加密。 服務網格可以加密和解密請求和回應，從而消除服務的這種負擔。 服務網格還可以透過優先考慮或重複使用現有持久連接來提高效能，從而減少創建新連接所需的昂貴計算。 流量加密最常見的實作是 相互 TLS (mTLS)，其中公鑰基礎設施 (PKI) 產生並分發憑證和金鑰以供 Sidecar 代理程式使用。
  • 認證與授權。 服務網格可以對來自應用程式外部或內部的請求進行授權和身份驗證，僅向實例發送經過驗證的請求。
  • 自動關機模式支持。 服務網格支援 自動關機模式，它會隔離不健康的實例，然後在需要時將它們逐漸返回到健康實例池中。

Service Mesh 應用程式中管理實例之間網路流量的部分稱為 數據平面。 建立和部署控制行為的配置 數據平面，使用單獨的執行 控制平面. 控制平面 通常包括或設計用於連接到 API、CLI 或 GUI 以控制應用程式。

什麼是服務網格？
服務網格中的控制平面在 Sidecar 代理和資料平面之間指派配置。

Service Mesh 架構通常用於使用容器和微服務來解決複雜的操作問題。 該領域的先驅 微服務 Lyft、Netflix 和 Twitter 等公司為全球數百萬用戶提供穩定的服務。 （以下詳細介紹了 Netflix 面臨的一些架構挑戰。）。 對於要求較低的應用程序，更簡單的架構可能就足夠了。

服務網格架構不太可能成為所有應用程式操作和交付問題的答案。 建築師和開發人員擁有龐大的工具庫，但其中只有一把錘子，而在眾多任務中，錘子必須解決的只有一個——錘釘子。 NGINX 的微服務參考架構例如，包括幾種不同的模型，它們提供了使用微服務解決問題的連續方法。

服務網格架構中匯集的元素（例如 NGINX、容器、Kubernetes 和微服務）作為一種架構方法，在非服務網格實作中也可以同樣有效率。 例如，Istio 被設計為完整的服務網格架構，但其模組化意味著開發人員可以只選擇和實現他們需要的技術元件。 考慮到這一點，即使您不確定是否能夠在應用程式中完全實現服務網格概念，清晰地理解它也很重要。

模組化單體和 DDD

來源： www.habr.com

添加評論