本文分享自華爲雲社區《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通過接口維度負載均衡的策略設置，爲不同的應用場景提供了非常強大的負載均衡管理能力，幫助解決負載不均衡、會話粘滯等應用負載問題。