應用現狀比較
由於歷史原因，集中式架構多用於傳統銀行、電信等行業。主機資源集中在大型主機或小型機上。集中式架構下，包括操作系統，中間件，數據庫等“基礎軟件” 均爲閉源商用系統。集中式架構的典型案例是 IOE（IBM， Oracle，EMC）提供的計算設備、數據庫技術和存儲設備共同組成的系統。
近年來，分佈式架構在 Google、 Amazon、Facebook、阿里巴巴、騰訊等互聯網公司廣泛應用基礎上、也越來越多被金融行業關注和應用。分佈式架構一般採用性價比更高的 PC 服務器、分佈式數據庫和大量 PC 內存閃存，程序同時運行在衆多 PC 服務器上。
核心對比
以下是兩種架構的核心要素的對比分析：
業務支撐能力
客觀講，分佈式架構在價格成本、自主研發、靈活兼容、伸縮擴展方面有比較顯著的優勢。互聯網行業具有請求量大，數據量大的特點，業務上又可能在集中的時間段出現高於日常流量數倍的業務高峯，這些特徵對架構的可擴展性提出了極高的要求。
在集中式架構下，爲了應對更高的性能，更大的數據量，往往只能向上升級到更高配置的機器，如升級更強的 CPU，升級多核，升級內存，升級存儲等，一般這種方式被稱爲 Scale Up，但單機的性能永遠都有瓶頸,隨着業務量的增長，只能通過 Scale Out 的方式來支持，即橫向擴展出同樣架構的服務器。在集中式架構下，由於單個服務器的造價昂貴，所以 Scale Out 的方式成本非常高，無法做到按需擴展。而分佈式架構的解決方案是基於廉價的 PC Server 來做 Scale Out, 藉助高速網絡組建的 PC 集羣在整體上提供的計算能力已大幅高於傳統主機，並且成本很低，橫向的擴展性還可帶來系統良好的成長性。
螞蟻金服通過幾年架構演進，已經從初級的服務器可擴展、數據層可擴展發展到 IDC 層面的可擴展。一旦採用了分佈式架構，天然支持按需擴展，唯一的要求是在設計上保持每個應用節點不保存狀態信息。隨着業務量從幾百筆/秒到幾萬筆/秒級別時，需要更多的服務器來支撐，數據庫單表的性能會成爲瓶頸。數據量也會從 GB 迅速飆升到 TB、PB，單數據庫實例的容量也會成爲瓶頸。數據層會採用分庫分表的策略來支持業務量的增長,具體策略根據業務場景可分爲垂直拆分（按業務）、水平拆分（按請求/用戶做哈希，或者做區間拆分）、讀寫拆分等。最後會通過統一分佈式數據訪問組件來屏蔽數據擴展的複雜性。下圖簡單描繪了服務器擴展性（應用層）和數據層可擴展（持久層）的形態：
隨着業務的發展，應用和數據層彈性伸縮也會受限於到單個機房的電力、面積、散熱等物理條件的制約而無法 Scale Out，同城的機房個數也是有限的，所以勢必要從機房層面支持彈性的可伸縮。螞蟻的業務規模早在兩年前就已突破這個規模， 因此進行了機房單元化改造，其架構核心思想是把數據水平拆分的思路向上提升到接入層、終端層。從接入層開始，把原來部署在一個 IDC 中的系統集羣，進一步分成多個更細粒度的部署單元，從而達到機房級別的擴展。這種機房架構在容災方面的優勢會在第五個小節中展開說明。下面爲這種架構的示意圖：
下表總結了兩種架構模式在業務支撐的幾個方面的比較：
兩種架構的可用性和一致性比較
從架構設計來看，集中式系統的計算、存儲都在一套硬件體系內，無需面對網絡分區（網絡無法連接）問題，能很容易實現高一致性，並通過存儲的冗餘和軟硬件結合的高度優化，達到了較高的可靠性。但在可用性方面，由於集中式架構在設計上是一個單點，單機不可用即全部不可用，所以集中式的系統只能在停機維護時暫停業務，這一點在很多互聯網場景下是難以接受的。分佈式架構設計，天然就有多個節點，很容易通過主備（HA）、冗餘、哈希等手段實現計算和存儲冗餘備份，從而實現高可用。
當然，軟件領域沒有銀彈，分佈式架構多個節點的設計也帶來了保持一致性和高可靠性上的巨大挑戰。2000 年，加州大學伯克利分校計算機教授 Eric Brewer 提出了著名的 CAP 理論，任何基於網絡的數據共享系統（即分佈式系統）最多隻能滿足數據一致性（Consistency）、可用性（Availability）和網絡分區容忍（Partition Tolerance）三個特性中的兩個。在大規模的分佈式環境下，網絡故障是常態，所以網絡分區是必須容忍的現實，只能在可用性和一致性兩者間做出選擇，即 CP 模型或者 AP 模型，實際的選擇需要通過業務場景來權衡。
對於一些離線的應用，或者對可用率不敏感的業務，可以適當犧牲可用性來保證強一致，即採用 CP 模型，這樣會大大簡化設計，系統具備不可用的發現和恢復機制就能讓系統保持正常的運轉，純粹的 CP 模型還是比較簡單，但適用場景也非常有限，真正複雜的還是 AP 模型。
在金融行業中，尤其是互聯網金融系統，保證提供連續可靠的服務尤爲重要，長時間的業務中斷會引發各種社會問題，影響到生活的方方面面，所以，必須考慮如何在採用 AP 模型的時候儘可能保證一致性（Consistency）。關於一致性，不是隻有 0 或者 1，是可以有程度的細分，一般可分爲強一致性、弱一致性和最終一致性。達成什麼程度的一致性，可以從客戶端和服務端兩個視角來分析。從客戶端來看，一致性主要指的是多併發訪問時更新過的數據如何獲取的問題。在支付寶系統中，爲保證性能，業務數據被垂直和水平拆分到多個數據源中，一次典型的轉賬操作，會在借貸雙方的數據庫中分別進行存入和扣除操作，螞蟻技術團隊借鑑了BASE理論（Basically Available, Soft State, Eventual Consistency 基本可用、軟狀態、最終一致性），設計了基於 TCC（Try Confirm Cancel）模型的兩階段的柔性事務框架，在保證單機事務的 ACID 原則的前提下，確保全局分佈式事務的最終一致性，在保證用戶體驗（性能）的前提下，讓客戶感受到了一致性，並向用戶屏蔽了短暫不一致（故障或者延遲）的恢復細節，滿足了業務上對一致性的要求。以下爲分佈式事務框架的模型示意圖：
圖 4 柔性事務框架原理圖
爲了保證高可用和業務連續性，分佈式系統的存儲往往會設計成多份冗餘，並儘可能在機架、機房甚至城市維度將冗餘的數據分散在多處。所以從服務端角度看，最關心一致性問題是如何儘快將更新後的數據分佈到整個系統，降低達到最終一致性的時間窗口。Paxos 協議就是一種在保證強一致性前提下把可用性優化到極限的算法。螞蟻金服自主研發設計的 OceanBase 數據庫就將數據存在多份存儲上，每個存儲都分佈在不同機房，任何一份存儲出問題，都不影響全局的可用性。爲保證這種高可用架構下的一致性， OceanBase 在多份存儲的寫入過程中，就用到了 Paxos 協議，並針對各種具體場景，對協議做了優化和改進。詳細的設計和說明可參考 OB 的資料。
下表列出了兩種架構的具體案例和相關的技術產品，支付寶的架構體系也經歷了從集中式到分佈式的演進。
兩種架構的運維複雜度和故障恢復能力比較
集中式架構部署結構簡單，設備數量少，在運維複雜度上較分佈式架構有天然的優勢。分佈式架構隨着機器數量的線性增長，複雜性也隨之增長，無法通過簡單的工具和腳本來支撐。這個複雜度包含了發佈部署、系統監控和故障恢復等幾個方面，下面會逐一對比。
集中式的發佈部署一般只需應對百臺內規模的代碼/配置更新，通過簡單的腳本或者平臺就可以自動化完成，發佈時間一般也能控制在小時級別。而且採用集中式架構的系統一般比較穩定，發佈週期也不會太頻繁。在分佈式環境下，千臺甚至萬臺服務器的規模很常見，如果按照傳統的串行操作和自動化腳本，整個發佈週期會非常長，一旦出現問題，回滾也會非常慢。在分佈式架構下，往往需要提供 P2P 分發或類似的技術手段來加速發佈過程，同時通過 beta 發佈、分組發佈、藍綠髮布等手段來解決大規模集羣下的發佈驗證、灰度引流和快速回滾等問題。螞蟻金服在發展過程中，整個運維體系也隨着業務規模的增長而升級演進，逐步形成了一套完整的運維管控平臺，支持單人運維千臺服務器，避免了分佈式架構下運維複雜度的增長。
在系統監控方面，集中式架構比較簡單。而在分佈式環境下做監控，主要挑戰在於海量日誌的實時分析和秒級展示。系統運行的狀態分散在上萬臺規模的集羣中，每時每刻都在產生新的狀態。監控系統需要通過日誌或者消息的方式採集整個集羣的數據做各種統計分析。在巨大的業務量下，每晚一秒鐘發現問題就會帶來大量的業務異常，在極端情況下還會產生不可估量的損失。因此，也需要監控體系具備秒級的實時計算能力。螞蟻金服也逐步沉澱這樣一套監控平臺，很好的彌補了分佈式環境下監控的劣勢，是整個平臺穩定運行的基石。
在系統的容災機制和故障恢復方面，集中式架構一般會採用主備複製和主備切換的方式來實現，幾種典型設計原則包括一主多備，同城雙活，兩地三中心等。集中式的容災方案比較成熟，也沉澱了數據複製、鏡像快照、一體化遷移等一系列容災相關的技術，可以從容應對各種場景，但仍然在以下幾個方面存在不足：
-
成本較高：在集中式架構下，經典的災備方案一般會做全量備份，在一些改進方案中會通過餘量空間做交叉互備等方式來降低成本，但整體上看還成本還是較高。爲 1% 甚至概率更低的災難場景，而付出與支撐當前業務量相等的成本，這對需要承載海量業務的互聯網業務來說更是一個巨大的負擔；
-
恢復時間較長：災備方案中大量用到數據複製技術，但由於網絡帶寬或者異地延遲等問題，在恢復時，需要等待數據完全一致後才能切換，而且無論備份數據是冷備還是熱備，切換都有一個預熱的過程。綜合切換複雜度和上述的技術限制等因素，很難縮短恢復時間。
-
業務影響面較大：由於集中式架構本身擴展性的不足，所有業務都跑在一個單點上，一旦發生故障就可能影響到所有用戶。在承載海量業務的系統上，這種影響更容易被放大，尤其在金融系統上，更有可能引發一些社會事件。
雖然在運維和監控複雜度方面在分佈式系統需要通過技術手段來彌補天然的不足，但在容災恢復方面卻有着天然的優勢。數據天然分佈在不同的存儲、機房和城市，而且架構上容易按合適的容量進行水平拆分。隨着這幾年互聯網的高速發展，各家互聯網公司都遇到了集中式架構下災備方案的幾個痛點，並進行了類似的架構改造，一般業界稱之爲單元化改造，其本質是將分佈式下可擴展的特性運用到災備場景，這個在第四章節中有提到。這種架構能將業務影響面控制在一定的範圍內（取決於單元的大小），並通過交叉互備降低災備成本，這種機房架構下的邏輯單元具備以下三個特徵：
1. 每個單元在業務處理能力上自包含，對外承載一定業務分片的業務流量，內部的系統調用鏈路和各類存儲訪問是局部化在本單元內的；
2. 每個單元的實時數據是獨立不共享的，配置類數據或讀多寫少且對延時性要求不高的數據全局共享；
3. 單元間的通信統一管控，儘量以異步化消息進行通信，同步調用則通過單元間代理方案實現，實現網絡上的收斂，便於監控和管控。
該架構解決了以下四個關鍵問題：
1. 由於儘量減少了跨單元交互和使用異步化，使得異地部署成爲可能。整個系統的水平可伸縮性大大提高，不再依賴同城 IDC ，真正實現異地多活架構；
2. 可以實現 N+1 的異地災備策略，大大縮減災備成本，同時確保災備設施真實可用；
3. 整個系統已無單點存在，大大提升了整體的高可用性；同城和異地部署的多個單元可用作互備的容災設施，通過運維管控平臺進行快速切換，有機會實現 100% 的持續可用率；
4. 該架構下業務級別的流量入口和出口形成了統一的可管控、可路由的控制點，整體系統的可管控能力得到很大提升。基於該架構，線上壓測、流量管控、灰度發佈等以前難以實現的運維管控模式，現在能夠十分輕鬆地實現。
下圖爲該架構的示意圖，表格中則總結了兩種架構在運維和容災方面的對比。
圖 5 單元化架構災備切換示意圖
小結
通過上述對集中式和分佈式架構在業務支撐、一致性/可用性、運維成本/故障恢復三個方面的分析發現，分佈式架構在經濟性、安全自主、靈活性、可伸縮性等方面有明顯優勢，隨着金融系統需要處理的交易量與數據量越來越大，分佈式架構在這方面的優勢也會越來越明顯。集中式系統在可維護性、一致性方面有優勢，而分佈式系統需要達到同等或更高的可維護性與高一致性，需要通過先進的分佈式中間件與大規模運維平臺來支持。螞蟻金服的通過自身的實踐，證明分佈式系統是能夠實現金融業務所需要的高一致性與可維護性的，並且將這種技術沉澱到了螞蟻金融雲計算平臺上，支撐合作伙伴更好地運用分佈式架構和雲計算的能力，共同用新技術的力量推進普惠金融的發展。