華為云云原生鉆石集訓營 第十五課:傳統微服務框架接入Istio方案詳解

      網友投稿 959 2025-04-01

      課程目標:


      學完本課程后,您將能夠:

      了解傳統微服務SDK和網格服務治理的原理

      了解傳統微服務SDK遇到的問題和網格的解決方案

      掌握傳統微服務SDK,包括Spring Cloud和Dubbo等開發的服務接入網格的詳細指導

      目錄

      1.微服務的概念和原理

      2.傳統微服務框架的問題和基于服務網格的解決方案

      3.傳統微服務框架在服務網格中集成的實踐詳細

      從前序課程,我們了解了Istio服務網格的基礎架構和用法。包括網格控制面架構、數據面架構和網格的流量和監控等內容。

      在本節我們將專注網格實際使用中一個典型場景,那就是傳統微服務框架開發的服務怎樣在服務網格上部署和使用網格能力。

      Istio 是一個由谷歌、IBM 與 Lyft 共同開發的開源項目,旨在提供一種統一化的微服務連接、安全保障、管理與監控方式。Istio 項目能夠為微服務架構提供流量管理機制,同時亦為其它增值功能(包括安全性、監控、路由、連接管理與策略等)創造了基礎。這款軟件利用久經考驗的 Lyft Envoy 代理進行構建,可在無需對應用程序代碼作出任何發動的前提下實現可視性與控制能力。Istio 項目是一款強大的工具,可幫助 CTO/CIO 們立足企業內部實施整體性安全、政策與合規性要求。

      優勢

      集群規模可視性:在故障狀況出現時,運營人員需要利用多種工具以始終關注集群運行狀況并分析微服務狀態圖表。Istio 項目能夠監控與應用程序及網絡活動相關的數據,利用 Prometheus 與 Grafana 對這部分數據加以渲染,而后將相關指標與日志記錄發送至任何收集、聚合與查詢系統當中以實現功能擴展。Istio 項目亦利用 Zipkin 追蹤分析性能熱點并對分布式故障模式加以診斷。

      彈性與效率:在開發微服務時,運營人員需要假設網絡本身處于不可靠狀態。運營人員能夠利用重試、負載均衡、流量控制(HTTP/2)以及斷路補償等方式解決由網絡可靠性低下所造成的各類常見故障模式。Istio 項目則提供一種統一方法以配置上述功能,使得運營人員能夠更為輕松地運作高彈性水平服務網格。

      開發人員生產力:Istio 項目能夠確保開發人員專注于利用已選擇的編程語言構建服務功能,從而極大提升其生產能力。另外,Istio 項目則負責以統一化方式處理彈性與網絡挑戰。開發人員無需將解決方案的分布式系統問題解決機制引入編寫的代碼當中。Istio 項目還能夠支持 A/B 測試、金絲雀部署以及故障注入等常用功能,旨在進一步提高生產效率。

      政策驅動型運營:Istio 項目能夠授權具有不同職能的團隊以實現獨立運作。其將集群運營人員與功能開發人員進行周期性剝離,從而在無需更改代碼的前提下提升安全性、監控能力、擴展性與服務拓撲水平。運營人員能夠精確控制生產流量中各個子集的路由方式,從而匹配新的服務版本。另外,運營人員還能夠在流量中注入故障或者提高延遲水平,用以測試服務見長的彈性 ; 同時設置速率限制以防止服務過載。Istio 項目還可用于強制執行合規性要求,例如在服務之間定義 CL 以確保僅具備授權的服務間可相互通信。

      默認安全:分布式計算當中經常存在著大量網絡安全問題。Istio 項目允許運營人員利用 TLS 連接以認證并保護各服務之間的所有通信,而不會給開發人員或者運營人員帶來由證書管理造成的額外負擔。其安全框架與新的 SPIFFE 規范保持一致,事實上谷歌公司一直在內部廣泛使用類似的保障性系統。

      增量化采用:在設計 Istio 項目時充分考慮到網絡內所運行各服務的透明性,允許團隊隨著時間推移逐步采用 Istio 提供的各項功能。采用方可以先從啟用集群范圍內可視性起步,并在 Istio 在環境中的表現感到滿意后根據實際需要啟用其它功能。

      熔斷器基本上是一種軟件設計模式,用于檢測故障并封裝防止故障進一步級聯的邏輯。這有助于創建有彈性的微服務應用程序,以限制故障和延遲尖峰的影響。

      2.傳統微服務框架的問題和基于服務網格的解決方案

      在微服務管理中常常需要使用到的一些列的組件:

      服務注冊:服務提供方將自己調用地址注冊到服務注冊中心,讓服務調用方能夠方便地找到自己。

      服務發現:服務調用方從服務注冊中心找到自己需要調用的服務的地址。

      負載均衡:服務提供方一般以多實例的形式提供服務,負載均衡功能能夠讓服務調用方連接到合適的服務節點。并且,節點選擇的工作對服務調用方來說是透明的。

      服務網關:服務網關是服務調用的唯一入口,可以在這個組件是實現用戶鑒權、動態路由、灰度發布、A/B 測試、負載限流等功能。

      配置中心:將本地化的配置信息(properties, xml, yaml 等)注冊到配置中心,實現程序包在開發、測試、生產環境的無差別性,方便程序包的遷移。

      API 管理:以方便的形式編寫及更新 API 文檔,并以方便的形式供調用者查看和測試。

      華為云云原生鉆石集訓營 第十五課:傳統微服務框架接入Istio方案詳解

      集成框架:微服務組件都以職責單一的程序包對外提供服務,集成框架以配置的形式將所有微服務組件(特別是管理端組件)集成到統一的界面框架下,讓用戶能夠在統一的界面中使用系統。

      分布式事務:對于重要的業務,需要通過分布式事務技術(TCC、高可用消息服務、最大努力通知)保證數據的一致性。

      調用鏈:記錄完成一個業務邏輯時調用到的微服務,并將這種串行或并行的調用關系展示出來。在系統出錯時,可以方便地找到出錯點。

      支撐平臺:系統微服務化后,系統變得更加碎片化,系統的部署、運維、監控等都比單體架構更加復雜,那么,就需要將大部分的工作自動化。現在,可以通過 Docker 等工具來中和這些微服務架構帶來的弊端。 例如持續集成、藍綠發布、健康檢查、性能健康等等。嚴重點,以我們兩年的實踐經驗,可以這么說,如果沒有合適的支撐平臺或工具,就不要使用微服務架構。

      微服務架構的優點:

      降低系統復雜度:每個服務都比較簡單,只關注于一個業務功能。

      松耦合:微服務架構方式是松耦合的,每個微服務可由不同團隊獨立開發,互不影響。

      跨語言:只要符合服務 API 契約,開發人員可以自由選擇開發技術。這就意味著開發人員可以采用新技術編寫或重構服務,由于服務相對較小,所以這并不會對整體應用造成太大影響。

      獨立部署:微服務架構可以使每個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。這些更改可以在測試通過后立即部署。所以微服務架構也使得 CI/CD 成為可能。

      Docker 容器:和 Docker 容器結合的更好。

      DDD 領域驅動設計:和 DDD 的概念契合,結合開發會更好。

      微服務架構的缺點:

      微服務強調了服務大小,但實際上這并沒有一個統一的標準:業務邏輯應該按照什么規則劃分為微服務,這本身就是一個經驗工程。有些開發者主張 10-100 行代碼就應該建立一個微服務。雖然建立小型服務是微服務架構崇尚的,但要記住,微服務是達到目的的手段,而不是目標。微服務的目標是充分分解應用程序,以促進敏捷開發和持續集成部署。

      微服務的分布式特點帶來的復雜性:開發人員需要基于 RPC 或者消息實現微服務之間的調用和通信,而這就使得服務之間的發現、服務調用鏈的跟蹤和質量問題變得的相當棘手。

      分區的數據庫體系和分布式事務:更新多個業務實體的業務交易相當普遍,不同服務可能擁有不同的數據庫。CAP 原理的約束,使得我們不得不放棄傳統的強一致性,而轉而追求最終一致性,這個對開發人員來說是一個挑戰。

      測試挑戰:傳統的單體WEB應用只需測試單一的 REST API 即可,而對微服務進行測試,需要啟動它依賴的所有其他服務。這種復雜性不可低估。

      跨多個服務的更改:比如在傳統單體應用中,若有 A、B、C 三個服務需要更改,A 依賴 B,B 依賴 C。我們只需更改相應的模塊,然后一次性部署即可。但是在微服務架構中,我們需要仔細規劃和協調每個服務的變更部署。我們需要先更新 C,然后更新 B,最后更新 A。

      部署復雜:微服務由不同的大量服務構成。每種服務可能擁有自己的配置、應用實例數量以及基礎服務地址。這里就需要不同的配置、部署、擴展和監控組件。此外,我們還需要服務發現機制,以便服務可以發現與其通信的其他服務的地址。因此,成功部署微服務應用需要開發人員有更好地部署策略和高度自動化的水平。

      總的來說(問題和挑戰):API Gateway、服務間調用、服務發現、服務容錯、服務部署、數據調用以及測試。

      Istio 提供了一個完整的解決方案,通過為整個服務網格提供行為洞察和操作控制來滿足微服務應用程序的多樣化需求,Service Mesh這個術語通常用于描述構成這些應用程序的微服務網絡以及應用之間的交互。

      隨著規模和復雜性的增長,服務網格越來越難以理解和管理。它的需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及通常更加復雜的運維需求,例如 A/B 測試、金絲雀發布、限流、訪問控制和端到端認證等。

      當服務providerB某個實例異常時,當客戶端consumera的流量均衡落到3個實例的這個故障實例時,會返回失敗。導致調用方consumera有很大的幾率收到異常的請求結果,影響最終用戶的接口調用。

      實踐: SpringCloud服務基于網格熔斷(2)

      構造providerB的一個實例異常。可以看到consumera至到providerb的訪問上,對這個實例的訪問逐漸變的不健康。

      總結

      本課程講解重點1∶傳統微服務SDK和服務服務網格服務治理的原理

      本課程講解重點2:傳統微服務SDK遇到的問題和網格的解決方案

      本課程講解重點3:傳統微服務SDK,包括Springcloud和Dubbo開發的服務接入網格的詳細指導

      參考鏈接

      流量治理: https://support.huaweicloud.com/usermanual-istio/istio_01_0011.html

      流量監控: https://support.huaweicloud.com/usermanual-istio/istio_01_0012.html

      lstio官方網站: https://istio.io/

      ASM應用服務網格官方首頁:https://support.huaweicloud.com/istio/

      Istio 云原生 微服務

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      上一篇:進銷存軟件哪個好(比較和選擇最適合的進銷存軟件
      下一篇:企業私有云建設指南一2.3.2 OpenStack
      相關文章
      亚洲一区二区三区亚瑟| 亚洲免费视频网址| 亚洲日产乱码一二三区别 | 亚洲欧美日韩综合俺去了| 亚洲一级特黄特黄的大片| 亚洲人成人77777网站不卡| 亚洲日产2021三区| 亚洲无成人网77777| 亚洲国产福利精品一区二区| 亚洲第一页中文字幕| 91亚洲精品自在在线观看| 亚洲国产精品成人精品小说| 亚洲精品国产肉丝袜久久| 亚洲伊人久久大香线蕉| 精品亚洲成A人无码成A在线观看| 亚洲AV无码精品蜜桃| 亚洲а∨天堂久久精品9966| 亚洲色大成网站www永久男同| 亚洲精品无播放器在线播放| 色窝窝亚洲av网| 亚洲国产婷婷香蕉久久久久久| 亚洲色偷拍区另类无码专区| 中文字幕亚洲一区二区三区| 亚洲免费人成在线视频观看| 亚洲Av无码专区国产乱码DVD| 亚洲国产精品一区| 亚洲欧洲日产国码在线观看| 亚洲精品午夜国产va久久| 亚洲精品久久无码av片俺去也| 国产成人人综合亚洲欧美丁香花| 亚洲成av人片一区二区三区| 国产亚洲色视频在线| 亚洲av无码片在线播放| 亚洲美女大bbbbbbbbb| 亚洲av成人综合网| 亚洲hairy多毛pics大全| 亚洲免费一区二区| 亚洲国产精品久久66| 亚洲人6666成人观看| 亚洲av纯肉无码精品动漫| 亚洲精品无码久久久久AV麻豆|