【转】框架设计思路参考
dream00csdn 2015-10-09
转于自己在公司的Blog：
http://pt.alibaba-inc.com/wp/dev_related_1283/dubbo-extension.html
原文：
http://javatar.iteye.com/blog/1041832
随着服务化的推广，网站对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实现，每个功能都是调用链上的一环。
比如：(基类模板方法)
Java代码复制代码收藏代码
1.publicabstractAbstractInvokerimplementsInvoker{
2.
3.publicResultinvoke(Invocationinv)throwsRpcException{
4.//伪代码
5.active++;
6.if(active>max)
7.wait();
8.
9.doInvoke(inv);
10.
11.active--;
12.notify();
13.}
14.
15.protectedabstractResultdoInvoke(Invocationinv)throwsRpcException
16.
17.}
改成：(链式过滤器)
Java代码复制代码收藏代码
1.publicabstractLimitFilterimplementsFilter{
2.
3.publicResultinvoke(Invokerchain,Invocationinv)throwsRpcException{
4.//伪代码
5.active++;
6.if(active>max)
7.wait();
8.
9.chain.invoke(inv);
10.
11.active--;
12.notify();
13.}
14.
15.}
第四步，最少概念，一致性概念模型。
保持尽可能少的概念，有助于理解，对于开放的系统尤其重要，
另外，各接口都使用一致的概念模型，能相互指引，并减少模型转换，
比如，Invoker的方法签名为:
Java代码复制代码收藏代码
1.Resultinvoke(Invocationinvocation)throwsRpcException;
而Exporter的方法签名为:
Java代码复制代码收藏代码
1.Objectinvoke(Methodmethod,Object[]args)throwsThrowable;
但它们的作用是一样的，只是一个在客户端，一个在服务器端，却采用了不一样的模型类。
再比如，URL以字符串传递，不停的解析和拼装，没有一个URL模型类，而URL的参数，却时而Map,时而Parameters类包装，
Java代码复制代码收藏代码
1.export(Stringurl)
2.createExporter(Stringhost,intport,Parametersparams);
使用一致模型：
Java代码复制代码收藏代码
1.export(URLurl)
2.createExporter(URLurl);
再比如，现有的：Invoker,Exporter,InvocationHandler,FilterChain
其实都是invoke行为的不同阶段，完全可以抽象掉，统一为Invoker，减少概念。
第五步，分层，组合式扩展，而不是泛化式扩展。
泛化式扩展指：将扩展点逐渐抽象，取所有功能并集，新加功能总是套入并扩充旧功能的概念。
组合式扩展指：将扩展点正交分解，取所有功能交集，新加功能总是基于旧功能之上实现。
上面的设计，不自觉的就将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核心的一个扩展，设计如下：
第六步，整理，梳理关系。
整理后，设计如下：
