本文章同時發佈於：
文章為自己的經驗與夥伴整理的內容，設計沒有標準答案，如有可以改進的地方，請告訴我，我會盡我所能的修改，謝謝大家～
大家好，在 K8s 告一段落後，接下來要來介紹 Istio，
圖片來源: gRPC in Microservices
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(service-oriented architecture)是比 microserivce 還早出現的一個名詞，中文為服務導向架構，在精神上，microservice 相同都是將服務切分為更小的服務組合，但如圖，
圖片來源: What is the difference between SOA and Microservices
SOA 更注重在一個框架中完成所以服務的組合，彼此間的呼叫還是被此框架掌控，
而現在的 microservice 專注於將服務完全切分，服務與服務的呼叫是沒有依靠任何框架或插件。
統整上述有幾個問題需要實現:
而 Istio 想到的方法就是 Sidecar，概念很簡單:
在每個 microserivce 旁新增一個 Envoy Proxy 來劫持所有流量，並統一控制所有 proxy 來管理通訊
如圖，圖中所有 Envoy Proxy 的部分都是附屬在 microservice 上的，如果我們想要加入 Istio，對我們整體的 K8s 容器是沒有太大影響的，因為他並不是實作在容器中，而是向妻管嚴這樣從旁拿取所有流量。
Istio 管理這些容器通訊可以稱為Service Mesh，有以下幾點有用的功能:
並且 Istio 可以讓一切的容器管理更加平台層化，這樣後端 RD 可以更專注業務邏輯開發，而架構師可以更專注平台維護。
iThome鐵人賽
看影片追技術