本文分享自華為雲社群《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的解決方案是提供介面維度的負載均衡。
預設場景，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透過介面維度負載均衡的策略設定，為不同的應用場景提供了非常強大的負載均衡管理能力，幫助解決負載不均衡、會話粘滯等應用負載問題。
點選關注，第一時間瞭解華為雲新鮮技術~