最近看到有部分招聘資訊，要求應聘者說一下分散式系統架構的思路。今天早晨正好有些時間，我也把我們實際在.net方面網站架構的演化路線整理一下，只是我自己的一些想法，歡迎大家批評指正。

首先說明的是.net下開源內容較少，並且也不是做並行資料庫等基礎服務，因此在這裡什麼Hadoop、Spark、ZooKeeper、dubbo等我們暫不去考慮。

一、最初假設的網站中，我們把應用系統網站、檔案和資料庫都放在一臺伺服器上，一臺伺服器包打天下。

二、隨著業務擴充套件，一臺伺服器無法滿足效能需求，將應用程式、資料庫、檔案分別部署在不同的伺服器上，並根據伺服器用途不同，配置不同的硬體，達到效能最佳的效果。

三、隨著業務擴充套件，一臺資料庫、網站、檔案伺服器再高效能也無法大量資料處理、高併發使用者訪問時，必須考慮採用叢集方式。

1、應用伺服器作為網站的入口，會承擔大量的請求，我們往往通過應用伺服器叢集來分擔請求數。應用伺服器前面部署負載均衡伺服器排程使用者請求，根據分發策略將請求分發到多個應用伺服器節點。常用的負載均衡技術硬體的有F5，價格比較貴，軟體的有LVS、Nginx、HAProxy等。

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

3、使用者一天天增加，業務量越來越大，產生的檔案越來越多。通常情況下，一個目錄下的檔案建議不能超過1萬個，否則對於檔案的查詢和輪詢都會非常慢，會導致整個系統無法正常執行。我們一般是按照"\應用程式名\模組名稱\日期"的目錄結構組織的，對於檔案數目仍舊很大的應用，應該再細分。當單臺的檔案伺服器已經不能滿足需求，就需要分散式的檔案系統支撐。常用的分散式檔案系統有NFS。我們用的是MS的分散式檔案系統（DFS），與AD域相關性較大。

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

中間插一段啊。對於各種政府、單位等不能將系統部署到網際網路的部門，並且在各省、市都有對應的分支機構。因為網路專線的價格還是比較高的，至少比網際網路的網路頻寬低了不少，當然了不差錢的不說啊。這種情況下，一般不採用如上的集中式、叢集部署方式，而是採用分散式部署的方式，第一種分散式部署是各分支機構搭建一整套系統，定期（例如每天）進行資料的同步工作，將分支資料彙總到總部、總部的資料下發回各分部；第二種分散式部署方式是各分支部署中介軟體，但是資料集中在總部。

四、隨著業務進一步擴充套件，應用程式變得非常臃腫，這時我們需要將應用程式進行業務拆分，如我們做的綜合業務管理系統分為門戶、聯絡處置、業務資訊、指標、資料查詢分析等業務板塊。每個業務板塊是一個獨立的應用負責相對獨立的業務運作。業務板塊之間通過訊息佇列進行通訊來實現。資料庫也進行相應的拆分，不同的主題放到不同的資料庫中。同時，最好搭建靜態資源伺服器，將公用的css、js、images等都存放到靜態資源伺服器中。

五、對於海量資料的查詢，我們使用nosql資料庫加上搜索引擎可以達到更好的效能。並不是所有的資料都要放在關係型資料中。常用的NOSQL有mongodb和redis，搜尋引擎有lucene，我們使用的Solr、ElasticSearch等基於Lucene核心實現的更易用的搜尋引擎。資料量大的話，Solr等也要做成叢集。

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

七、業務繼續發展，就是CDN，再往下就是搭建幾個中心，將系統部署在各個中心，各地使用者訪問距離他最近的中心，中心間資料保持同步。

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

這時，主要的工作是搭建資料倉庫，然後進行後續的分析和處理。使用ETL/ELT將資料定期從正式環境中匯入到資料倉庫中，按照不同的主題搭建一個個的資料集市。對於資料量比較小的系統，可以使用關係資料庫+多維資料庫的方式；對於大型系統，就要使用按列儲存、並行資料庫等方式了。對於資料的分析可以以報表、KPI、儀表盤駕駛艙等方式提供上層領導決策，也可以使用資料探勘、機器學習和訓練等方式實現價值發現、風險控制等。

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

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

上面說了一大堆，其實架構做的再好，還需要底層來實現。目前流行的語言還是面向物件OO的Java、.net等，也就是說還是用OO的思想和理念去程式設計。抽象、封裝、繼承、多型儘管很字面上比較容易理解，但是深入的認識確實需要一定的程式量的積累，面向物件的幾大原則和設計模式還是編寫出更高可擴充套件、可替換、可配置、可維護等軟體質量指標的程式碼的重要保證。