建站
咨詢
售后
建站咨詢
新聞中心
多語言技術(shù)棧不統(tǒng)一：C++、Java、PHP、Go。Spring Cloud無法提出非Java語言的微服務治理。
為宿松等地區(qū)用戶提供了全套網(wǎng)頁設計制作服務，及宿松網(wǎng)站建設行業(yè)解決方案。主營業(yè)務為成都網(wǎng)站建設、做網(wǎng)站、宿松網(wǎng)站設計，以傳統(tǒng)方式定制建設網(wǎng)站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
服務治理周期長：微服務治理框架與業(yè)務耦合，上線周期長，策略調(diào)整周期長。
產(chǎn)品能力弱：Spring Cloud缺乏平臺化和產(chǎn)品化的能力，可視化能力弱。
那么，是不是說企業(yè)一定需要使用Istio?不是。表2-2是對Spring Cloud與Istio的簡單對比。
▼表2-2 Spring Cloud與Istio的對比與選擇
也就是說，如果企業(yè)的開源語言主要是Java、更新升級不頻繁、無過多高級治理功能需求、業(yè)務規(guī)模不是非常大，使用Spring Cloud是比較合適的。
如果企業(yè)要引入Istio，引入成本有多高?具體分三種情況，如表2-3所示。
▼表2-3 企業(yè)引入Istio的成本
接下來，我們對在OpenShift上通過Spring Cloud和Istio實現(xiàn)的企業(yè)微服務治理進行對比，如表2-4所示。
▼表2-4 Spring Cloud與Istio的實現(xiàn)對比
從開放性以及先進性角度來說，建議將服務網(wǎng)格Istio作為選擇微服務應用框架。接下來我們介紹Istio在實踐中的使用建議。
Istio運維方面的建議包括版本選擇、備用環(huán)境、評估范圍、配置生效、功能健壯性參考、入口流量選擇。當然，這些建議只是基于目前我們在測試過程中得到的數(shù)據(jù)總結(jié)的。隨著Istio使用越來越廣泛，相信最佳實踐將會越來越豐富。
1. 版本選擇
Istio是一個迭代很快的開源項目。截止到2021年5月，社區(qū)最新的Istio版本為1.9。
頻繁的版本迭代會給企業(yè)帶來一些困擾：是堅持使用目前已經(jīng)測試過的版本，還是使用社區(qū)的最新版本?
在前文中我們已經(jīng)提到，紅帽針對Istio有自己的企業(yè)版，通過Operator進行部署和管理。出于安全性和穩(wěn)定性的考慮，紅帽Istio往往比社區(qū)要晚兩個小版本左右。因此建議使用紅帽Istio的最新版本。目前看，社區(qū)的最新版本的Istio的穩(wěn)定性往往不盡如人意。
2. 備用環(huán)境
針對相同的應用，在OpenShift環(huán)境中部署一套不被Istio管理的環(huán)境。比如文中的三層微服務，獨立啟動一套不被Istio管理的應用，使用OpenShift原本的訪問方式即可。
這樣做的好處是，每當進行Istio升級或者部分參數(shù)調(diào)整時都可以提前進行主從切換，讓流量切換到?jīng)]有被Istio管理的環(huán)境中，將Istio升級調(diào)整驗證完畢后再將流量切換回來。
3. 評估范圍
由于Istio對微服務的管理是非代碼侵入式的。因此通常情況下，業(yè)務服務需要進行微服務治理，需要被Istio納管。而對于沒有微服務治理要求的非業(yè)務容器，不必強行納管在Istio中。當非業(yè)務容器需要承載業(yè)務時，被Istio納管也不需要修改源代碼，重新在OpenShift上注入Sidecar部署即可。
4. 配置生效
如果系統(tǒng)中已經(jīng)有相關(guān)對象的配置，我們需要使用oc replace -f指定配置文件來替換之前配置的對象。Istio中有的配置策略能夠較快生效，有的配置需要一段時間才能生效，如限流、熔斷等。新創(chuàng)建策略(oc create -f)的生效速度要高于替換性策略(oc replace -f)。因此在不影響業(yè)務的前提下，可以在應用新策略之前，先刪除舊策略。
此外，Istio的配置生效，大多是針對微服務所在的項目，但也有一些配置是針對Istio系統(tǒng)。因此，在配置應用時，要注意指定對應的項目。
在OpenShift中，Virtual Service和Destination Rules都是針對項目生效，因此配置應用時需要指定項目。
5. 功能健壯性參考
從筆者大量的測試效果看，健壯性較強的功能有基于目標端的藍綠、灰度發(fā)布，基于源端的藍綠、灰度發(fā)布，灰度上線，服務推廣，延遲和重試，錯誤注入，mTLS，黑白名單。
健壯性有待提升的功能有限流和熔斷。
所以，從整體上看，Istio的功能雖日趨完善，但仍有待提升。
6. 入口流量方式選擇
在創(chuàng)建Ingress網(wǎng)關(guān)的時候，會自動在OpenShift的Router上創(chuàng)建相應的路由。Ingress網(wǎng)關(guān)能夠暴露的端口要多于Router。所以，我們可以根據(jù)需要選擇通過哪條路徑來訪問應用。
在Istio體系中的應用不使用Router也可以正常訪問微服務。但是PaaS上運行的應用未必都是Istio體系下的，其他非微服務或者非Istio體系下的服務還是要通過Router訪問。此外，Istio本身的監(jiān)控系統(tǒng)和Kiali的界面都是通過Router訪問的。
相比Spring Cloud，Istio較好地實現(xiàn)了微服務的路由管理。但在實際生產(chǎn)中，僅有微服務的路由管理是不夠的，還需要諸如不同微服務之間的業(yè)務系統(tǒng)集成管理、微服務的API管理、微服務中的規(guī)則流程管理等。
本文摘編自《金融級IT架構(gòu)與運維：云原生、分布式與安全》，經(jīng)出版方授權(quán)發(fā)布。(ISBN：978-7-111-69829-6)
網(wǎng)頁名稱：微服務治理框架的選擇：對比SpringCloud和Istio
URL分享：http://m.5511xx.com/article/coghpdg.html
