一. 背景
當我們提供的服務越來越複雜的時候，單一架構和垂直架構是無法應對的。我們需要使用分佈式服務架構或流動計算架構來進行處理，所以我們需要對應的治理系統來確保分佈式服務架構或流動計算架構有條不紊的運行。接下來介紹四種演化架構
1. 單一應用架構
在此架構中，只有一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用於簡化增刪改查工作量的數據訪問框架(ORM)是關鍵，那什麼是ORM呢？
ORM： Object Relastional Mapping，對象關係映射，一種爲了解決面向對象與關係數據庫存在的互不匹配的現象的技術。簡單的說，ORM是通過使用描述對象和數據庫之間映射的元數據，將程序中的對象自動持久化到關係數據庫中。但這種架構有明顯的 缺點 ，一旦出現業務需求的變更，就必須修改持久化層的接口。持久化層同時與域模型與關係數據庫模型綁定，不管域模型還是關係數據庫模型發生變化，都要修改持久化層的相關程序代碼，增加了軟件的維護難度
2. 垂直應用架構
當訪問量逐漸增大，單一應用增加機器帶來收益越來越小，於是我們將應用拆成互不相干的幾個應用，以提升效率。此時，用於加速前端頁面開發的Web框架(MVC)是關鍵
MVC： 是模型(model)－視圖(view)－控制器(controller)的縮寫，是一種軟件設計典範。它是用一種業務邏輯、數據與界面顯示分離的方法來組織代碼，將衆多的業務邏輯聚集到一個部件裏面，在需要改進和個性化定製界面及用戶交互的同時，不需要重新編寫業務邏輯，達到減少編碼的時間。
V 即View視圖是指用戶看到並與之交互的界面
M 即model模型是指模型表示業務規則
C 即controller控制器是指控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求，控制器本身不輸出任何東西和做任何處理
用戶首先在界面中進行人機交互，然後請求發送到控制器，控制器根據請求類型和請求的指令發送到相應的模型，模型可以與數據庫進行交互，進行增刪改查操作，完成之後，根據業務的邏輯選擇相應的視圖進行顯示，此時用戶獲得此次交互的反饋信息，用戶可以進行下一步交互，如此循環。
MVC舉例：
最典型的MVC就是jsp+servlet+javabean模式。
JavaBean作爲模型，既可以作爲數據模型來封裝業務數據，又可以作爲業務邏輯模型來包含應用的業務操作。其中，數據模型用來存儲或傳遞業務數據，而業務邏輯模型接收到控制器傳過來的模型更新請求後，執行特定的業務邏輯處理，然後返回相應的執行結果。
JSP作爲表現層，負責提供頁面爲用戶展示數據，提供相應的表單（Form）來用於用戶的請求，並在適當的時候（點擊按鈕）向控制器發出請求來請求模型進行更新。
Serlvet作爲控制器，用來接收用戶提交的請求，然後獲取請求中的數據，將之轉換爲業務模型需要的數據模型，然後調用業務模型相應的業務方法進行更新，同時根據業務執行結果來選擇要返回的視圖。
3. 分佈式服務架構
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務複用及整合的分佈式服務框架(RPC)是關鍵，而Dubbo就是這樣一個分佈式服務框架。
RPC： Remote procedure call，遠程過程調用。在一臺主機上各進程之間的通信可以是share memory 信號量等，而進程之間的通信被稱之爲IPC（inter-process communication）。而RPC是在不同主機上實現進程間的通信。而不同主機並不共用物理地址空間，所以我們需要一個框架提供此功能，使得我們調用不同主機上的服務就像在本地調用一樣。
RPC 框架： RMI，CORBA，ONC RPC，Dubbo，Hessian等
4. 流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集羣容量，提高集羣利用率。此時，用於提高機器利用率的資源調度和治理中心(SOA)是關鍵。
二. Dubbo是什麼
Dubbo是alibaba的一款開源軟件，它是基於java的RPC調用框架。
Dubbo主要提供了三種功能：
- 提供了基於接口的遠程調用接口
- 容錯性和負載均衡
- 服務自動註冊及發現
當我們在編寫java代碼時會調用Dubbo的接口進行編程。並通過配置文件說明通信協議，註冊中心，容錯方式等
三. Dubbo架構
(來自: http://dubbo.io/images/dubbo-architecture.png)
| 節點 | 說明 |
|---|---|
| Text | Text |
| Provider | 暴露服務的服務提供方 |
| Consumer | 調用遠程服務的服務消費方 |
| Registry | 服務註冊與發現的註冊中心 |
| Monitor | 統計服務的調用次數和調用時間的監控中心 |
| Container | 服務運行容器 |
調用關係說明
服務容器負責啓動，加載，運行服務提供者。
服務提供者在啓動時，向註冊中心註冊自己提供的服務。
服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
四. Dubbo配置文件說明
1. <dubbo:service/>
用於暴露一個服務，定義服務的元信息，一個服務可以用多個協議暴露，一個服務也可以註冊到多個註冊中心。服務暴露出去後，可被訂閱的服務調用。下面爲重要參數介紹
- interface：必填。服務接口名，實際就是一個java類的完整路徑，例如：com.test.rpc.api.user.service.DubboUserService。訂閱者調用此暴露的服務實際就是調用此類就有的功能（在java中實際即使此類具有的方法）
- ref：必填。服務對象實現引用，暫不太清楚。
詳細屬性說明：http://dubbo.io/books/dubbo-user-book/references/xml/dubbo-service.html
2. <dubbo:reference/>
用於創建一個遠程服務代理，一個引用可以指向多個註冊中心。用於指明要訂閱的服務。
- id：必填。服務引用BeanId
- interface：必填。服務接口名
- timeout：服務方法調用超時時間(毫秒)
- retries：遠程服務調用重試次數，不包括第一次調用，不需要重試請設爲0
- check：缺省會在啓動時檢查依賴的服務是否可用，不可用時會拋出異常，阻止 Spring 初始化完成，以便上線時，能及早發現問題，默認 check="true"。可以通過 check="false" 關閉檢查，比如，測試時，有些服務不關心，或者出現了循環依賴，必須有一方先啓動。
- loadbalance：負載均衡策略，可選值：random,roundrobin,leastactive，分別表示：隨機，輪循，最少活躍調用
詳細屬性說明：http://dubbo.io/books/dubbo-user-book/references/xml/dubbo-reference.html
3. <dubbo:protocol/>
用於配置提供服務的協議信息，協議由提供方指定，消費方被動接受。指明消費者消費時使用的通行協議，Dubbo支持的有http，dubbo，redis，memcache，rmi等也可以自行擴展，缺省是dubbo
- name : 協議名稱，缺省是dubbo
- port：服務端口，dubbo協議缺省端口爲20880，rmi協議缺省端口爲1099，http和hessian協議缺省端口爲80；如果配置爲-1 或者 沒有配置port，則會分配一個沒有被佔用的端口。Dubbo 2.4.0+，分配的端口在協議缺省端口的基礎上增長，確保端口段可控。
4. <dubbo:registry/>
用於配置連接註冊中心相關信息，dubbo支持的有多播，單播，redis，或使用Zookeeper。官方推薦使用Zookeeper
- address：必填，註冊中心服務器地址，如果地址沒有端口缺省爲9090，同一集羣內的多個地址用逗號分隔，如：ip:port,ip:port，不同集羣的註冊中心，請配置多個<dubbo:registry>標籤
5. <dubbo:monitor/>
用於配置連接監控中心相關信息，可選
參考資料
Dubbo官方文檔： http://dubbo.io/books/dubbo-user-book-en/
RPC解釋： https://en.wikipedia.org/wiki/Remote_procedure_call
下一篇會介紹以Zookeeper爲註冊中心的Dubbo示例