ServiceMesh-Istio：2. Istio架構和原理

文章目錄

• ServiceMesh-Istio：2. Istio架構和原理
• • 認識Istio
  • Istio 架構
  • • 數據平面
    • 控制平面
    • 組件解釋
    • Proxy
    • Pilot
    • Mixer
    • Gally
    • Citadel
  • Istio解決的問題
  • • 故障排查
    • 應用容錯性
    • 應用升級發布
    • 系統安全

認識Istio

Istio 中文文檔： https://istio.io./zh/

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Tm6MVsbE-1581645538909)(/Users/zck/Library/Application Support/typora-user-images/image-20200206141255635.png)]

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-YcLB4gr9-1581645538909)(/Users/zck/Library/Application Support/typora-user-images/image-20200206141312545.png)]

Istio 架構

Istio的核心就是一個代理，不過跟我們熟悉的Nginx代理不一樣，這個代理是針對每個服務，在kubernetes里面針對的是每個pod,一個pod 一個網絡代理，利用了pod中容器共享網絡的機制，通過某種手段完全接管pod的網絡，讓服務的進出流量都經過代理。這樣就可以做很多事情。

有了代理，還需要一個對這些代理統一管理的組件，畢竟手動更新每個代理的配置是不現實的。kub ernetes集群的情況如下：每個pod 的網絡都被上面的控制中心管理起來。

再看Istio更細致的架構看圖說話，上面是數據平面，下面是控制平面，

數據平面

數據平面就是由一系列的代理組成。這些代理控制微服務之間所有的網絡通信以及各種策略。ServiceA和ServiceB通信的時候，這個兩個pod的里面都有一個Proxy組件，他們之間的通信會通過Poxy進行轉發通信。并且Porxy通信支持很多協議：http/1.1、http/2,grpc tcp,覆蓋了主流的網絡通信協議。

控制平面

控制層面由很多模塊組成：管理流量、管理路由策略、搜集檢測數據的、校驗配置、負責通信安全功能非常多。

組件解釋

Proxy

Istio的Proxy選擇使用Envoy (c++開發的開源代理組件)作為網絡代理。來管理出口流量和入口流量。Envoy有非常多的功能動態服務發現 、負載均衡、多種協議的支持、斷路器、流量分割、健康檢查、故障模擬、健康指標等，Envoy以sidecar( 邊車模式)的形式部署在每個pod中，負責完成Istio的核心功能-代理轉發。

如果把Istio比作一個公司，Envoy就是這個公司的一線員工，所有的具體工作都是他們干的

Pilot

不可獲取模塊Pilot,好比Envoy的直接領導，Pilot會給你Envoy提供一些幫助，告訴Envoy怎么干活。

上面說到Envoy有很多功能服務發現 、負載均衡…但是它自己是跑在一個容器里面的什么信息也不知道，就沒辦法工作。Pilot就是給他提供信息的。告訴它集群都有什么服務，他就可以做服務發現了。告訴它哪些pod需要多少流量，它就可以做AB測試藍綠部署，告訴它多長時間算是超時，應該重試幾次。這些功能它就能很好的完成。

用戶可以通過客戶端通過Pilot配置流量管理，Pilot根據用戶的配置和服務信息轉換成 Envoy可以識別的格式，然后分發給它們，最后由Envoy實現用戶期望的行為。

Pilot和Envoy有了，Istio就可以轉起來了，其他的不需要也行。他倆是核心。

Mixer

Mixer獨立組件，兩大功能：策略和遙測。

策略：為整個集群提供訪問控制，哪些用戶訪問哪些服務，還有策略的管理。比如像對服務的訪問限制，一個服務最多接收100QPS，超過就拒絕。策略都是通過kubernetes的配置描述的，策略不是必須的沒有策略就沒有策略約束。

遙測：負責數據的搜集和匯報。可以看圖中的箭頭是從Proxy搜集服務之間流轉的數據。匯報給的對象非常多，每個對象有一個Adapter(適配器)：把數據轉成后端認識的格式；常見的Adapter有Prometheus、circonus、cloudwatch、statsd、stdio。匯報的數據為：請求哪里發出，發給誰，使用什么協議，請求的延時響應狀態碼等。

Mixer不是必須的，不需要它也能跑起來Istio。

Gally

最開始負責驗證配置，Istio1.1之后升級為控制平面的配置管理中心。主要目的其他所有的Istio組件與具體的底層平臺比如kubernetes 配置細節隔離開來，相當于一個后勤的工作。

Citadel

負責安全的相關的工作，可以為服務之間通過安全的通信，可以讓http服務無感知升級成https,還有訪問授權r bac 的訪問控制。Citadel也不是必須的，網絡是安全的業務上也不需要網絡的控制就完全可以忽略這個功能。

Istio解決的問題

架構和產品的都是要解決具體的問題。Istio主要解決微服務問題而生的。

故障排查

原來的單個服務才分出多個微服務，它們之間相互調用才能完成一個任務，而一旦某個過程出錯，出錯越多出錯概率越大，就會難以排查。

用戶請求：兩種錯誤，一個是請求錯誤，和慢響應。如果請求錯誤我們得知道哪個步驟出錯了，這么多的微服務怎么確定哪個成功哪個沒有調用成功。

響應慢，哪個地方響應慢，整個鏈路的耗時是多少，哪些是并發執行的，哪些是穿行執行的，我們必須清楚整個集群的調用和流量情況。

應用容錯性

沒有設置timeout；微服務才分成多個組件之后如果單個組件出現概率不變，那么整體出錯的概率就會增加。服務調用如果沒有錯誤處理機制，就會導致非常多的問題，比如應用沒配置超時參數，就導致請求的調用鏈超時疊加。對于用戶來說就是請求卡住了。

沒有重試機制，因為某種原因導致一些偶爾出現的故障，會知道導致把錯誤返回給用戶頁面，造成非常不好用戶體驗。

某些節點異常，比如網絡中斷，負載很高，也會導致整體的響應時間變長，這就需要我們的服務自動避開這些節點上的應用。

應用升級發布

當我們應用增多，對于日常發布就是一個難題，應用的發布需要我們非常謹慎，如果應用一次性升級的，一旦出錯影響范圍非常大。

無法進行AB測試，根據用戶屬性訪問不通版本。

服務版本的依賴關系處理不當導致服務不可用。服務升級改動了API，并且服務之間有相互依賴。那么還想希望自動控制發布期間不同的版本訪問不同應用，這些問題都需智能的流量控制機制。

系統安全

為了保證系統安全，每個應用都要實現一套相似的認證授權,https,限流等等這樣的功能。

沒有流量控制，任何人都可以對服務發起攻擊。

?

如果把上面的問題和Istio 的功能做一個映射，它們會非常匹配。

總結

以上是生活随笔為你收集整理的ServiceMesh-Istio：2. Istio架构和原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。