架構的演進過程
1、業務簡單、系統功能單一、訪問量小的場景下：單節點web應用架構。
2、業務和系統功能相對複雜、訪問量較大的場景下：Nginx負載的多web節點集羣架構。
3、業務複雜、系統龐大、訪問量巨大的場景下：分佈式微服務架構。
分佈式架構的特點
分佈性
對等性
併發性
缺乏全局時鐘
故障隨時會發生
分佈式架構中存在的問題
通信異常：
通訊異常其實就是網絡異常，網絡系統本身是不可靠的，由於分佈式系統需要通過網絡進行數據傳輸，網絡光纖，路由器等硬件難免出現問題。只要網絡出現問題，也就會影響消息的發送與接受過程，因此數據消息的丟失或者延長就會變得非常普遍。
網絡分區：
網絡分區，俗稱“腦裂現象”，是指集羣中本來只有一個領導者，但由於通信異常，導致某一區域自行推舉出另外一個領導，兩個領導互爲衝突。
三態：
通常情況下，方法執行的結果是一個明確的響應，要麼成功，要麼失敗。而在分佈式的場景下，會出現以一種除成功和失敗以外的第三種狀態—超時態。雖然絕大多數的情況下能夠接受到成功或失敗的響應，但網絡一旦出現異常，就非常有可能超時，這時請求的發起方是無法確定請求是否處理成功的。
節點故障：
組成分佈式集羣的節點機器比較多，節點出現宕機或“僵死”的現象會經常發生。
分佈式協調理論
CAP理論
C 一致性(Consistency)：在分佈式系統中，一致性是數據在多個副本之間是否能夠保證一致的特性。
A 可用性(Availability)：系統收到請求後，一定給出響應。
P 分區容錯性(Partition tolerance)：大多數分佈式系統都分佈在多個子網絡。每個子網絡就叫做一個區（partition）。分區容錯的意思是，區間通信可能失敗。比如，一臺服務器放在中國，另一臺服務器放在美國，這就是兩個區，它們之間可能無法通信。
一個分佈式系統不可能同時滿足一致性、可用性、分區容錯性這三個基本需求，最多隻能夠滿足其中兩項。由於分佈式系統中P總是成立，所以架構師的精力往往集中在根據業務場景，尋求A和C的平衡。
| 序號 | 被放棄的 | 說明 |
|---|---|---|
| 1 | 放棄Ｐ（滿足AC） | 將數據和服務都放在一個節點上，避免由於網路問題引起的負面影響，充分保證一致性和可用性。放棄P意味着放棄系統的擴展性。 |
| 2 | 放棄A（滿足CP） | 當節點故障或網絡故障時，受影響的服務需要等待一段時間才能恢復響應，在此期間系統無法對外提供正常服務。 |
| 3 | 放棄C（滿足AP） | 系統無法保證數據的實時一致性，但是承諾數據最終會保持一致性。因此存在數據不一致的窗口期，窗口期時間的長短取決於系統設計。 |
BASE理論
即使無法做到強一致性，但分佈式系統可以根據自己的業務特點，採用適當的方式來使系統達到最終的一致性。
Basically Avaliable 基本可用：當分佈式系統出現不可預見的故障時，允許損失部分可用性，保障系統的“基本可用”；體現在“時間上的損失”和“功能上的損失”；如：部分用戶雙十一高峯期淘寶頁面卡頓或降級處理；
Soft state 軟狀態：允許系統中的數據存在中間狀態，既系統的不同節點的數據副本之間的數據同步過程存在延時，並認爲這種延時不會影響系統可用性；如：12306網站賣火車票，請求會進入排隊隊列。
Eventually consistent 最終一致性：所有的數據在經過一段時間的數據同步後，最終能夠達到一個一致的狀態；如：理財產品首頁充值總金額短時不一致；
分佈式協調一致性的算法
| 序號 | 算法 | 說明 |
|---|---|---|
| 1 | 2p/3p | 2P兩階段提交，數據分佈式事務經常使用的一種分佈式算法，算法簡單，但會出現阻塞，數據在某種情況下不一致的問題。 3P對2P進行了完善。 |
| 2 | paxos | 分佈式一致性算法，分爲兩階段，遵循少數服從多數的原則，並不需要所有參與者都同意某一協議。 |
| 3 | zab | 借鑑paxos的思想，是zookeeper解決分佈式一致性所使用的算法。 |