Istio被引入的主要原因是傳統(tǒng)微服務(wù)存在以下問題。

多語言技術(shù)棧不統(tǒng)一：C++、Java、PHP、Go。Spring Cloud無法提出非Java語言的微服務(wù)治理。

服務(wù)治理周期長：微服務(wù)治理框架與業(yè)務(wù)耦合，上線周期長，策略調(diào)整周期長。

產(chǎn)品能力弱：Spring Cloud缺乏平臺化和產(chǎn)品化的能力，可視化能力弱。

那么，是不是說企業(yè)一定需要使用Istio?不是。表2-2是對Spring Cloud與Istio的簡單對比。

▼表2-2 Spring Cloud與Istio的對比與選擇

也就是說，如果企業(yè)的開源語言主要是Java、更新升級不頻繁、無過多高級治理功能需求、業(yè)務(wù)規(guī)模不是非常大，使用Spring Cloud是比較合適的。

如果企業(yè)要引入Istio，引入成本有多高?具體分三種情況，如表2-3所示。

▼表2-3 企業(yè)引入Istio的成本

接下來，我們對在OpenShift上通過Spring Cloud和Istio實(shí)現(xiàn)的企業(yè)微服務(wù)治理進(jìn)行對比，如表2-4所示。

▼表2-4 Spring Cloud與Istio的實(shí)現(xiàn)對比

從開放性以及先進(jìn)性角度來說，建議將服務(wù)網(wǎng)格Istio作為首選微服務(wù)應(yīng)用框架。接下來我們介紹Istio在實(shí)踐中的使用建議。

Istio運(yùn)維方面的建議包括版本選擇、備用環(huán)境、評估范圍、配置生效、功能健壯性參考、入口流量選擇。當(dāng)然，這些建議只是基于目前我們在測試過程中得到的數(shù)據(jù)總結(jié)的。隨著Istio使用越來越廣泛，相信最佳實(shí)踐將會越來越豐富。

1. 版本選擇

Istio是一個迭代很快的開源項目。截止到2021年5月，社區(qū)最新的Istio版本為1.9。

頻繁的版本迭代會給企業(yè)帶來一些困擾：是堅持使用目前已經(jīng)測試過的版本，還是使用社區(qū)的最新版本?

在前文中我們已經(jīng)提到，紅帽針對Istio有自己的企業(yè)版，通過Operator進(jìn)行部署和管理。出于安全性和穩(wěn)定性的考慮，紅帽Istio往往比社區(qū)要晚兩個小版本左右。因此建議使用紅帽Istio的最新版本。目前看，社區(qū)的最新版本的Istio的穩(wěn)定性往往不盡如人意。

2. 備用環(huán)境

針對相同的應(yīng)用，在OpenShift環(huán)境中部署一套不被Istio管理的環(huán)境。比如文中的三層微服務(wù)，獨(dú)立啟動一套不被Istio管理的應(yīng)用，使用OpenShift原本的訪問方式即可。

這樣做的好處是，每當(dāng)進(jìn)行Istio升級或者部分參數(shù)調(diào)整時都可以提前進(jìn)行主從切換，讓流量切換到?jīng)]有被Istio管理的環(huán)境中，將Istio升級調(diào)整驗證完畢后再將流量切換回來。

3. 評估范圍

由于Istio對微服務(wù)的管理是非代碼侵入式的。因此通常情況下，業(yè)務(wù)服務(wù)需要進(jìn)行微服務(wù)治理，需要被Istio納管。而對于沒有微服務(wù)治理要求的非業(yè)務(wù)容器，不必強(qiáng)行納管在Istio中。當(dāng)非業(yè)務(wù)容器需要承載業(yè)務(wù)時，被Istio納管也不需要修改源代碼，重新在OpenShift上注入Sidecar部署即可。

4. 配置生效

如果系統(tǒng)中已經(jīng)有相關(guān)對象的配置，我們需要使用oc replace -f指定配置文件來替換之前配置的對象。Istio中有的配置策略能夠較快生效，有的配置需要一段時間才能生效，如限流、熔斷等。新創(chuàng)建策略(oc create -f)的生效速度要高于替換性策略(oc replace -f)。因此在不影響業(yè)務(wù)的前提下，可以在應(yīng)用新策略之前，先刪除舊策略。

此外，Istio的配置生效，大多是針對微服務(wù)所在的項目，但也有一些配置是針對Istio系統(tǒng)。因此，在配置應(yīng)用時，要注意指定對應(yīng)的項目。

在OpenShift中，Virtual Service和Destination Rules都是針對項目生效，因此配置應(yīng)用時需要指定項目。

5. 功能健壯性參考

從筆者大量的測試效果看，健壯性較強(qiáng)的功能有基于目標(biāo)端的藍(lán)綠、灰度發(fā)布，基于源端的藍(lán)綠、灰度發(fā)布，灰度上線，服務(wù)推廣，延遲和重試，錯誤注入，mTLS，黑白名單。

健壯性有待提升的功能有限流和熔斷。

所以，從整體上看，Istio的功能雖日趨完善，但仍有待提升。

6. 入口流量方式選擇

在創(chuàng)建Ingress網(wǎng)關(guān)的時候，會自動在OpenShift的Router上創(chuàng)建相應(yīng)的路由。Ingress網(wǎng)關(guān)能夠暴露的端口要多于Router。所以，我們可以根據(jù)需要選擇通過哪條路徑來訪問應(yīng)用。

在Istio體系中的應(yīng)用不使用Router也可以正常訪問微服務(wù)。但是PaaS上運(yùn)行的應(yīng)用未必都是Istio體系下的，其他非微服務(wù)或者非Istio體系下的服務(wù)還是要通過Router訪問。此外，Istio本身的監(jiān)控系統(tǒng)和Kiali的界面都是通過Router訪問的。

相比Spring Cloud，Istio較好地實(shí)現(xiàn)了微服務(wù)的路由管理。但在實(shí)際生產(chǎn)中，僅有微服務(wù)的路由管理是不夠的，還需要諸如不同微服務(wù)之間的業(yè)務(wù)系統(tǒng)集成管理、微服務(wù)的API管理、微服務(wù)中的規(guī)則流程管理等。

本文摘編自《金融級IT架構(gòu)與運(yùn)維：云原生、分布式與安全》，經(jīng)出版方授權(quán)發(fā)布。(ISBN：978-7-111-69829-6)