【来龙去脉系列】.net分布式系统架构的思路
首先說明的是.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分布式系统架构的思路的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: c关键字
- 下一篇: 【原创】面向对象作业:选课系统中用pic