Dubbo设计中欠优雅的地方
在侵入性和配置上都有欠优雅的地方，以下内容来自于Dubbox的文档（文档地址）
RpcContext的侵入性
Dubbo的很多高级特性都依赖于RpcContext。一方面它是用单例的方式来访问上下文信息，这完全不符合spring应用的一般风格，不利于应用扩展和单元测试。另一方面RpcContext又是Dubbo特有的对象，会依赖于框架本身，造成与Dubbo耦合。
Protocol配置的局限性
dubbo支持多种远程调用方式，但所有调用方式都是用<dubbo:protocol/>来配置的，例如：
<dubbo:protocol name="dubbo" port="9090" server="netty" client="netty" codec="dubbo" serialization="hessian2"
charset="UTF-8" threadpool="fixed" threads="100" queues="0" iothreads="9" buffer="8192" accepts="1000" payload="8388608"/>
其实，上面很多属性实际上dubbo RPC远程调用方式特有的，很多dubbo中的其它远程调用方式根本就不支持例如server, client, codec, iothreads, accepts, payload等等（当然，有的是条件所限不支持，有的是根本没有必要支持）。这给用户的使用徒增很多困惑，用户也并不知道有些属性（比如做性能调优）添加了实际上是不起作用的。
另一方面，各种远程调用方式往往有大量自己独特的配置需要，特别是我们逐步为每种远程调用方式都添加更丰富、更高级的功能，这就不可避免的扩展<protocol/>中的属性（例如目前我们在REST中已经添加了keepalive和extension两个属性），到最后会导致<protocol/>臃肿不堪，用户的使用也更加困惑。
当然，dubbo中有一种扩展<protocol/>的方式是用<dubbo:parameter/>，但这种方式显然很有局限性，而且用法复杂，缺乏schema校验。
所以，最好的方式是为每种远程调用方式设置自己的protocol元素，比如<protocol-dubbo/>，<protocol-rest/>等等，每种元素用XML schema规定自己的属性（当然属性在各种远程调用方式之间能通用是最好的）。
如此一来，例如前面提到过的extension配置也可以用更自由的方式，从而更清楚更可扩展（以下只是举例，当然也许有更好的方式）:
<dubbo:protocol-rest port="8080">
<dubbo:extension>someInterceptor</dubbo:extension>
<dubbo:extension>someFilter</dubbo:extension>
<dubbo:extension>someDynamicFeature</dubbo:extension>
<dubbo:extension>someEntityProvider</dubbo:extension>
</dubbo:protocol-rest>
参阅
在Dubbo中开发REST风格的远程调用（RESTful Remoting）
转载注明出处，我就不和你计较。
by Donney Young
http://www.jianshu.com/p/561b5076dc66
