Istio 是什麼,原來是容器間通訊的妻管嚴嗎!? - 概念篇

本文章同時發佈於:

文章為自己的經驗與夥伴整理的內容,設計沒有標準答案,如有可以改進的地方,請告訴我,我會盡我所能的修改,謝謝大家~

大家好,在 K8s 告一段落後,接下來要來介紹 Istio,

圖片來源: gRPC in Microservices

K8s 與 Istio 都是平台層的架構,而他們的職責分別是:

  • K8s: 管理容器生命週期
  • Istio: 管理容器間的通訊

你可能會想K8s不是也能透過 load balance 來管理流量之類的通訊嗎?

是的,K8s 與 Istio 有著許多相似的功能,但是要注意的是 K8s 從頭到尾都是為了管理容器生命週期而生,管理容器間的通訊並不是他的強項。

容器間的通訊

在以往,容器間的通訊,往往是透過直接在容器裡的 code 來實作,

比如說 A service 呼叫 B service 失敗了,那就需要 retry,而 retry 就在 service 的 code 中實作,

你可以選擇在 code 中實作,但勢必就會造成 code 中除了有許多應用層的邏輯以外,又多了許多平台層的邏輯,這使得 microservice 變得很不 microservice,因為添加了許多

非此 microservice 邏輯的 code

或者你使用SOA(service-oriented architecture)框架例如 Spring Cloud、Go-Micro,這樣的框架幫你處理完了容器間通訊的問題,但這類框架通常與 K8s 整合上會遇到些問題,你可以參考當 Spring Cloud 遇上 Kubernetes-完整的微服務框架從此不完整了,最根本的原因就是

框架功能與 K8s 平台層的功能重疊

Spring Cloud 來說,基本上就可以當作一個完整的微服務平台了,其實不需要 K8s,但你的 backend 就無法與主流 K8s 靠攏,如果硬靠又會很多的見招拆招。

SOA 與 microservice 的差異

SOA(service-oriented architecture)是比 microserivce 還早出現的一個名詞,中文為服務導向架構,在精神上,microservice 相同都是將服務切分為更小的服務組合,但如圖,

圖片來源: What is the difference between SOA and Microservices

SOA 更注重在一個框架中完成所以服務的組合,彼此間的呼叫還是被此框架掌控,

而現在的 microservice 專注於將服務完全切分,服務與服務的呼叫是沒有依靠任何框架或插件。

服務溝通既沒有直接依賴框架或插件,又可以管理的聰明辦法 - Istio Sidecar

統整上述有幾個問題需要實現:

  1. 在不修改容器的前提下實現容器通訊的管理
  2. 容器通訊不直接依賴特定框架或插件
  3. 以 K8s 為基底設計

而 Istio 想到的方法就是 Sidecar,概念很簡單:

在每個 microserivce 旁新增一個 Envoy Proxy 來劫持所有流量,並統一控制所有 proxy 來管理通訊

如圖,圖中所有 Envoy Proxy 的部分都是附屬在 microservice 上的,如果我們想要加入 Istio,對我們整體的 K8s 容器是沒有太大影響的,因為他並不是實作在容器中,而是向妻管嚴這樣從旁拿取所有流量。

結論

Istio 管理這些容器通訊可以稱為Service Mesh,有以下幾點有用的功能:

  • 請求轉發:如服務發現,負載平衡
  • 流量控制:更加彈性的分流
  • 服務發布:使用金絲雀,A/B 等等方式來部署
  • 錯誤管理:現流,熔斷,重試,
  • 安全性:驗證,授權,加密

並且 Istio 可以讓一切的容器管理更加平台層化,這樣後端 RD 可以更專注業務邏輯開發,而架構師可以更專注平台維護。

參考

comments powered by Disqus