1.4 互聯網架構方法論

1.4.1 CAP模型

1.CAP理論

CAP是指任何分布式系統在可用性、一致性、分區容錯性方面，不能兼得，最多只能得其二，因此，任何分布式系統的設計只是在三者中的不同取舍而已，如圖1-1所示。

■ C指Consistency，即一致性。一致性被稱為原子對象，任何讀寫都應該看起來是“原子”的或串行的。寫后面的讀一定能讀到前面寫的內容，所有的讀寫請求都好像被全局排序。即更新操作成功并返回客戶端完成后，所有節點在同一時間的數據完全一致。

■ A指Availability，即可用性。對任何非失敗節點都應該在有限時間內給出請求的回應。

■ P指Partition tolerance，即分區容錯性。允許節點之間丟失任意多的消息，當網絡分區發生故障時，節點之間的消息可能會完全丟失。即分布式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。

2.CAP的證明

2009年，CAP理論的提出者Brewer給出了一個比較簡單的證明（見http://www.julianbrowne.com/article/brewers-cap-theorem）。

網絡中有兩個節點N₁和N₂，可以簡單地理解N₁和N₂分別是兩臺計算機，它們之間的網絡可以連通。N₁中有一個應用程序A和一個數據庫V，N₂中也有一個應用程序B和一個數據庫V。現在，A和B是分布式系統的兩個部分，V是分布式系統的數據存儲的兩個子數據庫。

如圖1-2所示，分布式系統正常運轉的流程為，用戶向N₁機器請求數據更新，程序A更新數據庫V₀為V₁，分布式系統將數據進行同步操作M，將V₁同步到N₂中的V₀，使得N₂中的數據V₀也更新為V₁，N₂中的數據再響應N₂的請求。

如圖1-3所示，假設在N₁和N₂之間網絡斷開的時候，有用戶向N₁發送數據更新請求，N₁中的數據V₀將被更新為V₁，由于網絡是斷開的，所以分布式系統同步操作M失敗，N₂中的數據依舊是V₀。這個時候，有用戶向N₂發送數據讀取請求，由于數據還沒有進行同步，應用程序沒辦法立即給用戶返回最新的數據V₁，此時有兩種選擇：第一，犧牲數據一致性，響應舊的數據V₀給用戶；第二，犧牲可用性，阻塞等待，直到網絡連接恢復，數據更新操作M完成之后，再給用戶響應最新的數據V₁。

這個過程證明，要滿足分區容錯性的分布式系統，只能在一致性和可用性兩者中選擇一個。

3.CAP理論的演化

CAP理論的主要貢獻者是Brewer和Lynch。CAP理論也是在辯論過程中不斷演化的，對CAP與分布式事務，CAP與響應時間的關系等概念不斷完善。

2012年，Brewer就CAP理論再次撰文《CAP Twelve Years Later：How the"Rules"Have Changed》，文章最主要的觀點是CAP理論并不是說三者必須選擇兩者。首先，只要是分布式系統，就可能存在分區，但分區出現的概率是很小的（否則就需要優化網絡或者硬件），CAP在大多數時候允許完美的C和A，只有在分區存在的時間段內，才需要在C與A之間權衡。其次，一致性和可用性都是一個度的問題，不是0或者1的問題，可用性可以在0%到100%之間連續變化，一致性分為很多級別（比如在Cassandra中，可以設置consistency level）。因此，當代CAP實踐的目標應該是針對具體的應用，在合理范圍內最大化提升數據一致性和可用性。文章中還指出，分區是一個相對的概念，當超過了預定的通信時限，即系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。

4.CAP的應用

CAP有三種組合模式，不同的組合模式適用于不同的業務場景。

（1）CA：優先保證一致性和可用性，放棄分區容錯。如果不要求P（分區容錯），則C（強一致性）和A（可用性）是可以保證的。這也意味著放棄系統的擴展性，系統不再是分布式的。如MySQL和Oracle就保證了可用性和數據一致性，但它們并不是分布式系統。其實分區錯誤始終會存在，無法通過降低CA來提升P，要想提升系統的分區容錯性，需要通過提升基礎設施的穩定性來保障。

2013年Lior Messinger在其文章《Better Explaining the Cap Theorem》中指出：在分布式系統中，網絡分區一定會發生，因此僅需要在A和C之間權衡，即“it is really just A vs C！”。

（2）CP：優先保證一致性和分區容錯性，放棄可用性。如果不要求A（可用），相當于每個請求都需要在節點之間強一致，而P（分區容錯）會導致同步時間無限延長，如此CP是可以保證的。很多傳統的數據庫分布式事務都屬于這種模式，在數據一致性要求比較高的場合是比較常見的做法，一旦發生網絡故障或者消息丟失，就會犧牲用戶體驗，等恢復之后用戶才逐漸能訪問。

HBase是一個強一致性數據庫，不是“最終一致性”數據庫，在HBase的官方文檔Architecture Overview中有說明（見https://hbase.apache.org/book.html#arch.timelineconsistent.reads）。

ZooKeeper是CP（一致性+分區容錯性）的，即任何時刻對ZooKeeper的訪問請求都能得到一致的數據結果，同時系統對網絡分區具備容錯性。但是它不能保證每次服務請求的可用性，也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果。ZooKeeper是分布式協調服務，它的職責是保證數據在其管轄下的所有服務之間保持同步、一致。所以就不難理解為什么ZooKeeper被設計成CP而不是AP特性的了。

（3）AP：優先保證可用性和分區容錯性，放棄一致性。一旦分區錯誤發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。NoSQL中的Cassandra就是這種架構。與CP一樣，放棄一致性不是說一致性就不保證了，而是逐漸變得一致。

對于多數大型互聯網應用場景來說，集群規模大，節點故障、網絡故障是常態，而且要保證服務可用性達到N個9，所以業務要設計成AP，舍棄C，退而求其次保證最終一致性。比如在電商秒殺活動中，當購買的時候提示有庫存（實際可能已經沒庫存了），當去支付時，系統再提示庫存不足。這其實就是先在可用性方面保證系統可以正常服務，然后在數據的一致性方面做了犧牲。在用戶可以接受的前提下，網站舍棄的只是強一致性，退而求其次保證了最終一致性。下單的瞬間，庫存可能存在數據不一致的情況，過程中對用戶體驗產生了影響，但是過了一段時間，還是要保證最終一致性的。

5.BASE理論

eBay的架構師Dan Pritchett源于對大規模分布式系統的實踐總結，提出BASE理論，BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用可以采用適合的方式達到最終一致性（Eventual Consistency）。

BASE是指基本可用（Basically Available）、軟狀態（Soft State）、最終一致性（Eventual Consistency）。

基本可用：基本可用是指分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。電商大促時，為了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務，這就是損失部分可用性的體現。

軟狀態：軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分布式存儲中，一般一份數據至少有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。

最終一致性：最終一致性是指系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。

6.ACID

關系型數據庫的事務操作遵循ACID原則，ACID原則是指在寫入/異動資料的過程中，為保證交易正確可靠而必須具備的四個特性，即原子性（Atomicity，又稱不可分割性）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）和持久性（Durability）。

原子性，即在事務中執行的多個操作是原子性的，要么事務中的操作全部執行，要么一個都不執行。

一致性，即保證進行事務的過程中整個數據庫的狀態是一致的，不會出現數據不一致的情況。

隔離性，即兩個事務不會相互影響，覆蓋彼此數據等。

持久性，即事務一旦完成，那么數據應該被寫到安全的、持久化存儲的設備上（比如磁盤）。

1.4.2 AKF Scale Cube擴展立方體

AKF Partners公司提出了Scale Cube，也就是AKF擴展立方體模型，是對應用橫向擴展、縱向擴展理論的完整性的總結。這是一個包含X，Y，Z軸的三維模型（見https://akfpartners.com/growth-blog/scale-cube）。AKF擴展立方體理論模型如圖1-4所示。

（1）X軸擴展

水平復制，復制同樣的工作或數據鏡像給多個實體，通過克隆的方式水平擴展。一般是在負載均衡后面放置多個相同的應用服務，如果有N個相同的應用部署，那么每個單獨的應用只需要處理1/N份的負載請求。優點是簡單易擴展。缺點是當單體應用本身的復雜性提高時所帶來的管理及運維挑戰，例如針對特定事件的處理需要對整個應用進行發布部署，同時數據庫的水平復制存在挑戰。

（2）Y軸擴展

功能分解，拆分不同的事務進行擴展。針對X軸擴展產生的問題，從Y軸這個方向擴展，將巨型應用拆解，分解為一組不同的服務，把分割的工作職責和數據分配給多個實體，這也是微服務理論誕生的基礎。例如將購物應用分解為購物車服務、訂單服務、支付服務等。優點是服務拆解以后便于維護和有針對性的擴展。缺點是按功能拆解以后，服務數量增多，部署成本增高；服務與服務之間調用傳輸成本增高；由內存調用轉變為網絡傳輸，故障率增高。

（3）Z軸擴展

數據分區，是指按照客戶的需求、位置或者價值分割或分配工作職責，一般來說就是對數據的擴展，將事務產生的數據按照一定的特征分區在不同的服務器上。如按照客戶ID進行分庫分表。優點是對數據進行隔離，不同數據的請求被分發到不同的服務器上。缺點是Z軸擴展是所有擴展中復雜度最高的。

從傳統的巨大的單體結構到如今面向服務的去IOE的架構，互聯網核心架構的演變和發展就是在不斷應用AKF擴展立方體模型。

三種擴展方式可以根據需要組合使用，但一定要選擇與應用規模相符合的架構，例如一個面向小企業的企業內部信息系統就沒必要進行Y軸擴展。