橫向擴展，主要用來解決應用架構上的容量問題。由于單臺服務器能支撐的服務能力始終是有限的，所以我們在架構上就必須做到能夠支持橫向服務能力的擴展。最典型的橫向擴展是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)服務化和分布式化
我們在網站升級中一般會接觸到兩個概念:一是服務化改造；二是分布式化改造。那么它們是一回事嗎?
服務化改造更多是從業務架構的角度出發，目的是將業務做更細粒度的功能拆分，使業務邏輯更加清晰、邊界更加清楚且易于維護；服務化的另一個好處是收斂業務邏輯，通過接口標準化提供統一-的訪問方式。 分布式化更多是從網站制作系統架構層面的角度出發，更多是看請求的訪問路徑，即一個請求必須先訪問什么再訪問什么、一次訪問要經過哪些步驟才能最終有結果等...因此，這是兩個不同層面的工作。
本文地址：http://123beaconmarketing.com//article/4456.html
