橫向擴展，主要用來解決應用架構上的容量問題。由于單臺服務器能支撐的服務能力始終是有限的，所以我們在架構上就必須做到能夠支持橫向服務能力的擴展。最典型的橫向擴展是Web/API接人層，它在支持1億PV和10億PV時所需要的服務器數(shù)量必然是完全不一樣的，因此要考慮當服務器不夠用時，它也能支撐PV的無限增長。因此這兩層~般都屬 于無狀態(tài)的服務。
縱向擴展，主要解決業(yè)務的擴展問題。當業(yè)務不斷擴展時，業(yè)務邏輯的復雜度也會不斷上升，所以在架構上要能根據(jù)功能的劃分進行縱向層次的劃分。例如，Web/API層只做頁面邏輯或者展示數(shù)據(jù)的封裝，服務層做業(yè)務邏輯的封裝等。業(yè)務邏輯層還可以劃分成更多的層次，以支持更細的業(yè)務的組合。
一個典型的分布式網站架構。它將用戶的請求通過負載均衡隨機分配給一臺Web機器，Web機器再通過遠程調用請求服務層。但是數(shù)據(jù)層一般都是有狀態(tài)的，而數(shù)據(jù)要做到分布式化，就必須保證數(shù)據(jù)的一致性。要保證數(shù)據(jù)的一一致性，一般都需要對最細粒度的數(shù)據(jù)做單寫控制，因此要記錄數(shù)據(jù)的狀態(tài)、做好數(shù)據(jù)的訪問控制等。
一個有狀態(tài)的分布式架構。分布式集群中-一般都有一個Master負責管理集群中所有機器的狀態(tài)和數(shù)據(jù)訪問的規(guī)制等，為了保證高可用Master也有備份，Master通常會把訪問的路由規(guī)則推給實際的請求發(fā)起端，這樣Client就可以直接和實際要訪問的節(jié)點通信了，避免中間再經過一層代理。
還有一種分布式架構是非Master-Slave模式而是Leader 選舉機制，即分布式集群中沒有單獨的Master角色，每個節(jié)點功能都是一樣的，但是在集群的初始化時會選取一個Leader承擔Master的功能。一旦該Leader失效，集群會重新選擇一個Leader。這種方式的好處是不用單獨考慮Master的節(jié)點的可用性，但是也會增加集群維護的復雜度。
(1)需要分布式中間件
從前面典型的分布式架構上可以看出，要搭建一個分布式應用系統(tǒng)必須要有支持分布式架構的框架。例如首先要有一個統(tǒng)一的負載均衡系統(tǒng)( LB/LVS )幫助平均分配外部請求的流量，將這些流量分配到后端的多臺機器上，這類設備一般都是工作在第四層，只做鏈路選擇而不做應用層解析；應用層的負載均衡可以通過HA來實現(xiàn)，例如可以根據(jù)請求的URL或者用戶的Cookie精準地調度流量。
請求到達服務層，就需要解決服務之間的系統(tǒng)調用了。這時，需要在服務層構建一個典型的分布式系統(tǒng)，包括同步調度的分布式RPC框架、異步調度的分布式消息框架和解決靜態(tài)配置信息的分布式配置框架。這三個分布式框架就像人體的骨骼和經絡，把整個服務層連接起來。我們會在后面詳細介紹這三個典型的分布式框架(分布式框架的開源產品有很多，例如Dubbo、RocketMQ等)。
請求到達數(shù)據(jù)層。數(shù)據(jù)層需要解決以下問題:第一，屏蔽不同數(shù)據(jù)庫的差異性，使底層數(shù)據(jù)庫的切換不影響上次應用代碼；第二，屏蔽應用層代碼對數(shù)據(jù)分布的感知，使對數(shù)據(jù)的分區(qū)或者分片不會影響應用代碼的編寫。由于般來說數(shù)據(jù)層都是有狀態(tài)的，所以用數(shù)據(jù)層解決分布式問題會更復雜、難度也更大。開源的DRDS等都是用于解決這類問題的。
(2)服務化和分布式化
我們在網站升級中一般會接觸到兩個概念:一是服務化改造；二是分布式化改造。那么它們是一回事嗎?
服務化改造更多是從業(yè)務架構的角度出發(fā)，目的是將業(yè)務做更細粒度的功能拆分，使業(yè)務邏輯更加清晰、邊界更加清楚且易于維護；服務化的另一個好處是收斂業(yè)務邏輯，通過接口標準化提供統(tǒng)一-的訪問方式。 分布式化更多是從網站制作系統(tǒng)架構層面的角度出發(fā)，更多是看請求的訪問路徑，即一個請求必須先訪問什么再訪問什么、一次訪問要經過哪些步驟才能最終有結果等...因此，這是兩個不同層面的工作。
本文地址：http://www.khwajamoinuddinchishty.com//article/4456.html
