分布式系統(tǒng)的架構(gòu)思路

1、分布式系統(tǒng)的架構(gòu)思路一、前言在計(jì)算機(jī)領(lǐng)域，當(dāng)單機(jī)性能達(dá)到瓶頸時(shí)，有兩種方式可以解決性能問題，一是堆硬件，進(jìn)一步提升配置，二是分布式，水平擴(kuò)展。當(dāng)然，兩者都是一樣的燒錢。今天聊聊我所理解的分布式系統(tǒng)的架構(gòu)思路。二、分布式系統(tǒng)的兩種方式平時(shí)接觸到的分布式系統(tǒng)有很多種，比如分布式文件系統(tǒng)，分布式數(shù)據(jù)庫，分布式WebService，分布式計(jì)算等等，面向的情景不同，但分布式的思路是否是一樣的呢?1.簡(jiǎn)單的例子假設(shè)我們有一臺(tái)服務(wù)器，它可以承擔(dān)1百萬/秒的請(qǐng)求，這個(gè)請(qǐng)求可以的是通過http訪問網(wǎng)頁，通過tcp下載文件，jdbc執(zhí)行sql，RPC調(diào)用接口，現(xiàn)在我們有一條數(shù)據(jù)的請(qǐng)求是2百萬/秒，很顯然服務(wù)器ho

2、ld不住了，會(huì)各種拒絕訪問，甚至崩潰，宕機(jī)，怎么辦呢。一臺(tái)機(jī)器解決不了的問題，那就兩臺(tái)。所以我們加一臺(tái)機(jī)器，每臺(tái)承擔(dān)1百萬。如果請(qǐng)求繼續(xù)增加呢，兩臺(tái)解決不了的問題，那就三臺(tái)唄。這種方式我們稱之為水平擴(kuò)展。如何實(shí)現(xiàn)請(qǐng)求的平均分配便是負(fù)載均衡了。另一個(gè)栗子，我們現(xiàn)在有兩個(gè)數(shù)據(jù)請(qǐng)求，數(shù)據(jù)1 90萬，數(shù)據(jù)2 80萬，上面那臺(tái)機(jī)器也hold不住，我們加一臺(tái)機(jī)器來負(fù)載均衡一下，每臺(tái)機(jī)器處理45萬數(shù)據(jù)1和40萬數(shù)據(jù)2，但是平分太麻煩，不如一臺(tái)處理數(shù)據(jù)1，一臺(tái)處理數(shù)據(jù)2，同樣能解決問題，這種方式我們稱之為垂直拆分。水平擴(kuò)展和垂直拆分是分布式架構(gòu)的兩種思路，但并不是一個(gè)二選一的問題，更多的是兼并合用。下面介紹一

3、個(gè)實(shí)際的場(chǎng)景。這也是許多互聯(lián)網(wǎng)的公司架構(gòu)思路。2.實(shí)際的例子我此時(shí)所在的公司的計(jì)算機(jī)系統(tǒng)很龐大，自然是一個(gè)整的分布式系統(tǒng)，為了方便組織管理，公司將整個(gè)技術(shù)部按業(yè)務(wù)和平臺(tái)拆分為部門，訂單的，會(huì)員的，商家的等等，每個(gè)部門有自己的web服務(wù)器集群，數(shù)據(jù)庫服務(wù)器集群，通過同一個(gè)網(wǎng)站訪問的鏈接可能來自于不同的服務(wù)器和數(shù)據(jù)庫，對(duì)網(wǎng)站及底層對(duì)數(shù)據(jù)庫的訪問被分配到了不同的服務(wù)器集群,這個(gè)便是典型的按業(yè)務(wù)做的垂直拆分，每個(gè)部門的服務(wù)器在hold不住時(shí)，會(huì)有彈性的擴(kuò)展，這便是水平擴(kuò)展。在數(shù)據(jù)庫層，有些表非常大，數(shù)據(jù)量在億級(jí)，如果只是純粹的水平的擴(kuò)展并不一定最好，如果對(duì)表進(jìn)行拆分，比如可以按用戶id進(jìn)行水平拆表，通

4、過對(duì)id取模的方式，將用戶劃分到多張表中，同時(shí)這些表也可以處在不同的服務(wù)器。按業(yè)務(wù)的垂直拆庫和按用戶水平拆表是分布式數(shù)據(jù)庫中通用的解決方案。三、負(fù)載均衡前面我們談到了分布式來解決性能問題，但其附帶的問題是怎么分布，即如何負(fù)載均衡。這里要解決的問題是當(dāng)客戶端請(qǐng)求時(shí)，應(yīng)該讓它請(qǐng)求分布式系統(tǒng)中哪一臺(tái)服務(wù)器，通常的做法是通過一臺(tái)中間服務(wù)器來給客服端分配目標(biāo)服務(wù)器。這里同樣拿兩個(gè)不同的分布式系統(tǒng)做說明，下圖左邊是分布式文件系統(tǒng)FastDFS,右邊是一個(gè)用于分布式的RPC中間件。 FastDFS的一次文件下載請(qǐng)求過程是這樣的1.client詢問tracker可以下載指定文件的storage；2.track

5、er返回一臺(tái)可用的storage；3.client直接和storage通信完成文件下載。其中tracker便是負(fù)載均衡服務(wù)器，storage是存儲(chǔ)文件和處理上傳下載請(qǐng)求的服務(wù)器。 而另一個(gè)RPC中間件Hedwig也是類似的1.client詢問zookeeper哪臺(tái)server可以執(zhí)行請(qǐng)求；2.zookeeper返回一臺(tái)可用server；3.client直接與service完成一次RPC。zookeeper是分布式系統(tǒng)中一個(gè)負(fù)載均衡框架，google的chubby的一個(gè)開源實(shí)現(xiàn)，是是Hadoop和Hbase的重要組件。同樣的在http中，常聽說的nginx也是一個(gè)負(fù)載均衡服務(wù)器，它面向的是分布式

6、web服務(wù)器。至于具體的負(fù)載均衡算法輪詢，hash等這里就不深入了。四、同步分布式系統(tǒng)中，解決了負(fù)載均衡的問題后，另外一個(gè)問題就是數(shù)據(jù)的一致性了，這個(gè)就需要通過同步來保障。根據(jù)不同的場(chǎng)景和需求，同步的方式也是有選擇的。在分布式文件系統(tǒng)中，比如商品頁面的圖片，如果進(jìn)行了修改，同步要求并不高，就算有數(shù)秒甚至數(shù)分鐘的延遲都是可以接受的，因?yàn)橐话悴粫?huì)產(chǎn)生損失性的影響，因此可以簡(jiǎn)單的通過文件修改的時(shí)間戳，隔一定時(shí)間掃描同步一次，可以犧牲一致性來提高效率。但銀行中的分布式數(shù)據(jù)庫就不一樣了，一丁點(diǎn)不同步就是無法接受的，甚至可以通過加鎖等犧牲性能的方式來保障完全的一致。在一致性算法中paxos算法是公認(rèn)的最好的算法，chubby、