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