(#)
隨著網際網路的發展。站點應用的規模不斷擴大，常規的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需乙個治理系統確保架構有條不紊的演進。
垂直應用架構
分布式服務架構
流動計算架構
在大規模服務化之前。應用可能僅僅是通過rmi或hessian等工具，簡單的暴露和引用遠端服務，通過配置服務的url位址進行呼叫。通過f5等硬體進行負載均衡。
(1) 當服務越來越多時，服務url配置管理變得很困難。f5硬體負載均衡器的單點壓力也越來越大。
此時須要乙個服務註冊中心。動態的註冊和發現服務，使服務的位置透明。
並通過在消費方獲取服務提供方位址列表。實現軟負載均衡和failover，降低對f5硬體負載均衡器的依賴。也能降低部分成本。
(2) 當進一步發展。服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動。架構師都不能完整的描寫敘述應用的架構關係。
這時。須要自己主動畫出應用間的依賴關係圖。以幫助架構師理清理關係。
(3) 接著，服務的呼叫量越來越大。服務的容量問題就暴露出來，這個服務須要多少機器支撐？什麼時候該加機器？
為了解決這些問題，第一步，要將服務如今每天的呼叫量，響應時間。都統計出來，作為容量規劃的參考指標。
以上是dubbo最主要的幾個需求，很多其它服務治理問題參見：
節點角色說明：
呼叫關係說明：
(1) 連通性：
(2) 健狀性：
(3) 伸縮性：
(4) 公升級性：
一、本地服務
1、定義服務介面: (該介面需單獨打包，在服務提供方和消費方共享)
public inte***ce customerservice在服務提供方實現介面：(對服務消費方隱藏實現)
public class customerserviceimpl implements customerservice
}
dubbo-2.5.3.jar
log4j.jar
netty-3.5.7.final.jar
slf4j.jar
slf4j-log4j.jar
zkclient.jar
zookeeper.jar
4、用spring配置宣告暴露服務：
<?xml version="1.0" encoding="utf-8"?>
-->
載入spring配置。並呼叫遠端服務：(也能夠使用ioc注入)
public class dubooprovider catch (ioexception e)
}}
以上為server提供者的完整步驟，功能介面都已經寫好，以下我們就開始怎麼遠端呼叫
二、服務消費者
<?xml version="1.0" encoding="utf-8"?>
contextconfiglocation
呼叫過程非常easy，先把介面檔案打成jar包。然後在此project中進行引用
在springmvc呼叫程式例如以下：
@autowired customerservice demoservice ;就可以執行成功
三、dubbo-admin的使用
將其放到tomcat以下，配置
dubbo.properties。
dubbo.properties
dubbo.registry.address=zookeeper:
dubbo.admin.root.password=root
dubbo.admin.guest.password=guest
改動zookeeper的url和port
啟動:
./bin/startup.sh
訪問
首頁：
應用頁面：
提供者頁面:
消費者頁面：
服務頁面：
dubbo的安裝和使用
隨著網際網路的發展，應用的規模不斷擴大，常規的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需乙個治理系統確保架構有條不紊的演進。垂直應用架構 分布式服務架構 流動計算架構 在大規模服務化之前，應用可能只是通過rmi或hessian等工具，簡單的暴露和引用遠端服務，通過配置服務的...
Dubbo的使用及安裝
zookeeper jdk先安裝jdk 解壓縮zookeeper 複製zookeeper的解壓路徑下的zoo sample.cfg成zoo.cfg 在zookeeper解壓路徑下建立乙個data的資料夾 修改zoo.cfg的datadir屬性為剛剛建立的data資料夾的全路徑 關閉防火牆 步驟其實差...
zookeeper 和 dubbo的使用
專案最近做成了分布式的 用zookeeper 註冊管理服務，使用dubbo做分布式開發。1 使用zookeeper和dubbo需要引入的包 com.github.sgroschupf zkclient 0.1org.apache.zookeeper zookeeper 3.4.6 com.aliba...