首先說明的是.net下開源內容較少，并且也不是做并行數(shù)據(jù)庫等基礎服務，因此在這里什么Hadoop、Spark、ZooKeeper、dubbo等我們暫不去考慮。

一、最初假設的網(wǎng)站中，我們把應用系統(tǒng)網(wǎng)站、文件和數(shù)據(jù)庫都放在一臺服務器上，一臺服務器包打天下。

二、隨著業(yè)務擴展，一臺服務器無法滿足性能需求，將應用程序、數(shù)據(jù)庫、文件分別部署在不同的服務器上，并根據(jù)服務器用途不同，配置不同的硬件，達到性能最佳的效果。

三、隨著業(yè)務擴展，一臺數(shù)據(jù)庫、網(wǎng)站、文件服務器再高性能也無法大量數(shù)據(jù)處理、高并發(fā)用戶訪問時，必須考慮采用集群方式。

1、應用服務器作為網(wǎng)站的入口，會承擔大量的請求，我們往往通過應用服務器集群來分擔請求數(shù)。應用服務器前面部署負載均衡服務器調度用戶請求，根據(jù)分發(fā)策略將請求分發(fā)到多個應用服務器節(jié)點。常用的負載均衡技術硬件的有F5，價格比較貴，軟件的有LVS、Nginx、HAProxy等。

2、隨著用戶量的增加，數(shù)據(jù)庫成為最大的瓶頸，改善數(shù)據(jù)庫性能常用的手段是進行讀寫分離以及分表，讀寫分離顧名思義就是將數(shù)據(jù)庫分為讀庫和寫庫，通過主備功能實現(xiàn)數(shù)據(jù)同步。分庫分表則分為水平切分和垂直切分，水平切換則是對一個數(shù)據(jù)庫特大的表進行拆分，例如訂單、物流信息表等。垂直切分則是根據(jù)業(yè)務不同來切換，如訂單、計稅等等不同的主題放在不同的數(shù)據(jù)庫中。這種情況下，關聯(lián)查詢是沒有的，通過程序可以比較容易的去解決，還有就是采用分布式事務，來保證數(shù)據(jù)的一致性。我們這里還有一個做法，一個大的數(shù)據(jù)表拆分為當前操作表和歷史記錄表， 當前操作表只保留正在操作的數(shù)據(jù)，完成后轉入歷史記錄表，這樣可以提高當前操作數(shù)據(jù)的效率。

3、用戶一天天增加，業(yè)務量越來越大，產(chǎn)生的文件越來越多。通常情況下，一個目錄下的文件建議不能超過1萬個，否則對于文件的查找和輪詢都會非常慢，會導致整個系統(tǒng)無法正常運行。我們一般是按照"\應用程序名\模塊名稱\日期"的目錄結構組織的，對于文件數(shù)目仍舊很大的應用，應該再細分。當單臺的文件服務器已經(jīng)不能滿足需求，就需要分布式的文件系統(tǒng)支撐。常用的分布式文件系統(tǒng)有NFS。我們用的是MS的分布式文件系統(tǒng)（DFS），與AD域相關性較大。

4、因為應用服務器是集群方式，用戶前后兩次請求可能訪問的不是一臺服務器。因此已經(jīng)不能像以前一樣使用狀態(tài)（Application、Session、Cache、ViewState等），應用系統(tǒng)必須是無狀態(tài)的（當然了，用的負載均衡具有會話保持的時候，一個用戶只會定位到一臺服務器）。系統(tǒng)的緩存應該保存在專門的緩存服務器上，如果必須有狀態(tài)，也應該保存在專門的緩存服務器中。作為第一批吃螃蟹者，我們用了微軟的AppFabric作為緩存服務器，因為當時版本很低，問題也不少，后來我們棄用了AppFabric，使用Redis作為緩存服務。現(xiàn)在，AppFabric已經(jīng)改進了不少，運行在Azure云上，應該是不會存在以前的問題了。

?

中間插一段啊。對于各種政府、單位等不能將系統(tǒng)部署到互聯(lián)網(wǎng)的部門，并且在各省、市都有對應的分支機構。因為網(wǎng)絡專線的價格還是比較高的，至少比互聯(lián)網(wǎng)的網(wǎng)絡帶寬低了不少，當然了不差錢的不說啊。這種情況下，一般不采用如上的集中式、集群部署方式，而是采用分布式部署的方式，第一種分布式部署是各分支機構搭建一整套系統(tǒng)，定期（例如每天）進行數(shù)據(jù)的同步工作，將分支數(shù)據(jù)匯總到總部、總部的數(shù)據(jù)下發(fā)回各分部；第二種分布式部署方式是各分支部署中間件，但是數(shù)據(jù)集中在總部。

四、隨著業(yè)務進一步擴展，應用程序變得非常臃腫，這時我們需要將應用程序進行業(yè)務拆分，如我們做的綜合業(yè)務管理系統(tǒng)分為門戶、聯(lián)系處置、業(yè)務信息、指標、數(shù)據(jù)查詢分析等業(yè)務板塊。每個業(yè)務板塊是一個獨立的應用負責相對獨立的業(yè)務運作。業(yè)務板塊之間通過消息隊列進行通信來實現(xiàn)。數(shù)據(jù)庫也進行相應的拆分，不同的主題放到不同的數(shù)據(jù)庫中。同時，最好搭建靜態(tài)資源服務器，將公用的css、js、images等都存放到靜態(tài)資源服務器中。

五、對于海量數(shù)據(jù)的查詢，我們使用nosql數(shù)據(jù)庫加上搜索引擎可以達到更好的性能。并不是所有的數(shù)據(jù)都要放在關系型數(shù)據(jù)中。常用的NOSQL有mongodb和redis，搜索引擎有l(wèi)ucene，我們使用的Solr、ElasticSearch等基于Lucene內核實現(xiàn)的更易用的搜索引擎。數(shù)據(jù)量大的話，Solr等也要做成集群。

?

六、再往下走，系統(tǒng)需要與其他系統(tǒng)進行交互，系統(tǒng)也要給各種前端（例如網(wǎng)站、安卓、IOS）提供服務，這樣我們就要在邏輯層之上建設應用服務層，提供對客戶端的和對外的SOA服務接口。這樣又涉及到DTO、WebService、WCF和WebApi（Rest）等概念。但是最重要的是，SOA方式下，包括前面的MQ方式下，事務一致性無法得到保障的，必須采用一定的機制例如事務補償機制來確保事務的最終一致性。各個業(yè)務板塊所在的服務器，在不同時段的壓力也不同，為了盡量做到服務器集群內各服務器的壓力平攤， 還需要提供更好的機制，記錄下每個服務器的壓力、資源情況、連接數(shù)等等，以便將新的請求轉向到壓力最小的服務器上。

?

七、業(yè)務繼續(xù)發(fā)展，就是CDN，再往下就是搭建幾個中心，將系統(tǒng)部署在各個中心，各地用戶訪問距離他最近的中心，中心間數(shù)據(jù)保持同步。

?

八、上面講了應用系統(tǒng)方面比較多，數(shù)據(jù)方面也要做許多工作。上面已經(jīng)介紹了分庫分表方式。應用系統(tǒng)做大了，勢必有許多的數(shù)據(jù)資源，尤其是現(xiàn)在大數(shù)據(jù)這個名詞非常火爆的情況下，數(shù)據(jù)分析和處理是一個系統(tǒng)必須要做的事情。這樣做的好處是，將數(shù)據(jù)的查詢、分析等獨立出來，不影響正式運行中的系統(tǒng)，另外是通過分析挖掘確實能得到許多意想不到的價值。

這時，主要的工作是搭建數(shù)據(jù)倉庫，然后進行后續(xù)的分析和處理。使用ETL/ELT將數(shù)據(jù)定期從正式環(huán)境中導入到數(shù)據(jù)倉庫中，按照不同的主題搭建一個個的數(shù)據(jù)集市。對于數(shù)據(jù)量比較小的系統(tǒng)，可以使用關系數(shù)據(jù)庫+多維數(shù)據(jù)庫的方式；對于大型系統(tǒng)，就要使用按列存儲、并行數(shù)據(jù)庫等方式了。對于數(shù)據(jù)的分析可以以報表、KPI、儀表盤駕駛艙等方式提供上層領導決策，也可以使用數(shù)據(jù)挖掘、機器學習和訓練等方式實現(xiàn)價值發(fā)現(xiàn)、風險控制等。

?

九、一般情況下，企業(yè)是沒有那么大的財力和人員去做上述內容的，因此使用云成為企業(yè)的一個選擇。無論是Azure、阿里云、亞馬遜等都會提供一個個的服務。我們就以阿里云為例，ECS提供虛擬服務器、SLB提供負載均衡、RDS提供數(shù)據(jù)庫服務、OSS提供存儲服務、DRDS是分布式數(shù)據(jù)服務、ODSP（現(xiàn)在改名叫MaxCompute）提供大數(shù)據(jù)的計算服務、RocketMQ提供MQ、OCS提供分布式緩存服務、以及CDN、OTS、ADS等等就不一一列舉了。

對了，現(xiàn)在還有Docker這個利器，無論在企業(yè)還是云中都可以使用，我們在自己內部使用的Redis、Memcached、RabbitMQ、Solr等都部署在Docker中，確實比較方便。

轉載于:https://www.cnblogs.com/tuyile006/p/8980428.html

總結

以上是生活随笔為你收集整理的【来龙去脉系列】.net分布式系统架构的思路的全部內容，希望文章能夠幫你解決所遇到的問題。

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