現在整體架構是如下圖（假設服務消費者為訂單服務，服務提供者為使用者服務）：
這樣會有什麼問題呢？
當服務提供者增加節點時，需要修改配置檔案
當其中乙個服務提供者宕機時，服務消費者不能及時感知到，還會往宕機的服務傳送請求
這個時候就得引入註冊中心了
註冊中心
dubbo目前支援4種註冊中心,（multicast zookeeper redis ******） 推薦使用zookeeper註冊中心，本文就講一下用zookeeper實現服務註冊和發現（敲黑板，又一種zookeeper的用處），大致流程如下
現在我們來看dubbo官網對dubbo的介紹圖，有沒有和我們上面畫的很相似
節點角色說明
呼叫關係說明
服務容器負責啟動（上面例子為spring容器），載入，執行服務提供者。
服務提供者在啟動時，向註冊中心註冊自己提供的服務。
服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
註冊中心返回服務提供者位址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
服務消費者，從提供者位址列表中，基於軟負載均衡演算法，選一台提供者進行呼叫，如果呼叫失敗，再選另一台呼叫。
服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
要使用註冊中心，只需要將provider.xml和consumer.xml更改為如下
如果zookeeper是乙個集群，則多個位址之間用逗號分隔即可
註冊資訊在zookeeper中如何儲存？
啟動上面服務後，我們觀察zookeeper的根節點多了乙個dubbo節點及其他，圖示如下
最後乙個節點中192.168.1.104是內網位址，你可以任務和上面配置的localhost乙個效果，大家可以想一下我為什麼把最後乙個節點標成綠色的。沒錯，最後乙個節點是臨時節點，而其他節點是持久節點，這樣，當服務宕機時，這個節點就會自動消失，不再提供服務，服務消費者也不會再請求。如果部署多個demoservice，則providers下面會有好幾個節點，乙個節點儲存乙個demoservice的服務位址
其實乙個zookeeper集群能被多個應用公用，如storm集群和dubbo配置的就是乙個zookeeper集群，為什麼呢？因為不同的框架會在zookeeper上建不同的節點，互不影響。如dubbo會建立乙個/dubbo節點，storm會建立乙個/storm節點，如圖
如何同樣的方法呼叫由dubbox集群提供那麼就會需要提供負載均衡的機制。（注：zookeeper自己本身沒有負載均衡功能，但是他的特性（可以通過心跳機制發現那些dubbo伺服器宕機了，從而維護可呼叫列表）可以借助其他方法實現類似負載均衡的能力。比如dubbo消費者取得了伺服器列表之後，會隨機呼叫其中的乙個。常用的負載均衡實現方式如下：
輪詢（round robin）
輪詢演算法把每個請求輪流傳送到每個伺服器上。
下圖中，一共有6個客戶端產生了6個請求，這6個請求按（1,2,3,4,5,6）的順序傳送。（1,3,5）的請求會被傳送到伺服器1，（2,4,6）的請求會被傳送到伺服器2.
該演算法比較適合每個伺服器的效能差不多的場景，如果有效能存在差異的情況下，那麼效能較差的伺服器可能無法承擔過大的負載
加權輪詢
加權輪序是在輪詢的基礎上，根據伺服器的效能差異，為伺服器賦予乙個的權值，效能高的伺服器分配更高的權值。例如下圖中，伺服器1被賦予的權值為5，伺服器2被賦予的權值為1，那麼（1,2,3,4,5）請求會被傳送到伺服器1,（6）請求會被傳送到伺服器2。
最少連線
由於每個請求的連線時間不一樣，使用輪詢或者加權輪詢演算法的話，可能會讓一台伺服器當前連線數過大，而另一台伺服器的連線過小，造成負載不平衡。
例如下圖中，(1, 3, 5) 請求會被傳送到伺服器 1，但是 (1, 3) 很快就斷開連線，此時只有 (5) 請求連線伺服器 1；(2, 4,6) 請求被傳送到伺服器 2，只有 (2) 的連線斷開，此時 (6, 4) 請求連線伺服器 2。該系統繼續執行時，伺服器 2 會承擔過大的負載。
最少連線演算法就是將請求傳送給當前最少連線數的伺服器上。
例如下圖中，伺服器 1 當前連線數最小，那麼新到來的請求 6 就會被傳送到伺服器 1 上。
加權最少連線
在最少連線的基礎上，根據伺服器的效能為每台伺服器分配權重，再根據權重計算出每台伺服器能處理的連線數
隨機演算法
把請求隨機傳送到伺服器上
和輪詢演算法類似，該演算法比較適合伺服器效能差不多的場景
源位址雜湊法（ip hash）
源位址雜湊通過對客戶端ip計算雜湊值之後，再對伺服器數量取模的得到目標伺服器的序號。
可以保證同一ip的客戶端的請求會**到同一臺伺服器上，用來實現會話粘滯。
dubbo的整體架構如下：
zhengti11
（01）微服務以及springCloud漫談
一 微服務與微服務架構 簡單概括一下微服務與微服務架構。微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。微服務架構是 種架構模式，它提倡將單 應 程式劃分成 組 的服務，服務...
微服務 微服務簡介
什麼是微服務 顧名思義，就是粒度較小的服務，不再侷限於系統與系統之間的藉口呼叫，也不侷限於某種具體的服務形式。系統中凡是可被復用的功能模組都可以被 服務化 轉變為 服務 這些服務可以對外暴露，也可能僅限於再系統內部使用。由於服務數量更多，粒度更小，因此管控難度會更大，對效能的要求也更高。微服務的好處...
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...