## 應用現狀比較 由于歷史原因，集中式架構多用于傳統銀行、電信等行業。主機資源集中在大型主機或小型機上。集中式架構下，包括操作系統，中間件，數據庫等“基礎軟件” 均為閉源商用系統。集中式架構的典型案例是 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 中的系統集群，進一步分成多個更細粒度的部署單元，從而達到機房級別的擴展。這種機房架構在容災方面的優勢會在第五個小節中展開說明。下面為這種架構的示意圖：  下表總結了兩種架構模式在業務支撐的幾個方面的比較：  ## 可用性和一致性比較 當然，軟件領域沒有銀彈，分布式架構多個節點的設計也帶來了保持一致性和高可靠性上的巨大挑戰。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 原則的前提下，確保全局分布式事務的最終一致性，在保證用戶體驗（性能）的前提下，讓客戶感受到了一致性，并向用戶屏蔽了短暫不一致（故障或者延遲）的恢復細節，滿足了業務上對一致性的要求。以下為分布式事務框架的模型示意圖：  為了保證高可用和業務連續性，分布式系統的存儲往往會設計成多份冗余，并盡可能在機架、機房甚至城市維度將冗余的數據分散在多處。所以從服務端角度看，最關心一致性問題是如何盡快將更新后的數據分布到整個系統，降低達到最終一致性的時間窗口。Paxos 協議就是一種在保證強一致性前提下把可用性優化到極限的算法。螞蟻金服自主研發設計的 OceanBase 數據庫就將數據存在多份存儲上，每個存儲都分布在不同機房，任何一份存儲出問題，都不影響全局的可用性。為保證這種高可用架構下的一致性， OceanBase 在多份存儲的寫入過程中，就用到了 Paxos 協議，并針對各種具體場景，對協議做了優化和改進。詳細的設計和說明可參考 OB 的資料。 下表列出了兩種架構的具體案例和相關的技術產品，支付寶的架構體系也經歷了從集中式到分布式的演進。  ## 運維復雜度和故障恢復能力比較 集中式架構部署結構簡單，設備數量少，在運維復雜度上較分布式架構有天然的優勢。分布式架構隨著機器數量的線性增長，復雜性也隨之增長，無法通過簡單的工具和腳本來支撐。這個復雜度包含了發布部署、系統監控和故障恢復等幾個方面，下面會逐一對比。 集中式的發布部署一般只需應對百臺內規模的代碼/配置更新，通過簡單的腳本或者平臺就可以自動化完成，發布時間一般也能控制在小時級別。而且采用集中式架構的系統一般比較穩定，發布周期也不會太頻繁。在分布式環境下，千臺甚至萬臺服務器的規模很常見，如果按照傳統的串行操作和自動化腳本，整個發布周期會非常長，一旦出現問題，回滾也會非常慢。在分布式架構下，往往需要提供 P2P 分發或類似的技術手段來加速發布過程，同時通過 beta 發布、分組發布、藍綠發布等手段來解決大規模集群下的發布驗證、灰度引流和快速回滾等問題。螞蟻金服在發展過程中，整個運維體系也隨著業務規模的增長而升級演進，逐步形成了一套完整的運維管控平臺，支持單人運維千臺服務器，避免了分布式架構下運維復雜度的增長。 在系統監控方面，集中式架構比較簡單。而在分布式環境下做監控，主要挑戰在于海量日志的實時分析和秒級展示。系統運行的狀態分散在上萬臺規模的集群中，每時每刻都在產生新的狀態。監控系統需要通過日志或者消息的方式采集整個集群的數據做各種統計分析。在巨大的業務量下，每晚一秒鐘發現問題就會帶來大量的業務異常，在極端情況下還會產生不可估量的損失。因此，也需要監控體系具備秒級的實時計算能力。螞蟻金服也逐步沉淀這樣一套監控平臺，很好的彌補了分布式環境下監控的劣勢，是整個平臺穩定運行的基石。 在系統的容災機制和故障恢復方面，集中式架構一般會采用主備復制和主備切換的方式來實現，幾種典型設計原則包括一主多備，同城雙活，兩地三中心等。集中式的容災方案比較成熟，也沉淀了數據復制、鏡像快照、一體化遷移等一系列容災相關的技術，可以從容應對各種場景，但仍然在以下幾個方面存在不足： 成本較高：在集中式架構下，經典的災備方案一般會做全量備份，在一些改進方案中會通過余量空間做交叉互備等方式來降低成本，但整體上看還成本還是較高。為 1% 甚至概率更低的災難場景，而付出與支撐當前業務量相等的成本，這對需要承載海量業務的互聯網業務來說更是一個巨大的負擔； 恢復時間較長：災備方案中大量用到數據復制技術，但由于網絡帶寬或者異地延遲等問題，在恢復時，需要等待數據完全一致后才能切換，而且無論備份數據是冷備還是熱備，切換都有一個預熱的過程。綜合切換復雜度和上述的技術限制等因素，很難縮短恢復時間。 業務影響面較大：由于集中式架構本身擴展性的不足，所有業務都跑在一個單點上，一旦發生故障就可能影響到所有用戶。在承載海量業務的系統上，這種影響更容易被放大，尤其在金融系統上，更有可能引發一些社會事件。 雖然在運維和監控復雜度方面在分布式系統需要通過技術手段來彌補天然的不足，但在容災恢復方面卻有著天然的優勢。數據天然分布在不同的存儲、機房和城市，而且架構上容易按合適的容量進行水平拆分。隨著這幾年互聯網的高速發展，各家互聯網公司都遇到了集中式架構下災備方案的幾個痛點，并進行了類似的架構改造，一般業界稱之為單元化改造，其本質是將分布式下可擴展的特性運用到災備場景，這個在第四章節中有提到。這種架構能將業務影響面控制在一定的范圍內（取決于單元的大小），并通過交叉互備降低災備成本，這種機房架構下的邏輯單元具備以下三個特征： 1. 每個單元在業務處理能力上自包含，對外承載一定業務分片的業務流量，內部的系統調用鏈路和各類存儲訪問是局部化在本單元內的； 2. 每個單元的實時數據是獨立不共享的，配置類數據或讀多寫少且對延時性要求不高的數據全局共享； 3. 單元間的通信統一管控，盡量以異步化消息進行通信，同步調用則通過單元間代理方案實現，實現網絡上的收斂，便于監控和管控。 該架構解決了以下四個關鍵問題： 1. 由于盡量減少了跨單元交互和使用異步化，使得異地部署成為可能。整個系統的水平可伸縮性大大提高，不再依賴同城 IDC ，真正實現異地多活架構； 2. 可以實現 N+1 的異地災備策略，大大縮減災備成本，同時確保災備設施真實可用； 3. 整個系統已無單點存在，大大提升了整體的高可用性；同城和異地部署的多個單元可用作互備的容災設施，通過運維管控平臺進行快速切換，有機會實現 100% 的持續可用率； 4. 該架構下業務級別的流量入口和出口形成了統一的可管控、可路由的控制點，整體系統的可管控能力得到很大提升。基于該架構，線上壓測、流量管控、灰度發布等以前難以實現的運維管控模式，現在能夠十分輕松地實現。 下圖為該架構的示意圖，  表格中則總結了兩種架構在運維和容災方面的對比。  ## 小結 通過上述對集中式和分布式架構在業務支撐、一致性/可用性、運維成本/故障恢復三個方面的分析發現，分布式架構在經濟性、安全自主、靈活性、可伸縮性等方面有明顯優勢，隨著金融系統需要處理的交易量與數據量越來越大，分布式架構在這方面的優勢也會越來越明顯。集中式系統在可維護性、一致性方面有優勢，而分布式系統需要達到同等或更高的可維護性與高一致性，需要通過先進的分布式中間件與大規模運維平臺來支持。螞蟻金服的通過自身的實踐，證明分布式系統是能夠實現金融業務所需要的高一致性與可維護性的，并且將這種技術沉淀到了螞蟻金融云計算平臺上，支撐合作伙伴更好地運用分布式架構和云計算的能力，共同用新技術的力量推進普惠金融的發展。