Dubbo中的那些坑（三）设计中欠优雅的地方

Dubbo设计中欠优雅的地方

在侵入性和配置上都有欠优雅的地方，以下内容来自于Dubbox的文档（文档地址）

RpcContext的侵入性

Dubbo的很多高级特性都依赖于RpcContext。一方面它是用单例的方式来访问上下文信息，这完全不符合spring应用的一般风格，不利于应用扩展和单元测试。另一方面RpcContext又是Dubbo特有的对象，会依赖于框架本身，造成与Dubbo耦合。

Protocol配置的局限性

dubbo支持多种远程调用方式，但所有调用方式都是用来配置的，例如：

其实，上面很多属性实际上dubbo RPC远程调用方式特有的，很多dubbo中的其它远程调用方式根本就不支持例如server, client, codec, iothreads, accepts, payload等等（当然，有的是条件所限不支持，有的是根本没有必要支持）。这给用户的使用徒增很多困惑，用户也并不知道有些属性（比如做性能调优）添加了实际上是不起作用的。
　　另一方面，各种远程调用方式往往有大量自己独特的配置需要，特别是我们逐步为每种远程调用方式都添加更丰富、更高级的功能，这就不可避免的扩展中的属性（例如目前我们在REST中已经添加了keepalive和extension两个属性），到最后会导致臃肿不堪，用户的使用也更加困惑。
　　当然，dubbo中有一种扩展的方式是用，但这种方式显然很有局限性，而且用法复杂，缺乏schema校验。
　　所以，最好的方式是为每种远程调用方式设置自己的protocol元素，比如，等等，每种元素用XML schema规定自己的属性（当然属性在各种远程调用方式之间能通用是最好的）。
　　如此一来，例如前面提到过的extension配置也可以用更自由的方式，从而更清楚更可扩展（以下只是举例，当然也许有更好的方式）:

    someInterceptor
    someFilter
    someDynamicFeature
    someEntityProvider

参阅

在Dubbo中开发REST风格的远程调用（RESTful Remoting）

转载注明出处，我就不和你计较。
by Donney Young
http://www.jianshu.com/p/561b5076dc66