聯(lián)系我們
        15608181518??? 18683438262
        歡迎進(jìn)入德天信科技(服務(wù)區(qū)域:貴陽(yáng)、成都、重慶)
        網(wǎng)站/微信/小程序/APP
        1500+客戶一致的選擇
        典型的分布式網(wǎng)站架構(gòu)
        日期:2019-03-29 09:20:07

        分布式架構(gòu)與傳統(tǒng)的單機(jī)架構(gòu)最大的區(qū)別在于分布式架構(gòu)能解決兩個(gè)方向的擴(kuò)展問(wèn)題:一是橫向擴(kuò)展,二是縱向擴(kuò)展。

        橫向擴(kuò)展,主要用來(lái)解決應(yīng)用架構(gòu)上的容量問(wèn)題。由于單臺(tái)服務(wù)器能支撐的服務(wù)能力始終是有限的,所以我們?cè)诩軜?gòu)上就必須做到能夠支持橫向服務(wù)能力的擴(kuò)展。最典型的橫向擴(kuò)展是Web/API接人層,它在支持1億PV和10億PV時(shí)所需要的服務(wù)器數(shù)量必然是完全不一樣的,因此要考慮當(dāng)服務(wù)器不夠用時(shí),它也能支撐PV的無(wú)限增長(zhǎng)。因此這兩層~般都屬 于無(wú)狀態(tài)的服務(wù)。

        縱向擴(kuò)展,主要解決業(yè)務(wù)的擴(kuò)展問(wèn)題。當(dāng)業(yè)務(wù)不斷擴(kuò)展時(shí),業(yè)務(wù)邏輯的復(fù)雜度也會(huì)不斷上升,所以在架構(gòu)上要能根據(jù)功能的劃分進(jìn)行縱向?qū)哟蔚膭澐帧@?,Web/API層只做頁(yè)面邏輯或者展示數(shù)據(jù)的封裝,服務(wù)層做業(yè)務(wù)邏輯的封裝等。業(yè)務(wù)邏輯層還可以劃分成更多的層次,以支持更細(xì)的業(yè)務(wù)的組合。
         
        一個(gè)典型的分布式網(wǎng)站架構(gòu)。它將用戶的請(qǐng)求通過(guò)負(fù)載均衡隨機(jī)分配給一臺(tái)Web機(jī)器,Web機(jī)器再通過(guò)遠(yuǎn)程調(diào)用請(qǐng)求服務(wù)層。但是數(shù)據(jù)層一般都是有狀態(tài)的,而數(shù)據(jù)要做到分布式化,就必須保證數(shù)據(jù)的一致性。要保證數(shù)據(jù)的一一致性,一般都需要對(duì)最細(xì)粒度的數(shù)據(jù)做單寫控制,因此要記錄數(shù)據(jù)的狀態(tài)、做好數(shù)據(jù)的訪問(wèn)控制等。
         
        一個(gè)有狀態(tài)的分布式架構(gòu)。分布式集群中-一般都有一個(gè)Master負(fù)責(zé)管理集群中所有機(jī)器的狀態(tài)和數(shù)據(jù)訪問(wèn)的規(guī)制等,為了保證高可用Master也有備份,Master通常會(huì)把訪問(wèn)的路由規(guī)則推給實(shí)際的請(qǐng)求發(fā)起端,這樣Client就可以直接和實(shí)際要訪問(wèn)的節(jié)點(diǎn)通信了,避免中間再經(jīng)過(guò)一層代理。
         
        還有一種分布式架構(gòu)是非Master-Slave模式而是Leader 選舉機(jī)制,即分布式集群中沒(méi)有單獨(dú)的Master角色,每個(gè)節(jié)點(diǎn)功能都是一樣的,但是在集群的初始化時(shí)會(huì)選取一個(gè)Leader承擔(dān)Master的功能。一旦該Leader失效,集群會(huì)重新選擇一個(gè)Leader。這種方式的好處是不用單獨(dú)考慮Master的節(jié)點(diǎn)的可用性,但是也會(huì)增加集群維護(hù)的復(fù)雜度。
         
        (1)需要分布式中間件
        從前面典型的分布式架構(gòu)上可以看出,要搭建一個(gè)分布式應(yīng)用系統(tǒng)必須要有支持分布式架構(gòu)的框架。例如首先要有一個(gè)統(tǒng)一的負(fù)載均衡系統(tǒng)( LB/LVS )幫助平均分配外部請(qǐng)求的流量,將這些流量分配到后端的多臺(tái)機(jī)器上,這類設(shè)備一般都是工作在第四層,只做鏈路選擇而不做應(yīng)用層解析;應(yīng)用層的負(fù)載均衡可以通過(guò)HA來(lái)實(shí)現(xiàn),例如可以根據(jù)請(qǐng)求的URL或者用戶的Cookie精準(zhǔn)地調(diào)度流量。


        請(qǐng)求到達(dá)服務(wù)層,就需要解決服務(wù)之間的系統(tǒng)調(diào)用了。這時(shí),需要在服務(wù)層構(gòu)建一個(gè)典型的分布式系統(tǒng),包括同步調(diào)度的分布式RPC框架、異步調(diào)度的分布式消息框架和解決靜態(tài)配置信息的分布式配置框架。這三個(gè)分布式框架就像人體的骨骼和經(jīng)絡(luò),把整個(gè)服務(wù)層連接起來(lái)。我們會(huì)在后面詳細(xì)介紹這三個(gè)典型的分布式框架(分布式框架的開源產(chǎn)品有很多,例如Dubbo、RocketMQ等)。


        請(qǐng)求到達(dá)數(shù)據(jù)層。數(shù)據(jù)層需要解決以下問(wèn)題:第一,屏蔽不同數(shù)據(jù)庫(kù)的差異性,使底層數(shù)據(jù)庫(kù)的切換不影響上次應(yīng)用代碼;第二,屏蔽應(yīng)用層代碼對(duì)數(shù)據(jù)分布的感知,使對(duì)數(shù)據(jù)的分區(qū)或者分片不會(huì)影響應(yīng)用代碼的編寫。由于般來(lái)說(shuō)數(shù)據(jù)層都是有狀態(tài)的,所以用數(shù)據(jù)層解決分布式問(wèn)題會(huì)更復(fù)雜、難度也更大。開源的DRDS等都是用于解決這類問(wèn)題的。
         
        (2)服務(wù)化和分布式化
        我們?cè)诰W(wǎng)站升級(jí)中一般會(huì)接觸到兩個(gè)概念:一是服務(wù)化改造;二是分布式化改造。那么它們是一回事嗎?


        服務(wù)化改造更多是從業(yè)務(wù)架構(gòu)的角度出發(fā),目的是將業(yè)務(wù)做更細(xì)粒度的功能拆分,使業(yè)務(wù)邏輯更加清晰、邊界更加清楚且易于維護(hù);服務(wù)化的另一個(gè)好處是收斂業(yè)務(wù)邏輯,通過(guò)接口標(biāo)準(zhǔn)化提供統(tǒng)一-的訪問(wèn)方式。 分布式化更多是從網(wǎng)站制作系統(tǒng)架構(gòu)層面的角度出發(fā),更多是看請(qǐng)求的訪問(wèn)路徑,即一個(gè)請(qǐng)求必須先訪問(wèn)什么再訪問(wèn)什么、一次訪問(wèn)要經(jīng)過(guò)哪些步驟才能最終有結(jié)果等...因此,這是兩個(gè)不同層面的工作。

        ?