企業服務匯流排ESB已死! 服務網格上位

banq發表於2018-08-17
服務網格是企業服務匯流排ESB的一種雲原生版本，在面向服務的體系結構（SOA）中，微服務不斷在進化，已經涉及到傳統SOA中企業服務匯流排（ESB）所處理的任務，所以現在需要的是一種ESB的雲原生版本。

在精彩的軟體容器世界中，新專案的出現不斷解決你認為早已經解決的問題，可以感覺到腳下的地面不斷在移動，現代雲原生架構正在推動應用程式向比以前更大規模的方向去部署，這需要新的方法和工具產品。

微服務是這樣一個基於雲原生架構的新方法，它將傳統的應用或服務分解為可獨立部署的功能模組，這些模組可以彼此分開擴充套件和維護，並且連結在一起以提供整個應用程式或服務的全部功能。

現在需要的是一種基於雲原生的產品架構，像ESB那樣將所有微服務組合在一起，此前有Netflix和Spring Cloud提出的API Gateway概念，Zuul實現API代理和URL路由，Eureka實現服務發現，Ribbon負責負載平衡，這些算是第一代雲原生ESB，缺點是這些配置被放入程式碼階段，對於開發人員要求素質比較高。

開源專案Istio作為服務網格的概念推出是第二代雲原生ESB，它有一部分會與基礎設施一起分佈部署在容器旁邊，主要負責服務發現、負載平衡、訊息路由，遙測和監控等要求，當然包括安全。

Istio是由IBM和Google共同推出，Istio由以下元件組成：

1.Envoy：也稱邊車代理，因為它作為代理部署在每個微服務例項旁邊。
2.Mixer：它是一個核心元件，用於透過Envoy代理實施策略，並從中收集遙測指標。
3.Pilot：負責配置代理。
4.Citadel是負責頒發證書的集中元件，也有自己的每個節點代理。

Mixer、Pilot和Citadel都是中央集中的，類似API閘道器+Eureka，不過這些中央集中點不會成為單點風險點，因為不會所有微服務都會經過這些中央集中點，而是直接由邊車Envoy負責，這就避免了第一代方式的單點風險，因為在Spring cloud中，所有微服務都是透過單個API閘道器路由，包括透過Eureka或Zoopkeeper進行服務發現，微服務之間的通訊都會依賴於Eureka或Zoopkeeper伺服器，這些伺服器的設計就只能在CAP定理中進行妥協選擇，而Istio則不會出現這種情況，關鍵是邊車sidecar代理的實現Envoy。

[img index=1]

Envoy是由Lyft開發的元件，被描述為“非常小，是第4到第7層智慧路由器”，它捕獲來自與其配對的微服務的所有傳入和傳出通訊，控制流量路由、應用策略和收集遙測。 Pilot是IBM提供的主要元件，可作為部署在基礎架構中的所有Envoy代理的控制版。

如果你想象在一個服務網格中，你可能有幾百個微服務，如果每個都有多個例項，你可能有數百或數千個這些智慧路由器，你需要一種方法對它們進行全部程式設計，所以Istio引入了這個稱為Pilot的東西。可以把它想象成程式設計師，所有這些路由器的控制版。所以你有一個地方可以透過它來程式設計這個服務網路，然後圍繞資料收集進行遙測，實現圍繞安全的證書管理，從根本上講你依靠這個智慧路由層和這個控制版來管理整個服務網格。

Istio還有自己的API，允許使用者將其插入現有的後端系統，例如用於日誌記錄和遙測。

根據谷歌的說法，Istio的監控功能使使用者能夠測量服務之間的實際流量，例如每秒請求數，錯誤率和延遲，還可以生成依賴關係圖，以便使用者可以看到服務如何相互影響。

透過其Envoy邊車代理，Istio還可以在每個服務呼叫上使用相互的TLS身份驗證（mTLS），新增飛行加密並使使用者能夠授權跨基礎架構的每個呼叫。

Istio的目的是，消除了開發人員如何保護例項之間通訊的擔心，控制哪個例項可以與哪些例項進行通訊以及執行諸如金絲雀部署之類的運維能力，如果是釋出特定微服務的新版本程式碼，最初只更新例項的一部分，直到您對新程式碼可靠執行感到滿意才會全部更新。

服務網格只是網路管道上方的抽象層，因此假設前提是已經為每個容器例項配置了網路介面、IP地址和其他網路屬性。這通常意味著，無論何時建立新的容器例項，部署微服務還將需要一個單獨的工具來自動化網路配置，這是Docker和Kubernetes用武之地，因此，Docker+Kubernetes是使用Istio服務網格的前提。

Istio也獲得了業內其他公司的支援，尤其是Red Hat，幾年前它以Docker容器和Kubernetes為基礎重新設計了OpenShift應用程式平臺。

應該注意的是，其他服務網格平臺已經存在，例如開源的Linkerd或Conduit，而微軟有一項服務，它稱之為Azure Service Fabric Mesh，目前作為其雲平臺的技術預覽。

結束語
新技術的出發展不斷解決你認為早已經解決的問題，如果說Istio是對SOA的ESB替代，那麼Knative將可能是對SOA的BPM替代。

主要參考：

Istio Aims To Be The Mesh Plumbing For Containeriz

[該貼被banq於2018-08-17 22:12修改過]

相關文章