應用現狀比較
由于曆史原因，集中式架構多用于傳統銀行、電信等行業。主機資源集中在大型主機或小型機上。集中式架構下，包括作業系統、中間件、資料庫等“基礎軟體” 均為閉源商用系統。集中式架構的典型案例是 IOE（IBM、 Oracle、EMC）提供的計算裝置、資料庫技術和儲存設備共同組成的系統。
近年來，分布式架構在 Google、Amazon、Facebook、阿裡巴巴、騰訊等網際網路公司廣泛應用的基礎上，也被金融行業越來越多關注和應用。分布式架構一般采用成本效益更高的 PC 伺服器、分布式資料庫和大量 PC 記憶體閃存，程式同時運作在衆多 PC 伺服器上。
圖 1 集中式與分布式系統示意圖
核心要素比較
以下是兩種架構的核心要素對比分析：
表 1 集中式與分布式架構核心要素對比
業務支撐能力比較
客觀講，分布式架構在價格成本、自主研發、靈活相容、伸縮擴充方面有比較顯著的優勢。網際網路行業具有請求量大、資料量大的特點，業務上又可能在集中的時間段出現高于日常流量數倍的業務高峰，這些特征對架構的可擴充性提出了極高的要求。
在集中式架構下，為了應對更高的性能、更大的資料量，往往隻能向上更新到更高配置的機器，如更新更強的 CPU、更新多核、更新記憶體、更新存儲等，一般這種方式被稱為 Scale Up。但單機的性能永遠都有瓶頸，随着業務量的增長，隻能通過 Scale Out 的方式來支援，即橫向擴充出同樣架構的伺服器。
在集中式架構下，由于單個伺服器的造價昂貴，是以 Scale Out 的方式成本非常高，無法做到按需擴充。而分布式架構的解決方案是基于廉價的 PC Server 來做 Scale Out，借助高速網絡組建的 PC 叢集在整體上提供的計算能力已大幅高于傳統主機，并且成本很低，橫向的擴充性還可帶來系統良好的成長性。
螞蟻金服通過幾年架構演進，已經從初級的伺服器可擴充、資料層可擴充發展到 IDC 層面的可擴充。一旦采用了分布式架構，天然支援按需擴充，唯一的要求是在設計上保持每個應用節點不儲存狀态資訊。
随着業務量從幾百筆/秒到幾萬筆/秒級别時，需要更多的伺服器來支撐，資料庫單表的性能會成為瓶頸。資料量也會從 GB 迅速飙升到 TB、PB，單資料庫執行個體的容量也會成為瓶頸。
資料層會采用分庫分表的政策來支援業務量的增長，具體政策根據業務場景可分為垂直拆分（按業務）、水準拆分（按請求/使用者做哈希，或者做區間拆分）、讀寫拆分等，最後通過統一分布式資料通路元件來屏蔽資料擴充的複雜性。
下圖簡單描繪了伺服器擴充性（應用層）和資料層可擴充（持久層）的形态：
圖 2 應用層與資料層彈性伸縮架構示意圖
随着業務的發展，應用和資料層彈性伸縮也會受限于到單個機房的電力、面積、散熱等實體條件的制約而無法 Scale Out，同城的機房個數也是有限的，是以勢必要從機房層面支援彈性的可伸縮。
螞蟻的業務規模早在兩年前就已突破這個規模， 是以進行了機房單元化改造，其架構核心思想是把資料水準拆分的思路向上提升到接入層、終端層。
從接入層開始，把原來部署在一個 IDC 中的系統叢集，進一步分成多個更細粒度的部署單元，進而達到機房級别的擴充。這種機房架構在容災方面的優勢會在第五個小節中展開說明。
下面為這種架構的示意圖：
圖 3 單元化架構示意圖
下表總結了兩種架構模式在業務支撐的幾個方面的比較：
表 2 集中式與分布式架構業務支撐能力對比
可用性和一緻性比較
從架構設計來看，集中式系統的計算、存儲都在一套硬體體系内，無需面對網絡分區（網絡無法連接配接）問題，能很容易實作高一緻性，并通過存儲的備援和軟硬體結合的高度優化，達到了較高的可靠性。
但在可用性方面，由于集中式架構在設計上是一個單點，單機不可用即全部不可用，是以集中式的系統隻能在停機維護時暫停業務，這一點在很多網際網路場景下是難以接受的。分布式架構設計，天然就有多個節點，很容易通過主備（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 的資料。
下表列出了兩種架構的具體案例和相關的技術産品，支付寶的架構體系也經曆了從集中式到分布式的演進。
表 3 集中式和分布式可用性、一緻性和可靠性對比
運維複雜度和故障恢複能力比較
集中式架構部署結構簡單，裝置數量少，在運維複雜度上較分布式架構有天然的優勢。分布式架構随着機器數量的線性增長，複雜性也随之增長，無法通過簡單的工具和腳本來支撐。這個複雜度包含了釋出部署、系統監控和故障恢複等幾個方面，下面會逐一對比。
集中式的釋出部署一般隻需應對百台内規模的代碼/配置更新，通過簡單的腳本或者平台就可以自動化完成，釋出時間一般也能控制在小時級别。而且采用集中式架構的系統一般比較穩定，釋出周期也不會太頻繁。
在分布式環境下，千台甚至萬台伺服器的規模很常見，如果按照傳統的串行操作和自動化腳本，整個釋出周期會非常長，一旦出現問題，復原也會非常慢。
在分布式架構下，往往需要提供 P2P 分發或類似的技術手段來加速釋出過程，同時通過 beta 釋出、分組釋出、藍綠釋出等手段來解決大規模叢集下的釋出驗證、灰階引流和快速復原等問題。
螞蟻金服在發展過程中，整個運維體系也随着業務規模的增長而更新演進，逐漸形成了一套完整的運維管控平台，支援單人運維千台伺服器，避免了分布式架構下運維複雜度的增長。
在系統監控方面，集中式架構比較簡單。而在分布式環境下做監控，主要挑戰在于海量日志的實時分析和秒級展示。系統運作的狀态分散在上萬台規模的叢集中，每時每刻都在産生新的狀态。監控系統需要通過日志或者消息的方式采集整個叢集的資料做各種統計分析。
在巨大的業務量下，每晚一秒鐘發現問題就會帶來大量的業務異常，在極端情況下還會産生不可估量的損失。是以，也需要監控體系具備秒級的實時計算能力。螞蟻金服也逐漸沉澱這樣一套監控平台，很好地彌補了分布式環境下監控的劣勢，是整個平台穩定運作的基石。
在系統的容災機制和故障恢複方面，集中式架構一般會采用主備複制和主備切換的方式來實作，幾種典型設計原則包括一主多備、同城雙活、兩地三中心等。
集中式的容災方案比較成熟，也沉澱了資料複制、鏡像快照、一體化遷移等一系列容災相關的技術，可以從容應對各種場景，但仍然在以下幾個方面存在不足：
1、成本較高
在集中式架構下，經典的災備方案一般會做全量備份，在一些改進方案中會通過餘量空間做交叉互備等方式來降低成本，但整體上看還成本還是較高。為 1% 甚至機率更低的災難場景，而付出與支撐目前業務量相等的成本，這對需要承載海量業務的網際網路業務來說更是一個巨大的負擔；
2、恢複時間較長
災備方案中大量用到資料複制技術，但由于網絡帶寬或者異地延遲等問題，在恢複時，需要等待資料完全一緻後才能切換，而且無論備份資料是冷備還是熱備，切換都有一個預熱的過程。綜合切換複雜度和上述的技術限制等因素，很難縮短恢複時間。
3、業務影響面較大
由于集中式架構本身擴充性的不足，所有業務都跑在一個單點上，一旦發生故障就可能影響到所有使用者。在承載海量業務的系統上，這種影響更容易被放大，尤其在金融系統上，更有可能引發一些社會事件。
雖然在運維和監控複雜度方面在分布式系統需要通過技術手段來彌補天然的不足，但在容災恢複方面卻有着天然的優勢。資料天然分布在不同的存儲、機房和城市，而且架構上容易按合适的容量進行水準拆分。
随着這幾年網際網路的高速發展，各家網際網路公司都遇到了集中式架構下災備方案的幾個痛點，并進行了類似的架構改造，一般業界稱之為單元化改造，其本質是将分布式下可擴充的特性運用到災備場景，這個在第四章節中有提到。
這種架構能将業務影響面控制在一定的範圍内（取決于單元的大小），并通過交叉互備降低災備成本，這種機房架構下的邏輯單元具備以下三個特征：
1、每個單元在業務處理能力上自包含，對外承載一定業務分片的業務流量，内部的系統調用鍊路和各類存儲通路是局部化在本單元内的；
2、每個單元的實時資料是獨立不共享的，配置類資料或讀多寫少且對延時性要求不高的資料全局共享；
3、單元間的通信統一管控，盡量以異步化消息進行通信，同步調用則通過單元間代理方案實作，實作網絡上的收斂，便于監控和管控。
該架構解決了以下四個關鍵問題：
1、由于盡量減少了跨單元互動和使用異步化，使得異地部署成為可能。整個系統的水準可伸縮性大大提高，不再依賴同城 IDC ，真正實作異地多活架構；
2、可以實作 N+1 的異地災備政策，大大縮減災備成本，同時確定災備設施真實可用；
3、整個系統已無單點存在，大大提升了整體的高可用性；同城和異地部署的多個單元可用作互備的容災設施，通過運維管控平台進行快速切換，有機會實作 100% 的持續可用率；
4、該架構下業務級别的流量入口和出口形成了統一的可管控、可路由的控制點，整體系統的可管控能力得到很大提升。基于該架構，線上壓測、流量管控、灰階釋出等以前難以實作的運維管控模式，現在能夠十分輕松地實作。
下圖為該架構的示意圖，表格中則總結了兩種架構在運維和容災方面的對比。
小結
通過上述對集中式和分布式架構在業務支撐、一緻性/可用性、運維成本/故障恢複三個方面的分析發現，分布式架構在經濟性、安全自主、靈活性、可伸縮性等方面有明顯優勢，随着金融系統需要處理的交易量與資料量越來越大，分布式架構在這方面的優勢也會越來越明顯。
集中式系統在可維護性、一緻性方面有優勢，而分布式系統需要達到同等或更高的可維護性與高一緻性，需要通過先進的分布式中間件與大規模運維平台來支援。
螞蟻金服通過自身實踐，證明了分布式系統能夠實作金融業務所需要的高一緻性與可維護性，并将這種技術沉澱到其雲計算平台上，支撐使用者更好地運用分布式架構和雲計算能力，共同用新技術的力量推進普惠金融的發展。
原文釋出時間為：2018-06-15
本文來自雲栖社群合作夥伴“
中生代技術”，了解相關資訊可以關注“
”。