Dubbo扩展点重构

随着服务化的推广，网站对Dubbo服务框架的需求逐渐增多，
Dubbo的现有开发人员能实现的需求有限，很多需求都被delay，
而网站的同学也希望参与进来，加上领域的推动，
所以平台计划将部分项目对公司内部开放，让大家一起来实现，
Dubbo为试点项目之一。

既然要开放，那Dubbo就要留一些扩展点，
让参与者尽量黑盒扩展，而不是白盒的修改代码，
否则分支，质量，合并，冲突都会很难管理。

先看一下Dubbo现有的设计：

这里面虽然有部分扩展接口，但并不能很好的协作，
而且扩展点的加载和配置都没有统一处理，所以下面对它进行重构。

第一步，微核心，插件式，平等对待第三方。

即然要扩展，扩展点的加载方式，首先要统一，
微核心+插件式，是比较能达到OCP原则的思路，

由一个插件生命周期管理容器，构成微核心，
核心不包括任何功能，这样可以确保所有功能都能被替换，
并且，框架作者能做到的功能，扩展者也一定要能做到，以保证平等对待第三方，
所以，框架自身的功能也要用插件的方式实现，不能有任何硬编码。

通常微核心都会采用Factory，IoC，OSGi等方式管理插件生命周期，
考虑Dubbo的适用面，不想强依赖Spring等IoC容器，
自已造一个小的IoC容器，也觉得有点过度设计，
所以打算采用最简单的Factory方式管理插件，

最终决定采用的是JDK标准的SPI扩展机制，参见：java.util.ServiceLoader
也就是扩展者在jar包的META-INF/services/目录下放置与接口同名的文本文件，
内容为接口实现类名，多个实现类名用换行符分隔，
比如，需要扩展Dubbo的协议，只需在xxx.jar中放置：
文件：META-INF/services/com.alibaba.dubbo.rpc.Protocol
内容为：com.alibaba.xxx.XxxProtocol
Dubbo通过ServiceLoader扫描到所有Protocol实现。

并约定所有插件，都必须标注：@Extension(“name”)，
作为加载后的标识性名称，用于配置选择。

第二步，每个扩展点只封装一个变化因子，最大化复用。

每个扩展点的实现者，往往都只是关心一件事，
现在的扩展点，并没有完全分离，

比如：Failover, Route, LoadBalance, Directory没有完全分开，全由RoutingInvokerGroup写死了。

再比如，协议扩展，扩展者可能只是想替换序列化方式，或者只替换传输方式，
并且Remoting和Http也能复用序列化等实现，
这样，需为传输方式，客户端实现，服务器端实现，协议头解析，数据序列化，都留出不同扩展点。

拆分后，设计如下：

第三步，全管道式设计，框架自身逻辑，均使用截面拦截实现。

现在很多的逻辑，都是放在基类中实现，然后通过模板方法回调子类的实现，
包括：local, mock, generic, echo, token, accesslog, monitor, count, limit等等，
可以全部拆分使用Filter实现，每个功能都是调用链上的一环。

比如：(基类模板方法)

public abstract AbstractInvoker implements Invoker {

public Result invoke(Invocation inv) throws RpcException {
// 伪代码
active + + ;
if (active > max)
wait();

doInvoke(inv);

active – - ;
notify();
}

protected abstract Result doInvoke(Invocation inv) throws RpcException

}

改成：(链式过滤器)

public abstract LimitFilter implements Filter {

public Result invoke(Invoker chain, Invocation inv) throws RpcException {
// 伪代码
active + + ;
if (active > max)
wait();

chain.invoke(inv);

active – - ;
notify();
}

}

第四步，最少概念，一致性概念模型。

保持尽可能少的概念，有助于理解，对于开放的系统尤其重要，
另外，各接口都使用一致的概念模型，能相互指引，并减少模型转换，

比如，Invoker的方法签名为:

Result invoke(Invocation invocation) throws RpcException;

而Exporter的方法签名为:

Object invoke(Method method, Object[] args) throws Throwable;

但它们的作用是一样的，只是一个在客户端，一个在服务器端，却采用了不一样的模型类。

再比如，URL以字符串传递，不停的解析和拼装，没有一个URL模型类， 而URL的参数，却时而Map, 时而Parameters类包装，

export(String url)
createExporter(String host, int port, Parameters params);

使用一致模型：

export(URL url)
createExporter(URL url);

再比如，现有的：Invoker, Exporter, InvocationHandler, FilterChain
其实都是invoke行为的不同阶段，完全可以抽象掉，统一为Invoker，减少概念。

第五步，分层，组合式扩展，而不是泛化式扩展。
原因参见：http://pt.alibaba-inc.com/wp/experience_760/generic_vs_composite_expansibility.html
泛化式扩展指：将扩展点逐渐抽象，取所有功能并集，新加功能总是套入并扩充旧功能的概念。
组合式扩展指：将扩展点正交分解，取所有功能交集，新加功能总是基于旧功能之上实现。
上面的设计，不自觉的就将Dubbo现有功能都当成了核心功能，
上面的概念包含了Dubbo现有RPC的所有功能，包括：Proxy, Router, Failover, LoadBalance, Subscriber, Publisher, Invoker, Exporter, Filter等，
但这些都是核心吗？踢掉哪些，RPC一样可以Run？而哪些又是不能踢掉的？
基于这样考虑，可以将RPC分解成两个层次，只是Protocol和Invoker才是RPC的核心，
其它，包括Router, Failover, Loadbalance, Subscriber, Publisher都不核心，而是Routing，
所以，将Routing作为Rpc核心的一个扩展，设计如下：

第六步，整理，梳理关系。

整理后，设计如下：

————————
Dubbo设计分享系列：
实现的健状性
配置设计
防痴呆设计
负载均衡扩展接口重构
一些设计上的基本常识
谈谈泛化式扩展与组合式扩展