分佈式系統部署方案

• 分佈式系統的部署

　　日常咱們都說三層架構，我認爲它是一個廣義的模型，更多層的設計能夠合併相鄰幾層的方式最終迴歸到三層這個寬泛的概念上來，個人意思是：這些都只是概念，忘記這些概念去實際分析設計會離這些概念更近一些。

　　接下來我要把三層變的更簡單點，兩層，數據訪問層合併到業務層，統稱爲業務層，由於咱們面對的問題不是分層的問題，而是分佈式系統中各層應該怎麼部署的問題。在CSLA.NET書中也說到業務層和數據訪問層放到同一臺機器上能夠提升性能和容錯性。所以他們倆的合併不影響分佈式系統的部署。

　　不過要解釋的是數據庫系統（CSLA.NET中說的數據存儲和管理層）並無考慮到三層中來，也就是它不包含在數據訪問層中，若是把它算進來，那麼它是在數據訪問層之下單獨存在的。

　　綜上，在分佈式系統部署角度考慮的分層實際是三層：界面層、業務層（包含數據訪問層的業務層）、數據存儲層。

　　下面舉例說明可能的部署情景，帶陰影的框框表示一臺機器，虛線框表示根據使用場合無關緊要，虛橫線表示今後處劃開單獨出服務器。在B/S應用中，Web瀏覽器爲客戶端，其餘所有爲服務器。在C/S應用中，處在最上層的界面層+業務層爲客戶端，其餘爲服務器。

非分佈式系統的部署

單機版

 

兩三臺機器

分佈式系統的部署

分佈式的Web系統

 

分佈式的C/S系統

有幾點要說明：
1． 客戶端上的驗證等業務邏輯是不可信的，所以任何一種部署都須要服務器端包含業務層；
2． 爲了開發、維護和部署中的高度可伸縮性，圖中的各業務層所包含的代碼都是如出一轍的；
3． 由於第2點，因此我遇到了業務層的同一個操做是與其餘機器上的業務層通訊仍是訪問數據庫這個難題。

解決業務層的數據訪問問題

　　這個問題是關鍵問題，也就是上面幾點說明中的第3個問題，爲了解決這個問題咱們引入數據門戶的概念。

　　下面以WebService爲例說明：界面層訪問本機的業務對象的增刪改查中的「查」方法時，跳過數據庫的查詢操做，訪問另外一臺機器中的同一個業務對象類的「查」方法。

　　以上是向另外一臺機器發送請求，該請求並不直接調用另外一臺機器上的業務對象類的「查」方法，而是將要調用的業務對象和方法參數信息轉爲一個「二進制包」，做爲參數去調用另外一臺機器上通用的「查」方法，另外一臺機器上的「查」方法再解開這個包，而後去調用解開的包中所表示的業務對象類型，下面的靜態圖是另外一臺機器接受到請求後的工做。

又有些說明：
1． 關於原理都已在圖中作了描述，不另寫大段文字解釋了；
2． 上面兩個圖中，除了「實際業務對象類」之外的部分所有屬於架構或者框架部分；
3． 若是用OO的思想去審查上面的兩個圖，你必定會爲這糟糕的設計而抱怨，這裏只是爲了儘量簡單的表述分佈式系統的工做原理，你能夠採用策略模式使數據門戶不改變的狀況下適應各類請求響應場合，採用工廠模式實現不一樣的請求響應場合的切換。

 

 

 關於數據庫的分佈

　　爲了解決數據庫服務器的負擔，咱們可能但願把數據分佈存儲在多個服務器上，我設想的數據庫分佈方案是，各服務器上的數據庫在結構上如出一轍，而表裏的數據存儲到不一樣服務器上，這樣數據訪問層在查數據的時候分別向全部數據庫服務器發送一樣的sql命令，而後數據訪問層獲得數據後整合，這樣減輕每臺服務器的工做量。亦或者根據表裏的某個表明性的字段（如：省份）分佈數據到不一樣服務器。
 

   項目模塊依賴

特別提醒：開發人員在開發的時候能夠將本身的業務REST服務化或者Dubbo服務化

2.    項目依賴介紹

   2.1 後臺管理系統、Rest服務系統、Scheculer定時調度系統依賴以下圖：

 

       2.2 Dubbo獨立服務項目依賴以下圖：

 

3.  項目功能部分截圖：

 

 

 

 

 

 

 

zookeeper、dubbo服務啓動 

 

 

dubbo管控臺 

 

 

 

 

 

 

 REST服務平臺