數字金融時代的雲原生架構轉型的關鍵挑戰和應對思路
背景
在產品需求日漸豐富、迭代速度不斷加快的背景下，金融機構數字化轉型需要有成熟的IT架構、敏捷交付流程和技術風險保障機制支撐，縮短新業務產品的研發與投產時間，快速響應細分客戶需求，還要保證在更新和維護應用及軟硬體系統時不對用戶體驗產生負面影響，即使在極端嚴苛的業務壓力下也須始終保持順暢的產品服務體驗，保證業務連續性和數據安全。
近幾年來，「雲原生架構」的相關話題討論比較熱烈，我們也相信這也將是金融IT架構的關鍵發展趨勢之一。IT架構轉型絕不是一蹴而就的，積極探索和應用以「雲原生」為代表的新興技術的同時，還需考慮與傳統模式和技術融合併存，沿著一條穩妥的可落地路徑進行創新變革，確保架構轉型的價值交付能夠穩妥支撐甚至積極引領業務創新。
在螞蟻金服內部架構變遷和對外金融科技開放的過程中，我們一直在持續探索，並在不斷鞏固總結出一套金融級雲原生的架構落地路徑，順應廣大金融機構分散式改造和IT架構穩妥創新升級的需求。我們希望本文能作為分享的開端，在未來我們將就相關實踐經驗，持續和大家進行積極開放的交流分享。
雲原生架構的緣起和發展
許多行業的領導者和新興創業機構，其技術架構都有普遍的共同點：以移動為核心增強用戶體驗、快速敏捷創新、服務持續可用、基礎架構可擴展。這也是以金融為代表的傳統機構IT數字化轉型的目標，恰好也是當前非常火熱的「雲原生（Cloud Native）」架構所希望帶來的真正價值。
雲原生（Cloud Native）這個概念名詞最初於2013年在技術社區中誕生，代表著一套先進架構理念的思想集合，包括了微服務、敏捷、DevOps、持續集成部署、容器、可靠、高彈性、易擴展等領先的概念和特性，之後整個業界也在不斷發展，社區中湧現了許多非常優秀的項目，Linux基金會旗下的CNCF（雲原生計算基金會）應運而生。
CNCF對雲原生定義了三個基礎要素，即：
1.微服務化，為架構敏捷性和運維精益性奠定基礎。
2.容器化，以確保資源可重用、透明及隔離性。
3.動態編排，以確保資源調度的效率，通過精益化運維極大降低成本和提升效能。
由此可見，雲原生是加快產品發布速度、增強服務穩定性、提高計算資源利用率、降低運維成本的關鍵架構之道。
雲原生的企業架構演進之路
為充分理解雲原生這個概念，並思考傳統企業架構邁向雲原生的轉型升級路徑，我們先簡單回顧一下雲計算的行業發展和企業架構演進的一般情況。縱觀全局，我們把傳統企業架構邁向雲計算架構的演進之路，可以粗粒度地抽象成三個階段：
1.雲機房（Cloud-Based），指的是把機房遷移到雲（包括公有雲或專有雲）的第一步，基於虛擬化技術使資源利用率和運維效率有所提高，但依舊需要重點關注中間件和底層平台，每一部分都要考慮高可用、擴展、交付部署等因素。
2.雲就緒（Cloud-Ready），基本完成去中心的服務化改造，應用無狀態化並與緩存、資料庫等持久化層分而治之，應用服務規模擴大，需要有較成熟的DevOps和自動化工具平台來統一管控。
3.雲原生（Cloud-Native），通過微服務化架構、容器和編排技術、DevOps等技術實踐，加快應用的交付和部署；通過對平台能力的抽象和標準化，輔以微服務治理、敏捷的資源編排和管控技術，使開發者的關注重心上移，更關注業務邏輯本身，做到「代碼定義一切」(Code Defined Infrastructure/Everything)。
雲原生的本質：平台能力抽象& 標準化
在這三個發展階段演進過程中，體現出了兩層關鍵趨勢：
1.從應用上雲歷程上看，架構關注重心逐漸上移：隨著研發運維理念升級發展、相關工具平台的規範成熟，底層和中層基礎平台設施的能力逐漸抽象，並同上層業務應用解耦，使得軟體團隊更加專註於業務邏輯的研發成為可能。
回顧螞蟻金服的架構演進，從某種程度上也代表了許多發展成熟的互聯網公司的多年架構升級過程，最早亦是從單體巨石應用架構發展而來，逐漸開始應用SOA服務化的架構思想，開展應用和數據的分拆，發展出較細粒度的微服務架構，並沉澱出能支撐上層業務靈活發展的堅實業務中台和技術中台。
通過成套的應用開發框架、研發流程和中間件、運維平台，基礎平台技術和業務研發有了較清晰的邊界和協同機制。業務開發團隊因可不必太過關心業務系統的容災、擴展等非功能特性，得以更加聚焦專註於業務邏輯的研發實現。
2.隨著容器和編排技術的成熟和統一，PaaS層的技術方向也趨於穩定：企業應用遷移上雲的歷程，亦是代表著業界對雲計算認知的過程和雲計算技術本身成熟度的升級過程，逐漸從對IaaS層的依賴，發展向對PaaS層的依賴。
回顧行業發展史，早在大約2006年AWS開創了雲計算商業化的先河，推出了雲端彈性虛擬機、存儲等產品，直接定位於從IaaS層面解決傳統應用雲上遷移的需求，直到現在，公有雲市場絕大多數的收入還都是來自於IaaS產品服務。但是反觀微軟雲和谷歌雲的早期市場進入策略，最開始的差異化競爭點都在PaaS層：以Google App Engine作為一個PaaS平台為例，開發者在一整套平台框架內研發、部署和管控應用程序，底層資源全部由雲服務來進行託管，省去了許多底層系統管理操作。現在來看這些理念是非常先進的，但在那個年代對於大多數還在理解什麼是雲計算的企業客戶來說，過多的代碼框架侵入性和研發運維架構模式的轉變，為整體架構遷移至PaaS帶來了非常高的壁壘，最後就如同大家所看到的一樣，以虛擬機產品為代表的IaaS層仍將是遷移至雲的第一站。
但不管是雲計算服務商還是機構用戶，都希望最大程度上發揮出雲上能力，有非常多的商業公司和開源社區不斷在PaaS領域上深耕，PaaS也逐漸出現了細分，例如以應用發布運維為核心的Application PaaS (aPaaS)，託管資料庫服務Database PaaS(dbPaaS）等等，可謂百家爭鳴，這些平台服務確實解決了許多現實應用問題，降低對底層基礎設施的依賴，但業界也產生了困惑 - PaaS產品本身很可能對應用開發和運維產生侵入性，這對廠商來說是粘性，對用戶來說可能就是廠商綁定了。直到後來Kubernetes等容器編排技術的成熟，獲得了大部分社區和用戶的認可，行業才相對往一個較為統一的方向發展，與此同時「雲原生」的先進理念也開始蓬勃發展，逐漸被開發者和架構師們所接受。
雲原生可能是「銀彈」，但架構轉型絕非一蹴而就
「銀彈」一詞出處來自歐美民間傳說，指的是只有「銀質的子彈」才能使狼人這樣的怪物一槍斃命。在軟體工程界，「沒有銀彈（No Silver Bullet）」的說法來自弗雷德里克·布魯克斯在1986年所發表的一篇經典論文，該論述中強調「真正的銀彈並不存在」，隱喻沒有任何一項技術或方法可以能讓軟體工程的生產力在十年內提高十倍。
從技術圈的社區討論火熱程度來看，雲原生、微服務、DevOps、敏捷、容器化等技術和理念似乎就是未來IT基礎設施建設的方向。業界普遍認為，雲原生架構能加快需求交付、降低運營成本、支持容量伸縮、保證業務連續，從而使組織能更從容地接入創新技術、促進渠道觸達。同時從最基礎的定義上來看，面向雲原生的架構轉型貌似就像把大象放進冰箱一樣簡單：1. 微服務化 - 把大象拆分成許多小象；2. 容器化 - 打開冰箱門，把小象塞進冰箱；3. 動態編排 - 最優化這些冰箱的排列以保證空間資源利用率。
且不說在信息技術高速發展的今天，「沒有銀彈」是否依舊能夠成立，在企業級特別是銀行等金融機構架構轉型方面，雲原生是一個很好的方向，只是在應用這套新技術時，仍舊需要充分考量各項因素，以及使用一整套經過驗證有效的落地路徑與方法來進行有力支撐。
事實上，金融系統的架構轉型不太可能一蹴而就，新興技術同傳統架構的融合併存在許多方面帶來了更大挑戰。以銀行為例，從80、90年代開始建設電子銀行、網上銀行到移動智慧銀行，新的業務需求層出不窮，面臨著很多架構轉型和變革的機會。銀行的IT化程度很高，也看重雲原生和分散式架構對於業務和整體IT交付的價值，但是系統越是成熟，歷史包袱就越重，有著大量非常關鍵的遺留系統，實施架構轉型時則無疑將面臨許多關鍵的重大挑戰。
金融級雲原生架構轉型路徑
伴隨著螞蟻金服在數字金融領域的探索，在十多年的發展過程中，技術團隊積累了大量的架構設計原則、最佳實踐和產品服務案例，而這背後的出發點和技術思考，同雲原生架構的理念是高度一致的，我們致力於構築一個完整的金融級雲原生架構，通過成熟的中間件和架構運維平台，使上層的應用能專註業務邏輯並具備敏捷交付的能力，又使其天然擁有金融級的高可用、一致性特性和互聯網的海量並發、彈性伸縮等雲原生基礎架構能力。
下面我們希望通過一些關於螞蟻架構發展的實踐案例和經驗，和大家分享我們總結出的金融級雲原生架構轉型路徑上的關鍵挑戰，以及在面臨這些挑戰時的一些應對思路和策略，與行業共同推動架構轉型升級與數字金融創新。
挑戰1：金融IT架構如何進行穩妥轉型？
「架構」一詞原本來自建築學，其背後有著關於建築的隱喻，從藍圖到地基再到封頂，在絕大多數建築物拔地而起的發展過程中會盡量較少引入新的變數，因為對於建築而言改變整體結構或根基的成本非常高，軟體業從建築業借用了「架構」這個概念時，我們把那些一旦改變就會傷筋動骨的系列組件構成方式或者設計決策集稱之「架構（Architecture）"。傳統IT架構和早期的軟體研發，喜歡運用「瀑布式研發」模型，而這個概念現在可能只在軟體歷史教科書中提到，自上而下進行充分論證和設計，最終按照設計藍圖的定義進行構建，一旦設計成型之後很難改變，如果產生設計變更，則往往牽一髮而動全身，一輪變更下來研發團隊常常要脫一層皮，導致研發過程效率低下。
隨著敏捷軟體開發方法和互聯網商業的崛起，21世紀的軟體工程更偏向於使用生物進化的隱喻，就像從猿猴逐漸進化成現代人的過程中，能夠不斷根據外界環境和自身發展的需求，持續進行適應性和最優化的調整演進。回顧螞蟻十多年的發展過程中，飛速發展的業務場景和使用量級，一直在推動團隊組織和技術架構進行持續的升級演化。螞蟻從最早的單體應用，到SOA服務化改造、分散式架構主機下移、單元化改造，再到從容承載互聯網金融業務的異地多活架構，整個循序漸進的演進過程都是暗合生物進化的架構隱喻。
好的軟體架構是進化來的，而不是由一開始就能夠進行完整的巨細靡遺的設計和按圖製造。當前螞蟻的IT架構已經有了諸如「金融級、異地多活、彈性伸縮、事務一致性」等標籤，但在早期階段，我們只是對這些架構目標做了設定，但並未在開始就完全設計好所有細節。回顧架構的歷史變遷，金融IT架構轉型創新的前提是保證用戶體驗和現有業務連續，確保整體穩妥可控，對此我們分享三個原則觀點：
1.增量化交付(Incremental)
架構落地不追求一步到位，由簡單入手，漸進式攻克，每一步都為未來奠定基礎。
支付寶的架構每年都需要迎接天貓雙十一大促的峰值和容量挑戰。從2012年開始，整體架構開始面臨瓶頸，預計很難通過傳統的擴容手段支撐來年業務量增長。（事實上，2013年的峰值交易量達到了前一年的近四倍，已經達到每秒15300筆）。當時我們已經對單元化架構和LDC（Logical Data Center, 邏輯數據中心）的整個願景提出了設想，只是當時並沒有想到其最終能發展到何種成就。
關於單元化架構，最初是支付寶用來解決業務和數據拆分後資料庫連接數過多的問題，通過更多的場景沉澱，單元化架構今天已經成為螞蟻金服異地多活和容災架構的基礎。單元化架構的本質是將系統進行水平拆分後的邏輯隔離，每一個單元都具備更小的規模，但擁有完整的業務功能，從接入網關到應用伺服器再到資料庫，每個單元依據規則支撐一定的流量和數據。通常來說，一般雲計算應用的「分片」（Sharding） 通常是在數據層維度的，以支撐上層無狀態（Stateless）應用的橫向擴展。而單元化架構的核心設計思想，是把這種分片能力提升到機房入口流量的位置，使整體的業務處理能力能夠通過一個個邏輯單元在數據中心的層級進行橫向伸縮。
增量化交付：異地多活架構的演進歷程
完成一個交易，背後有非常多的業務邏輯，調用非常多的業務系統。為驗證單元化架構的思路的可行性，我們最初圍繞著交易創建系統進行相關改造。通過前置系統從流量中截取用戶的支付寶賬戶ID並取模，以識別該用戶的數據屬於哪一塊邏輯單元分片，隨後進行路由轉發並執行處理邏輯，實現在網關層的服務路由、數據層的數據分布都能夠通過賬戶ID來進行分片並形成封閉單元。
在2012年底完成交易系統的原型驗證之後，才開始了全面的單元化改造。我們需要把這些業務系統集中在一個邏輯單元上，使流量一旦進入這個邏輯單元就能完成整個交易的全過程，盡量減少同其他單元進行通訊的機會，因此背後需要有一系列業務系統的改造，使完整鏈路的架構分片邏輯能與交易系統對齊。
那一年我們解決了大促高峰時資料庫連接池的瓶頸，在夯實這個基礎之後，我們把紅利再擴展到核心的支付鏈路，一步一步再到賬務鏈路，一直到整個體系完成覆蓋，完成了單一機房內的邏輯單元化改造。在2014年的時候，遇到了單機房的容量瓶頸，於是把邏輯單元部署到了同城的第二個機房，完成「同城雙活」的架構。這也為「異地多活」奠定了基礎，並在之後通過容器和資源調度技術的成熟，使得邏輯單元能更靈活地「彈入」雲計算機房和大數據離線機房，使得單元化不僅解決了機房級橫向擴展的問題，更是在跨地域跨機房的容災和資源利用率方面取得了很多紅利。
2.穩健型創新(Sustainable)
行走江湖安全第一，技術風險兜底增強適應能力。
金融的本質是風險識別和管理，而對於金融IT架構來說技術風險亦是重中之重。任何一筆交易處理的差錯背後都有可能導致不可預計的資金損失。螞蟻金服有一支專業的技術風險團隊（SRE，Site Risk Engineering），確保從系統架構平台到風險文化機制，在架構設計、產品開發、變更上線、穩定性評估到故障定位恢復等等環節，都能全生命周期地確保風險質量控制，對任何系統變更作兜底保障。許多關於技術風險的實踐經驗，都已經沉澱到螞蟻的架構邏輯和平台產品之中。以下我們舉一個關於會員系統資料庫遷移至OceanBase的案例，分享其技術風險保障方案和兜底邏輯。
2015年的雙十一大促，OceanBase資料庫已經支撐了100%的交易流量，並開始支撐支付寶的會員系統等其他核心業務，全天運行穩定，零數據差錯，在那一刻開始標誌著OB已經成為了一個金融級資料庫。這屆大促的準備工作的目標之一就是會員系統背後的原商業資料庫遷移至OB，同時又要驗證系統在新資料庫下的可靠性和穩定性，不能影響整體業務連續性。確保項目萬無一失，絕非只是進行簡單的複製同步和數據源切換，這背後項目組對穩妥方案不斷進行探求和驗證，解決了具有挑戰的核心技術問題，在多個架構層次上都達成了平衡和優雅的設計。「開著飛機換引擎」的過程，歷時將近一年。
穩健型創新：會員系統遷移OB
資料庫層面的遷移過程可以抽象成四個步驟，包含了許多兜底邏輯：
第一步，寫老讀老，在原有架構下，通過同步機制，確保OB端的數據同原資料庫對齊，但業務應用的數據讀寫依舊在商業資料庫中；
第二步，寫老讀新，我們通過數據中間件，將一部分對一致性要求不高的訪問流量，通過白名單切流的方式遷移至OB，此時OB的數據來源仍舊來自商業資料庫的同步；
第三步，寫新讀新，同步機制斷開。這個步驟比較複雜，包含了大量的數據對比、禁寫切換和性能驗證操作。首先通過資料庫層以及中間件層的禁寫操作，關閉商業資料庫的讀寫流量。其次，等待增量數據同步組件同步日誌，邊同步邊開啟增量比對。之後，增量數據同步完成後，開啟數據全量比對。數據全量比對完成後，資料庫層以及中間件層打開對Oceanbase的讀寫流量，完成"換主"操作。在整個切換過程中，針對每個階段都準備了相應的回滾操作，並在線下多次練習，最終確保10億＋數據分鐘級的切換。
第四步，雙寫同步數據，保留原資料庫作兜底，通過數據中間件雙寫來同步數據，一邊做驗證，一邊確保整個體系有隨時回滾能力，項目歷時幾個月，最終確保OB成功切換，完成大促挑戰。
3.演進式規劃(Evolutionary)
在架構演化選擇時，對關鍵架構決策進行原型驗證，確定最佳演化方向。
談到互聯網時代的技術和產品迭代，我們常常看到一個觀點，鼓勵「快速試錯」。精益創新和敏捷迭代固然重要，然而在嚴苛金融場景下進行關鍵架構決策時，「試錯」的代價往往會變的難以承受。從我們的實踐經歷來看，演進式規劃的本質是，邁向一個架構願景目標時一定要對關鍵架構決策進行原型驗證，為此還要最大程度上在實際環境中保證可行性。回顧2015年從同城雙活邁向異地多活時，整個體系改造包括了機房搬遷、選址，幾乎所有系統的相關改造，為保證能萬無一失，所以我們做了非常多的驗證。
演進式規劃：異地部署前的充分原型驗證
異地部署的一大難以逾越的挑戰是地理位置所帶來的延時。光纖可以做粗，但光速無法變快。我們首先在中間件層面實現了故障注入的能力，而延時就是可能的故障之一。我們在當時同城雙活的架構中，在未來可能產生異地延時的節點加入埋點，模擬一旦流量走向異地機房時可能發生的延時。基於這個方案思路，我們做了非常多的演練，逐漸從某個單點應用擴展到數據層、路由層等方面。為了能更準確地評估模擬延時注入後的影響效果，我們還加入了鏈路追蹤Tracer的能力，使一個交易請求從發起，經過各微服務和中間件再到資料庫訪問的整個過程，都能夠被穿透式地監控記錄到。以一個涉及到跨城調用的交易為例，整個過程涉及到的遠程調用、非同步消息等都有可能觸發延時邏輯。通過對完整鏈路的跟蹤串聯，我們對異地部署延時對鏈路的影響作了充分可行性驗證，最後流量切換上線、直到異地多活的改造完成，全程作到用戶無感知，保證了用戶體驗和數據安全。
通過儘可能真實的狀況模擬和故障注入，再到後來逐漸成熟的全鏈路壓測，都是架構演化選擇時的最佳實踐，在演化的過程中，必須要對關鍵架構決策進行充分的原型驗證，如同生物進化，做多種可能的嘗試，以確定最佳演化方向。
小結：金融級雲原生架構升級參考路徑
我們把以上提到的三個觀點，總結為一組金融架構進行穩妥轉型的三大原則。大道至簡卻知易行難，在架構的演進過程中，這些原則已然深深的寫進了螞蟻的代碼里。正是基於這些原則，螞蟻應用架構完成了從單體改造，走向單元化，實現同城雙活再到異地多活的變遷。在此過程中，我們關注技術風險，形成中台架構，不斷把技術中台和業務中台沉澱下來。我們相信這些原則有一定的通用性，尤其是適合作為金融IT架構變遷的參考路徑。
金融級雲原生架構升級參考路徑
對於絕大多數以銀行為代表的金融機構，到了一定體量並對業務發展有積極預見之時，我們建議IT架構規劃和升級，需要基於業務價值作增量化交付、穩健型創新、演進式規劃，構建中台能力敏捷響應市場需求，同時夯實完整的技術風險平台和體系以保證在容量、變更、故障自愈、資損防控領域等方面的建設，使新老技術和價值理念混合併存、架構升級的過程中，依舊可以保證穩妥發展與創新。
挑戰2：嚴苛金融場景下如何確保架構平衡？
螞蟻金服這十多年來，業務場景和規模持續同技術產品一起飛速發展，對技術能力的要求不斷提高，從量變發展到架構質變；有了堅實的技術架構底盤支撐，業務亦能有更為廣闊的想像空間，通過科技創新能力搭建一個開放、共享的信用體系和金融服務平台。
我們倡導「架構平衡」，意味技術目標與組織需求能夠相互適應，共同發展。關於「嚴苛金融場景下如何確保架構平衡」的問題挑戰，我們通過介紹微服務架構產品在螞蟻的發展歷程，講述我們在不同階段的架構平衡考量和原則，希望能對金融機構進行架構選型和路徑決策時提供參考。
階段一：快速搭建單體應用：滿足交付效率
在最早期還只是淘寶收銀台的早期時代，支付寶還是一家純粹的創業公司，當時最重要的就是交付效率，當時嘗試使用眼前能獲得的最快最成熟的方案，比如許多金融機構IT耳熟能詳的商業軟硬體、互聯網上能找到的開源技術。當時不用考慮太多擴展性和容災能力，而正是這些非常經典的技術和架構，支撐了支付寶業務模式的早期探索。
階段二：模塊化+SOA：組織和業務規模飛速增長
第二個階段，我們發現組織和業務規模上漲的非常快，同時對交付的要求又非常高，因此業務架構和應用設計急需一種抽象和模塊化的能力，解決多方協作開發部署的需求。此時整體研發框架開始了面向服務化的改造，應用開始拆分以確保能夠分而治之，極大了改善先前100多人同時開發整個業務模塊的情況，通過抽象和隔離，減少並行研發過程中互相之間的影響，又極大加快了編譯、測試、發布的效率。在這個背景下，分散式中間件SOFA應運而生，當時SOFA在內部的全稱叫做Service Oriented Fabric Architecture，意為能夠將SOA架構通過服務化地方式重新組織，讓研發運維人員像坐「沙發」一樣舒適工作。
階段三：微服務的「靜態拆分」與「動態組合」：優化成本以應對容量問題
在第三階段，業務規模和成本優化的這兩個大的互相撕扯的力量是最需要破局的技術挑戰。團隊和開發人員的規模、業務的規模和峰值容量都上漲的非常快。關於微服務的拆分和治理，當時我們內部激烈討論過一個問題，到底拆100個服務、1000個服務還是2000個服務是正確的，而我們當時就在不斷摸索這個平衡點。
俗話說分久必合，合久必分。微服務架構的優勢不言而喻，但有時逆向思維也會非常精彩。我們考慮了另外一條路徑，即有沒有可能把各應用以微服務的方式分別開發測試的前提下，把一些系統上合併起來進行部署。回顧支付寶系統中的關鍵交易鏈路，交易創建、收銀台展現、交易支付三個階段的調用量是高度耦合的，這些業務邏輯背後所關聯的許多微服務應用是否能有更優化的部署模型。於是我們對研發框架和運行時組件作了非常多的研究和改造，確保保持項目代碼分開的情況下，能夠進行「合併部署」。
合併部署的核心思路是實現類隔離，同時服務註冊發現、路由邏輯以調用本地實例為優先。合併部署的技術應用經歷過大量POC原型驗證，最後成功地把一些指定的服務部署成為一套合併的系統，同時保持其他仍舊以微服務形式，最終為當年大促省下了非常多的機器，極大提高了資源利用率。隨著架構的演進，後期我們將這套思路用更為優雅的編排調度和容器來實現，升級為合併部署2.0，這個是後話了。
階段四：單元化與異地多活：跨機房和地域的容災和擴展能力保障業務急速發展
單機房的容量無法無限伸縮，更是無法保證容災能力能滿足業務連續性的需要。在此階段，我們會在風險質量以及業務規模、成本方面去平衡，通過單元化改造使整體架構具備異地多活能力。為此，我們實現了跨機房的服務註冊發現能力、提供了跨機房的服務調用路由邏輯，從入口流量到微服務、中間件和底層資料庫，全鏈路地消除了單點，使整體服務都具備了分片和橫向擴展能力，同時保證了資源利用率，破除了傳統主備架構所帶來的成本負擔。
階段五：服務化基礎設施下沉：Service Mesh平滑支撐海量異構的金融科技應用
隨著螞蟻業務發展和各線金融科技的不斷探索，不止團隊規模在飛速擴充，以支撐區塊鏈、人工智慧、風控核身、物聯網、金融計算等各方面發展的需要。在這樣的現狀前提下，內部技術棧逐漸開始多樣化，從相對統一的 Java 逐漸加入了非常多的基於 Node.js、C++、Python 等異構語言的微服務應用。但這些應用本身不應是割裂的，我們依舊希望依舊能夠貫通到一個統一的體系進行管理，盡量以輕量級、低成本的方式向這些系統提供近乎一致的微服務管控和互相發現通訊能力，而不是向每一種技術棧都提供一個客戶端 SDK 並將關鍵能力重新實現一遍。
同業界的觀點一致，我們亦認為Service Mesh 是微服務未來發展的重要趨勢。其本身的實現原理和優勢，社區已經有了非常多的討論，而對螞蟻來說，首先看重的就是其對異構微服務應用、遺留應用互相之間發現、通訊和治理提供了非常優雅的解法。通過 Service Mesh 的方案，我們可以盡量把最多的功能從中間件的客戶端中移到一個並行部署的輕量代理中，並對服務應用透明，目標是做到一次實現，就搞定所有語言，這個對於基礎設施團隊來說，在成本和穩定性上都是一個提升。
小結：尋求最平衡的架構發展路徑以滿足業務發展和嚴苛場景考驗，而不僅僅關注功能本身
微服務演進：應對業務發展訴求的架構平衡
金融IT系統的架構選型需要非常慎重，以銀行核心系統為例，系統選型幾乎就是一個公司戰略級別的決策，關乎著長期影響。在當前歷史時期，有非常多的銀行機構開始考慮逐漸從單體架構向分散式架構進行融合與升級。圍繞著業務價值作IT架構交付，絕不只是看哪種技術比較時髦或功能強大，這背後的選型元素涵蓋了服務化架構、敏捷交付、API平台開放、綜合成本等話題，也包含著落地可行性和生態成熟度等方面，因此更需要關注這套技術產品的長期願景和發展規劃，比如有沒有公有雲的業務戰略、有沒有提供一整套從經典架構遷移至先進架構的轉型路徑方法實踐，更看重在業內有沒有真實參考案例和服務體系支撐。
在通過多個維度對架構和技術產品本身進行評估的同時，對組織發展現狀的認知也非常重要。為此，我們為「技術選型決策」抽象出兩部分能力，一部分代表不斷發展的「現實狀態」，包括了「團隊能力」、「組織規模」和「業務規模」；另一部分代表「技術目標」，代表業務對我們的要求，包括了「交付效率」、「成本優化」和「質量風險」。我們認為架構選型的實質是為了使組織能力和技術能力達成一種平衡，通過權衡組織發展的現狀和未來，來找尋最合適的技術發展可實現願景和可落地路徑。
挑戰3：如何應對核心金融系統的關鍵技術挑戰？
成熟的新技術推動著數字化業務能力和客戶體驗個性化的提升。在購物、醫療、出行、社交等不同的複雜場景，最終用戶通過互聯網、移動端，甚至物聯網設備等渠道獲取金融服務的機會已經越來越頻繁。在這樣的場景化數字金融時代，用戶選擇多樣，市場競爭也在不斷加劇，在眾多同類金融服務競爭中脫穎而出的必要條件是能夠提供一體化全方位數字化的服務，即用戶希望無論何時何地，通過觸手可及的設備或者平台，都能一站式地滿足其金融生活和業務的需求。場景極大豐富，亦為金融業務營銷活動提供了非常大的想像空間–地理位置、時間作息、淡季旺季等因素不再是決定獲客營銷的關鍵因素，計劃中的大促活動和計劃外的熱點事件，都有可能為金融機構的信息系統產生巨大挑戰。
以一個常見的日常交易場景是當面付為例。當用戶拿出手機，打開二維碼進行付款操作，後台會進行一系列技術處理。這中間最主要的環節是風險識別；風險識別以後，是相應的營銷決策，判斷用戶在該筆交易中應該獲得多少紅包或者獎勵；最終完成交易，發生賬戶扣款併產生結果。這樣一個簡單的場景背後蘊含著一系列以計算為核心的交易處理過程。而這個場景正在時時刻刻發生在現實生活中。在普惠金融和互聯網業務蓬勃發展的大背景下，具備大規模高並發交易處理的能力已成為銀行等金融機構業務系統的標配。
核心金融系統，在技術層面的挑戰有別於其他大規模互聯網系統。在數字化轉型的過程中，我們建議金融機構的技術決策者，預先考慮可靠的基礎設施和彈性應用數據架構，在不同業務壓力下依舊保證業務連續性和數據安全。而且在金融級交易系統中，對事務型的狀態數據一致性處理以及交易成本的要求更高，對客戶資金風險和安全性處理更加複雜。在產品迭代速度不斷加快的背景下，還要有成熟的架構、流程和風險保障機制，在更新和維護應用及軟硬體系統時，不對用戶負面影響，保證在任何極端嚴苛的業務壓力下始終保持絲般順暢的用戶體驗。
基於螞蟻的實踐經驗，金融級IT系統在邁向雲原生架構的過程中，有以下四大關鍵技術挑戰需要積極應對：
·無限可擴展能力：如何規模化分散式服務和數據能力，也就是服務和數據處理的可伸縮性
·無損秒級容災：如何做到秒級快速容災能力，做到四個9及以上的系統可靠性
·高性能分散式事務：當服務和數據分布後，如何保證事務中數據的強一致性，這是金融級分散式系統最大挑戰之一
·彈性供給與調度：怎麼做低成本，按需提供資源配置與調度，如何做到交易成本的降低
無限可擴展能力
我們在前文架構變遷歷程中提到了單元化，這是整體架構能夠進行無限可擴展的關鍵前提。單元具備四個重要特性：
一、自包含性，比如賬戶充值交易所涉及的所有計算和數據都會被封閉在一個單元；
二、松耦合性，單元之間只允許進行服務調用，不允許直接訪問資料庫或其他存儲，對於必須跨單元的操作，比如位於兩個不同單元之間的用戶轉賬交易，服務調用需儘可能少，同時在不影響客戶體驗的情況下，儘可能非同步化。這樣，即便兩個單元相距較遠，整個系統的響應也不會受單元間訪問延遲的影響；
三、故障獨立性，一個單元的故障不會影響其他單元；
四、容災性，單元之間相互備份，每個單元都保證在發生同城或異地故障時有可接管的單元，單元之間的備份方式是使用自研資料庫提供的多地多中心的一致性方案。
無限可擴展：異地多活與單元化架構
通過單元化架構，全局系統的伸縮問題變成了邏輯單元的增減問題，而在此過程中，整個單元的規模和內部複雜性是相對穩定的，這就降低了系統整體伸縮的複雜度；其次，單元的故障獨立性使得我們能夠控制軟硬體故障的影響面；最後，單元之間可快速切換，這就使得我們處理同城和異地容災時可以更加簡單高效。
無損秒級容災
單元化解決了業務和服務層面的擴展性和容災問題，但數據層面的容災問題並沒有得到解決。如果發生城市級故障，我們仍然不敢把核心業務流量切換到另一城市，那我們實際上仍然停留在原地。但這個問題不管是商業資料庫還是開源資料庫都是無解的，我們可以通過各種技術手段儘可能降低故障切換時間，減少故障影響的客戶範圍，但無法避免資損的發生。這個問題，在我們有了自己的資料庫OceanBase之後，被徹底解決了。
OceanBase的核心是基於Paxos協議的多數派分散式選舉協議，Paxos協議的價值已被業內廣泛認可。該協議保證只要多數成員依然存活，任何少數成員的故障不會影響系統的整體可用性和數據一致性。所以，如果把一個數據集群部署到三個或三個以上城市時，我們就可以保證任何一個城市的故障，系統都可以實現無損容災，也就是RPO=0。同時，系統可在30秒以內把故障切換到另一城市，故障切換過程在資料庫層面自動完成，對上層業務沒有影響。另一方面，當我們把一個資料庫集群部署到三個城市時，為了避免任何單機故障導致的業務跨城市訪問問題，我們把資料庫集群中的副本數量從3個增加到5個，這就是我們今天所說的三地五中心，或者嚴格一點，三地五副本多中心。
無損秒級容災：金融級關係型資料庫OceanBase，三地五中心高可用部署
從兩地三中心到三地五中心，我們解決了一個基礎又非常重要的問題，即便發生城市級故障，整個城市都不可用，資料庫層面仍然可以做到，系統不丟數據，不停服務。
螞蟻金服花了數年時間來演進基於單元化和三地五中心的異地多活和容災架構，至今已在多個城市部署了多個數據中心，所有的核心交易流量部署在所有數據中心並可隨時切換和調配，通過異地多活，我們實現了流量在全國範圍內的任意擴展，極大地提高了資源利用率。最重要的是，我們提升了系統面對城市級故障的能力。螞蟻金服在如此大規模的金融交易系統中實現了這樣的容災能力，這在世界上屬於首創。
高性能分散式事務
眾所周知，金融交易對於一致性要求非常高，傳統銀行集中式核心採用單一事務，要麼全成功，要麼全失敗，非常好的滿足了一致性要求。螞蟻通過微服務架構，實施業務垂直拆分和數據水平拆分，這就意味著存在大量的微服務和大量的單元資料庫，一個完整金融業務需要調用多個服務和資料庫完成，因此，保證服務與數據處理達到金融級的一致性將是面臨的首要難題。傳統技術中的事務一致性方案對資源加鎖的時間長、粒度大，在很大程度上制約了系統的可伸縮性與高可用性，無法滿足架構向單元化、異地多活的發展需要。
為了解決這個難題，我們自主研發和演進SOFA-DTX分散式事務解決方案已經近10年，伴隨著支付寶一起經歷了複雜場景和高並發的挑戰，充分考慮了各類異常情況，具備足夠的伸縮性、高並發和高可用性，支持跨機房的事務協調能力，已經是一套非常成熟的金融級分散式事務框架和服務。該方案引入事務觀察者協調分散式事務的各參與方，達到整體的事務一致性。實現了兩階段提交協議，第一階段採用本地端事務，操作僅預留必要的資源，處理成本足夠低，第二階段可以非同步執行，使得業務整體具備了較高的性能和較強的吞吐能力。
高性能分散式事務：跨服務一致性保證和非同步可靠消息
我們還輔以可靠消息中間件來支持最終一致性的需要，形成了一套事務型消息框架。此類消息發送給消息伺服器與資料庫事務狀態保持一致，當事務狀態是提交時，消息才會被投遞到訂閱者，當事務狀態是回滾時，消息不會被投遞到訂閱者。
分散式事務解決方案被螞蟻金服、網商銀行各業務系統（包含核心賬務等）廣泛使用，從上線至今一直穩定運行，沒有出現任何因為分散式事務機制，導致數據不一致的生產問題。
彈性供給與調度
互聯網化的業務會出現短期的業務高峰，螞蟻金服通過單元化架構化解了業務峰值對系統的衝擊，再通過彈性伸縮架構實現了資源的按需供給。彈性混合雲通過統一資源調度平台實現了資源的快速申請和建站，在業務高峰時將流量和數據動態彈出到新的單元，快速提升系統容量，在業務回落時，將流量和數據彈回，快速釋放雲上資源，從而極大降低資源採購和運行成本。在整個過程中，中間件將應用與基礎設施充分解耦，整個過程對應用系統不需要改變。再通過統一管控平台，將高層的彈性操作，翻譯成各個組件的部署與配置指令，並且統一調度執行，使操作協調一致、精準高效。
彈性供給與統一資源調度：彈性混部架構
彈性操作，需要在流量、數據與資源之間協調一致地操作，尤其是有狀態的數據的彈性操作是最困難的，需要不中斷業務，也需要保證數據的一致性。這些操作如果依靠運維人員人工執行會十分複雜低效，需要架構、中間件與管控系統的支持，其在實踐中有以下關鍵點：
·通過統一資源調度，靈活地申請與分配計算、存儲與網路資源，創建單元，快速部署資料庫、中間件與應用；
·通過中間件，將應用與基礎設施充分解耦，無論流量、數據與資源如何分布，應用系統不需要改變；
·通過分散式架構與數據規範，以及中間件支持，保證所有請求、服務、數據、消息等都有全局唯一的ID和一致的ID編碼規則。根據ID，從接入網關、服務中間件、消息中間件、數據中間件等都能夠正確地路由服務請求與數據訪問；
·通過統一管控平台，將高層的彈性操作，翻譯成各個組件的部署與配置指令，並且統一調度執行，使操作協調一致、精準高效。
·通過單元化伸縮的機制和容器化技術對底層虛擬化平台的屏蔽，實現多個異構機房的資源充分利用，無論基於什麼架構，無論在哪個城市，都可以快速建站部署單元，並在業務高峰期過後快速回收，完成數據的回遷。
金融級雲原生架構的共創設想
我們認可並通過實際行動踐行雲原生架構，但云原生還需繼續發展前行以滿足金融級的需求。對於金融級雲原生架構，我們倡議如下：
· 以「異地多活」為目標--- 使系統容量能在多個數據中心內任意擴展和調度，充分利用伺服器資源，提供機房級容災能力，保證業務連續性。
· 具備「分散式事務」和「無損容災」能力--- 保證在分散式架構下承受高並發交易，在系統擴展、容災恢復、更新發布時確保數據無損，服務可用。
· 整體設計秉承「開放」原則--- 使新興架構向下兼容，能與經典架構有機融合；開放技術標準，擁抱開源生態；提供開放API，實現能力復用、方便二次開發。
金融級雲原生架構的共創設想
從經典IT架構邁向金融級雲原生架構的轉型過程，我們建議應基於業務價值作增量式交付、穩健型創新、演進式規劃，構建中台能力敏捷響應市場需求；在架構和技術選型過程中，應尋求最平衡的發展路徑以滿足業務發展和嚴苛場景考驗，而不僅僅關注功能本身；基於雲原生架構的核心金融系統，還應面對並解決機房級的擴展能力、地區級的容災能力、高並發條件下的分散式事務並做到靈活資源調度以保證成本最優化。
螞蟻金服將持續把多年的積累的經驗和科技向行業分享和開放，提供架構轉型的可落地路徑和相關洞見經驗，也希望能同廣大技術社區和各行業的夥伴深入交流，共同探討和共建金融級雲原生架構標準和最佳實踐，使業務應用能專註需求作敏捷交付，又能同時原生地擁有高可用、一致性和互聯網海量並發、彈性伸縮等金融級基礎架構能力。
我們把這套金融級雲原生的分散式架構解決方案，稱之為SOFA（Scalable Open Financial Architecture），SOFA源自螞蟻內部分散式架構實踐，是一整套完整的金融級中間件產品技術和演進式架構轉型服務體系。
同時，SOFA 體系內的各個組件已經開始逐步向社區開源，鏈接：
https://github.com/alipay
希望能與技術社區共同完善和改進各關鍵產品，支持大家更加敏捷穩妥地實現金融級雲原生架構。
高可用架構
改變互聯網的構建方式
TAG:高可用架構 |