Java Chassis 3：接口维度负载均衡

本文分享自华为云社区《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的流量均衡，可以通过配置：

1. servicecomb.loadbalance.${微服务B}.${契约名称}.${接口名称}.strategy.name=RoundRobin

复制代码

比如：

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

复制代码

给耗时请求OP1（login）设置不同的负载均衡。
进一步讨论

从上述负载均衡的原理可以看出，假设微服务X会访问M个微服务，每个微服务均匀有N个契约，那么X会创建M * N的负载均衡。对于大多数体系，这个数量级都在1K以内。一样平常的，只必要对于耗时的接口分配独立的负载均衡，以保证耗时请求的流量均衡。除了解决流量均衡标题，Java Chassis的配置方法，还可以针对其他特殊场景提供非常简洁的配置方案，比如可以通过配置：

1. servicecomb.loadbalance.${微服务B}.${契约名称}.${接口名称}.strategy.name=SessionStickiness

复制代码

为具体的接口指定会话粘滞策略。
总结

Java Chassis 3通过接口维度负载均衡的策略设置，为不同的应用场景提供了非常强盛的负载均衡管理能力，帮助解决负载不均衡、会话粘滞等应用负载标题。
 
点击关注，第一时间了解华为云新鲜技术~
 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。