到底為什麼我們要使用 istio 呢？ 有什麼需求是原生 k8s 辦不到的事情？ 這就可以稍微跟大家分享一下團隊導入的故事。

我們導入 k8s 在一個新專案，大約開發了近一年，也都 QA 過了，在即將上線的時侯，我們才發現了一個重大的問題，就是 k8s 的 service 並沒有辦法替 grpc 做 load balance，偏偏我們專案內除了對外 client 是用一般 http api，其餘內部 server 對 server 的溝通都是透過 grpc 。那這樣就完全無法用到 k8s 自動 scale pod 的功能，也就是所有服務的 pod 都只能起一台。

我們這時就瘋狂去找各種解決方案，當然也有諮詢公司內比較早接觸 k8s 的前輩做諮詢，前輩就回了『你們可以自己做 grpc 的connection pool ，自己做 load balance。』這當然是一個非常差的建議，都已經要上線不可能再去更動程式底層架構，更動完再進行送測，這中間的成本可不小，所以我們當然不會選擇這個方案。

這時侯就找到了 istio 可以解決 grpc load balance的問題，而且因為它的 side car pattern，可以無痛注入到我們現行的服務中，不用作任何程式碼異動，最後我們先用原生的 k8s 先上線，另一方面我們開始嘗試在 DEV 站導入 istio，最終我們花了三個月的時間，也就是產品上線後三個月，我們就把線上的 k8s 裝上 istio，並且正式在營運中使用。

這是我們最初的使用目的，雖然只是用到 istio 很小的一個功能，但是專案上線到現在一年多，我們也因為客戶 request 次數太頻繁，而導入的 istio 的 request limit，限制他們每分鐘 request 次數。這個東西，在之前通常都是直接 hardcore 寫在服務本體，但是現在有了 istio 我們竟然可以透過設定，看是要 by ip or by 某個特定的 header key 去做限制都可以。

甚至配合廠商 api 不穩定，我們自己需要模擬廠商不穩定時，我們的流程會有什麼影響，而導入的 istio 裡面的熔斷，在沒這個之前，可能要自己寫一個 mock server...，但是有了這個後，可以透過簡單的設定，我可以指定模擬廠商 api 不通或是廠商的 reponse 延遲超過 30s ，去觀測我們的系統會發生什麼事情，

還有我們有一個服務從 php 重構為 golang 版本，當然 api 格式也都改完 grpc ，我們透過 istio 包好的 kiali 就可以觀察到，到底有哪些相依服務，還沒有把接口接上新服務。

這些東西這是我們在導入 istio 後，慢慢去挖掘出它強大之處。後續幾天我也會把我們有用到的功能一樣樣專題分享給大家知道。