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

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

• 分布式系統(tǒng)的部署

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

　　接下來我要把三層變的更簡單點(diǎn)，兩層，數(shù)據(jù)訪問層合并到業(yè)務(wù)層，統(tǒng)稱為業(yè)務(wù)層，因?yàn)槲覀兠鎸Φ膯栴}不是分層的問題，而是分布式系統(tǒng)中各層應(yīng)該怎么部署的問題。在CSLA.NET書中也說到業(yè)務(wù)層和數(shù)據(jù)訪問層放到同一臺(tái)機(jī)器上可以提高性能和容錯(cuò)性。因此他們倆的合并不影響分布式系統(tǒng)的部署。

　　不過要解釋的是數(shù)據(jù)庫系統(tǒng)（CSLA.NET中說的數(shù)據(jù)存儲(chǔ)和管理層）并沒有考慮到三層中來，也就是它不包含在數(shù)據(jù)訪問層中，如果把它算進(jìn)來，那么它是在數(shù)據(jù)訪問層之下單獨(dú)存在的。

　　綜上，在分布式系統(tǒng)部署角度考慮的分層實(shí)際是三層：界面層、業(yè)務(wù)層（包含數(shù)據(jù)訪問層的業(yè)務(wù)層）、數(shù)據(jù)存儲(chǔ)層。

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

非分布式系統(tǒng)的部署

單機(jī)版

?

兩三臺(tái)機(jī)器

分布式系統(tǒng)的部署

分布式的Web系統(tǒng)

?

分布式的C/S系統(tǒng)

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

解決業(yè)務(wù)層的數(shù)據(jù)訪問問題

　　這個(gè)問題是關(guān)鍵問題，也就是上面幾點(diǎn)說明中的第3個(gè)問題，為了解決這個(gè)問題我們引入數(shù)據(jù)門戶的概念。

　　下面以WebService為例說明：界面層訪問本機(jī)的業(yè)務(wù)對象的增刪改查中的“查”方法時(shí)，跳過數(shù)據(jù)庫的查詢操作，訪問另一臺(tái)機(jī)器中的同一個(gè)業(yè)務(wù)對象類的“查”方法。

　　以上是向另一臺(tái)機(jī)器發(fā)送請求，該請求并不直接調(diào)用另一臺(tái)機(jī)器上的業(yè)務(wù)對象類的“查”方法，而是將要調(diào)用的業(yè)務(wù)對象和方法參數(shù)信息轉(zhuǎn)為一個(gè)“二進(jìn)制包”，作為參數(shù)去調(diào)用另一臺(tái)機(jī)器上通用的“查”方法，另一臺(tái)機(jī)器上的“查”方法再解開這個(gè)包，然后去調(diào)用解開的包中所表示的業(yè)務(wù)對象類型，下面的靜態(tài)圖是另一臺(tái)機(jī)器接受到請求后的工作。

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

?

?關(guān)于數(shù)據(jù)庫的分布

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。