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.lxweimin.com/p/561b5076dc66
