頭條楓林網
螞蟻金服系統架構的升級之路
首先由楊冰為參會人員介紹了螞蟻金服的系統架構發展。 支付寶的第一代架構就像一個個獨立的煙囪，做一個業務就豎起一個煙囪。 煙囪型架構能夠較好地滿足小團隊開發、業務快速試錯的需求，但隨著業務生態越來越豐富，煙囪型架構的缺點就顯露出來了。
比如，每做一個新業務就要將一個煙囪進行手動改造，而支持主要業務的大煙囪則要經歷無數次的改動。 再比如，每個煙囪裡面都會涉及到會員支付等基礎的服務模塊，但由於菸囪之間關聯不大，就無法做到資源的共享，不可避免地寫大量重複性代碼。 同時，煙囪型架構的部署也是集中的，核心系統就是一個集群，數據庫也只有一個，隨著業務量的上升，這樣的數據庫和集群很容易達到極限。
從2006年開始，支付寶的技術團隊意識到，煙囪架構無法支持支付寶未來業務的發展，如果要繼續拓展業務，必須先把架構分佈化，建立底層服務架構。 正如螞蟻金服OceanBase首席架構師馮柯所說，分佈式架構可以通過架構設計和軟件的可靠性來彌補硬件的問題，硬件本身不再需要為系統的可靠性而托底，從而實現基於普通PC 服務器來構建核心業務集群，在性價比方面也會呈現出數量級的壓倒性優勢。
而從2010年因為雙11的原因，交易量一下子就上來了，之前的分佈式架構也開始無法支撐高峰值的業務需求，螞蟻金服逐漸開始將系統部署到雲端，變成了雲平台架構 。
到了2013年，螞蟻金服開始涉足更多的金融場景，不僅有支付，還有理財、保險、消費金融等業務，整個業務的架構也從一個支付云變成了整體的雲金融的架構。 同時為了支撐豐富的業態，也開始從純粹的雲架構變成開放式混合雲架構，逐步便有了螞蟻金服當前的架構雛形。
在架構的演進過程中也存在很多挑戰。 據楊冰介紹，螞蟻的金融級分佈式架構有六大目標，分別是資金安全、高可用、安全、性能、成本和數據質量。 一般來講，一套承載重要業務的系統，必須是高可用的、安全、性能要高，而且要有很好的性價比，但用在金融領域的話，還要強調資金安全和數據質量。
類似螞蟻金服這個體量的機構，對金融分佈式架構就提出了四大要求或者說挑戰：
一是無限擴展能力，為了支撐這麼大的量，要求系統能夠實現靈活地伸縮，突破數據庫，機房，地域等各個層面上的瓶頸。
二是高性能分佈式事務。 當數據在一台物理設備上無法全部存儲時候，就需要分攤到不同的數據庫或者不同的存儲上面去，但是在金融場景裡面又要保證跨庫或者跨存儲的事務一致性，同時還要確保很 高的性能，這是非常大的挑戰。
三是強一致秒級容災。 這個不難理解，像支付寶這麼大的一個體量，如果業務停三分鐘，會產生很大的不良影響，用戶體驗會很差，所以要保證故障的時候能夠快速恢復，以及業務整體的連續。
四是彈性供給與調度。 即不能毫無邊際的用金錢的方式去完成這些挑戰，還是要控制整體的成本。
基於OceanBase的金融雲賦能
從螞蟻金服的整個金融級分佈式架構進化過程不難看出，傳統的集中式架構很難解決一個快速增長的核心企業，對於容量以及容災能力的關鍵訴求。 對於提供雲計算服務的機構而言，如何構建可靠性更高、擴展性更好、成本更低的分佈式架構便成為核心競爭力所在。
要構建這樣的分佈式架構，業界出現了幾種模式，一類是單機數據庫+分佈式中間層，本質是把原本應該由數據庫解決的問題向業務層上移。 在馮柯看來，這種模式會帶來業務侵入、數據庫功能受限和難以確保跨庫數據強一致等潛在問題，相比之下，螞蟻金服的原生分佈式關係數據庫可能是更好的 解決方案， OceanBase便是典型代表。
據馮柯介紹，基於OceanBase的擴展能力，可以方便地實現業務的快速水平擴展和一鍵的擴容縮容，包括完全自動的負載均衡等。 結合螞蟻金服的單元化架構，可以在小時級別將螞蟻金服的任何一個業務從日常模式擴展至大促模式，這是傳統的集中式架構完全無法做到的。 而OceanBase的擴展能力完全是基於數據庫內核的原生能力，也就是說，不管物理層面跨越多少個機房，跨越多少個城市，所有這些參與部署的數據庫服務器在邏輯上是一個OceanBase集群的一部分，無論是 從應用視角還是運維視角，都是整體交付的。
對國內很多自主研發做基礎類軟件產品的團隊而言，除了產品研發之外，最大的挑戰是如何向你的客戶證明你的產品是可靠的。 要證明這一點，要求產品能夠長期的在一些有典型性的示範應用中持續的運行，這就變成了一個死循環，先有雞還是先有蛋的問題。
而 OceanBase成長於螞蟻金服這樣的一個快速發展的互聯網金融企業當中，最不缺的就是應用場景，尤其是金融核心場景。 通過核心業務的不斷上線，螞蟻金服幫助OceanBase渡過了一個對自主研發的基礎軟件產品而講最艱難的應用關。 螞蟻金服本身作為互聯網金融的標杆企業，也通過OceanBase的應用於2017年真正實現了所有核心業務100%去商業數據庫。 時至今日，OceanBase已經支持了阿里巴巴、螞蟻金服數百個關鍵業務的執行，參與了四次的雙11大促。
在沙龍的問答環節，有觀眾問到螞蟻金服科技輸出的路徑問題，楊冰做了回應，提到了三個階段：一是把在實踐中形成的金融級的大規模交易處理能力開放出來， 包括數據庫、分佈式架構、微服務框架以及移動端研發平台、大數據處理平台等；二是逐步開放實時風控、反欺詐、客戶洞察等金融級實時計算能力；三是會逐步開放一些類似於 大數據的PB級的分析數據平台。 此外，技術的開放也會與產品的輸出同步進行，成熟一個輸出一個。
微服務架構立大功
在雲計算平台中，有IaaS雲平台、PaaS雲平台、SaaS雲平台等幾類，在IaaS模式下，服務商主要提供虛擬計算機、存儲、網絡等計算資源和訪問云計算基礎設施的服務接口； 在PaaS模式下，服務提供商提供的則是運行在雲計算基礎設施之上的軟件開發和運行平台；而在SaaS模式下，服務提供商提供的則是可以直接使用的應用軟件。
從IaaS過渡到PaaS的過程中，需要在雲端部署軟件和應用，就產生了雲原生應用的概念，在馮柯看來，所謂原生是指真正在數據庫內核層面去解決掉數據庫本身的可靠性和 擴展性問題。 而Pivotal的吳疆認為，一個雲原生應用應具有四個特點：一是開發運維一體化，二是可以使用CI/CD工具實現持續的發布，三是基於微服務的架構，四是運行在 容器之中。 在構建雲原生應用過程中，微服務架構是不可或缺的基礎和前提。
微服務架構是相對傳統的單體而言的，指把一個複雜的功能分解為若干個獨立的可以相互協作模塊的一種新型架構模式。 在互聯網時代，對系統應用的要求就是“快”，要快速開發、快速部署、快速迭代，快速試錯，微服務架構便是在這種“快”節奏下應運而生的。
單體架構下，各個功能模塊耦合度非常緊密，牽一發而動全身，一點點修改所需要的測試工作量都非常巨大，交付速度很慢，不容易部署，系統吞吐量受限，一旦發生 故障，影響範圍較大，在擴展性等方面也存在局限。 而相比之下，微服務架構的每一個微服務的功能都很簡單，代碼量少，所以功能交付快，也容易部署，且系統吞吐量大，一旦發生故障，影響範圍較小，擴展性 也更好。
不過，有一利也有一弊，微服務架構對系統運維能力也提出了很高的要求，或者說挑戰。 吳疆介紹了Pivotal在這方面的一些感受。 首先是服務拆分，拆分之後要考慮服務的隔離，同時服務之間會有同步或異步的依賴，此時需要對這些依賴進行管理，否則服務之間耦合度過高，在系統進行升級的 時候，就會變得很困難。 此外，還要考慮服務治理、服務追踪、服務監控等問題。 以服務追踪為例，系統分佈式化之後，一個請求進來，處理這個請求需要很多的微服務進行配合，互相工作，才能最終完成這個請求，還會涉及到日誌的管理、會話的識別、還有 聯合診斷等等方面，這也是一個新的挑戰。
傳統金融機構科技轉型的路徑
據《哈佛商業評論》的調查，在包括消費金融領域的十個行業是受數字化浪潮最大的行業。 在裴興蕊看來，傳統金融企業要建立開放的金融生態需要做到三點：第一要圍繞客戶全生命週期做整個用戶體驗的重構；第二要做到基於數據的全維度和數據分析。 第三點是能夠進行全價值鏈的佈局。 同時這三點也是傳統金融企業做數字化轉型的關鍵點。
同時，金融企業的Fintech創新引擎要解決四個關鍵性問題：第一個是如何聚焦價值，第二個是如何做到快速的驗證，第三個是怎麼能夠做到內外部的協作，第四 個是如何建設允許失敗的創新文化。 這四種支撐起到了價值閉環的作用。 第四點在互聯網公司是非常順理成章的事情，但是在傳統金融企業卻舉步維艱。
以ThoughtWorks的經驗來看，以上的四大支撐其實體現了數字化企業在做轉型的四個核心能力，第一個是以客戶為中心的服務設計能力，第二點是面向價值的端到端的產品 開發能力。 第三個數據驅動的洞察和運營能力。 第四個是以服務化為中心的開放中台能力。 數字平台戰略就是企業在構建上述四種能力的非常有效的方式。
企業數字平台是基於雲計算Iaas能力之上為數字化戰略提供能力支撐的一系列平台服務，涵蓋IT系統研發與運營全生命週期，處於這個環節的最中間，它是提供客戶洞察、服務供給、數據 決策和實驗創新這四大支撐能力的基礎。
在講到資源服務化平台的快速供給時，裴興蕊為聽眾舉了一個如何區別微服務和單體應用的有趣例子：樂高的玩具有兩種，一種是大塊的拼裝玩具，可以拼插幾 種固定的形狀，組合方便，但一個部件壞了會對整體拼裝有很大影響，這就像是一個單體的業務應用一樣；另外一種是小塊的樂高，它可以拼插成各種 形狀，非常靈活，它就像面向業務的微服務單元一樣，但是小塊樂高的拼裝難度會更大，對小朋友來說組裝較為困難。 微服務的困難在於調用和組裝難度大，包括它的配置管理、服務名冊、服務網關等。 它就像是面向大人的樂高積木一樣，需要更強的專業性才能實現。 這時資源服務化平台就很好的解決了這個問題，能夠覆蓋微服務的全生命週期，通過內部資源的服務化，促成內外部能力的打通，和內部能力的外化。 有效的解決了微服務在構建調用和註冊過程中的一系列的難題。
科技發展的量變到質變
最後由來自眾安科技的吳婧琦分享了眾安在Saas層面的應用與實際案例。 在眾安看來，金融科技的發展經歷了渠道驅動型的1.0互聯網金融、技術驅動型的2.0智能金融及跨界融合型的3.0融合金融三個階段。
吳婧婍認為，金融科技的演進有兩大驅動力，一是技術驅動，將原先需要人工花費大量時間處理的業務流程，通過系統升級、智能風控、生物識別、OCR識別等技術手段實現秒 級處理，提升業務效率；二是業務驅動，通過增加運營分析、監管合規、增信措施等等的方式，提升精細化運營水平。
結合眾安科技與城商銀行的案例進行解讀。 隨著前沿科技不斷滲透到各行各業，城商銀行也在尋求業務互聯網化轉型的契機，但該銀行在現有的系統支撐，大數據風險管理以及互聯網運營分析方面，都存在較大挑戰。 眾安科技為該銀行客戶提供了以互聯網的信貸交易系統以及資金資產交易系統為基礎的解決方案，同時對接增信方，引入全流程實時風險控制、數據化運營管理涵蓋整個信貸週期的消費金融 解決方案。 通過底層區塊鏈的運用，所有資產數據不可篡改、逐筆還原，且基於大數據和人工智能技術對業務數據進行智能監控，實現業務風險實時預警，並提供標準的合規審計與監管報送 工具，實現資產面對監管合規的穿透要求。
總體而言，眾安科技為該銀行提供的解決方案從技術和業務兩大層面，驅動業務的成功開展，體現了技術創新和業務賦能的雙重價值，最終實現互利共贏，共建生態的 合作宗旨。
在最後的圓桌討論環節有觀眾問到，眾安作為互聯網保險公司與傳統保險公司的區別是什麼？ 它的邏輯又有何不同？ 吳婧琦認為，嚴格意義上講眾安也並沒有改變保險的核心邏輯，保險還是靠精算。 但是之前的精算是拿精算表，更新速度相對緩慢。 可用到大數據和實時計算的時候，精算賠付表是可以做到實時更新的。 以眾安的延誤險為例，以往的延誤險需要提前一天買，而眾安的延誤險可以提前半天甚至一個小時都能買，背後是有一整套的體係來支撐業務。 科技賦能之後並不會改變保險的核心邏輯，而是把很多的底層的技術和應用做更好的提升，同時為保險創造更多的場景和可能。
寫在最後
在新興的互聯網企業積極發展金融科技的同時，傳統金融機構對大數據、雲計算、人工智能、區塊鍊等技術的接受程度也越來越高，銀行等傳統機構甚至更為激進地走在 了浪潮的前沿，成立相應的數字化體驗部門或互金中心。 而隨著監管體系的不斷完善和技術應用的逐漸普及，金融科技的紅利也將逐步顯現出來，即使科技無法顛覆金融的邏輯，但以銀行、保險、證券、基金、互金為代表的機構也 必將迎來新的變革。
未來面前，你我還都是孩子，還不去下載 虎嗅App 猛嗅創新！