點關注不迷路，歡迎再訪！精簡部落格內容，盡量已行業術語來分享。既然是新手教學，肯定很多同學不明白什麼是分布式和遠端服務呼叫，為什麼要分布式，為什麼要遠端呼叫。下圖為例：努力做到對每一位認可自己的讀者負責。
幫助別人的同時更是豐富自己的良機。
以前什麼的都在乙個伺服器上，呼叫方法直接就自然而然呼叫了，沒啥問題。現在因為需求增多拆分了這麼多個，部署在不同的伺服器上，那是不是相對以前都在乙個伺服器上，現在分布式後，web層呼叫service層的服務變成了遠端呼叫？那怎樣像以前那樣都在乙個伺服器上自然而然呼叫方法呢？dubbo來解決。這就是下面dubbo的好處。
講解架構圖之前，我們先普及下幾個概念。
provider（生產者）: 暴露服務的服務提供方。
consumer（消費者）: 呼叫遠端服務的服務消費方。
如圖，我們可以簡單理解為web1234是消費者，service1234是生產者。
你看著暈不暈？暈不暈？暈不暈？反正我是暈了，萬一分布式得更多呢？，所以我們需要registry（註冊中心）: 服務註冊與發現的註冊中心。
dubbo推薦的是zookeeper。什麼是zookeeper？
zookeeper是用於分布式中一致性處理的框架。其實就是個框架，是一致性處理用的。簡單的講，zookeeper就是起到中介作用，賣樓的（生產者）把樓盤資訊放在中介（註冊中心）那裡，想買樓的（消費者）去中介那裡獲得樓盤資源清單。於是，我們的圖變成了這樣：
是不是好很多了？還不夠， 我們還需要個監控中心（幹嘛用的？當然是監控用的，呼叫失敗怎麼辦？掛了怎麼辦？）： monitor: 統計服務的呼叫次調和呼叫時間的監控中心。
最終dubbo架構，如圖（從0開始看起）：
0. 服務容器負責啟動，載入，執行服務提供者。
1. 服務提供者（生產者）在啟動時，向註冊中心註冊自己提供的服務。
2. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3. 註冊中心返回服務提供者位址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
4. 服務消費者，從提供者位址列表中，基於軟負載均衡演算法，選一台提供者進行呼叫，如果呼叫失敗，再選另一台呼叫。
5. 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心
Dubbo簡單介紹及其和zookeeper的關係
dubbox 是乙個分布式服務框架，其前身是阿里巴巴開源專案dubbo 被國內電商及網際網路專案中使用，後期阿里巴巴停止了該項目的維護，當當網便在dubbo基礎上進行優化，並繼續維護，為了與原有的dubbo區分，故將其命名為dubbox。dubbox 致力於提供高效能和透明化的rpc遠端服務呼叫方案...
基於springboot和dubbo搭建SOA服務
詳見zookeeper搭建 配置 修改tomcat的埠8088，修改方法如下，打到conf下的檔案 server.xml，因為zookeeper會用到8080的埠，所以為了不衝突，把tomcat的埠改一下。設定dubbo掃瞄包 param packagename return bean public...
Dubbo 基於zookeeper註冊中心（二）
目錄 jar包依賴 服務提供者配置檔案修改 客戶端修改配置檔案 文章中配置檔案的修改都是基於簡單dubbo專案專案，由於要使用zookeeper註冊中心，所以還需要安裝好zk，基於虛擬機器安裝zookeeper可以參考zookeeper的安裝配置，window系統下的按照也是大同小異。這裡使用的是使...