一直在思考分佈式系統設計的問題，業務對象原封不動的情況下部署在客戶端和服務器端，可以根據配置文件選擇是連接服務器還是連接本地的數據庫，這個問題讓我絞盡腦汁，我總是設想的客戶端與服務器端通信的方式是最低端的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命令，然後數據訪問層得到數據後整合，這樣減輕每臺服務器的工作量。亦或者根據表裏的某個代表性的字段（如：省份）分佈數據到不同服務器。