微服務中的Sidecar設計模式解析

Sidecar 設計模式已經越來越受歡迎，並在社群內得到更廣泛的採用。構建具有高度可擴充套件性、彈性、安全性和可觀察性的微服務架構具有挑戰性。Service Mesh 架構的發展已經改變了遊戲規則。它降低了與微服務架構相關的複雜性，並提供了許多功能，如負載平衡、服務發現、流量管理、熔斷、遙測、故障注入等。

閱讀我之前的部落格能夠了解 Service Mesh 的概念，為什麼雲原生應用需要它以及它受歡迎的原因——服務網格架構的興起。

什麼是 Sidecar 模式

將應用程式的功能劃分為單獨的程式可以被視為 Sidecar 模式。Sidecar 設計模式允許你為應用程式新增許多功能，而無需額外第三方元件的配置和程式碼。

就如 Sidecar 連線著摩托車一樣，類似地在軟體架構中， Sidecar 應用是連線到父應用並且為其擴充套件或者增強功能。Sidecar 應用與主應用程式鬆散耦合。

讓我用一個例子解釋一下。想象一下假如你有6個微服務相互通訊以確定一個包裹的成本。

每個微服務都需要具有可觀察性、監控、日誌記錄、配置、斷路器等功能。所有這些功能都是根據一些行業標準的第三方庫在每個微服務中實現的。

但再想一想，這不是多餘嗎？它不會增加應用程式的整體複雜性嗎？如果你的應用程式是用不同的語言編寫時會發生什麼——如何合併那些特定用於 .Net、Java、Python 等語言的第三方庫。

使用 Sidecar 模式的優勢

• 通過抽象出與功能相關的共同基礎設施到一個不同層降低了微服務程式碼的複雜度。
• 因為你不再需要編寫相同的第三方元件配置檔案和程式碼，所以能夠降低微服務架構中的程式碼重複度。
• 降低應用程式程式碼和底層平臺的耦合度。

Sidecar 模式是如何工作的

服務網格層可以存在於與應用程式一起執行的 Sidecar 容器中。 每個應用程式旁邊都附有相同 Sidecar 的副本。

來自單個服務的所有傳入和傳出網路流量都流經 Sidecar 代理。 因此，Sidecar 能夠管理微服務之間的流量，收集遙測資料並實施相關策略。從某種意義上說，該服務不瞭解整個網路，只知道附加的 Sidecar 代理。這實際上就是 Sidecar 模式如何工作的本質——將網路依賴性抽象為 Sidecar。

在服務網格中有資料平面和控制平面的概念：

• 資料平面的職責是處理網格內部服務之間的通訊，並負責服務發現、負載均衡、流量管理、健康檢查等功能。
• 控制平面的職責是管理和配置 Sidecar 代理以實施策略並收集遙測。

在 Kubernetes 和 Istio 世界中，你可以將 Sidecar 注入 Pod 內。Istio 使用帶有 Envoy 的 Sidecar 模型作為代理。

來自 Lyft 的 Envoy 是為雲原生應用程式設計的最流行的開源代理。Envoy 依附著每項服務執行，並以平臺無關的方式提供必要的功能。所有的服務流量都通過 Envoy 代理流動。

www.envoyproxy.io

從單體服務到微服務的轉變使組織能夠獨立且大規模地部署應用程式。 在 Container 和 Kubernetes 世界中，Sidecar 設計模式更適合。Sidecar 從應用程式中抽象出了複雜性，並處理服務發現、流量管理、負載均衡、斷路器等功能。

在此處瞭解有關 Sidecar 模式的更多資訊：

docs.microsoft.com/en-us/azure…

本文轉載自：www.servicemesher.com/blog/sideca…