隨著互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

• 單一應用架構
  • 　　當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
  • 　　此時，用於簡化增刪改查工作量的 數據訪問框架(ORM) 是關鍵。
• 垂直應用架構
  • 　　當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相幹的幾個應用，以提升效率。
  • 　　此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
• 分布式服務架構
  • 　　當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
  • 　　此時，用於提高業務復用及整合的 分布式服務框架(RPC) 是關鍵。
• 流動計算架構
  • 　　當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集群容量，提高集群利用率。
  • 　　此時，用於提高機器利用率的 資源調度和治理中心(SOA) 是關鍵。

　　Dubbo就是資源調度和治理中心的管理工具。

1.1.1. Dubbo的架構

節點角色說明：

Provider: 暴露服務的服務提供方。

Consumer: 調用遠程服務的服務消費方。

Registry: 服務註冊與發現的註冊中心。

Monitor: 統計服務的調用次調和調用時間的監控中心。

Container: 服務運行容器。

調用關系說明：

0. 服務容器負責啟動，加載，運行服務提供者。

1. 服務提供者在啟動時，向註冊中心註冊自己提供的服務。

2. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。

3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。

4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。

5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

1.1.2. 使用方法

Dubbo采用全Spring配置方式，透明化接入應用，對應用沒有任何

單一工程中spring的配置

遠程服務：

在本地服務的基礎上，只需做簡單配置，即可完成遠程化：

將上面的local.xml配置拆分成兩份，將服務定義部分放在服務提供方remote-provider.xml，將服務引用部分放在服務消費方remote-consumer.xml。

並在提供方增加暴露服務配置<dubbo:service>，在消費方增加引用服務配置<dubbo:reference>。

發布服務：

調用服務：

1.1.3. 註冊中心

註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心交互，註冊中心不轉發請求，壓力較小。使用dubbo-2.3.3以上版本，建議使用zookeeper註冊中心。

Zookeeper是Apacahe Hadoop的子項目，是一個樹型的目錄服務，支持變更推送，適合作為Dubbo服務的註冊中心，工業強度較高，可用於生產環境，並推薦使用

Zookeeper的安裝：

第一步：安裝jdk

第二步：解壓縮zookeeper壓縮包

第三步：將conf文件夾下zoo_sample.cfg復制一份，改名為zoo.cfg

第四步：修改配置dataDir屬性，指定一個真實目錄

第五步：

啟動zookeeper：bin/zkServer.sh start

關閉zookeeper：bin/zkServer.sh stop

查看zookeeper狀態：bin/zkServer.sh status

*註意要關閉linux的防火墻或放行相關端口號

分布式服務框架Dubbo