iT邦幫忙

0

Week27 - 從 gPRC 一路探討Go-Micro, Docker, Kubernates, Istio 的愛恨情仇 [Server的終局之戰系列]

本文章同時發佈於:


大家好,最近與夥伴們想導入 gRPC 這個技術來讓微服務的溝通介面更加穩定,但 gRPC 使用的協定是基於 HTTP/2 的,有些語言是只支援 HTTP/1.1 的,所以需要透過 Envoy 把 HTTP/1.1 轉換成 HTTP/2。

不過這篇文章不是要探討 gRPC XD,而是探討以 Envoy 來架構的 Istio 對現代微服務架構的影響。

如果試著去 Google 搜尋一下 Envoy,馬上就會搜尋到 Istio,而 Istio 的用途是為了解決 Kubernetes 上的各種Service Mesh問題,官網是這樣說的:

Its requirements can include discovery(服務發現), load balancing(負載平衡), failure recovery(故障恢復), metrics(指標), and monitoring(監控).

我與夥伴們最近也有在研究 Go-Micro 這樣的微服務框架,在ITNEXT: Go-Micro Tutorial的教學系列文章中,會發現 discovery, load balancing, failure recovery 等等以上專有名詞也提了不少次。

這時候我們的疑惑就來了:

  • 問題 1: Istio 跟 Go-Micro 是同樣類型的東西嗎?
  • 問題 2: Istio 如果跟 Go-Micro 是同樣類型,那他怎麼又常常與不同層次的 Kubernetes 一起討論呢?

這篇文章會以這樣的角度出發,如果你跟我一樣在微服務框架Istio所負責的職責中迷惘,希望可以解決你的困惑。

並且也歡迎各個大神教導指正本文的想法,謝謝~


先說結論再來細講:

廣義上,管理各個微服務,Go-Micro 是在軟體層,而 Istio 是在平台層

一開始的微服務

在 Docker 才剛帶領微服務快速發展的時候,很多微服務的管理與溝通,都是在 Code 這個軟體層完成,以 Go-Micro 來舉例:

  • Service 要怎麼知道彼此的位置: 可透過 etcd 的 discovery 來完成。教學文在此
  • Service 的流量太大要管控怎麼辦: 可透過 Go-Micro 的 Rate-Limiter 來限制。教學文在此

這些功能你現在去查 Kubernetes,會發現其實也有類似的功能,為什麼要在 Code 裡實作一套卻又在平台實作一套呢?原因其實很簡單:

在那個時候 Kubernetes 還處於與 OpenShift, Docker Swarm 四處奔殺的戰國時代,容器管理的平台的發展還不完全,這些功能他們還不在行。

所以各個社群單純就以以下方式建構微服務:

  • Docker 來打包 Service
  • 容器管理的平台單純就只是部署容器
  • Service 的溝通與管理全部透過 Code 來完成

逐漸進化的微服務

後來 Kubernetes 在容器管理大戰勝出後,就開始妥善的完善其功能,比如說 discovery, load balancing, failure recovery 等等,所以這時候尷尬的點就來了,

Code 實作的微服務溝通與管理的功能,Kubernetes 也可以辦到

所以大家就開始把 Code 的功能丟到 Kubernets 來處理,以 load balancing 來說,改用 Kubernets 可以:

  • 避免被特定語言的微服務框架綁住,例如用 Golang 的 Go-Micro, Java 的 Spring-Cloud 等等都要配合他們所屬的語言生態系
  • 可以很好的與 AWS, GCP, Azure 的 load balancing 結合
  • Service 只掌管業務邏輯,而這些溝通與管理的功能就交給平台,職責更加清晰

於是微服務的溝通與管理就從軟體層移到了平台層上。

平台層大爆炸的救世主 - Istio

當大家把很多 Code 處理的微服務相關事項移到平台層上後,發現

Damn! 好像 Kubernets 也不是能全部的微服務溝通都解決掉啊

舉個簡單的例子:

  • 以往在 Code 裡 Service A 呼叫 Service B 假設超時,只要透過 Go-Micro 的 Hystrix 來斷線即可,現在換成了 Kubernets 那該怎麼辦?

大家把這些麻煩的微服務溝通問題稱作Service Mesh,Kubernets 本質是個容器管理平台,這些溝通問題就得交給另一個角色,即是Istio

而要可以不入侵 Code,又要可以處理Service 的溝通問題要怎麼做呢?Istio 想到一個有趣的做法,

Sidecar - 在每個 Service 旁都增加一個 Envoy Proxy 來掌握所有溝通

如圖所示,每個藍色圖標的 Service 旁邊都會跟著一個粉紅色圖標的 Envoy Proxy,每個 Service 發出去與接收的流量,都要透過他轉送(就是妻管嚴的意思),如此一來就可以管理所有微服務的溝通。

有了 Envoy Proxy 來統一溝通介面,Istio 就可以依照這個界面透過 kiali, jaeger 等專業的 Service Mesh Tool 來輔助。

結論

回到原本的問題:

  • 問題 1 解答: Istio 跟 Go-Micro 所屬的層次不同,但都有負責解決微服務溝通的職責
  • 問題 2 解答: Istio 跟 Go-Micro 都有解決微服務溝通的職責,但 Istio 是非常完好的與 Kubernetes 結合的,因為他們都是平台層的東西

而我個人傾向於將這些微服務的溝通與管理交給平台層,而業務邏輯交給軟體層的 Service,更清晰的分層。

這樣的思維導致再见,micro: 迁移 go-micro 到纯 gRPC 框架這樣的文章產生,每個 Service 只要知道其他 Service 怎麼呼叫與回應,所以 Service 只需要有統一回應與呼叫介面的 gRPC,其他 Service Mesh 的問題就交給 Istio 吧!不要大家全攪和在 Code 裡。

不過在市場上很多產品都已經頭洗一半了,要換架構消耗的成本極大,像我與夥伴們做的一些 API-Gateway 就是透過 Code 管理而非平台,這幾天使用 Istio + Kubernetes 管理 API-Gateway 也讓我體會到這些 Service Mesh 的問題的確交給平台層解決也是很不錯的選擇。

而你是怎麼認為的呢?歡迎分享討論指正,謝謝你的閱讀~

參考與引用資料


尚未有邦友留言

立即登入留言