如何理解Istio在FreeWheel微服務中的實踐

如何理解Istio在FreeWheel微服務中的實踐，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

FreeWheel的微服務之痛

FreeWheel是一家數字視頻解決方案公司，我們核心業務系統可以理解為一個Web ERP。最初核心業務系統完全基于Rails，是一個典型的三層架構，但這個大型單體應用在發展了近十年以后，維護成本越來越大，而且難以擴展。2016年FreeWheel開始遷移到微服務架構，所有的業務功能都用Golang來重寫，同時引入了Kubernetes作為服務的部署平臺。

但在遷移到微服務之后，FreeWheel面臨很多通信方面的矛盾。一方面，平臺層的運維開始和應用層的改動互相牽制。有時升級核心網絡設備，整個系統都會被波及。另一方面，隨著應用層越來越快的迭代，模塊之間開始互相牽制，進而影響了客戶，同時也降低了應用迭代的效率。歸結起來是兩方面的問題：一個是通信的控制，另外一個是通信的可見性，可以理解成監控。

最初我們嘗試用一個中心化的服務網關Gateway來解決這種矛盾。但隨著遷移微服務的模塊越來越多，這種服務出現了兩個矛盾：一個是服務和服務之間的流量互相影響，第二個是在微服務中服務網關的配置有很多個性化的地方，大鍋飯帶來了復雜的配置管理，漸漸難以為繼。

在這樣的背景下，FreeWheel切換到了Service Mesh解決方案，選擇了Istio。

FreeWheel選擇Istio解決方案的主要原因，是因為FreeWheel的技術棧是Golang和Kubernetes，Istio是目前最合適的選擇。

02

Istio的架構和基本原理

首先來看一下Istio的架構和基本原理。Istio有四個核心模塊：

1. 反向代理模塊: Istio Proxy劫持Pod的所有流量，管理Service Mesh里面的通信。同時，管理Mesh內外邊界交互的流量也是反向代理。

2. Pilot模塊: 管理所有Service Mesh的動態配置。

3. Citadel模塊: 主要是自動維護服務之間通信的證書。

4. Mixer模塊: 在Kubernetes部署了兩組服務：一組服務提供授權和容量檢查的能力，另外一組Policy提供數據采集的能力，通過該服務將數據匯總。

如果從整個系統設計上看，也可以分成四個板塊：

1. 反向代理。

2. 網絡安全，目前主要兼容Spiffe標準實現。

3. 為C++實現的Proxy接入K8s的動態配置管理。

4. 對于Attribute的有限狀態機模型，授權、容量、管理監控等所有的基礎。

03

Istio管理下的微服務

Service Mesh部署pod之后，發生了什么？

1. 創建Pod之前，首先由Sidecar Injector來將自定義的initContainer, sidecar container、volume添加到Pod中，這里的volume是Istio自帶的通信安全相關的，Istio為Pod維護了動態的認證密鑰。

2. 接下來創建容器啟動Pod，其中initContainer先為當前Pod生成流量劫持的iptables規則。

3. 然后啟動Pod中的sidecar和實際應用容器。

4. 接下來sidecar和Pilot建立連接接受動態配置和更新；和Mixer(policy)建立連接來檢查授權、容量等；和Mixer(telemetry)建立連接來上報流量相關的監控元數據。

Pod啟動完成并且接入Service Mesh后，這里面還有兩個組件：

Galley：實現對動態配置的校驗。

Citadel：檢查Pod中mount的secret的有效性，并自動為Pod分發合法的證書。

04

FreeWheel如何充分利用Istio？

FreeWheel已經有一套復雜的自定義認證、授權機制，為了充分利用Istio，我們通過擴展Istio來整合這些系統，涉及兩方面：

擴展Sidecar：加入認證支持，提供了對業務系統的認證支持，將用戶相關信息以header的形式傳入Mesh，后續的授權、監控、限流都可以用Istio原生的機制來完成。

擴展Mixer：選擇一部分流量來應用對應的授權邏輯。

擴展Sidecar接入認證

FreeWheel原本就有一個簡單的服務網關實現，將認證邏輯抽取到這個模塊中，認證完成之后在反向代理中為下游的服務插入一些header，比如認證后得到的用戶信息等。

Istio沒有開發這種對請求完全定制的接口，所以要想修改請求和響應的內容，就必須要定義反向代理。我們沒有替換Envoy，改為在它下面接一個反向代理來實現，這個反向代理同時還接入了配置管理服務，可以利用原生的k8s配置管理接口來實現動態配置管理。不過需要注意的是，Sidecar里面的容器的流量默認是不被Iptables劫持的，如果需要納入流量劫持，需要顯式指定Aannotation來包含端口或者CIDR。

接入Sidecar其實就是修改Istio-system/istio-sidecar-injector的ConfigMap，并加入自定義的反向代理。

這個反向代理很簡單，寫死了token和用戶信息的映射關系，如果上游傳入了token，就將用戶信息塞到header中傳給下游，然后流量被轉發給應用服務，在反向代理和應用服務之間還有一個檢查授權、容量的過程，這是通過定制Mixer來實現的。

通過在Sidecar中增加FreeWheel自定義認證支持，下游可以充分利用Istio提供的授權、限流、監控接口。不過在Sidecar Injector用了一段時間以后，發現里面有兩個問題：

Sidecar沒有K8s自動注入的secret，也無法通過容器內環境變量自動建立Master連接，需要管理額外的Kubernetes。

Sidecar內的服務流量默認是不被劫持的，如果需要劫持需要添加額外的Annotation。

擴展Mixer接入授權

我們為實現高度定制的請求和響應內容時，用Sidecar實現擴展，但服務在授權、自定義限流的時候，很多類似的功能并不需要修改請求響應，只是在請求到達下游服務之前算一下，結果拒絕，或者通過。這時候就可以通過Mixer來擴展。

Mixer是一個高度可定制的狀態機模型，Envoy提供兩個接口：Report 和Check。這兩個接口會在連接和請求的不同生命后期被多次調用，我們經常用到的Quota，Metrics，Tracing 之類的功能都是通過它來實現的。

下圖為Mixer的基本原理，Template是對Proxy上報的Attribute的特定處理機制的框架，支持四類：

Preprocess: 匯總流量相關元數據和環境（k8s）相關的元數據。

Report: 上報數據。

Check: 決策是否允許當前訪問。

Quota: 決策容量是否足夠。

Mixer的基本原理

FreeWheel是如何擴展Mixer的呢？

首先，增加了一個adapter來實現授權的模板。其實，FreeWheel已有一個默認的RBAC模板。但新增一個授權能力的時候，我們希望做到絕對可控。比如，通過一個動態配置，在只有某一部分user或訪問某一類URL的時候打開這個授權，其他的時候則把它關掉。

Mixer提供了一種非常靈活的模型，讓Handler可以在流量中動態地選擇一部分來引入額外的機制（如權限控制、限流等），在應用運維中這是很重要的能力，只要是不修改請求、響應的功能都可以采用擴展Mixer來實現。

這里，mymock會完全拒絕所有被匹配到的流量：

mymock Handler的基本原理

在擴展Mixer的過程中有三個關鍵要素：

1. Handler的配置。這是一個默認行為，讓checknothing匹配到user1的時候返回到400，然后全部拒絕。

2. 系統進程instance。這是每個模塊固定的東西，定義了這種輸入以后，里面可以有一個黑盒，是面向對象的概念。

3. RUL。當用戶身份是user1的時候，instance會被handler來處理。如果要擴展，第一步需要定義handler的數據結構；第二步，實現time的接口，這里有兩個接口；第三把定義的handler的文件里面相關go的接口通過代碼生成。最后，注冊到mixer里面，重新編譯打包mixer以后就可以直接用了。

需要注意的是，mixer接入的是授權的policy模塊，可能會影響服務網格（Service Mesh）不工作。因此，重新部署這些模塊的時候，如果不能忍受短時間的宕機，則可能需要做一些灰度發布的機制。

對于Istio配置管理，我們也發現一些性能瓶頸和局限性。

Kubernetes和對etcd配置管理存在性能瓶頸。單個Resource控制在K級別，能夠比較正常的工作，一旦到達萬級別可能會出現不工作，比如好幾萬的單個Resource。

Istio配置本身的局限性。首先是防抖動處理，集群里面部署變化再快，都不會阻塞Istio。其次Istio其他的配置沒有防抖動處理，一旦用程序插入的時候一定要做限流。最后Istio用了CRD無法做到的兼容性設計，所以升級CRD也沒有辦法做到平滑的升級。

FreeWheel未來將怎么做？

首先是Service Contract，封裝Istio以及平臺層其他配置的復雜度，抽象出一個安全，高效的應用運維體系，為未來技術上的改進留出空間。

然后是Chaos Testing，解決復雜的微服務系統的持續運營和風險控制問題。這個也是目前比較火的一個主題。

現場問答

1. 對于Service Mesh外部流量進入，在Kubernetes有Ingress，在微服務Service Mesh的應用里面也有一個Gateway的情況下，它里面是把Gateway轉到Service Mesh，這三個怎么聯動讓外部的流量能夠順暢地進去？

答：很簡單。Service Mesh可以理解成是一個封閉的盒子，你所有的外部的Ingress以前該怎么運作還怎么運作，我們現在就討論在Service Mesh里面是怎么運作的。如果把它看作一個黑盒，現在你有一個Ingress，可以把它轉到Istio里面的Ingress Gateway，過去流量會直接轉發到各個Pod，是直接打到Pod，由Pod上Sidecar，再轉給應用。

2. 您剛才說的Sidecar里的應該是直接把Pod里面的流量屏蔽掉，只能通過Service Mesh里面的Gateway流量才能夠進到Pod里面？

答：不會。你說的這個流量轉發其實并沒有任何的限制，Service Mesh里面每一個反向代理都可以承擔Ingress Gateway的功能，僅僅是路由配置的問題。如果把這個弄好了，在任何一個Service Mesh上都可以配置這個功能。這個反向代理是一模一樣的。

3. 我用Istio的Gateway，Kubernetes里面的Ingress關掉，能夠跟外部之間聯系。

答：這個才是Istio比較推薦的模式，你管理這個集群外部進來流量的時候直接走Ingress Gateway，可以做到很好的限制。

4. 你們在落地的過程中有沒有遇到一些坑？

答：有。我們一開始試圖把業務的權限數據直接轉成原生的數據結構，因為我們想用它來做權限控制。但是后來發現它掌控不了那么大的數據量。第二個坑是Istio對它的一些Resource是沒有防抖動處理的，可能會導致這個Service Mesh行為很不穩定，在客戶端一定要做限流。

另外從長遠看，Istio的這些模塊目前都還是單點，可能導致Service Mesh不可用。我們以前也有遇到過跑了三個月莫名其妙出問題了，維護這種監控系統要頻繁地做演習。我們公司現在一個月做一次演習，會定時在一個主生產環境里把問題拿出來，然后檢查各個環節有沒有正常工作，這也是我們未來會發展的一個事情。

關于如何理解Istio在FreeWheel微服務中的實踐問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。