模版模式介绍
在模板模式(Template Pattern)中,一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现,但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。
使用场景:定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
dubbo源码中应用
如上图,dubbo的负载均衡算法都继承同一个抽象类,抽象类中select方法把通用逻辑都完成了,留了一个抽象的doSelect方法给子类实现。源码如下:
public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {if (CollectionUtils.isEmpty(invokers)) {return null;}if (invokers.size() == 1) {return invokers.get(0);}return doSelect(invokers, url, invocation);}
dubbo支持的负载均衡算法如下:
算法 | 特性 | 备注 |
---|---|---|
Weighted Random LoadBalance | 加权随机 | 默认算法,默认权重相同 |
RoundRobin LoadBalance | 加权轮询 | 借鉴于 Nginx 的平滑加权轮询算法,默认权重相同, |
LeastActive LoadBalance | 最少活跃优先 + 加权随机 | 背后是能者多劳的思想 |
Shortest-Response LoadBalance | 最短响应优先 + 加权随机 | 更加关注响应速度 |
ConsistentHash LoadBalance | 一致性哈希 | 确定的入参,确定的提供者,适用于有状态请求 |
P2C LoadBalance | Power of Two Choice | 随机选择两个节点后,继续选择“连接数”较小的那个节点。 |
Adaptive LoadBalance | 自适应负载均衡 | 在 P2C 算法基础上,选择二者中 load 最小的那个节点 |
代码实现逻辑图如下:
使用时由AbstractClusterInvoker(容错方法基类)初始化指定的LoadBalance,然后调用算法。初始化源码如下:
protected LoadBalance initLoadBalance(List<Invoker<T>> invokers, Invocation invocation) {ApplicationModel applicationModel = ScopeModelUtil.getApplicationModel(invocation.getModuleModel());if (CollectionUtils.isNotEmpty(invokers)) {return applicationModel.getExtensionLoader(LoadBalance.class).getExtension(invokers.get(0).getUrl().getMethodParameter(RpcUtils.getMethodName(invocation), LOADBALANCE_KEY, DEFAULT_LOADBALANCE));} else {return applicationModel.getExtensionLoader(LoadBalance.class).getExtension(DEFAULT_LOADBALANCE);}}
调用源码如下:
public Result invoke(final Invocation invocation) throws RpcException {.....省略代码// 初始化loadBalanceLoadBalance loadbalance = initLoadBalance(invokers, invocation);RpcUtils.attachInvocationIdIfAsync(getUrl(), invocation);InvocationProfilerUtils.enterDetailProfiler(invocation, () -> "Cluster " + this.getClass().getName() + " invoke.");try {// 传递给下层,调用loadBalancereturn doInvoke(invocation, invokers, loadbalance);} finally {InvocationProfilerUtils.releaseDetailProfiler(invocation);}}
总结
在多元化的实际业务应用中,模板模式以其灵活而强大的设计哲学,被广泛采用来构建可扩展且易于维护的代码结构。通过精心定义一个基类,我们不仅实现了共通的核心逻辑和校验机制,而且通过引入抽象方法,为子类提供了一个定制化实现的舞台,允许它们在不改变算法框架的前提下,注入特定的业务规则和行为。
这样的设计策略,既确保了整体架构的稳固性,又赋予了系统以必要的灵活性,使得新的业务需求能够在现有的模板基础上迅速得到适应与实现,从而提升了开发效率,并降低了后期维护的复杂性。
在项目架构的精妙设计中,我们精心定义了一系列的策略接口来应对多样化的业务场景。尽管策略接口众多,但大多数校验流程和调用模式却高度一致,唯一的差异在于各自的策略数据结构。
为了遵循软件设计的开闭原则——即对扩展开放,对修改封闭,我们采用了抽象基类来封装这些通用的方法。如此一来,当引入新的策略时,我们便无需触及已有的校验逻辑,仅需扩展基类,实现特定的策略方法即可。这种设计不仅提高了代码的复用性,也大大简化了后续的维护和扩展工作,确保了系统的健壮性和灵活性。