swtIrene 2015-10-09
转于自己在公司的Blog:
http://pt.alibaba-inc.com/wp/experience_1003/loadbalance_refactor.html
项目中的一个重构的过程及理由,用于知会团队成员,在这里备一个。
RPC远程调用框架中有很多可选的负载均衡策略,
比如:随机,轮循,最少连接等等,
这个时候就需要一个SPI扩展点,为后续增加新的策略提供可能,
重构前:
原接口形式,如下:
1.public class LoadBalance<T> { 2. 3. // 给定资源和权重,返回选中资源的下标号 4. int select(T[] resources, int[] weights); 5. 6.}
问题一:
返回下标号,使接口输入输出不一致,并且限制了资源的包装,如:
Java代码 复制代码 收藏代码 1.public class LoadBalance { 2. 3. // 给定资源和权重,返回选中资源 4. <T> T select(T[] resources, int[] weights); 5. 6.}
问题二:
作为扩展接口,即然使用泛型,表示策略实现不限制资源类型,接口本身定义泛型没有意义,泛型声明应该定义在方法上,如:
Java代码 复制代码 收藏代码 1.public class LoadBalance { 2. 3. // 给定资源和权重,返回选中资源 4. <T> T select(T[] resources, int[] weights); 5. 6.}
问题三:
作为扩展接口,权重信息的传递过于特殊化,
比如现在最小连接数策略要用到当前活跃连接数,
需增加新的参数actives,如:
Java代码 复制代码 收藏代码 1.public class LoadBalance { 2. 3. // 给定资源和权重,返回选中资源 4. <T> T select(T[] resources, int[] weights, int[] actives); 5. 6.}
问题四:
但像上面这样,你并不清楚后续还有什么参数要加入,接口的契约不容扩展,
另一种办法是,在最小连接数策略实现中将T强制转型成RpcInvoker接口,然后调用getActive(),
但即然active数通过get方获取,为什么weight却通过另一个参数传入,明显的不一致,
而且这里的强制转型,也会导致策略的实现并不能像原来期望的通用,
作为一个框架的扩展点,通用意义并不大,越通用越难用,上面的泛型T有过度设计之嫌,
直接用RpcInvoker作为参数,更能保证契约的完备性,如:
Java代码 复制代码 收藏代码 1.public class LoadBalance { 2. 3. // RpcInvoker接口中有getWeight(), getActive()等获取参数方法 4. // 给定资源和权重,返回选中资源 5. RpcInvoker select(RpcInvoker[] resources); 6. 7.}
如果有通用性需求,也可以考虑再抽取一个接口,如:
Java代码 复制代码 收藏代码 1.public class LoadBalance { 2. 3. // 给定资源和权重,返回选中资源 4. Selectable select(Selectable[] resources); 5. 6.}
问题五:
有一种需求是基于客户端一致性的,要求执行所有RpcInvoker,而不是选其中一个RpcInvoker执行,
原有实现,是将其作为特例,写死在代码中的,基于上面的LoadBalance接口,
完全可以将传入的所有RpcInvoker[]包装成一个总的RpcInvoker,里面用for循环委派所有调用。
如果有w+r>n(写节点+读节点>总节点)的一致性需求,也可以用相应方法处理,只是增加一些配置项,如:
Java代码 复制代码 收藏代码 1.public class AllLoadBalance { 2. 3. public RpcInvoker select(RpcInvoker[] resources) { 4. return new AllRpcInvoker(resources); 5. } 6. 7.} 8.class AllRpcInvoker implements RpcInvoker { 9. 10. private RpcInvoker[] invokers; 11. 12. public AllRpcInvoker(RpcInvoker[] invokers) { 13. this.invokers = invokers; 14. } 15. 16. // Delegate all methods to invokers 17. 18.}
问题六:
有的策略实现是带状态的,比如轮循策略需记录轮循序号,
也就是并不能单实例使用LoadBalance实例,
这对框架的维护非常不利,容易给后来的维护者埋下地雷,
而且,同一个resources集合,必需用同一个LoadBalance实例,
也就是LoadBalance实例的变更是跟随resources集合的变更,
即然如此,资源集合的设定,可以在select()之前确定,如:
1.public class LoadBalance { 2. 3. // 初始化资源集合 4. void init(RpcInvoker[] resources); 5. 6. // 返回选中资源 7. RpcInvoker select(); 8. 9.}
这样的好处是,LoadBalance的实现可以在init()时做预处理及缓存,
比如随机策略,需要统计总权重,如果在init()方法中统计,
select()时可以减少一次for循环,
而且,可以通过重复调用init()方法,复用单一LoadBalance实例,
当然,LoadBalance的实现需确保线程安全性。
------------------------
Dubbo设计分享系列:
一些设计上的基本常识
谈谈泛化式扩展与组合式扩展