https://my.oschina.net/tantexian/blog/632100?p={{page}}

當(dāng)然，我知道在dubbo不支持rest的情況下，很多朋友采用的架構(gòu)是spring mvc restful調(diào)用dubbo (spring) service來發(fā)布restful服務(wù)的。這種方式我覺得也非常好，只是如果不修改spring mvc并將其與dubbo深度集成，restful服務(wù)不能像dubbo中的其他遠(yuǎn)程調(diào)用協(xié)議比如webservices、dubbo rpc、hessian等等那樣，享受諸多高級(jí)的服務(wù)治理的功能，比如：注冊(cè)到dubbo的服務(wù)注冊(cè)中心，通過dubbo監(jiān)控中心監(jiān)控其調(diào)用次數(shù)、TPS、響應(yīng)時(shí)間之類，通過dubbo的統(tǒng)一的配置方式控制其比如線程池大小、最大連接數(shù)等等，通過dubbo統(tǒng)一方式做服務(wù)流量控制、權(quán)限控制、頻次控制。另外spring mvc僅僅負(fù)責(zé)服務(wù)端，而在消費(fèi)端，通常是用spring restTemplate，如果restTemplate不和dubbo集成，有可能像dubbo服務(wù)客戶端那樣自動(dòng)或者人工干預(yù)做服務(wù)降級(jí)。如果服務(wù)端消費(fèi)端都是dubbo系統(tǒng)，通過spring的rest交互，如果spring rest不深度整合dubbo，則不能用dubbo統(tǒng)一的路由分流等功能。

上述各個(gè)組件之間的關(guān)系（引自Dubbo文檔）說明如下：

這里的Invoker是Provider的一個(gè)可調(diào)用Service的抽象，Invoker封裝了Provider地址及Service接口信息。

Directory代表多個(gè)Invoker，可以把它看成List，但與List不同的是，它的值可能是動(dòng)態(tài)變化的，比如注冊(cè)中心推送變更。

Cluster將Directory中的多個(gè)Invoker偽裝成一個(gè)Invoker，對(duì)上層透明，偽裝過程包含了容錯(cuò)邏輯，調(diào)用失敗后，重試另一個(gè)。

Router負(fù)責(zé)從多個(gè)Invoker中按路由規(guī)則選出子集，比如讀寫分離，應(yīng)用隔離等。

LoadBalance負(fù)責(zé)從多個(gè)Invoker中選出具體的一個(gè)用于本次調(diào)用，選的過程包含了負(fù)載均衡算法，調(diào)用失敗后，需要重選。

http://www.infoq.com/cn/news/2014/10/dubbox-open-source/

dubboX 實(shí)現(xiàn)了基于http+JSON的rest服務(wù)擴(kuò)展https://github.com/dangdangdotcom/dubbox/tree/dubbox-2.8.4

RestEasy，jboss開源項(xiàng)目，基于restful的web service框架

我們?cè)谟胐ubbo，朋友的公司也有在用的，面臨的問題也大致相似，問題定位、熔斷和監(jiān)控方面的問題讓人沒有那么的放心，最近打算嘗試在spring-cloud中尋找答案。

spring cloud整機(jī)，dubbo需要自己組裝；整機(jī)的性能有保證，組裝的機(jī)子更自由。

新浪-motan、google維護(hù)的grpc