本文章同時發佈於：
大家好，最近與夥伴們想導入 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 等等以上專有名詞也提了不少次。
這時候我們的疑惑就來了：
這篇文章會以這樣的角度出發，如果你跟我一樣在微服務框架與Istio所負責的職責中迷惘，希望可以解決你的困惑。
並且也歡迎各個大神教導指正本文的想法，謝謝～
先說結論再來細講：
廣義上，管理各個微服務，Go-Micro 是在軟體層，而 Istio 是在平台層
在 Docker 才剛帶領微服務快速發展的時候，很多微服務的管理與溝通，都是在 Code 這個軟體層完成，以 Go-Micro 來舉例:
這些功能你現在去查 Kubernetes，會發現其實也有類似的功能，為什麼要在 Code 裡實作一套卻又在平台實作一套呢？原因其實很簡單：
在那個時候 Kubernetes 還處於與 OpenShift, Docker Swarm 四處奔殺的戰國時代，容器管理的平台的發展還不完全，這些功能他們還不在行。
所以各個社群單純就以以下方式建構微服務:
後來 Kubernetes 在容器管理大戰勝出後，就開始妥善的完善其功能，比如說 discovery, load balancing, failure recovery 等等，所以這時候尷尬的點就來了，
Code 實作的微服務溝通與管理的功能，Kubernetes 也可以辦到
所以大家就開始把 Code 的功能丟到 Kubernets 來處理，以 load balancing 來說，改用 Kubernets 可以:
於是微服務的溝通與管理就從軟體層移到了平台層上。
當大家把很多 Code 處理的微服務相關事項移到平台層上後，發現
Damn! 好像 Kubernets 也不是能全部的微服務溝通都解決掉啊
舉個簡單的例子:
大家把這些麻煩的微服務溝通問題稱作Service Mesh，Kubernets 本質是個容器管理平台，這些溝通問題就得交給另一個角色，即是Istio。
而要可以不入侵 Code，又要可以處理Service 的溝通問題要怎麼做呢？Istio 想到一個有趣的做法，
Sidecar - 在每個 Service 旁都增加一個 Envoy Proxy 來掌握所有溝通
如圖所示，每個藍色圖標的 Service 旁邊都會跟著一個粉紅色圖標的 Envoy Proxy，每個 Service 發出去與接收的流量，都要透過他轉送(就是妻管嚴的意思)，如此一來就可以管理所有微服務的溝通。
有了 Envoy Proxy 來統一溝通介面，Istio 就可以依照這個界面透過 kiali, jaeger 等專業的 Service Mesh Tool 來輔助。
回到原本的問題:
而我個人傾向於將這些微服務的溝通與管理交給平台層，而業務邏輯交給軟體層的 Service，更清晰的分層。
這樣的思維導致再见，micro: 迁移 go-micro 到纯 gRPC 框架這樣的文章產生，每個 Service 只要知道其他 Service 怎麼呼叫與回應，所以 Service 只需要有統一回應與呼叫介面的 gRPC，其他 Service Mesh 的問題就交給 Istio 吧！不要大家全攪和在 Code 裡。
不過在市場上很多產品都已經頭洗一半了，要換架構消耗的成本極大，像我與夥伴們做的一些 API-Gateway 就是透過 Code 管理而非平台，這幾天使用 Istio + Kubernetes 管理 API-Gateway 也讓我體會到這些 Service Mesh 的問題的確交給平台層解決也是很不錯的選擇。
而你是怎麼認為的呢？歡迎分享討論指正，謝謝你的閱讀～
髒桶子 York Lin
iThome鐵人賽
看影片追技術