一直在思考分布式系統設計的問題，業務對象原封不動的情況下部署在客戶端和服務器端，可以根據配置文件選擇是連接服務器還是連接本地的數據庫，這個問題讓我絞盡腦汁，我總是設想的客戶端與服務器端通信的方式是最低端的Socket。花了兩個晚上研究CSLA.NET框架關于數據門戶這塊代碼，才發現問題的關鍵所在：客戶端與服務器端通信不能采用最低端的Socket，而要用高端的WebService、.NET Remoting或者是自己定義一種協議等，只要它們支持客戶端直接根據服務器端的服務URL、類名、方法名和方法參數四個信息就可以調用服務器對應的類和方法就行。

說明：本文中所表達的思想與CSLA.NET有很大區別，不要看了本文就以為是CSLA.NET的設計思想，也不要以為本文錯誤的解釋了CSLA.NET，這不是一篇介紹CSLA.NET的文章，但純思想上它們是相同的。

• 分布式系統的部署

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

　　接下來我要把三層變的更簡單點，兩層，數據訪問層合并到業務層，統稱為業務層，因為我們面對的問題不是分層的問題，而是分布式系統中各層應該怎么部署的問題。在CSLA.NET書中也說到業務層和數據訪問層放到同一臺機器上可以提高性能和容錯性。因此他們倆的合并不影響分布式系統的部署。

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

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

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

非分布式系統的部署

單機版

?

兩三臺機器

分布式系統的部署

分布式的Web系統

?

分布式的C/S系統

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

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

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

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

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

又有些說明：
1． 關于原理都已在圖中做了描述，不另寫大段文字解釋了；
2． 上面兩個圖中，除了“實際業務對象類”以外的部分全部屬于架構或者框架部分；
3． 如果用OO的思想去審查上面的兩個圖，你一定會為這糟糕的設計而抱怨，這里只是為了盡可能簡單的表述分布式系統的工作原理，你可以采用策略模式使數據門戶不改變的情況下適應各種請求響應場合，采用工廠模式實現不同的請求響應場合的切換。

?

?關于數據庫的分布

　　為了解決數據庫服務器的負擔，我們可能希望把數據分布存儲在多個服務器上，我設想的數據庫分布方案是，各服務器上的數據庫在結構上一模一樣，而表里的數據存儲到不同服務器上，這樣數據訪問層在查數據的時候分別向所有數據庫服務器發送同樣的sql命令，然后數據訪問層得到數據后整合，這樣減輕每臺服務器的工作量。亦或者根據表里的某個代表性的字段（如：省份）分布數據到不同服務器。

總結

以上是生活随笔為你收集整理的分布式系统设计原理与方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。