dubbo是阿里巴巴的乙個開源rpc專案，可在進行訪問
類似的產品有hessian、spring httpinvoke 等。
dubbo的亮點總結如下：
1、服務註冊中心
相比hessian類rpc框架，dubbo有自己的服務中心， 寫好的服務可以註冊到服務中心， 客戶端從服務中心尋找服務，然後再到相應的服務提供者機器獲取服務
通過服務中心可以實現集群、負載均衡、高可用(容錯) 等重要功能
服務中心一般使用zookeeper實現， 也有redis和其他一些方式 。 以使用zookeeper作為服務中心為例， 服務提供者啟動後會在zookeeper的 /dubbo節點下建立提供的服務節點，包含服務提供者ip、port等資訊。 服務提供者關閉時會從zookeeper中移除對應的服務。
服務使用者會從註冊中心zookeeper中尋找服務，同乙個服務可能會有多個提供者， dubbo會幫我們找到合適的服務提供者
2、集群容錯
當服務呼叫失敗時（比如響應超時），根據我們的業務不同，可以使用不同的策略來應對這種失敗。
比如我們呼叫的服務是乙個查詢服務，不會修改資料庫，那麼可以給該服務設定容錯方式為failover ， 當呼叫失敗時，自動切換到其他服務提供者去呼叫，當失敗次數超過指定重試次數，那麼就丟擲錯誤。
如果服務是更新資料的服務，那就不能使用失敗重試的方式了， 因為這樣可能產生資料重複修改的問題，比如呼叫提供者a的插入使用者方法，但是該方法業務邏輯複雜，執行過程很慢，導致響應超時， 那麼此時如果再去呼叫另外乙個服務提供者的插入使用者方法，將會又重複插入同乙個使用者。 對於這種型別的服務，可以使用容錯方式為failfast，如果第一次呼叫失敗，立即報錯，不需要重試。
另外還有下面幾種容錯型別
failsafe 出現錯誤，直接忽略，不重試也不報錯
failback 失敗後不報錯，會將該失敗請求，定時重發，適合訊息通知型別的服務
forking 並行呼叫多個伺服器，只要在某一台提供者上面成功，那麼方法返回， 適合實時性要求較高的查詢服務， 但是要犧牲效能。因為每台伺服器會做同乙個操作
broadcast 廣播呼叫所有服務提供者，逐個呼叫，任意一台報錯則報錯。 適合與更新每台提供者上面的快取 這泓型別的服務
3、直連提供者
在開發階段為了方便測試，通常系統客戶端能指定呼叫某個服務提供者，那麼可以在引用服務時加乙個url引數去指定服務提供者
4、負載均衡
當同乙個服務有多個提供者在提供服務時， 客戶端如何正確的選擇提供者實現負載均衡dubbo也給我們提供了幾種方案
random 隨機選提供者，並可以給提供者設定權重
roundrobin 輪詢選擇提供者
leastactive 最少活躍呼叫數，相同活躍數的隨機，活躍數指呼叫前後計數差。
使慢的提供者收到更少請求，因為越慢的提供者的呼叫前後計數差會越大。
consistenthash 一致性hash，相同引數的請求發到同一臺機器上
5、服務版本，服務分組
通過服務版本可以控**務的不相容公升級， 當同乙個服務有多種實現時，可以使用服務分組進行區分
6、多協議
dubbo提供了多種協議給使用者選擇， 如dubbo、hessian、rmi 。 並可為每個服務指定不同的傳輸協議，粒度可以細化到方法， 不同服務在效能上適用不同協議進行傳輸，比如大資料用短連線協議，小資料大併發用長連線協議。
dubbo總結 dubbo的使用
dubbo是乙個微服務框架，dubbo也是有乙個服務註冊中心 zookeeper 服務提供者以及服務消費者。服務提供者需要乙個暴露介面的工程，用來服務消費的呼叫。服務提供者的介面實現類繼承暴露介面工程的介面。dubbo呼叫流程 1.服務容器負責啟動，載入，執行服務提供者 2.服務提供者在啟動時，向註...
dubbo使用總結
rest 客戶端呼叫亂碼 將服務端的 produces 中加入charset utf 8 dubbo暴露的rest服務時，如果使用客戶端引用介面jar方式呼叫，必須在介面上面新增rest annotation，否則會報錯 urls to invokers error invokerurls.size...
dubbo個人總結
dubbo，分布式服務框架，rpc服務框架。註冊中心zk,redis.使用大多為zk 註冊流程 最後一圖服務提供者啟動時向 dubbo com.foo.barservice providers目錄下寫入url 服務消費者啟動時訂閱 dubbo com.foo.barservice providers...