您好,登錄后才能下訂單哦!
本篇文章為大家展示了如何解析Istio流量治理原理中的負載均衡功能,內容簡明扼要并且容易理解,絕對能使你眼前一亮,通過這篇文章的詳細介紹希望你能有所收獲。
動態修改服務間訪問的負載均衡策略,比如根據某個請求特征做會話保持;
同一個服務有兩個版本在線,將一部分流量切到某個版本上;
對服務進行保護,例如限制并發連接數、限制請求數、隔離故障服務實例等;
動態修改服務中的內容,或者模擬一個服務運行故障等。
在Istio中實現這些服務治理功能時無須修改任何應用的代碼。較之微服務的SDK方式,Istio以一種更輕便、透明的方式向用戶提供了這些功能。用戶可以用自己喜歡的任意語言和框架進行開發,專注于自己的業務,完全不用嵌入任何治理邏輯。只要應用運行在Istio的基礎設施上,就可以使用這些治理能力。
一句話總結Istio流量治理的目標:以基礎設施的方式提供給用戶非侵入的流量治理能力,用戶只需關注自己的業務邏輯開發,無須關注服務訪問管理。
Istio流量治理的概要流程如圖1所示:
圖1 Istio流量治理的概要流程
在控制面會經過如下流程:
(1)管理員通過命令行或者API創建流量規則;
(2)Pilot將流量規則轉換為Envoy的標準格式;
(3)Pilot將規則下發給Envoy。
在數據面會經過如下流程:
(1)Envoy攔截Pod上本地容器的Inbound流量和Outbound流量;
(2)在流量經過Envoy時執行對應的流量規則,對流量進行治理。
下面具體看看Istio提供了流量治理中的負載均衡功能。
負載均衡從嚴格意義上講不應該算治理能力,因為它只做了服務間互訪的基礎工作,在服務調用方使用一個服務名發起訪問的時候能找到一個合適的后端,把流量導過去。
如圖2所示,傳統的負載均衡一般是在服務端提供的,例如用瀏覽器或者手機訪問一個Web網站時,一般在網站入口處有一個負載均衡器來做請求的匯聚和轉發。服務的虛擬IP和后端實例一般是通過靜態配置文件維護的,負載均衡器通過健康檢查保證客戶端的請求被路由到健康的后端實例上。
圖2 服務端的負載均衡器
在微服務場景下,負載均衡一般和服務發現配合使用,每個服務都有多個對等的服務實例,需要有一種機制將請求的服務名解析到服務實例地址上。服務發現負責從服務名中解析一組服務實例的列表,負載均衡負責從中選擇一個實例。
如圖3所示為服務發現和負載均衡的工作流程。不管是SDK的微服務架構,還是Istio這樣的Service Mesh架構,服務發現和負載均衡的工作流程都是類似的,如下所述:
(1)服務注冊。各服務將服務名和服務實例的對應信息注冊到服務注冊中心。
(2)服務發現。在客戶端發起服務訪問時,以同步或者異步的方式從服務注冊中心獲取服務對應的實例列表。
(3)負載均衡。根據配置的負載均衡算法從實例列表中選擇一個服務實例。
圖3 服務發現和負載均衡的工作流程
Istio的負載均衡正是其中的一個具體應用。在Istio中,Pilot負責維護服務發現數據。如圖4所示為Istio負載均衡的流程,Pilot將服務發現數據通過Envoy的標準接口下發給數據面Envoy,Envoy則根據配置的負載均衡策略選擇一個實例轉發請求。Istio當前支持的主要負載均衡算法包括:輪詢、隨機和最小連接數算法。
圖4 Istio負載均衡的流程
在Kubernetes上支持Service的重要組件Kube-proxy,實際上也是運行在工作節點的一個網絡代理和負載均衡器,它實現了Service模型,默認通過輪詢等方式把Service訪問轉發到后端實例Pod上,如圖5所示。
圖5 Kubernetes的負載均衡
上述內容就是如何解析Istio流量治理原理中的負載均衡功能,你們學到知識或技能了嗎?如果還想學到更多技能或者豐富自己的知識儲備,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。