Java Chassis 3:介面維度負載均衡

华为云开发者联盟發表於2024-05-13

本文分享自華為雲社群《Java Chassis 3技術解密:介面維度負載均衡》,作者: liubao68。

Java Chassis 3技術解密:負載均衡選擇器中解密了Java Chassis 3負載均衡在解決效能方面提供的演算法。這次解密的技術來源於實際客戶案例:

在客戶的微服務系統中,存在很多種不同邏輯的介面,以及特殊的訪問模式,經常會出現部分例項執行緒池排隊嚴重,而其他例項負載不高的負載不均衡現象。比如:微服務A訪問微服務B,微服務B存在B1、B2兩個例項,OP1、OP2兩個介面,其中OP1處理比較耗時,佔用較多CPU時間,OP2處理較快。微服務A的業務邏輯會以OP1、OP2、OP1、OP2…這樣的訪問模式呼叫微服務B。客戶系統會經常出現OP1全部訪問B1、OP2全部訪問B2的現象。

產生這個問題的原因是Round Robin演算法根據請求順序來分配例項,而未差異化考慮不同請求的均衡要求。解決這個問題最簡單直接的思路是使用Random演算法,但是在進行負載均衡演算法選擇的時候,可預期性對於問題定位、問題分析、問題規避等都有非常大的便利,因此Round Robin演算法仍然是預設的最優選擇。

Java Chassis 3的解決方案是提供介面維度的負載均衡。

cke_132.png

預設場景,Java Chassis為每個契約(Schema)建立一個負載均衡,如果OP1和OP2分別屬於UserService和LoginService,那麼在上述示例的場景中,開發者不需要做任何配置,流量會自動實現均衡。

如果OP1和OP2都屬於LoginService,並且需要保證OP1的流量均衡,可以透過配置:

servicecomb.loadbalance.${微服務B}.${契約名稱}.${介面名稱}.strategy.name=RoundRobin

比如:

servicecomb.loadbalance.B.LoginService.login.strategy.name=RoundRobin

給耗時請求OP1(login)設定不同的負載均衡。

進一步討論

從上述負載均衡的原理可以看出,假設微服務X會訪問M個微服務,每個微服務平均有N個契約,那麼X會建立M * N的負載均衡。對於大多數系統,這個數量級都在1K以內。一般的,只需要對於耗時的介面分配獨立的負載均衡,以保證耗時請求的流量均衡。除了解決流量均衡問題,Java Chassis的配置方法,還可以針對其他特殊場景提供非常簡潔的配置方案,比如可以透過配置:

servicecomb.loadbalance.${微服務B}.${契約名稱}.${介面名稱}.strategy.name=SessionStickiness

為具體的介面指定會話粘滯策略。

總結

Java Chassis 3透過介面維度負載均衡的策略設定,為不同的應用場景提供了非常強大的負載均衡管理能力,幫助解決負載不均衡、會話粘滯等應用負載問題。

點選關注,第一時間瞭解華為雲新鮮技術~

相關文章