任何對新技術或是新產品邏輯的探索，并不會自動地等同于其發展道路上的救命稻草，光鮮的技術名詞或許能帶來短暫的估值光環，卻未必能改變廠商長久以來的To B商業化困境。

傳統To B的雙輸困局

To B商業化實際上一直存在著一種“雙輸”局面。

百融云創首席產品與市場官王偉民，在接受雷峰網采訪時指出，傳統模式下，甲方企業對軟件或服務的采購邏輯，一直是“價低者得”的招標思維，既要產品卓越又要成本低廉；而乙方廠商的生存邏輯，則是在有限預算內完成交付并爭取微薄利潤。

早在云計算火熱、廠商和客戶都熱衷于數字化轉型的時期，這種“甲方總是不滿，乙方總是疲憊”的局面，其實就已經存在了：甲方抱怨不好用，甚至會因為效果不達預期，直接讓項目成果直接束之高閣；乙方抱怨客戶需求善變、付款苛刻，有些客戶索取的不像是商品，倒像是情緒價值。

這種局面，也催生了To B行業難以掙脫的衍生困境。我們此前在《云計算五問》等多篇文章中都提到過，困境之一，是標準化與定制化之困：為了贏得訂單，軟件廠商不得不向大客戶的個性化需求低頭，陷入無休止的定制化開發，使產品變得臃腫、非標，最終淪為“項目制”作坊，徹底偏離了通過標準化產品實現規模效應的初衷。

抉擇之二，是增長與健康度之困：追求合同額與市場占有率，往往意味著卷入低價競爭和人力成本的軍備競賽；若想追求盈利質量，堅持產品化與高定價，則可能在殘酷競爭中迅速丟失份額，更快地面臨生存危機。

困境的根源，本質上是來自于過時的交易模式：甲方支付的，是購買功能模塊、軟件許可或人力工時的費用，即生產資料的成本；而他們真正渴望獲得的，是一個清晰的業務結果。

打破這一困境的核心，應當是建立“風險共擔、利益共享”的新型甲乙方關系——讓乙方的收入，與它為甲方創造的可量化業務價值直接掛鉤。這正是“結果即服務（RaaS）”的核心理念：乙方不再是“賣軟件的供應商”，而是“共擔風險的合作伙伴”；甲方不再是“買工具的采購方”，而是“共享收益的同盟者”。 

而百融云創已經率先開啟了嘗試，將RaaS模式從理念轉化為規模化落地的實踐。在12月18日的發布會上，百融云創發布了自己的RaaS戰略和“結果云（Results Cloud）”平臺，正是這種新型關系的實體化載體。

告別“賣鏟子”的商業模式

要打破“工具買賣”的零和博弈，需要的不僅是一個新概念，更需要對產業價值鏈條的深刻重構能力。百融云創之所以能率先探索“結果即服務”的企業級AI新范式實踐，正源于其自身商業模式的持續進化史。

百融云創的創始人張韶峰，基于自己在甲骨文、IBM時的觀察，從一開始就摒棄了傳統“交付工具”的思路。在2014年創業初期，數據與AI能力尚屬稀缺資源時，百融選擇以MaaS（模型即服務）切入，通過API按調用量計費。這本質是將核心的“數據+算法+行業經驗”進行產品化封裝，以最高效、標準的方式為金融機構提供KYC能力。在這一階段，按調用收費是技術價值可衡量、服務可規模化的最優解。

百融云創創始人張韶峰

到了2017年，隨著語音交互技術的成熟與平臺經濟的興起，百融的業務演進至BaaS（業務即服務）階段。 其邏輯從“提供分析能力”升級為“構建交易場景”，通過連接海量B端金融機構與C端用戶，扮演智能匹配撮合平臺的角色。其商業模式也相應變為“僅成交后分潤”，收入與為客戶促成的實際交易緊密掛鉤。這也意味著，百融的價值承諾，已經從“提供有效工具”，向前邁進到“參與業務成效”的階段。

回顧這段從MaaS到BaaS的演進史，有一個經典的To B行業命題，值得我們重新思考：我們究竟是在“賣水”，還是“賣鏟子”？

在此前的技術浪潮中，無論是云計算還是AI，廠商常常陷入這種爭論。“賣鏟子”意味著提供基礎的工具和算力，相對標準化；“賣水”則是提供基于工具的增值服務或解決方案，常結合場景而呈現定制化。二者均對結果的價值有所助力，但都是客戶先付錢，乙方再交付，客戶要自行承擔 “付了錢沒結果” 的風險，這就回到了文章開頭提到的To B困局。

百融云創探索的RaaS模式，其實指向了第三條路：帶著自己錘煉多年的數據、算法、行業經驗，跳進一線與客戶并肩“共同挖金子”。“結果云”是其統一的作業平臺，“硅基員工”是其專業化的數字勞動力，收費取決于最終挖出的“金子”——即可衡量的業務成果，并以此參與價值分配。

在百融的實踐經驗里，“共同挖金子”的伙伴關系，已經被具象化為一套清晰、可執行的商業模式。目前，百融云創主要通過三種方式與客戶進行價值結算，共同構成了其RaaS（結果即服務）的價值交付體系。

其中最核心且具顛覆性的，是“按崗位計價” 的新模式。這也是業界對于AI Agent發展的理想終局之一。它徹底重構了定價邏輯，直接參照現實世界中人類專家的薪資水平，為承擔同等職責的“硅基員工”定價。

例如，一個相當于月薪3萬元法務專家的“硅基員工”，其服務定價約為1.5萬元。客戶無需任何軟硬件前置投入，即可獲得一個能7×24小時工作、效率數倍于人類且投資回報率清晰的硅基勞動力團隊，并像支付薪酬一樣，按實際使用的崗位數量進行月度結算。

在此基礎上，百融也延續并升級了更為標準化的“按量計件”模式，例如為汽車金融客戶生成每一份信審報告，或撰寫深度投研報告，都按實際交付的合格成果份數進行結算，使計費與明確的業務產出掛鉤。此前的BaaS邏輯也延續了下來，即為金融機構成功撮合交易后，按最終達成的業績進行分潤。

這三種由淺入深的結算方式，共同實踐著“不為過程賣工具，只為結果共分配”的核心原則，將合作雙方緊密地轉變為利益共同體。

RaaS的工程化答卷

這一套從理念到結算的完整商業閉環，若要實現穩定、規模化地交付“結果”，離不開一個強大而靈活的技術基座作為支撐。百融云創也為此推出了承載RaaS理念的工程化核心：Results Cloud（結果云）平臺。

王偉民向雷峰網清晰講述了“結果云”平臺的運轉，這套讓“硅基員工”能夠被高效創造、管理和規模化運營的智能體生態系統，其架構清晰分為三層，共同構建了從底層算力到頂層智能體應用的全棧服務能力。

在最底層的是AI基礎設施層，涵蓋了從英偉達到國產海光、昇騰等異構算力，Results Cloud不僅深度集成主流開源與商用模型，更基于多年產業場景沉淀，構建了覆蓋語言理解、語音交互、多模態文檔處理三大方向的自有大模型家族——包括 BR-LLM-Proactive、BR-VOICE 和 BR-Vision-Doc等旗艦模型。這些模型深度融合行業知識與結果導向機制，為“硅基員工”提供可調度、可進化、可對齊業務KPI的專業認知能力，確保“硅基員工”擁有穩定、高效且自主可控的算力與智力源泉。

在此之上是智能體操作系統層，為無論是百融自身的業務部門還是未來的第三方伙伴，都提供了一套完整的工具鏈，支持智能體的全生命周期管理，包括開發、部署、運行、觀測與調優。開發者可以像在移動互聯網時代開發App一樣，在此高效地創建和迭代各類業務智能體。

最終，所有這些能力在頂層的智能體商店層匯聚，并面向最終價值場景。這里陳列著兩大類“硅基員工”：一類是直接面向客戶業務增量的智能體，如營銷、客服專家；另一類是服務于內部提效的智能體，如HR、財務、法務助手。它們不再是孤立的功能模塊，而是基于統一平臺生長出的、可計量、可運營的數字化生產力。

值得注意的是，負責復雜決策的智能體，在企業級落地中普遍面臨“連接不穩、知識不準、運維失控”三大工程化難題，任何一環的缺失都會讓“交付結果”的承諾淪為空談。百融云創通過MCP統一連接、GraphRAG知識工程、AgentDevOps運維體系等工程體系能力，為RaaS筑牢了技術根基。

首先，在企業級合作中，標準碎片化、安全顧慮和復雜的運維，使得傳統對接方式成本高昂且脆弱，一旦出問題，甲乙雙方極易陷入拉扯停滯的狀態。百融云創的解法，是在其“結果云”與“百融百工”平臺中，將開源社區提出的模型上下文協議（MCP） 深化為統一、可治理的連接核心，實現了對多模型、多工具、多業務系統的“一站式接入”，大幅降低了企業因協議不一而重復適配的成本。倘若能在對接環節就構建完善的安全治理與審計機制，明確數據訪問的權限邊界，就能從根源上規避了跨系統數據泄露的風險，并將運維管理標準化，進一步使得“硅基員工”能夠以即插即用的方式無縫融入企業現有流程。

其次，傳統AI常因知識檢索粗糙而“答非所問”，尤其是在金融、法律等要求高精準性、高一致性的領域。百融沒有采用簡單堆砌知識庫的做法，而是致力于構建一條 “可治理的知識資產鏈路” 。其工程體系聚焦三大核心能力：一是高精度文檔解析，能將復雜的非結構化文檔（如PDF、財報）準確轉化為結構化信息，為后續處理打下堅實基礎；二是嚴格的知識版本治理，確保“硅基員工”始終引用最新的規章制度，避免引用過期規則的低級錯誤；三是意圖澄清能力，基于結構化知識樹做可控的意圖澄清，才能精準地獲取用戶實際問題，最終輸出可靠的答案。

第三，傳統DevOps關心“系統是否可用”，但智能體的價值在于“任務是否完成、判斷是否準確”。百融云創的AgentDevOps體系，正是針對“推理型系統”的全新工程方法，其核心是確保智能體的行為質量與持續進化能力。具體從四個方向推進落地：

• 全流程工程能力，覆蓋開發 - 調試 - 部署 - 監控 - 優化的全鏈路；

• 場景化評估器：在業務維度實時跟蹤“硅基員工”的實際表現，每一個節點、每一個業務指標的變化都可視化；

• 半監督自適應優化：在開發階段自動搜索最優參數與提示詞（ Prompt ）組合，使 Al Agent 快速達到可上線標準；

• 強化學習增強的在線優化：在運營階段基于回流數據持續迭代策略，讓 Al Agent 隨使用不斷更穩、更佳。

在落地實踐中，這些系統性增強帶來顯著且可量化的效果，比如，人工調參與維護的成本顯著下降，Al Agent 的上線周期大幅縮短，并且超過 70% 的典型應用場景實現了自動優化，穩定性提升明顯，Al Agent的產出質量持續增強。

可以看到，這三大工程能力環環相扣，共同構成一個堅實的閉環：MCP保障了“硅基員工”能安全、穩定地接入企業環境；GraphRAG確保了其在專業領域內輸出的知識是精準、可靠的；AgentDevOps則賦予了其持續觀測、調試與進化的生命力。 它們共同將“結果云”從一個技術平臺，升級為能持續交付、優化并驗證業務結果的工程體系，使得“按崗位計價”“按效果分潤”的RaaS商業模式，具備了扎實可靠的技術支撐。

從“替代恐懼”到“價值同盟”

商業模式和工程能力的討論固然重要，但當這些硅基勞動力真正走入企業，與人類員工并肩工作時，挑戰會直接躍升至組織與協作層面：硅基員工是否直接取代人類員工（碳基員工）？

在與多位從業者的交流中，我們注意到，眼下有關智能體的討論雖然如火如荼，但在落地環節往往會迎來極大阻礙。一位CTO向雷峰網透露，智能體越是高效，越容易讓一些部門高管心生抵觸，智能體實際“上崗”取代人類員工，也就意味著高管們手下的headcount會一減再減，影響其在企業內部的話語權。

這一尖銳的議題，或許還能有別的答案。百融云創給出的答案，則指向了一個更具建設性的未來范式：硅碳共治，追求協作而非替代。硅基員工憑借其效率與穩定性，規模化承接定義清晰、重復性高的任務；而碳基（人類）員工則被解放至需要復雜判斷、創造性思維和情感交互的高價值領域。

王偉民告訴雷峰網，在百融看來，部分工作流程（如標準化信息查詢、初版報告生成）已可由硅基員工獨立完成；在風險審核、合規校驗等關鍵環節，則采用“硅基初審、人類專家復核”的模式；更多時候，兩者需要緊密配合，由硅基員工實時提供數據分析和知識支持，人類員工在此基礎上做出最終決策。

百融云創首席產品與市場官王偉民

雙方協作的具體比例因工作性質而異，但目標始終統一：圍繞一個共同的、可量化的“業務結果”，重新編織工作流，實現整體效率與質量的最優解。

這一轉變若推廣開來，則有望打破傳統軟件采購中固有的“壓價-減配”死循環。當甲乙雙方的利益，通過對“硅基員工”的績效KPI（如審核準確率、問題解決率）達成共識并緊密綁定時，雙方的博弈焦點便從“如何為工具成本砍價”，轉向了“如何協同優化，讓數字勞動力創造更大價值”。這便從根源上化解了因目標錯位而導致的內耗，使合作關系從甲乙方進化成為真正的“價值同盟”。

百融云創的野心，顯然不止于重塑單一的客戶關系。其更深層的行業愿景，在于以自身實踐為藍本，推動整個To B行業從“價低者得”的惡性競爭，轉向“價值為王”的良性生態。一個健康的RaaS生態，需要更多參與者共同實踐“為可衡量的業務價值付費”這一準則。為此，百融的核心動作是 “開放賦能”，即通過百工平臺向更多機構開放底座，讓合作伙伴能夠在平臺之上沉淀自身的場景經驗。

然而，開放生態也伴隨著復雜性的提升，業界對于智能體的責任界定方面也有一定爭議。王偉民透露，百融的應對思路是推動智能體向“標準化模板與可定制部分”相結合的方向發展：平臺提供經過驗證的基礎能力模板與合規框架，開發者可在可控范圍內進行定制。同時，平臺具備的學習與迭代能力，也能持續優化智能體的行為邊界。

縱觀百融云創從商業模式到工程架構，再到組織協同的完整藍圖，其真正試圖構建的，或許是一種適應智能時代的新生產關系。在這里，軟件不再是冷冰冰的、有待驗收的“交付物”，而進化為可考核、可優化、能共同成長的“數字同事”；合作也不再是切割責任的一紙合同，而是一場圍繞共同目標展開的動態共創。

“硅碳共治”是這幅藍圖的運行狀態，它的終極目標，是讓技術進步的收益，能以更清晰、更公平的方式，在創造者、使用者和賦能者之間進行分配。

硅基員工已經站在門外，這場生產關系的變革，可能比我們想象的更早到來。

6月18日，雷峰網受邀參加了2024騰訊云融合創新大會。在這場活動上，不僅有騰訊云諸多產品負責人分享了他們在各自領域的自主創新探索，同時還有一批先行先試企業開始站出來，如工信部、太平人壽、交通運輸部、廣西北部灣銀行、興業銀行、山西證券等，分享了過去他們國產方向的創新與實踐。

整場活動觀察下來發現，上述提到的企業對國產產品的不信任感，到眼下這個節點，已經在被迅速打破，且機構的自主創新速度在進一步加快。

據騰訊云副總裁胡利明表示，即便2023年大環境經濟壓力大，企業IT預算縮緊，但過去一年，金融機構在國產領域的投入顯著增加，頭部機構已完成技術可行性驗證和風險評估，區域性機構開始大規模跟進。

廣西北部灣銀行股份有限公司副行長葉友表示，去年他們銀行國產技術的采購金額比較大，占比達到86.33%。

除了不信任感進一步被打破，自主創新提速升級之外，從大會也可以觀察到另一個現象：在自主創新潮中，數據庫作為基礎軟件“皇冠上的明珠”走在了前頭。

“目前TDSQL已實實在在成為我們行基礎軟件的重要軟件支撐底座。”興業銀行科技管理部高級經理胡凡表示。

興業銀行在2020年啟動了分布式數據庫的選型工作，并最終選擇TDSQL作為試點數據庫，到現在完成面向全行分布式數據庫體系建設，并且有手機銀行類、零售網貸類、數字錢包類、移動生活APP類等多個行內重要信息系統使用TDSQL，部署規模超過300個節點。

除數據庫自主創新升級之外，這兩年大數據平臺的改造工作也提速了。在會上，很多企業也分享了他們大數據平臺自主創新的案例。胡利明在采訪時透露，今年騰訊云的大數據平臺需求超過數據庫。

企業大數據平臺建設速度加快，這也并不奇怪，數字化轉型的基礎是數據，把數據收集起來、管起來、用起來是所有企業在未來市場取得競爭力的關鍵。

近幾年大數據平臺的技術沿著湖倉一體化技術棧在演進。在這個演進過程中，市面上也出現了一種觀點，認為只有大型機構才有應用湖倉一體化技術棧的必要性，而中小機構應用性價比不高。

騰訊云大數據總經理徐曉敏認為，只要湖倉一體整合好的情況下，它的綜合投入產出比實際是更高的，因為湖倉一體化之后，就不需要引入那么多的技術棧，同時在湖的技術架構上也不會需要對那么多的計算組件挨個維護。此外，同時在整個聯動性和業務創新上它有更多的價值。

太平人壽就是一個案例，過去他們搞各種營銷活動，其后臺數據系統都只能采用T+1的數據更新模式，即今天進行的活動，第二天才能看到相關數據。現在，太平人壽采用湖倉一體的騰訊大數據平臺，將數據更新速度從一天縮短至半小時，甚至五分鐘，這對公司的經營決策帶來顯著好處。

不過，企業國產化提速，也離不開產業機構積極融入自身行業的自主創新生態中，加大技術創新和產品的供給力度，在產品成熟度和技術自主可控度等方面不斷突破，推動國產產品從可用到好用不斷成熟。

“以前很多金融機構常會質疑國產的能不能用，但現在可以非常自信地回答這個問題，我們是行的。”胡利明說道。

去年，騰訊金融云是提了三個小目標，一個是加速金融軟件的產品開發，第二個打造更多金融產品解決方案，第三是去構建金融產品生態。而今年胡利明表示，這三個方向都有了不少進展。

在產品開發上，數據庫、專有云、大數據等產品都有了新的升級，比如數據庫，去年做了HTAP混合式負載的支持，以及對數據庫內核不斷新的優化、智能運維、AI用在數據庫的慢查詢等等。過去一年他們的大數據研發投入基本上是翻倍的狀態。在解決方案上，過去幾年，騰訊云與幾個頭部的保險、券商合作，打造標桿案例，之后會把這些自主創新的方案進一步的去擴展和復制。而在生態方面，除了進一步加強與硬件、服務器、網絡、操作系統等領域朋友合作外，他們還開拓了保險等行業上下游生態伙伴。

據了解，截止到今年5月份，騰訊云總共有99款產品進入工委會軟硬件圖譜，取得了1398項互認證證書，獲得自主創新優秀解決方案及相關獎項超40項，參與標準課題研究超70項。TDSQL集中式數據庫和TencentOS服務器操作系統通過了國家的安全可靠測評，分布式數據庫也在測評中。

不過，國產產品在從"可用"階段邁向"好用"階段的過程中，確實還面臨一些關鍵問題需要解決。

胡利明對雷峰網說道，第一是低延時，很多行業對于延時性是有極高要求的，特別是金融，低延時才能確保交易的實時性和準確性，避免因系統延遲造成的損失。第二是易用性，產品界面復雜，新用戶難以快速上手，產品功能繁多，但缺乏有效的引導和幫助文檔，使得企業需要花費大量時間學習等情況很常見，第三是人員的培訓，像是原來的國產軟件廠商，比如說Oracle，他們已經建立一套培訓體系來幫助企業學習使用軟件，但目前國內軟件在這方面還有待提升。

只有解決低延時、提高易用性、加強人員培訓等問題，國產產品將更加成熟和完善，更好地滿足市場和用戶的需求。

8月17日，騰訊發布2022年第二季度業績報告。其中，總營收1340億元，“金融科技及企業服務”營收422億元，占總營收的31.5%。

財報指出，To B業務成為騰訊收入的重要支柱，連續五季收入占比超30%；因收入結構得以優化，降低成本，企業服務毛利率環比提升。

2021年第四季度，騰訊把To B業務目標定在了“健康可持續”上。這一目標提出至今，已過去大半年時間，期間，騰訊的To B做了這樣幾件事：

一是提高產品自研競爭力，“聚焦高質量的收入增長，優先專注自研產品同時減少虧損項目。”

本次財報也指出，PaaS方面，TDSQL數據庫收入同比增長超過30%，占2022年第二季企業服務營收超過5%——這是騰訊首次在財報中，披露數據庫產品的收入增幅。

二是鼓勵產品被集成，而非一味死磕總集成和轉包的做法。

此前雷峰網也多次寫到，重營收規模、重發展增速的階段將逐漸過去，聚焦在高毛利、標準化的產品上，調整收入結構，會是云廠商的必經之路。

三是騰訊云與智慧產業事業群（CSIG）于今年7月，宣布成立政企業務線，持續深耕政務、工業、能源、文旅、農業、地產、體育、運營商等領域。李強出任政企業務線總裁，全面負責行業團隊管理和區域業務拓展。

不久前，騰訊還宣布自研業務全面上云，上云規模突破5000萬核，累計節省成本超30億，這也為騰訊在面對B端客戶時，增添了更多底氣。

其實從財報整體而言，這張成績單難言理想。“凈利腰斬”這樣的字眼，某種程度上也說明了騰訊的處境，算不上是順風順水。

再看中國云市場，也仍處在動蕩變化之中，局內人無一不被內卷和焦慮裹挾。

但越是逆境之中，越是筋疲力竭，就越該把力氣花在刀刃上。

一把磨了十五年的利刃

“自研產品”，是騰訊To B選中的刀刃之一。本次財報中，以數據庫為首的自研產品，所給出的成績，證明了這把刀刃日漸鋒利，可供騰訊在To B的叢林中披荊斬棘。

此前我們在《云·五問》曾分析過，為何國內云廠商一直不如國外同行賺錢：

通常來說，云廠商的成本結構通常包含基礎硬件和軟件研發兩部分。與之對應，云廠商提高利潤率的方法主要有：通過擴大用戶服務數，做大基礎設施規模，靠規模效應攤薄硬件成本；控制定制化項目和集成項目的規模；多做毛利率高的標準化產品。

但要想做好數據庫等高毛利的產品，談何容易。有業內人士向雷峰網指出，數據庫是基礎軟件的三架馬車之一，關乎企業核心業務系統，可這一領域屬性重、壁壘高，需要花費極大的時間、資金、精力，廠商必須戒驕戒躁，沉下心來長期投入。

利刃磨成，非一日之功。“長期投入”應該有多長，沒有標準答案，而騰訊云數據庫已經度過了十四年。

故事可以追溯至2007年，當時騰訊內部開始需要做增值業務、計費業務等泛金融場景的支撐，迫切需要符合數據強一致、穩定可靠、系統高可用性等特性的數據庫。

2009年，騰訊進入開放時代，誕生了開心農場等代表性產品，但全面開放策略同時也帶給騰訊巨大的技術挑戰。當時互聯網行業也逐步進入全民社交的高速發展時代，每秒億級并發的場景比比皆是。

騰訊云CTO王慧星回憶，當時的全面開放策略之下，騰訊與外部合作伙伴的接觸逐漸增多，一些游戲廠商將自家游戲業務接入到QZone、QQ秀等大流量平臺時，經常會被上面的用戶流量一下子沖垮。

“在面對海量互聯網用戶高并發，面對一些對延時很敏感的業務形態時，大家意識到，騰訊是可以在這個地方去做不少事情的。”

這一階段，支撐騰訊計費支付業務的騰訊數據庫，在7*24小時高可用、數據強一致的基礎上，對高性能吞吐、分布式水平擴展、分布式KV存儲等進行了研發布局，幫助擺脫業務系統流量對服務器數量的依賴，以及突破了性能瓶頸、數據可靠性保障、高可用等“不可能三角”的技術難題。

當時在騰訊內部，部分業務對數據庫不僅僅要求純交易型（OLTP）的能力，還需要比如復雜的關聯查詢、或者按天匯總等偏分析的場景支持。

簡單來說，OLTP側重于記錄事件的發生，但當記錄的內容累積到一定厚度，我們需要對此作出總結分析時，OLAP就該登場了。

從2011年開始，騰訊云相關數據庫團隊，開始關注PostgreSQL數據庫的研究，并在2014年開始正式探索OLAP型數據庫研發與應用，布局安全可控的分析型數據庫領域——這便是現在的TDSQL-A的雛形。

與此同時，隨著云計算興起，數據庫走到上云時代，數據庫產品服務的提供也逐漸離不開云為基礎。騰訊數據庫產品能力，也正是從這個時候開始，經歷了公有云上海量實際用戶場景的打磨。

在2014-2020年期間，國產數據庫走向行業大規模應用，也是騰訊云數據庫更直接走到臺前的一段時期。微眾銀行是國內首家采用互聯網分布式技術架構的銀行，也是首家核心系統未采用Oracle等集中式商業數據庫的銀行。在其背后，TDSQL作為其分布式數據庫底座承擔了非常核心的作用。

“那是TDSQL第一次作為交付型的產品，真正使用到銀行的核心系統里面。”騰訊云相關人士向雷峰網回憶道。

從多年前的內部增值業務、計費業務等泛金融場景起步，騰訊云數據庫先后經歷了賦能互聯網新興產業和民生政務兩大發展階段，近兩年，金融行業逐漸成為其主戰場。

在金融領域，淬煉至極致

但這場比賽才剛剛進入到拼刺刀見血的時候。

如果說數據庫是皇冠明珠，那金融數據庫，大抵就是明珠上最奪目的一點光芒。

核心系統數據庫存儲著銀行核心交易信息，包括用戶財務數據、銀行交易記錄等重要信息，銀行在核心系統數據庫替代方面尤為謹慎。

金融數據庫地位之險要，說明了銀行為何遲遲難去IOE，也說明了金融核心國產替代為何勢在必行。

過去數十年內，數據庫的牌桌上鮮有中國廠商的身影，但大數據和云計算的出現，讓國產數據庫有了更多底牌。

當數據爆發式增長，甲骨文這類集中式的數據庫處理起來開始顯得力不從心。在這個背景下，分布式數據庫應運而生。分布式數據庫能夠根據需求彈性伸縮，能處理幾乎無限量的數據。

曾有知名數據庫廠商CTO對雷峰網表示：“相比于傳統單機版的經典數據庫，由于其積累的時間更長，國產數據庫的成熟度肯定還是會差一些。但是在云數據庫領域，我國與國外的同類產品相比，技術上已經沒有任何差距，甚至在一些高并發的場景上，國產數據庫更具有優勢。”

與此同時，近年來，中國人民銀行、銀保監會等主管部門密集出臺文件，推動以銀行業為主的金融行業加快實現自主可控技術創新。面對“卡脖子”的現實困境，銀行核心系統的全鏈路信創國產化尤其緊迫。

銀行業也開始嘗試引入國產數據庫技術替代國外數據庫，但出于穩定性的高度謹慎，國產數據庫還是多被應用在互聯網核心以及相關外圍系統中，在業務種類多、流程復雜的傳統核心系統中應用，被視為檢驗國產數據庫的試金石，也是行業里程碑式的挑戰。

以昆山農商行核心系統替換為例，基于國產分布式數據庫騰訊云TDSQL打造的新一代核心系統成功投產上線后，高頻帳戶類交易平均響應時間在300毫秒之內，查詢類交易平均交易響應時間在100毫秒之內，96秒能完成10萬筆社保代發，性能遠超原核心系統，在全國同類型銀行中處于領先地位。

昆山農商行僅是騰訊云數據庫服務的眾多銀行之一。據統計，騰訊云分布式數據庫TDSQL已服務近半國內TOP 20銀行，TOP10銀行中服務比例高達60%，包括中國銀行、平安銀行等。

在金融行業“攻城拔寨”的過程，自然滿是艱辛。

騰訊云數據庫技術負責人潘安群曾向雷峰網感慨，“每次的POC測試都是對抗性的，友商坐在對面，甲方坐在旁邊，都盯著看，完全是檢驗產品和技術實力的赤身肉搏戰。”

他們所面對的客戶，從互聯網銀行到農商行、城商行、股份行，再到國有大行。在“面對疑慮、消除疑慮、獲取信任”的不斷循環中，騰訊云數據庫得以穩扎穩打，穩步向前。

大量的摸底測試和POC測試，考驗重重，也讓團隊養成了“人有我無，就敏捷跟上；人有我優，就繼續保持和優化”的好習慣，整體團隊能力得到了有效提升。這種“邊戰邊學”，讓騰訊云數據庫在過去十幾年的發展中，一直保持著在產品和技術研發上的創新迭代力。

據了解，騰訊云數據庫目前已形成較為全面的產品矩陣，包括關系型數據庫、非關系型數據庫、國產分布式數據庫、數據庫SaaS產品四大部分。

今年第二季度，云原生數據庫TDSQL-C新版本正式對外，在云原生架構、基礎硬件能力、自研內核等方面進行了全面升級。性能測試結果顯示，在全緩存場景、大數據集等場景中，新版TDSQL-C對比傳統云數據庫有近200%的性能提升。

首款軟硬件結合、高速低延遲的分布式數據庫產品KeeWiDB，和實現300%性能提升的Redis高性能版本，也同樣在這一季度發布。

長期以來，騰訊“產品強”的口碑都是眾所周知的，但那是To C互聯網時代的美譽。在產業互聯網時代，騰訊能否在To B領域中延續這樣的美譽？或許，數據庫會將這樣的故事延續下去。

“五年6次POC測試，最終拿到農行核心系統項目，對我們來說意義非常大。”時隔快一年，騰訊云副總裁李綱想起這段經歷時仍感慨不已。

金融行業是騰訊云數據庫目前的主戰場。近年來，中國人民銀行、銀保監會等主管部門密集出臺文件，推動以銀行業為主的金融行業加快實現自主可控技術創新。

核心系統是銀行的心臟，面對“卡脖子”的現實困境，銀行核心系統的全鏈路信創國產化尤其緊迫。

此前盡管各大云和數據庫廠商都重兵投入，但在這項關鍵環節上一直未有大的進展，而現在這一紀錄被騰訊打破。

在李綱看來，與農行，以及類似中行的合作中，騰訊云數據庫不僅實現了國有大行案例零的突破，更助力了國有大行首次實現核心系統全鏈路信創國產化，完成行業從0到1的跨越。

事實上，騰訊云數據庫的成績遠不止這些。自2014年第一次作為交付型產品賦能微眾銀行至今，騰訊云數據庫目前已服務了近半國內TOP 20銀行，在TOP10銀行中的服務比例高達60%，頗有一騎絕塵之感。

而這些成績背后，是騰訊云數據庫在樹標桿、插紅旗、拓生態上持續不懈的爬坡向上，五年6次POC測試最終拿到大單，更像是其一路成長的縮影。

赤身肉搏下的產品創新力

“每次的POC測試都是對抗性的，友商坐在對面，甲方坐在旁邊，都盯著看，完全是檢驗產品和技術實力的赤身肉搏戰。”

李綱回憶道，“每次測試都像是一場友商大聚會，結果時間一長，客戶發現只有我們這幫人一直沒變，其他友商或多或少都出現了團隊重組。抗壓、有耐力，也是我們能拿單的原因之一。

除了耐力比拼外，在他看來，大量的摸底測試和POC測試，還讓團隊養成了“人有我無，就敏捷跟上；人有我優，就繼續保持和優化。”的好習慣，整體團隊能力得到了有效提升。

這種“邊戰邊學”，讓騰訊云數據庫在過去十幾年的發展中，一直保持著在產品和技術研發上的創新迭代力。

據了解，發展至今，騰訊云數據庫已形成較為全面的產品矩陣，包括關系型數據庫、非關系型數據庫、國產分布式數據庫、數據庫SaaS產品四大部分，其中，國產分布式數據庫是其重中之重。此次11月4日的騰訊數字生態大會上，騰訊云數據庫針對該板塊，集中發布了兩款新產品，對原有產品做了重要升級。

（騰訊國產數據庫產品體系）

雷鋒網AI金融評論了解到，騰訊云數據庫此次針對金融政企場景發布了新的Oracle兼容引擎，以滿足金融核心快速去“O”需求。據李綱介紹，這款引擎在保險和運營商等行業兼容度達98%以上，可以幫助行業在短時間內，近乎零成本改造下實現國產化；同時最高20倍的壓縮比和查詢性能，可大幅節省資源成本。

同時，為應對金融敏態業務發展過程中業務形態、業務量的不可預知性，會上還發布了一款新敏態引擎。該引擎實現了EB級存儲的Online DDL，有效提升了表結構變更過程中的數據庫吞吐量，并且騰訊獨有的數據形態自動感知特性，使數據能夠根據業務負載情況自動遷移，打散熱點，降低分布式事務比例，增強擴展性和性能。

此外，對于云原生數據庫TDSQL-C，騰訊云數據庫也做了新升級，包括吞吐率提升50%、將IO延遲降低80%，整體性能提升85%，并帶來新形態Serverless，通過全局工作流預測以及動態擴縮資源，進一步降低成本，做到按需計費。

在分析引擎TDSQL-A方面，新自研列式存儲引擎，搭配新智能執行引擎，向量化執行性能有10倍以上的提升，同時憑借分布式延遲物化技術，大幅優化分布式場景下關聯查詢的計算效率，有助于進一步挖掘數據價值。

用穩扎穩打回應半信半疑

2007年騰訊云數據庫伴隨著內部增值業務、計費業務等泛金融場景起步，先后經歷了賦能互聯網新興產業和民生政務兩大發展階段，近兩年，金融行業逐漸成為其主戰場。

“主要是發展階段到了。”在騰訊云數據庫副總經理王義成看來，經過前期的實踐積累，數據庫產品已經成長到了能夠獨立輸出的階段，足以支持騰訊云數據庫在金融行業里大展身手。

與前兩大行業相比，金融行業對數據庫的要求最為苛刻，尤其對銀行而言，核心系統數據庫是“生命線”，它存儲著銀行多年來收集的數據信息，包括用戶財務隱私、銀行交易記錄等重要信息，因而銀行在核心系統數據庫替代方面尤為謹慎。

在李綱的回憶里，騰訊云數據庫多年來都在不斷“面對疑慮、消除疑慮、獲取信任”，持續向上爬坡。

“從互聯網銀行到農商行、城商行、股份行，再到國有大行，一邊是客戶對我們半信半疑，一邊是我們穩扎穩打。與騰訊大多業務風格類似，攻一城、扎一寨的踏實積累，才是挑戰更高難度任務的絕佳鋪墊。”他總結道。

在這樣的理念下，騰訊云數據庫一路通關，截至目前積累了2000多家金融客戶，其中包括超20個金融核心系統標桿項目的落地。

但這還遠遠不夠。實際上，目前國內排名靠前的幾家公有云廠商，總體實力相差并不大，當這些巨頭爭奪同一個客戶時，往往是標桿案例越好，脫穎而出的概率越大。因此做好標桿案例，仍是此后一段時間里各大廠商的主要角力點。

“我們未來兩到三年的重點也還是做好標桿案例，但標桿的顆粒度會更細。”王義成表示。近幾年，他發現，越來越多的中小型城商行和農商行，對股份行和國有大行的案例不再感冒，反而更愿意看一些與自己同類型的案例，于是樹標桿進入到精細化階段。“會細到是什么類型的銀行、是核心系統還是單系統，甚至細到具體的攻堅點。”他表示。

而精細化趨勢的背后，是對產品和服務標準化的要求。不斷領先的市場地位，永遠無法靠苦做項目打下來，但可以靠標準化和規模化的能力錘煉出來。 

據了解，在下一步發展規劃里，騰訊云數據庫會把服務按照不同的能力和工種進行拆分，做標準化打磨，同時在產品體系上，重點投入協議兼容、應用遷移、規范化部署等的標準化，努力從苦做項目進化到規模化復制階段。

“我們希望未來三到五年，騰訊云數據庫能夠基于過去豐富的經驗和逐漸標準化的解決方案能力，助力1000家金融機構實現核心系統的數據庫國產化轉型。”李綱表示。

“免費版計劃”正當時

然而To B業務的規模化復制遠比To C要難，需要對服務體系、產品能力、上下游合作伙伴等整個生態進行全面提升，才有可能實現。

在王義成看來，過去，騰訊云數據庫的生態布局廣泛，更多是點到點的連接，需要一條能把ISV、服務商、轉售商等上下游伙伴都串聯起來的紐帶，而此次生態大會上重點推出的數據庫“TDSQL免費版計劃”正是那條尋覓已久的紐帶。

具體來說，該計劃將通過“軟件+服務”的形式來實施：軟件部分，用戶將通過騰訊云官網提供免費版下載介質以及對應的文檔；對于普通開發者，將通過官網社區提供答疑和交流的平臺。 

“在行業里，我們可能是首家正式提出‘免費版’這個點的，它和簡單的開源不一樣。”騰訊云副總裁李綱強調到。

目前國內數據庫市場上的開源主要有兩種模式，一種是“羊毛出在豬身上”，把數據庫開源，放棄掉這部分利潤，借此帶動其他板塊如硬件的發展，然后以此獲利；另一種是通過數據庫開源來低成本獲客。 

事實上，撬動生態從來都是說起來容易做起來難。

近些年經過各大廠商的紛紛開源，開源在某種程度上已然“內卷”，簡單的開源再難打出水花，而且在國產化市場上，很多用戶需要的并不是更多的開源工具，而是生態和生態中的商業機會。

因此想要做好生態，不能再靠簡單的開源，而要建立起一種打造商業化平臺的思維。從這個角度看，免費版策略可能要比目前市場上大多數的開源策略更具優勢。

在王義成看來，免費版是一種比開源更大的生態布置。把輻射群體從開發者擴展到更多的上下游伙伴，并通過商業化模式，把各方都串聯起來，形成有效互動，從而實現生態閉環。

具體來說，在最外層，針對免費版數據庫產品，培訓伙伴和基礎服務商可以通過開設在線問答平臺，解答開發者的各類疑問來賺取收益，也幫騰訊構建起了TDSQL社區或問答互助平臺。

往里一層，當用戶在使用免費版的過程中遇到一些升級需求時，ISV可以承接下來，或針對免費版軟件的特性去做定制化新功能，并推向市場。

再深入，免費版軟件還能幫助挖掘出一些基礎功能部署上的踩點，有助于創新產品的孵化。

如此一來，就形成了一個以免費版數據庫產品為核心，不同合作伙伴環繞，相互間合作程度層層加深的圓環，然后針對不同的合作伙伴，在基礎認證、技術支持、渠道政策、培訓體系等方面給予不同的扶持，讓各個板塊和整個生態盡量飛轉起來，形成良性循環，吸引更多伙伴加入進來，不斷擴大生態邊界。

“我們之前提過一個詞叫‘TDSQL insight’，就是希望不管是生態伙伴還是集成商，當他們二次開發后做出一個更有競爭力的產品投放到市場上，我們只在里面做一個‘TDSQL insight’就OK了。”在李綱看來，這種生態策略和此前賦能各個行業企業的思路一脈相承，都是以一個服務者和底層支持者的姿態去真正助力國產化信創事業。（雷鋒網雷鋒網）

封面圖片來源：電影《特洛伊》

2021年6月30日，值得寫進中華財險的歷史。中華財險與阿里云合作的新一代核心業務系統，其業務中臺的最小可用版本已完成交付，進入最后驗收階段。

一年前，中華財險和阿里云正式達成合作意向，雙方的合作金額高達7億元，是國內金融云領域迄今為止的第一大單。

在他們看來，這場合作不僅是交付一個項目，更是要打造一支新團隊、共建一種新模式。

一年后，兩方共同在無人攀登過的高峰上，率先豎起一面旗。

一家擁有4萬名員工、去年單財險營收就超過500億的老牌選手，要完成這場前所未有的“手術”，對中華財險和阿里云來說，實力和魄力，底氣和勇氣，缺一不可。

在中華財險數字化轉型一周年之際，這場轉型到目前為止的成果和細節，終于展露于世人面前。

不動核心，言何重生

中華財險和阿里云正式簽約那天，正值2020年的兒童節。

“巧合遇到這個日子，一個新生兒，開始重生。”中華財險副總裁王永祥說。

2020年6月1日，簽約當日

轉型啟動的時點不能算早，但一定夠巧。因為就在簽約前數天，銀保監會下發了一份文件，給各家財險公司出了道題：

到2022年，車險、農險、意外險、短期健康險、家財險等業務領域，線上化率≥80%。

——2020年5月26日《關于推進財產保險業務線上化發展的指導意見》

監管層對此類保險行業的具體指標下發指導意見，尚屬首次。

無論是疫情的影響、市場的驅動還是監管的鼓勵，都讓數字化浪潮的水花，比以往任何時候都要逼近保險行業。中華財險也適時開啟了自己的數字化之旅，和阿里簽下全面戰略合作協議。

但千頭萬緒，從何做起？

事實上，智能化應用幾年前已經深入保險業務的細枝末節里，像是智能客服機器人，音視頻能力+線上營銷。

可若是俯瞰這場數字化革命，就會發現，故事已經從那些炫目耀眼的“黑科技”應用，轉向夯實基礎設施的“內功修煉”。

中華財險的選擇也正體現了這一趨勢，他們目標清晰：不破不立，就從核心系統動起。

這堪稱“地獄級”任務：從核心業務系統的重構開始，直接觸及這家成立三十五年的資深險企的“中樞系統”。項目難度在保險乃至整個金融業都實屬罕見，所采用的設計理念、產品架構、建模方式和容災方案均在行業前列，甚至是保險業內首創。

“起初，行業里是有一點質疑的，甚至不太看好。”阿里云工程師趙非回憶。

之前并非沒有險企試水上云，但趙非告訴雷鋒網《AI金融評論》，應用上云的情況較多，核心系統的重構卻是涉及到生產關鍵，這是從未有過的挑戰。

這對于資產規模超過900億的中華財險而言，挑戰巨大。

但如果改造不徹底，原有的核心系統老態龍鐘，根本無法快速響應市場海量的新需求。“核心系統是業務層的基礎設施，能夠稱之為基礎設施的東西，一定是做得越深入扎實，對未來的商業投影面會越大。”阿里云新金融事業部副總經理婁恒說。

金融行業對核心系統的合規性、穩定性要求都很高，高并發、低延時。而保險的核心系統上云，又與銀行、券商頗為不同。相比之下，“保險的交易鏈路和用戶服務時間的跨度都要更長。” 婁恒說。

打個比方，證券的一筆實時交易，買入賣出用時不過幾秒，但要進行一次保險購買或者理賠，涉及的環節、花費時間都得翻倍計算。

阿里云工程師江冉補充稱，保險的并發性、實時性不及證券等業務，但一個保單可能就涉及10+流程、20+系統的交互，還可能受發生時間點不固定等一系列因素影響，因此在流程設計上，也要對系統交互的便捷性、可實現性，以及業務邏輯的關系上有更周全的考量。

加上保險在技術方面，較銀行也有一定程度的落后，這些都意味著其他金融業務的改造上云經驗，未必能成功復制到保險領域。

而這家險企的老一代核心系統，投產以來已有十余年，有如一間舊屋落滿塵埃，讓人無從下手，改造步步維艱。

架構轉型：從0到1，沒有先例

如此龐大的工程，非一日之功，自然要先進行任務拆解。

中華財險的核心系統升級改造，有兩個“華彩篇章”不得不提：基于雙中臺的應用架構轉型，和基于單元化、混合云基礎架構的轉型。

雙中臺方面，主要是業務中臺和數據中臺的建設。

眾所周知，傳統煙囪式架構縱向割裂，相應的Web、APP、DB以及計算資源和存儲資源在系統內重復建設；一旦有突發狀況，系統間聯動起來更是費勁。

中華財險信息技術部總經理陳小虎表示，接收一個業務的變動需求，可能要同時修改3~5個系統，甚至更多，重復的修改和維護對公司的人力財力來說都是嚴重浪費。

但與其說“拆煙囪”，這次的雙中臺更像是一次徹底的推倒重建。

傳統金融機構的IT架構轉型往往都背著歷史包袱，以前積累的數據標準不一，光是做數據清洗都已經筋疲力盡。更不要提幾十個系統攪在一處，像極一個物品堆放無序、電線亂纏一通的房間。

這么困難，要不數據中臺和業務中臺先選其一？

雙方經過討論大膽選了雙管齊下。“破釜沉舟，用同一個數據標準，重構兩個中臺。” 阿里云數字保險總監馬榮強說，他是雙中臺項目里阿里側的總設計。

推翻重做，意味著不用考慮傳統系統留下的“臟數據”，直接繞開讓金融機構頭疼的數據治理問題。

在這一認知之上，構建沉淀通用能力的業務中臺，和以數據智能為主的數據中臺。馬榮強告訴雷鋒網，與傳統模式相比，現在的雙中臺都更側重模型和場景的匹配。

數據中臺會預判保險場景，做相應的模型設計和落地。豐富的數據導入其中后，產生各種數據要素，可供未來的業務智能決策所用。

業務中臺則圍繞前端業務去識別公共服務，構建微服務的共享庫以供調用。“簡單來說，就是把我們業務上的所有的功能原子化，前端場景有什么需求，可以重新編排，快速響應業務。”負責中華財險雙中臺具體建設、落地工作的創新中心總經理胡岱磊說。

總體而言，中華財險的中臺設計，就像一個定制款的樂高工具箱。中臺整合之后，業務、產品、服務、客戶要素等進行原子化，公共技術也抽象、歸并到中臺里，同時借助云技術，實現資源的彈性擴展。在這樣全分布式核心系統建設中，一致性、微服務的設計、服務的編排都是挑戰。

如今，回望過去一年的推進過程，搭建云平臺和構建雙中臺MVP的“打基礎”階段，是最艱巨的一環。

這里的MVP指的是最小交付版（或稱最小化可實行產品，Minimum Viable Product）。

MVP就相當于先花費最小的代價，在“新房”盡快布置一套麻雀雖小五臟俱全的家私，測試宜居程度，有問題也可以及時迭代更新，試錯成本比直接整體搬遷要小得多。

核心系統的新老交替，和搬家異曲同工。如果一股腦全部搬完就入住，一旦發現問題，又不能退回舊房子暫避，但又要保證搬遷的進度，確保日常生活不受影響。

“建設新一代分布式核心系統雖然是項目組雙方all in的目標，但是在建設過程中，老的業務系統也不能停掉，還要保障業務正常進行。新老系統‘雙規’并行，其中的磨合適配過程充滿挑戰。”婁恒對雷鋒網《AI金融評論》坦言。

馬榮強更愿意把打基礎環節稱之為“從0到1”，基礎沒打牢會影響到后面的試點和全面上線——“但如果做成了，對行業的影響和價值就會凸顯出來。”

“沒有先例”像一枚徽章隱隱發光，象征著第一和開創，只等中華財險和阿里云一起鑿開眼前的墻。

而前面提到的所謂彈性，很大程度上來自于分布式、單元化、彈性多活的混合云基礎架構。

部分保險公司號稱完成系統部署在云上，但在陳小虎看來，恐怕業內只有極個別公司實現真正意義上的全云架構適配。

這種適配意味著什么？“未來的核心系統將永遠在線，用戶請求會從頂端的云解析引導到相應的端，在每個點的服務都是‘活的’，都具備實際業務承載能力。”陳小虎說。

例如在平時，云上只提供5%的業務承載能力，但當遇到雙十一這樣的業務高峰期，云可以將原有的承載能力快速擴展到翻倍，支持突如其來的業務并發。

而單元化意味著云的能力可以像積木一樣，依需求而定，可快速復制成千上百。“云是可彈性的，給我們提供未來的橫向的擴展能力，也提供了很多的想象的空間。”陳小虎感慨道。

在架構轉型推進之下，中華財險的研發和運維效率呈現了指數級提升。陳小虎表示，銀行核心系統的大版本升級，通常以半年和年為單位，保險公司則通常以月為單位，而中華財險的研發周期已經縮短到了以天為單位。

現在，在新架構下支撐近200個應用上云，代碼的構建頻率也從原來的兩到三天一次，提升到一天三到四次。生產環境今年五個月內發布近600次，無重大的P1級故障和資損事件發生。

打通云上云下

值得注意的是，阿里云還為中華財險構建了一套云上應用級災備方案。

中華財險的不少數據系統都依賴線下搭建的機房，時間一長，機房老化，存在較大的故障風險。

阿里云意識到，雖然系統上云在穩步推進，但線下機房在短期內也不會完全失效。抱著“適合客戶的才是最好”的服務理念，阿里云公有云CSM團隊在最短時間內拉通內部專家資源，為中華財險迅速制定一套打通云上云下的災備策略。

這又是一塊“硬骨頭”。

阿里云工程師江冉解釋稱，線下如數據庫，往往搭建在IBM小型機上，而云上目前以x86體系為主，倘若云上云下要發生數據交互，就會涉及到很多大表的拆分。“拆分是和業務邏輯強相關的，就需要雙方團隊專家既懂保險行業，又懂云計算產品。”

這就像是一張龐大的電路圖，元器件之間的聯系極其復雜，如果不看連接就隨便挪動，可能會導致開關失靈、燈泡不亮。

但這些系統的“歲數”實在太大，江冉告訴雷鋒網《AI金融評論》，不少交互關系只能靠客戶口授或者印象來提供相應信息，跟實際情況還未必吻合，開發人員也不一定能在當年的設計文檔里找到答案。

因此，阿里云的前期調研中，最耗時的工作之一，就是把核心系統之間的關聯梳理出一整張關系邏輯圖，歸入對應文檔，確保在云上災備時不出現系統間的斷連。

江冉介紹稱，項目整體開始之后，首先要完成云上系統搭建，包括專線打通和整體網絡架構的復制，其次則是周期較長的整體數據遷移，也就是前面提到的云上云下兩套體系間的交互，需要反復數據驗證、調整設計邏輯。

緊接著，就要在云上跑通整體鏈路，保證云上系統能夠單獨成為一個獨立的節點，提供相應的服務。“這一階段更多的是壓測，交易模擬，錄入測試數據。”

之后便是最驚心動魄的環節：云上云下切換的測試和驗證。

在某次切換演練中，有一個操作始終過不去，事關演練乃至整個項目成敗，所有人的心都懸了起來，所幸在阿里云專家服務團隊和客戶方的共同排查下，演練最終順利完成。

云上災備取得階段性成果，中華財險的業務穩定性邁上新臺階。陳小虎稱，UM-SSO、內容影像等33套系統已部署到云上災備。今年5月，中華財險與阿里云也成功完成了首批2套關鍵系統從本地IDC機房生產環境向金融云的切換演練。

這恰巧反映阿里云所提供的服務，不僅是交付一款產品，更是交付一種能力

阿里云幫助中華財險構建全面的系統災備體系，使其掌握了獨立的系統容災能力，災備建設周期由按年提速到按月為單位進行計量。同時，該方案采用金融云按需購買資源的特點，極大降低首次投入成本。

數字化轉型，知難而上

保險行業的數字化轉型，某種程度上是一件“難而正確”的事。

正如前文提到的種種麻煩，有時候保險公司的核心系統和機房，說不定比技術團隊里的年輕人們還要年長，內里繁復又脆弱，動彈不得。

不光是技術層面如過蜀道，組織架構和企業文化層面上更是重重關卡。

開啟轉型，就意味著進入“無人區”，很大程度涉及到現有業務、流程、人員、系統、數據等多方面因素。

轉型不僅僅意味著“敏捷文化”與傳統“瀑布文化”的碰撞，更重要的是思維模式、獲客模式、運營模式、管理模式的改變，要沖破部門間的阻力，改善一線執行態度，短時間內應對無數的新技術、新觀念涌入。

但在王永祥看來，數字化轉型是整個保險行業必須面對的問題，沒有退路可言。

中華財險副總裁王永祥分享轉型經驗

曾經，許多保險公司車險一個產品獨大，部分公司占比80%以上，可去年“919車險綜改”提出“降價、增保、提質”的目標，保費下降，責任范圍擴大，賠付率直接從60%以下的水平飆升到75%~80%之間，這對消費者來說是讓利，對保險公司來說卻是巨大的成本挑戰。

王永祥指出，綜改之后，車險保費規模急劇下降，車險行業呈現整體虧損的局面；目光放到整個保險業來看，原有的傳統業務也在逐步萎縮。

靠車險的好光景不再，保險公司能否抓住新的市場機遇，在他看來，“取決于對風險的完整把控能力”，要建立更直接的觸客通道，縮短交易鏈條上的中間環節，建立成本上的巨大優勢。

以前的保險業務經常被吐槽：除了收錢，其他時候都見不著面。因此，銷售和服務之間需要被打通，保險公司要告別信息化時代的閑散，走向智能一體化的未來。

以營銷為例，中華財險加速實現銷售的智能化升級，不但提升銷售成單率，更為客戶提供更好的互動體驗。

今年3月初，中華財險銷售智能一體化項目在杭州試點上線。截至6月上旬，杭州家用車續保率提升超6%，首日報價率提升近9%，保費多元化率提升約4%，均取得超出預期的成效。

“業務系統不再只記錄交易結果，而是要記錄觸達客戶的全鏈路，學習互聯網產品思維方式去洞見客戶的需求，去提升自身主動分發的能力，提升客戶黏度。”王永祥說，“這是數字化真正對一個企業組織能發生的業務模式的變革。”

雙中臺也好，混合云架構也罷，核心系統的種種改造升級，智能一體化平臺的不斷改進，也是在同業異構和異業同構當中融會貫通，賦予新時代的保險公司更多想象空間。

行業風云變幻，這是中華財險的關鍵時刻，這同時也是阿里云的關鍵時刻。

趙非對雷鋒網《AI金融評論》說，與中華財險的項目合作三年打底，300余人的服務團隊已經做好了駐場陪伴三年的準備，打一場決定行業價值的“舉國戰爭”。他們也希冀這場戰役之后，能夠沉淀一套可復用的打法和技術，服務到更多的保險機構。

那些無人攀登過的高峰，只有知難而上的人們，才會留下足跡。

華為發布鴻蒙系統后，中行、浦發等數十家銀行，立刻發聲力挺鴻蒙，并接入系統。

鴻蒙的面世，也立馬引發了金融IT從業者的三個疑問：

 ? 哪些金融機構會支持鴻蒙，怎樣支持？

 ? 金融機構接入鴻蒙，有哪些方式和形式？

 ? 接入鴻蒙可能存在哪些隱患和風險？

帶著疑問，雷鋒網《AI金融評論》與業內多位銀行IT專家進行探討。

（一）哪些金融機構力挺鴻蒙？

在鴻蒙發布后，老字號的中國銀行、股份制銀行的代表中信銀行和廣發銀行就率先第一時間用行動力挺：加入鴻蒙！

除了上述三大銀行，當前其他多家銀行、大型基金公司以及券商也紛紛表態支持鴻蒙。

于是，鴻蒙第一梯隊的金融合作伙伴，成了。

（二）如何金融機構如何接入鴻蒙系統？

從形式來看，金融機構接入鴻蒙系統，目前主要有三種形式：（1）APP適配鴻蒙系統；（2）商城上線鴻蒙專區；（3）推出原子化服務。

值得注意的是，各家金融機構接入鴻蒙操作系統的程度不盡相同。

以中國銀行、中信銀行兩家銀行為例，兩家銀行與鴻蒙合作“原子化服務”。

所謂原子化服務，就是在鴻蒙“原子化”系統架構下，客戶無需重新下載app，而是像“小程序”一樣使用相關服務。也就是使用者能夠即搜即用，不需要事先下載應用程序軟件。

其中，中國銀行在鴻蒙“原子化”系統架構下，使用者通過鴻蒙的服務中心搜索“外幣”二字，即可快速進入“中銀外幣現鈔預約”程序進行預約。

這種方式，能夠讓使用者更便捷地獲取超過20種外幣的現鈔預約服務，省去應用下載安裝、用戶注冊等步驟，簡化了業務辦理流程。

中信銀行，則推出借記卡原子化服務。

客戶無需下載App，通過“中信銀行”的服務卡片，即可享受中信銀行借記卡申卡及進度查詢服務。

其他銀行更多選擇：將旗下手機app完全適配鴻蒙系統。

如廣發銀行將信用卡app適配鴻蒙操作系統，光大銀行旗下云繳費app全面支持華為鴻蒙系統。浙商銀行、寧波銀行、上海銀行等將手機銀行app完全適配。

其中，廣發銀行信用卡的官方APP——“發現精彩”，在成為首批適配鴻蒙系統的APP的同時，廣發信用卡在廣發商城還上線了鴻蒙專區。

廣發商城上線HarmonyOS專區的作用主要是，消費者可以在該App上購買搭載鴻蒙系統的相關產品。

此外，保險機構方面，眾安在線是華為鴻蒙全場景應用生態伙伴中唯一一家保險公司借助鴻蒙OS的能力，用萬能卡片為用戶打造個性化、場景化、智能化的保障產品和服務。同時，中國人壽app以及e店均已支持華為的鴻蒙系統。

從銀行三種不同的接入鴻蒙系統的方式，可以看出：目前大部分銀行比較常見的方式是：支持手機APP兼容；而少部分銀行在商城上線鴻蒙專區的方式，很可能是出于與合作伙伴構建更好的行業生態的考量。

而原子化服務，是目前銀行接入鴻蒙系統較為創新的其中一種方式。第三種方式很有想象空間，雷鋒網《AI金融評論》在后期也會積極和傳統金融機構的資深人士進行交流，以期將原子化服務更充分向大家展現。

（三）存在哪些隱患和風險？

鴻蒙的問世，迎來了一大批金融機構的盟友，助力了金融機構的數字化轉型。

與此同時，鴻蒙的問世，也給黑灰產帶來了一些作案契機。

近日，同盾情報部門發現，在網絡上已經有黑產利用HarmonyOS的作案案例。

小盾安全解決方案專家向雷鋒網《AI金融評論》分享了以下兩個案例：

案例一：

羊毛黨在升級鴻蒙系統后，舊設備繞過某電商原有設備指紋，可以重新進行薅羊毛行為。

某電商平臺的風控系統機制是：一個手機不管是在原有系統（安卓&ios）做了版本升級還是用了改機作弊軟件，該電商平臺都會識別出是同一個手機。所以，即使有些黑產想通過同一個手機登錄不同的賬號來薅羊毛，也是無法實現的。

例如，黑產在賬號A上獲取了“新戶優惠券”，想通過登錄賬號BCD再獲取更多的“新戶優惠券”，該電商平臺的風控系統就能夠自動識別和檢測出：黑產使用的是同一部手機，從而限制其無法獲取。

但是，目前黑產升級了鴻蒙系統，在同一個手機再次登錄B賬號后，就能夠再次獲得“新戶優惠券”。

這說明：黑產在升級鴻蒙系統后，手機因為系統的變化而不能被電商平臺識別出是同一部手機，因此黑產薅羊毛成功。

案例二：

某多開工具已經在6月7日實現兼容HarmonyOS 2系統，“多開工具”是一種能夠讓一部手機同時裝幾個相同APP的支持性工具。

黑產在手機上可以裝“多開工具”，然后裝幾個相同的APP，從而登錄不同的賬號薅羊毛。

也就是，黑產如果想在同一個手機裝幾個微信，可以先裝一個“多開工具”的APP，然后在多開工具的支持下，就可以在一個手機裝幾個微信APP。

在過往，黑產不管是在蘋果系統還是安卓系統，如果在通過“多開工具”去登錄，企業是能夠及時發現這種情況，從而限制黑產的操作。

但是，目前黑產升級了鴻蒙系統后，發現只要裝了“多開工具”，企業的風控系統則無法識別出黑產是在“多開”的環境下進行操作，因此黑產可以在手機裝多個相同的APP，然后登陸不同的賬號薅羊毛。

以上案例可見：目前部分黑產通過升級鴻蒙系統進行作案，可見企業APP在鴻蒙系統支持下存在數據隱患。

從前述可知，目前多家銀行的APP適配了鴻蒙系統。那么，用戶在鴻蒙系統前提下進行銀行APP的相關操作，是否安全？

小盾安全解決方案專家提到：“如果要解決這些風險問題，則需要企業針對鴻蒙系統部署終端設備指紋技術。”

終端設備指紋技術能夠支持安卓、ios、鴻蒙、H5、小程序全業務場景，為每一臺設備生成唯一的設備ID，可實時檢測當前終端風險狀態，識別模擬器、作弊?具、改機、?次打包App、位置偽造等風險?為。

不僅是終端設備指紋技術方面，原來已有其他技術應用，諸如人臉識別等，在與鴻蒙適配的過程中，還需要積極進行反復溝通。

在金融行業，目前鴻蒙已與多家金融機構進行了合作，但是新系統面世跟原來的金融風險管理體系還需要繼續磨合。如何及時找到漏洞，防范于未然？這應該是鴻蒙與金融機構，還有技術服務商都應該關注的問題。 

雷鋒網雷鋒網雷鋒網

其實他們最在意的，是希望技術保證核心穩定運行，是整體完全自主掌控，是最后達到每單筆交易/每個賬戶成本下降的目標，是在業務穩定性、連續性不降低的前提下，支撐業務敏捷。

抽絲剝繭數個實踐合作案例后，我們可以看到，金融機構的訴求，或許可以分為三環：

• 最難解決的是“1環”問題，分布式事務怎么實現？各種模式應用在哪些場景？有何利弊？異地多活情況下，數據庫怎么保證良好的支撐？

• 到了“2環”，重點落在領域化建模，機構們要參考最佳實踐，思考底層模型框架如何處理，他們也在關心集中化架構——分布式架構——云化架構，有沒有一些特殊的差異？

• 上升到“3環”，訴求就會涵蓋整個云化環境下的運維保障體系、devOps體系、整體的部署架構體系……

2020年被認為是云原生核心的元年，更多金融機構逐漸從混沌中醒來，與科技公司聯手摸索出核心系統的“病灶”所在，對癥下藥。

陳威是阿里云新金融事業部金融核心部負責人，曾從事企業級信息技術產業十余年，具備豐富的應用架構與設計，數據智能，云平臺，互聯網等領域的理論與大型復雜項目實踐，尤其在金融行業具有多年的交叉實踐經驗，服務于近百家大型機構與客戶。

在雷鋒網《AI金融評論》與阿里云聯合主辦“銀行系統云化升級”實戰體驗營中，陳威就從阿里云服務金融機構的過往經驗中提取精華，詳盡深入地討論了他們在金融核心系統轉型方面的探索和實踐。

欲獲得所有講者視頻，可關注公眾號“AI金融評論”（ID: aijinrongpinglun），進群獲取回放鏈接。

以下為陳威演講內容，雷鋒網做了不改變原意的編輯和整理：

今天的主題是《金融核心云原生轉型的探索與實踐》。

在整個金融業，尤其在銀行領域，核心系統是IT整體支出占比最大，最為復雜，對于技術要求最高的一塊。這也是我們認為，整個金融行業包括銀行，在朝著云化轉型的理念里，最后最難的一部分。

今天的內容首先會講到銀行核心系統云化轉型的訴求，簡單來講就是客戶和我們為什么要做這件事？其次是核心云原生轉型的挑戰與應對。

銀行核心系統云化轉型的訴求

可能在座的聽眾有所了解，金融核心實際上經過了好幾代，存在代際的差異。

最早是傳統綜合業務系統這部分，然后到第一代基于主機的單體式核心系統。比如錢存在國有大行那里，都是在主機系統Mainframe（大型機）上。

大量的農商農信體系是在AS400上；還有一部分在Power小型機系列。

第二代就是我們通常看到銀行會走到瘦核心的階段，從原來的核心系統進行拆分，尤其是面向敏態的部分，通常會建設一個叫互聯網核心的系統。

第一代的技術架構的改造或者升級，通常的做法，基于從單體下移到基于ESB的SOA架構。近幾年有些開發商會基于開源Spring Cloud把這部分SOA架構升級到微服務的架構。

從技術架構路線來講，這是從ESB向微服務框架的體系改進，這就是我們經常聽到的分布式核心的實際的現狀。

從應用架構路線來看，技術層面雖然有一些升級，但是它底層模型和應用架構，其實沒有太大變化。

第二代核心的典型特征就是以ESB為核心和微服務架構，但有個問題沒有解決：底層對業務敏捷的支撐是心有余而力不足。支撐一些新的產品，服務或者功能上線需要大量的人力定制化開發，業務并不夠敏捷。

隨著云計算技術的不斷發展和成熟，云化的潮流勢不可擋，不論是傳統企業還是金融系統，有意愿和動力升級到云上核心，這就是所謂的第三代，也叫云原生核心，基于容器云原生或者基于PaaS等技術。

它跟我們通常理解的分布式核心，實際上有較大差異。第三代是完全走向IaaS/PaaS化，但在底層應用架構方面，其實也有相應的變更，類似于大家聽到的中臺化、領域設計，這些關鍵字都會在第三代核心中有所體現。

• 第三代金融核心關鍵性標準

我們試圖總結一下第三代核心的一些關鍵詞，經過長時間的調研與歸納，形成了這么一些標簽，云原生，異地多活，中臺化，數字化。

云原生和異地多活，偏向技術架構和基礎設施；中臺化和數字化，偏向于業務和應用。

云原生：金融核心實際上也是應用系統，本質上和其他業務系統沒有特別大的差異，但是它比較復雜，對業務連續性和一致性的保障會比較高。

同時，它本質上是一個應用，所以云原生應用該具備的特征，它實際上也具備。比如容器化部署模式，PaaS的資源供給應用需要的能力，這都屬于云原生范疇。

異地多活：大部分新建的銀行要做的核心，基本上會有異地多活。它不光是同城容災或者異地容災，是能夠做到多地多活的模式，可以做到城市級的容災。對于傳統金融機構而言，異地多活也是比較大的挑戰。

中臺化：原來的集中式架構，就是傳統一個大的單體化應用，牽一發而動全身。

當需要定制化或創新金融產品服務，尤其是疫情常態化之后，未來有很多不見面的流程服務，包括基于互聯網或者視頻的新渠道形態，原來的架構不能復用。

這時希望打造一個堅實的業務中臺能力，能夠支撐未來多變的挑戰。中臺化最終是為了提高面向創新的效率，這也是建中臺的初心，這是支撐業務敏捷非常重要的手段。

數字化：能夠以數字化模式，展現里面所有運營相關內容，有了數字化運營的基礎和能力，智能自動化運維才有空間，這是核心未來發展的重要方向。

其次，因為核心系統的生命周期非常長，可能會要支撐全行的業務支撐十年八年的的時間。如果遇上比如數字貨幣這種國家大力推行的方向，它對于核心有怎樣的挑戰？所以架構上的設計，一定要把這個（時間跨度）也考量進去，具備很強的擴展能力。

• 第三代金融核心的重要意義

自主創新：首先它是自主創新的一個標桿。但從我們的觀察來看，2020年是云原生核心的元年，諸多傳統金融機構在逐步的進行嘗試。

行業標準：在第三代核心，或者全分布式、云原生、多活核心架構領域，還沒有公認的標準。金融機構非常想去打造行業的先鋒標桿，沉淀的卓越實踐參考。

實施工藝：核心是一個龐大的項目群，周期很長，可能有不同的開發商，涉及的人員非常多，不可能按照原來的小應用開發模式，必須要有一套統一規范的框架和實施工藝，支撐長生命周期的大型系統開發，能夠在上面開發整個核心系統上百個應用。

能把這三點做好，是我們認為第三代核心在金融機構落地的標志。

• 第三代金融核心的業務價值

首先是全棧式的自主可控，滿足相關的要求。

多活架構，可以做到RPO=0，甚至是城市級的容災，RPO=0，有問題的話恢復時間＜1分鐘。如果大家對于基礎設施比較了解，就會了解要達到這樣一個指標會有多么巨大的挑戰，只有達到城市級別的RPO=0，RTO分鐘級，才能夠真正的保證業務的連續性。

彈性擴展，基于分布式架構的擴展性，一定比集中式架構要好，所以它完全能夠滿足業務的特殊要求或者線性增長，支撐傳統金融機構做類似于雙十一這樣的大促銷，金融爆款產品的秒殺，或者是一些高并發的場景金融。

業務敏捷，產品團隊能很快在該框架的核心上，實現新的金融產品和服務。在傳統的集中式架構下，上線新的大一些的功能就可能需要大量改動核心內部、關聯系統，造成業務上架用時較長。基于微服務或分布式架構的，可以通過devops模式縮短業務交付時間。

運維成本，云原生架構基于相對低廉的x86服務器構建，同等處理能力下，分布式架構的單位運行成本大幅降低，分布式架構的年均運行維護成本是大型機的17%。

• 金融機構們的訴求是什么？

在一個分布式的云化環境中，要保證核心穩定運行，其實有三個非常關鍵的標志。

1. 整體完全自主掌控。

2. 從財務的角度看，最后達到每單筆交易/每個賬戶成本的下降。

3. 業務穩定性、連續性不降低的前提下，支撐業務敏捷。

這三點衍生出金融機構對供應商/合作伙伴的訴求，大體分為4個方向。

咨詢與設計：架構咨詢指導，技術，開發規范等，配套的組織體系架構等。

服務交付：服務的長期交付過程，一般來講建設周期在2~3年，所以整體的人員投入，開發實施交付規范等。

運維保障：后續的長期運維保障，出問題怎么監控、解決，怎么更自動化；

產品與方案：最底層的是產品方案的支撐，包括整體規劃路線圖，產品的延續性、一致性、無縫升級維護，還有產品計劃的發布策略、相應的生態豐富度。

客戶的訴求可以分為三環，最難解決的是“1環”問題：

業務一致性，怎么實現分布式事務？各種各樣的模式，到底用在哪些場景？各種模式的利弊是什么？

數據一致性，尤其是異地多活這種情況下，數據庫怎么保證良好的支撐，尤其在異地之后的數據容災等問題，都是基礎架構部門非常關心的“1環”內容，通常很難靠金融機構自己解決，一般需要外部供應商來做。

“2環”重點是怎么領域化建模，有沒有一些最佳實踐？底層模型框架怎么處理？集中化架構到分布式架構，再到云化架構，有沒有一些特殊的差異？

“3環” 涵蓋整個云化環境下的運維保障體系，devOps體系，整體的部署架構體系，比如怎么做單元化架構等。

云原生轉型的挑戰和應對

從哪些框架/思路，去解決轉型訴求帶來的挑戰？

可能原來大家理解的，主要是在業務和數據建模，以及底層的技術軟件支撐。但在大量調研之后，發現其實中間還缺兩層，就是架構集成、開發運維部分，這也是要攻克的難點。

之前講到，第一代、第二代（金融核心）里這塊業務流程不會有太大調整，但在第三代，一定要真正讓它敏捷，對業務流程清晰梳理，同時要能轉化為類似中臺的模式。

上半部分屬于企業級架構建模的范疇，下半部分是建模之后怎樣在云上落地。

• 我們怎么做敏捷的架構設計？

做敏捷的架構設計，首先要考慮中臺化領域設計。

相對傳統的服務集成架構是渠道層+整合層+核心系統，但中臺化分層就會拆成渠道層、開放層、產品服務層、中臺能力層、基礎服務層等。

其中，渠道層，包括各個電子化渠道，開放互聯網渠道，線下的渠道等。

像產品服務層，其實不是產品真正執行代碼的地方，實際是業務能力編排的領域。例如存貸款這些業務，也是經過一個流程編碼，調用不同的引擎賬戶和中臺能力，去支撐完成業務鏈。

其次是思考云原生應用框架的搭建。

為什么要考慮框架？我們在客戶項目中經常遇到一個客戶的問題，感嘆懂業務的不懂云原生分布式；懂云原生分布式的，對業務理解可能也沒有那么深。

現在更先進的底層技術，比如云原生分布式數據庫，學習使用和運維的難度可能比原來要高，這樣會極大影響技術的可獲得性，就是好不好用的問題。

這需要一套框架整合起來，在業務組件技術層面封裝，降低開發難度，最后讓普通的應用開發人員，能夠像普通單體架構一樣開發業務應用，而不用關心這后面到底是在什么樣的環境里部署的。

再就是底層基礎設施部分。

因為開發周期非常長，難免中間有老的核心系統，怎么統一完成服務調度治理，怎么在盡量不改代碼的情況下，更平滑地接入和交互？

其實我們講的mesh技術，就比較好解決這個問題。我們也發現很多客戶不由自主地運用mesh來支撐集成的架構核心。

使用mesh，下一代的微服務技術，結合分布式網關，能夠跟ESB對接，支撐傳統業務調用——這也是服務網格目標。這部分與現在經常講到的low code低代碼、低侵入，都具備相近似的模式。

如果想用mesh的模式實現異構架構集成等？這就尤為需要關注云化分布式改造方面的新進展。

以往來講，spring cloud這套體系，如果你要寫一個比較健壯的核心應用，一定要在體系里把所有代碼和編排都放進去，實際上每個真正的業務代碼量占整體比較少，會有大量業務無關的邏輯。

這部分如果通過mesh技術，直接用sidecar處理，對于原來的業務應用不會有大量的侵入。因為走的是網絡層所有監控，所以能夠把整個架構的鏈路全部清晰表達出來。這對全方位監控也是很重要的內容。

• 如何保證質量安全與穩定性？

客戶無論是大機下移還是云化轉型，都有一個非常重要的前提：保證自身業務連續性；保證整體業務安全情況下，能支撐業務敏捷。

在質量安全與穩定性方面，我們有一整套可回滾可灰度可監控的防控體系，分為三層質量網。

未來一旦微服務化、云化，它會有大量的容器應用，不大可能靠人力定位最終的問題，一定要靠自動化、智能化的方式解決傳統的巡檢監控問題。總的來說，會有配套機制保障終端客戶不出問題，設施是不可靠的，要從應用、軟件、機制規范、工具體系支撐。

另外就是異地多活架構。

這部分實際是支付寶能去支持雙十一的底層核心架構，是三地五中心的多活架構。在互聯網上，我們一般采用客戶ID號尾號分片的方式，最后拆到100個單元，能夠在不同機房之間精細調撥流量。

所以任何一個機房或城市出現問題，我們都能把流量瞬間調撥過去，同時業務應用能承擔起來，機房級或城市級容災都能做到RPO=0。這里面非常核心的，就是底層分布數據庫，真正能夠支持異地容災的分布式結架構。

比如在異地機房，整個單元從端到端升級到一個新的架構，現在可以做到機房級的邏輯單元架構更新，或者應用版本大規模升級，這些都可以通過單元化方式實現。

無論在哪個級別，RPO都能做到等于0，但由于網絡或者物理限制，無法做到RTO=0。

陳威在本場演講中，還談到了金融核心轉型的實踐路徑和案例分析，并回答了銀行大機下移、數字貨幣對金融核心的挑戰等提問。欲獲得本場演講回放，可關注公眾號“AI金融評論”（ID: aijinrongpinglun），回復關鍵詞“參會”，進群獲取回放鏈接。

雷鋒網

 “開門紅”通常是上一年年末12月份到第二年的3月份。在這個活動高峰期，保險訂單的峰值有可能是平常的10倍以上，而如何保障營銷、銷售、服務等全鏈路系統的穩定運營，在關鍵時刻不掉鏈子，對于任何一家保險企業的技術團隊而言都是一個不小的挑戰。

 “類似‘開門紅’這樣的活動，我們不上云的時候非常難以處理。”在回憶多年從業經歷時，友邦人壽首席信息技術官劉立民坦言道，按照以往經驗，技術團隊會采購性能強大的服務器放在數據中心內，但是一年中這些機器絕大部分時間所支撐的訂單量可能只有高峰時期的十分之一，“造成了巨大的成本浪費。”

現在，通過將銷售、精算、財務等數十個核心系統部署在阿里云金融云上，友邦人壽可以根據業務拓展的節奏，提前幾天時間來購買充足的計算資源以應對可預見的業務高峰。在大量運用云的基礎能力之外，友邦人壽同時還在廣泛使用云上開箱即用的數據處理分析能力，在云上持續挖掘數據的價值。

“采用這種比較靈活的方式，可以使我們所花的每一分錢都物有所值，并且可以高效支撐業務高速增長。”劉立民說。

“逐步上云”的五年

友邦保險是一家擁有100多年歷史的國際化保險公司，2020年位列財富500強榜單第250名，在中國內地、中國香港等亞太地區的18個市場開展業務。友邦人壽是友邦保險在中國內地的壽險子公司，也是中國內地首家獲批的外資獨資人身保險公司。

最近幾年，數字化轉型大潮涌來，云計算、數據智能等關鍵技術加速滲透，如何運用新技術提升效率，促進產品與服務創新，已經成為保險企業構建未來核心競爭力的關鍵所在。緊跟產業發展趨勢，友邦保險也加快了數字化轉型步伐。

2015年年底，友邦保險在集團層面制定了Cloud First戰略，推動業務系統從傳統數據中心遷移上云。在經過細致的安全、合規、技術領先性等詳細市場調研之后，友邦人壽決定與阿里云展開合作，推動中國區業務系統的上云工作。

雖然認準了上云的大方向，但是友邦人壽在具體實施上采用了非常穩健的策略——逐步上云。2016年4月，友邦將旗下的電商業務系統率先遷移到阿里云金融云上，這也是該公司首個上云的業務系統。

相比傳統模式之下需要耗時3-6個月才能買到服務器，在云上的流程可以說非常敏捷，只需以天為單位就可以準備好運行系統的資源和環境，效率提升非常明顯。正是嘗到了云計算帶來的紅利，友邦保險緊接著又把重要的客戶健康管理系統部署在了阿里云金融云上。

真正讓友邦決定大規模開啟上云進程的拐點出現在2018年。這一年，友邦把非常核心的SAP S4財務系統遷移到了阿里云金融云上。相比傳統IT廠商給出的線下部署方案，不但成本大幅降低，系統穩定性也得到大幅提升。

“核心財務系統放在云上，其實經過了一番心理斗爭。”劉立民談到SAP系統上云時坦言，“作為一家國際化的金融機構，這樣一個核心系統，如果放在云上出現了問題，對于我們來說是一件壓力很大的事。非常高興地看到，在上云之后的幾年中，財務系統運行得比線下還穩定。”

SAP財務系統的成功上云，充分驗證了阿里云金融云的可靠性和便捷性。在這之后，友邦就啟動了大規模系統上云的方案。

“隨著業務擴展，很多業務系統需要快速靈活地部署，同時又要考量成本，這種情況下，傳統數據中心就顯現出不適應性，而云就比較符合業務需求。”劉立民透露，友邦人壽現在已有幾十個系統跑在云上，其中包括銷售系統、管理系統、精算系統、財務系統等。

外部沖擊與數據難題，保險云化如何招架

隨著加速上云，友邦人壽所嘗到的云紅利也越來越多，除了IT層面的降本增效之外，還助力業務從容應對外部沖擊。這一點在去年疫情時期表現得比較突出。

2020年年初，新冠疫情突然爆發。面對疫情對線下保險業務帶來的沖擊，友邦在極短的時間內就全面實現了云培訓、云招募、云管理，保障了內部運營以及外部服務的連續性，而阿里云金融云上開箱即用的豐富功能，也為疫情期間的業務正常開展提供了支撐。

疫情期間，由于保險營銷員不能跟客戶面對面，在“非接觸”的情況下，如何合規地完成人壽保險合同的簽約，一時間成為了一個難題。而通過阿里云金融云上的“智能雙錄”應用，友邦保險很快就解決了這個難題，實現了“空中簽單”。

“最初我們的業務比平時下降了80%，但是這個功能上線之后，幾乎當天業務就恢復到了正常水平。”劉立民透露，隨著疫情緩解，客戶已經可以跟營銷員面對面簽約，但現在仍有很高比例的客戶因為工作忙等原因選擇遠程簽單服務。

“從某種意義上講，云上的技術幫助保險企業擴大了接觸客戶的可能性和銷售的范圍。”阿里云智能新金融事業部總經理劉偉光認為，隨著客戶行為加速向線上化全面遷移，保險機構必須加快數字化和智能化轉型進程，學會“數據驅動”，才能在數字時代獲得競爭優勢。

除了外部沖擊，行業內部的數據問題也同樣不可忽略。

過去幾百年間，雖然保險行業的發展嚴重依賴數據，但是數據收集和高效使用的能力始終是個難以解決的問題，今天保險行業很多關于客戶體驗的問題的根源都在于此。

在數字化浪潮帶動下，僅過去兩年間產生的數據就占到了世界上既有數據的90%。數據存儲、數據處理、計算和算法的大幅進步，為保險企業帶來了新機遇。

據阿里云新金融技術架構師王磐介紹，以往很多保險企業把各個業務系統部署在數據中心內，各有一套集中式技術架構，導致“數據孤島”現象嚴重。而通過上云，使用數據中臺，保險企業可以很自然地解決類似問題，最大化數據資產價值。

而致力于成為一家數據科技驅動的公司，也正是友邦人壽正在踐行的事情。據劉立民介紹，隨著上云的深入，友邦人壽正逐步在云上建設數據中臺，并已經在日常運營中引入數據智能技術，助力內部高效培訓、精準識別保險詐騙等業務場景。

以培訓營銷員為例。友邦保險內部構建了一套交互式的智能評估系統，對營銷員的培訓效果進行評估。以前培訓效果主要借助考試成績來評估，而今天通過這套智能化系統，主管人員可以對營銷員的整個培訓過程進行“切片式”分析，及時發現問題所在。

“友邦人壽營銷員出單率遠高于行業平均水平。”劉立民表示，通過智能化的技術，友邦人壽不但降低了培訓成本，更為重要的是幫助營銷員提升銷售業績，降低流失率，助力整體業務的穩定增長

押注數字化轉型，2023年爭取90%的系統上云

新冠疫情是一場大考，倒逼整個保險行業加速發展數字化能力。與此同時，保險公司正在經歷著從關注“保單”向關注“人”和“家庭”的轉變，而要在新一輪變革大潮中擁有可持續的競爭力，積極主動進行數字化轉型成為了必選項。

據劉立民介紹，如今友邦人壽已有超過50%的核心業務系統完成上云，公司云上使用的服務器數量穩居友邦保險集團第一名，而在2023年，友邦人壽還將努力實現超過90%的系統部署在云上的目標。

“頭部保險公司其實都在積極地轉型。”劉立民認為，這樣的形勢之下，對于任何一家保險公司而言，數字化轉型都是必須要做的事情，沒有選擇。“大象都能夠跳舞了，如果不跟著跳的話，可能就意味著淘汰。”

中國保險行業尤其壽險行業，是一個大型保險企業占據80%以上市場份額的市場格局。在過去的2020年，頭部保險公司幾乎全都在重兵投入科技，部分保險企業還成立專業的保險科技子公司，加速充實技術實力。

這些大型保險企業重磅押注科技，背后的思考并不再是單純加大IT投入，更多地是提升自身科技力量，運用新數字科技孵化全新的保險產品，對保險的定價、理賠、體驗等方方面面進行重構。

保險行業中也經常會有新來的入行者，它們的商業模式可能跟過去完全不同。這類企業剛成立的時候，保險業務體量可能非常小，但是通過數字化和新模式，可能一兩年時間就會變得很大。

在劉立民看來，保險公司無論強與弱，都需要在數字化轉型做出大量投資，保持一種警醒的心態，使自己不要在這場競爭中落到后面。此外，劉立民強調：加強科技投入的目的在于通過電子化、數字化平臺的能力，更好地賦能產品服務創新和營銷員團隊，以數據化的形式構建出對客戶和營銷員團隊更精準的認識，從而更好地認知、分析和滿足客戶的需求，優化客戶體驗、創造客戶價值，并提升渠道效率。

展望未來，他說友邦人壽將會加速規劃數據中臺，優化數據模型，進一步最大化數據資產價值。“友邦人壽會在數字化轉型的方向上一直做下去，在競爭激烈的保險行業中占據一席之地。”

雷鋒網雷鋒網雷鋒網

但這些問題，在傳統銀行大步向前、業務飛速發展的過程中，一定會遇到：

• 怎樣才能在整個底盤升級過程中，盡量避免對已上線業務造成打擾？

• 想做到架構平穩切換，壓測方案如何設計定奪？

• 銀行怎樣改造數據中心，才能保證不同業務間的流量調度、隔離一切正常？

而網商銀行就用自身的云原生實踐給出了解答。從云平臺+分布式架構，演化到云原生、混合云彈性架構，這家被稱為“國內首家跑在云技術之上”的商業銀行，他們五年來的云化升級歷程，所遇到的典型挑戰、解決思路都頗具借鑒意義。

在雷鋒網《AI金融評論》與阿里云聯合主辦“銀行系統云化升級”實戰體驗營，網商銀行基礎技術架構部負責人蔣易民就深入講解了他們的云原生演進之路。

欲獲得所有講者視頻以及PPT回顧內容，可關注公眾號“AI金融評論”（ID: aijinrongpinglun），進群獲取回放鏈接。

以下為經雷鋒網AI金融評論編輯的蔣易民演講內容：

今天很榮幸和大家分享網商銀行的實踐情況。

從云計算走向金融級云原生

從這張圖來看，網商銀行主要經歷了三代架構的演進。

一，2015-2016年，主要是基于云平臺+分布式架構建立起來的。整個的部署模式是同城雙活模式。

二，2017-2018年，在同城雙活的基礎上需要建設一個異地數據中心，希望這個異地的數據中心在日常過程中能承載業務流量，能與杭州數據中心同時對外提供服務。

在滿足異地災備要求的同時考慮提升整個IT基礎設施的資產利用率，所以打造了單元化多活架構，它是一個三地五中心的部署結構。

三，2019年，網商銀行開始關注云原生架構，包括開始引進一些產品，設計建設相關能力。在這個過程中，我們也建設了混合云彈性架構，具備了在兩朵云之間調度資源的能力。

在上圖右側的曲線可以看出，從網商銀行開業，全行的容量水位大概是50 TPS，經過多年的發展，到現在已經到了5萬TPS。

但在整個過程中，也發現了存在的一些問題：

在底層基礎架構頻繁演進過程中，需要大量上層業務研發去配合。這個時候升級改造，控制進度、周期是非常難的。

一代架構的演進大概需要兩年左右的時間，基本上把全行所有的系統都切過了。過程中，研發人員的體驗感也不是特別好。

怎樣才能在整個底盤升級過程中，盡量避免對已上線業務造成打擾？這也是我們引入云原生最初的一個原動力。

放眼多年的發展，我們的路徑是一種雙模路徑——為什么叫雙模？就是在多個架構運行過程中，除了對新技術的探索，最重要的是要做好技術風險的防控，保證業務的連續性。

怎樣保證在新舊架構演進的過程中，最大化地減少對業務的影響？

我們在進行新技術探索時，也需要做好風險防控。

新一代架構誕生以后，并不是立馬全面投產，新老架構會經歷較長時間并軌運行，這種情況下是基于增量式的交付，逐漸把老的架構往新的架構演進，并且具備快速回退的能力。

網商銀行的技術架構特征

回顧網商銀行多年的發展，全行的技術架構特征，有以下幾個方面：

因為網商銀行是一家沒有線下網點的互聯網銀行，IT系統需要支撐上億的客戶，每天處理上億的交易量，雙11這種活動也會帶來流量的一個突增。同時還要確保安全、穩定和可控。

從我行的架構特征來看，要滿足這些高性能、高可靠，還有高彈性、高標準，低成本、低風險等要求，架構演進主要也是圍繞著解決穩定、效能、安全、容量、成本等多個方面進行。從安全角度來看，有兩個維度：

一，信息安全，主要是確保抵御惡意攻擊的能力，保證用戶數據和隱私安全。

二，資金安全，需要避免在交易過程中數據不一致，特別是一些缺陷導致公司和客戶的資金出現問題。

多年的架構演進，“壓艙石”是什么，那非全鏈路追蹤和壓測能力莫屬。如何做到架構平穩切換，壓測方案的設計是其中重要一環。

從開業至今五年多，三代架構的演進整體上是平滑的，我們認為很關鍵的一點是從第一代架構誕生就已具備了全鏈路壓測的本領。我們的方案跟一些業內方案可能存在一些差異，我們是直接拿生產環境去壓測的，沒有去做模擬的環境，盡最大可能避免環境配置和服務器的水位不同帶來的一些差異。

從上圖可以看出，我們計算上是共享的，但是存儲層面是同庫不同表。從這個角度來看，在壓測過程中是能最大化還原真實的生產流量對生產系統的壓力。

云原生在網商銀行的關鍵實踐

云原生架構是基于云原生技術的一組架構原則和設計模式的集合，最關鍵的點就是把一些業務處理邏輯中非功能性的代碼剝離出來，從而讓云設施接管應用中原有的大量非功能特性（如彈性、韌性、安全、可觀測性、灰度等）。

圖左可以看到，傳統架構的一段代碼邏輯包含三部分，非功能性代碼、業務代碼、三方依賴。
而云原生，希望非功能性的代碼在理想情況下最大化的減少，相對的業務代碼只要聚焦自己的業務即可。

大量非功能的特性，包括彈性、容量、安全可觀測性、灰度等都會逐漸下沉到底層的基礎設施，特別像高可用能力、容災能力、容量保障、安全特性，還有一些可運維的特性，逐漸讓基礎設施去接管。

這種情況下可以看出，在我們在部署上會發生的一些變化。從圖的右下角看到，容器會進行進一步的拆分，拆成應用一個進程，邊車（sidecar）一個進程。

網商銀行云原生的關鍵實踐，主要包含4個部分：微服務，容器化，不可變基礎設施，服務網格。

受益于第一代跟第二代架構打下的基礎，前兩個層面已經有了較好的積累，我們在進行云原生實踐過程中沒有投入太多的精力，后兩個部分投入很大。

涉及到不可變基礎設施最重要的一點，就是要完成它的鏡像化改造。對此，我們的要求應用是無狀態化。

早期的微服務有部分系統并不具備無狀態化，此時要求逐漸變成無狀態化。對于服務網格，我們引進SOFA Mesh來實現Mesh的落地。（注：SOFA是螞蟻金服自主研發的分布式中間件，Scalable Open Financial Architecture；SOFAMesh即其第三輪開源產品）

現在網商銀行部署的一個基線，主要是三地五中心的模式。

從應用層看，現有容量運用三個數據中心已經足夠，但在存儲層面選擇了5個中心。這種情況下，我們做的是多活的模式。

那么這套架構是怎么建起來的？依賴于商業化的一些成熟產品，包括金融級中間件SOFASTACK、分布式數據庫OceanBase。

這套架構最核心的一個特征，就是可以做到同城和異地容災切換時，RPO=0。

如圖所示，IDC1跟IDC2如果同時出現問題，我們可以做到分鐘級內把流量切到IDC3。這個過程基于異地多活架構提供的能力是非常快的。從近期生產演練的數據來看，同城大概是2分鐘，異地大概是3分鐘。

• 微服務與單元化架構

如圖所示，網商銀行早期也是非單元化。

非單元化有一個很典型的特點：在計算跟存儲上，會存在交叉訪問的情況。雖然網商早期設計中，做好了分庫分表的設計，但從上層計算層面看，它也會出現跨層。

早期運用同城雙活的模式，兩邊的數據跟計算存在交叉，這是沒什么問題的。但要建設異地數據中心時，兩地之間的延遲可能會導致一次服務的耗時大幅上漲，可能會導致最終客戶的一筆交易會出現超時，這種情況下計算跟存儲之間的跨城通訊是不可以接受的。

如何解決？采用的是單元化的架構模式，最典型特征是，它的流量是受控的，能形成一個小的閉環，讓計算跟存儲基本封閉在一個邏輯數據中心，但不排除有部分的跨城或者跨數據中心的訪問。

當跨城、跨數據中心的訪問是基于服務級別，不是數據級別的情況下，它的延遲是可以得到很好的控制。

當我們進入了單元化架構，在服務上會有多種路由模式，除了在同一個數據中心內部，單元之間、同城的數據中心之間也都會存在通訊的情況。最重要的是我們解決了跨城數據服務通訊。從實踐來看，延遲是可以接受的。

重點看右下角的路由表，分片標記用戶，用戶屬于某一個數據中心下面的一個單元，通過該路由表，用戶的請求進入后會找到對應的數據中心下面的單元。也可能會出現一部分用戶進入后，并沒有到正確的數據中心，這種情況下我們會在接入層把用戶的請求轉到它對應的一個數據中心。

路由的核心是在SDK層面解決的。在業務系統代碼里引入一些關鍵的API去做一些路由的定制，這種情況其實是非常重的。

從全行的單元化升級來看，花的時間也較長，這個跨度至少是一年以上，才會把一些關鍵的系統全部切到單元化架構上面。

• 容器技術

網商銀行早期也經歷過富容器，這種較重，包含了所有的應用發布部署需要的依賴，不限于一些關鍵的RPC、消息、數據庫等SDK。

最小的部署單元也是一個容器，在云原生里做進一步劃分。

容器會區分為APP的容器，跟Sidecar 的容器。根據現在的實踐來看，主要是包含Service Mesh里面MOSN的容器，還有DBMesh的容器。這兩個容器解決的是 RPC、消息，還有數據庫跟緩存層面的轉發。

這種模式有一個最大的好處，就是MOSN跟DBMesh可以獨立演進，即可以不需要在上層業務容器配合的情況下，自己完成一些升級跟發布。

當我們做一次全行的架構升級，富容器模式會帶著全行所有的應用，可能會進行一到多次迭代的發布。

升級一個SDK最大的問題是什么呢？因為各個系統有自己的進度安排，各自資源可能不一致。要做到全行統一升級，周期往往會拉得非常長。

最不可控的是什么？升級過程中，不同的系統質量保障各有差異。有些可能做得非常好，但有些如果稍有瑕疵，就會引發生產問題，這種情況下很難通過統一的手段去保障。

全行架構升級過程中，關注質量的品質，一致性和普遍性。

相對而言，輕容器較好做，因為所有的能力下沉到MOSN跟DBMesh之后，只要在這兩個層面做好質量保障，聚焦后能保障升級品質的一致性和普遍性。上層云的應用很少會關注下層的一些變化。

舉個例子，有一次全行升級，大概是一個人花了不到一個月的時間，把全行上萬的容器全部進行升級，基本不會對上層的業務造成打擾。所以輕容器相比富容器模式有了極大的提升。

• 不可變基礎設施

早期發布時，這是分階段的，一般要先創建服務器，再下載依賴，過程中可能還要安裝一些插件。全程存在很多變量，包括環境標記，依賴于不同人的配置能力。

早期配置的過程，會把一部分代碼的參數放在配置平臺。相當于引入一個可變的變量。

當配置平臺發生一些變化，整個部署的效果就可能會出現差異，最明顯的就是線下環境部署沒問題，但在生產過程可能會發現問題。

怎么解決？在云原生架構理念上，我們考慮把所有的信息都放在鏡像化包中，最大的好處是所有東西都包含在一個鏡像里面，就可以從鏡像環境到生產環境都使用同一個鏡像。

這個過程需要應用保證它的無狀態化。如果做不到無狀態化，它就不能做到自動的擴收容和自動恢復。

從圖中可以看出，我們的鏡像是分層的，這有利于不同的團隊可以聚焦在自己的那一部分，然后整合起來形成一個大的鏡像。在發布過程中，能保證質量品質的一致性，不會受限類似于一些環境或者人的操作水平。

• 單機故障問題的云原生解決方法

在實際的生產過程中，全行幾百個系統最典型的問題是單物理機故障對業務產生的影響較大。

物理機的規模較小，很容易導致部分核心系統的容器分布集中。普通的PC物理機會有宕機問題，造成影響面的半徑較大。

比方說一個核心系統，可能有百分之四十容器集中在這臺物理機上。當它出現問題，對業務穩定有極大的挑戰，即使只是小部分出問題也會引起較大的抖動。

怎么解決？有了云原生架構后，我們根據業務特點，包括應用等級，去制定策略，確保所有的調度不會集中在個別的物理機上，也可以說是把它“打散”。

另一方面，之前配置中心不能自動發現物理機上的容器問題并自動剔除，通過監控 MOSN的監控狀態，探測它的服務健康狀態。下發自愈策略后，當它發現監控報警有問題，讓它自動剔除。

因為在分布式架構下，很多業務最終會匯集到同一個服務上。怎樣保證這些服務占用的資源不會互相影響？這也是我們目前面臨的一個較大的挑戰。

其實除了物理機故障場景，在實際生產過程中還經常遇到這種問題：因為業務場景增多，有一些日常過程中流量非常少的業務場景，突然間提速后，會導致周邊跟業務相關的所有系統發生變化。

這種情況下，很可能出現部分服務器請求積壓，導致其他業務請求發到這臺服務器時處理時會失敗。這種情況下可能會影響很多業務，嚴重情況時會出現“雪崩”效應。

很多時候聯機交易跟批量交易并沒有拆分系統，所以他們占用的資源是同一批。

這種情況下，在新的云原生架構下，借助資源調度和流量的標記能力對資源進行隔離使用，這樣聯機交易和批量任務所依賴的資源就可以區分開來，同時，我們希望把這些批量任務托管起來，做到資源的彈性調度。

當批量任務開始跑批時，能動態給它更多的資源；但沒有跑批時，把資源給釋放出來，可以減少對聯機交易的一些影響。

• 不同業務的流量隔離與調撥

從上圖可以看出，當一個流量進到生產系統時，它經過了多個系統，最終它會反映到的底層是容器，當沒有進行有效區分時，不同的流量在容器內部是互相干擾的。

基于新的云原生能力，在流量轉發的過程，它會有具備染色能力，可以在流量通過mosn時進行標記，讓它路由到指定的一些容器上，就可以做到不同業務請求下，它會路由到不同的容器集群里，業務之間的相互影響就得到進一步降低。

最典型的是生產遇到的熱點賬戶問題，很容易導致全行的交易抖動。如果我們可以識別不同的業務所導致的熱點，可以做到有效的隔離，發生熱點時不會影響到非產生熱點的其他業務場景。

而近幾年銀行在改造數據中心，新中心的流量調度能力以往是比較弱的。

數據中心間的流量調撥的一般做法會在流量入口層做處理。如果投產過程中出現問題，對業務打擾較大。雖然也能做到快速回切，但從銀行每天上億的交易筆數來看，哪怕是幾十秒，受影響的用戶數可能也非常大。

在新的云原生架構之下，基于mosn可以打造更細粒度流量調撥，從數據中心層面進一步下沉到單個應用級別。可以找一些不敏感的應用服務先切流，避免影響到關鍵業務內容。

云原生架構的核心價值是可以實現流量的精細化隔離。

在單元化異地多活架構下，可以做到數據中心里某一個邏輯區域的隔離。到云原生架構下，可以把流量的隔離能力做得更細。

原來的模式下，兩個業務同時進來，還是會互相影響。而云原生模式，可以按業務等級進行管理。

我們會給不同敏感度的業務打上標記，以此區分業務應該到什么樣的容器下去做完成交易。

標記能力因為有MOSN，所以實現起來較容易。相比早期第二代架構做單元化用UID做標記，是通過研發人員編寫代碼實現的。因此借助MOSN，可以用很低的代價實現這個邏輯。

運用MOSN之后新的數據中心啟用方式會有什么不一樣？

我們早期做新數據中心壓測，一般來說有兩種方式。

1、 通過找一些系統進行流量轉發。做流量轉發往往需要系統自我改造，這樣不具備規模化、快速化的復制能力。

2、 直接把流量入口遷入新的數據中心。

早期做數據中心壓測時，很難做到較細粒度，這和網商銀行是異地多活模式有很大關系。它有一個全局的路由表，如果做不到新舊數據中心隔離，就會有問題。

舉個例子：在沒有升級能力的情況下，如果做壓測，可能就需要讓全局路由表在新的數據中心生效。新的數據中心在沒有經過充分驗證的情況下，一旦路由表生效，生產流量進入就很有可能導致故障。我們通過Mesh進行了路由表的隔離。

新舊數據中心的路由表是有差異的，這個差異體現在哪里？

兩個老數據中心生產流量配比可以做到50%：50%，新數據中心沒有生產流量，而壓測流量在兩個老數據中心和新數據中心中配比可以做到40%、40%、20%，壓測流量有一部分在新的機房進行處理，根據新的路由表轉到了新的數據中心。

Mesh在我們新的實踐過程中，可以支撐不同的技術棧。從網商銀行建站以來，我們是有一部分外購的系統，雖然它是Java技術棧，但是它可能和我們的體系，比方說基于SOFA，還是有差異的。

實踐層面上看，讓外購的廠商改成SOFA框架是很難的。傳統模式下是希望廠商適當改一部分，框架不用修改，他可能修改服務調用方式，而我行內部的這些自研系統，他會提供某種輕量級的HTTP服務，暴露給外購系統進行互聯互通。

整個過程來看，代價是較高的，它對相關的每個系統都有改造要求。

現在隨著我們整個業務的發展，特別是智能化和新技術引進，逐漸出現了JAVA之外的其他語言系統，最典型的就是Python、GO語言，這些系統怎樣跟Java系統互聯互通？這種情況下其實也會帶來新的問題。

在云原生模式下，這個問題就變得簡單。因為sidecar解決了，像服務發現路由、加密。鑒權，限流等通用性問題，它集成了一些不同的語言，這種情況下，它只要提供一個SDK，輕量化就能對接上系統。

這樣服務提供方和服務消費者都不用做大的改動，只要單邊系統修改就可以，不需要所有相關方做改造，對我們整個研發效能提升和業務拓展帶來非常大的幫助。

未來：可信原生

總結下來，前面提到的云原生實踐更多的是在穩定性、效能方面去提升。現在需要關注的問題，在云原生架構模式下，我們做安全會有哪些不一樣的地方？

• 解決應用層的安全。

• 從整個基礎設施層面做到安全可信。其中包含多個環節，包括硬件準入，從主機的供應鏈層面可能要防止物理機入侵。

• 從鏡像準入層面做一些控制，防止鏡像被非法篡改后在生產上運行。

在有了MOSN以后，最大的好處就是可以做到全局的服務和數據鑒權。

原來那種架構模式，如果要做數據鑒權跟服務鑒權，也需要很多系統去改，去做 SDK的升級。

在寫入鏡像中心時，要做安全可信。

1、首先，控制在研發環境的鏡像編譯、準入。

2、在整個鏡像被使用的過程中，去驗證鏡像是否安全。

3、從底層的物理機層面，在供應鏈采購時可能會做準入控制。

4、在上層應用層的容器啟動時，我們也會探測它是不是可信的。

有了MOSN，我們在進行服務的鑒權，還有數據的加密都可以下沉到相關的sidecar，這種時候做安全方面的控制都集中在底層的基礎設施，可以明顯看到云原生帶來的紅利。

上層的業務可以不用關心相關的要求，基本上安全工程師通過配置一些規則，然后把這些規則下發到全行相關的一些sidecar產品上即可，包括 MOSN、DBMESH。

答疑環節精選

問：壓測采用的是生產流量還是模擬的流量？

蔣易民：我們用的是模擬的流量，它跟生產流量是不一樣的。這是另外一套賬號體系，它不是真實的。

生產流量是真實的用戶，壓測流量來源于壓測平臺，且流量并不是同一套流量，用戶體系也是不一樣的。在存儲結構上是同庫上兩套不同的表（表結構完全一致但表名不同），落的數據處于不同的區域。

問：關于客戶統一視圖查詢的問題。

蔣易民：如果要在多個服務中獲得最新的客戶信息匯總，就需要把數據集中化處理了。但是從實際的過程看，至少在交易層面，是很少用到客戶信息的匯總，更多的是在批處理層面。在批處理層面，我們會把它放到類似于odps大數據平臺去解決。

所有數據回流到大數據平臺，多庫多表，最終會集中到一張表里，這個數據是全量的。

采用 sidecar以后，我們運行這套架構也有較長時間了，對日常其實沒什么影響。基本上層業務對它沒有什么感知。整個sidecar引進以后，對資源的占用是非常少的，不會影響到整個系統的容量水平。

系列全回顧丨銀行系統云化升級·實戰體驗營

本次實戰體驗營由雷鋒網《AI金融評論》與阿里云聯合主辦。欲獲得所有講者視頻以及PPT回顧內容，可關注公眾號“AI金融評論”（ID: aijinrongpinglun），進群獲取回放鏈接。

“工業革命不得不等候金融革命”。

英國學者、諾貝爾經濟學獎得主約翰·希克斯的這句原話，道盡了金融與社會經濟變遷的規律：歷次消費升級伴隨的產業結構的演進變化中，銀行都發揮了極其重要的作用：

17世紀末，英國依靠中央銀行和商業銀行體系提供資本燃料和動力。以蒸汽機為標志的工業革命，其實是金融革命的產物。

20世紀初，摩根、卡內基等一眾金融大鱷掀起了第二次金融革命，主導了五次并購浪潮，完成了第二次工業革命；

如果說，此前的數百年，是銀行為科技革命體注入新的活力。那么，在五年前，銀行差點被“科技革命”所拋棄。

作為數據密集型行業，銀行業一直是與科技走的最近的一個行業：上個世紀80年代的ATM機、90年代的網上銀行、十年前的手機銀行。

在以大數據和人工智能為標志的第四次工業革命，銀行業的轉型并不簡單。

在2018年年報里，針對金融科技對傳統金融機構的重塑，“零售之王”招行做了深刻反思：

“過去十年，傳統金融機構已惘然目睹了金融科技重新定義零售業務的全過程，從支付延伸到存貸款、財富管理，傳統銀行的資金中介、信息中介職能已受到深刻沖擊，信用中介作用亦面臨威脅。

隨著社會發展從消費互聯網向產業互聯網深入，金融科技重新定義公司金融和資產管理也迫在眉睫。”

金融科技的轉型，不是一次簡單的小修小補，而是一次全面的“大掃除”。

首先是底層系統架構的轉型，從傳統集中式架構轉為分布式、開放式架構；其次是業務流程的重塑；再次是用戶運營和場景生態搭建。

如果從云計算、人工智能等科技屬性的角度來說，網商銀行反倒是新銀行的“前輩”。

網商銀行被認為是“國內首家跑在云技術之上的商業銀行”，開了時代的先河。

從2015年起，這家沒有線下營業網點的創新金融機構將通過互聯網來開展服務。比如，網商銀行利用數據智能進行貸款發放，300人就可以支撐了全國的業務量。

2009年9月成立的第一天起，阿里云就是一家金融級的技術和服務廠商，支撐網商銀行最初的雛形——牧羊犬項目。

2018年，南京銀行宣布聯手阿里云，國內首個商業銀行分布式核心業務系統順利上線運營。其基于阿里云飛天系統構建的“鑫云+”平臺已服務多家銀行的上百萬用戶，平均每個客戶的放款時間只需1秒，日處理訂單量可達到100萬筆，是原來的10倍。

同年的8月，民生銀行通過與阿里云合作，將核心系統上云，并且成立民生科技有限公司。

在一些中小行的身上，也能看到非常多金融云的求變身影。

2020年，民營銀行華瑞銀行與阿里云正式簽署全面戰略合作協議，推動華瑞銀行核心業務系統加速向云架構轉型。

上海華瑞銀行科技部總經理葉寧曾表示，“移動銀行上云之前，華瑞銀行三年軟硬件的投入逾千萬元，上云之后，每年投入可以控制在數百萬元以內。”

2019年底，華瑞銀行在阿里云“飛天”云計算操作系統、螞蟻金融分布式架構SOFAStack、mPaaS移動開發平臺和大數據風控平臺的幫助下，已成功構建并上線了“祥云”私有云平臺，支撐手機銀行、營銷系統、反欺詐系統、貸款核算等業務系統運行，同時實現了App的迭代升級。

數年的時間，國內大大小小的銀行，都實現了“云上作業”。

然而，上云從不是一件簡單的事，一味的跟風和不加選擇更是不可取，核心在于認真梳理好業務需求和投入產出比。

要知道，上云是過程，而不是目的。在上云之前，銀行的IT人員，一定要多問自己幾個問題：

不同類型/規模的銀行核心上云的價值差異在什么地方？

如何確保核心安全可靠的下移上云？

要啟動核心上云下移的工作該如何準備，如何著手，需要考慮哪些方面的內容？

核心上云的實施路徑有那些, 采用什么樣的步驟會比較好？

核心下移上云目前的生態是什么樣子，有足夠的服務和支持能力嗎？

工欲善其事，必先利其器。思考銀行為什么上云，從來不是一件太晚的事情。

基于此，雷鋒網《AI金融評論》與阿里云聯合主辦“銀行系統云化升級”實戰體驗營，邀請到五位頂尖行業專家線上分享。

從本周起，阿里云新金融事業部金融核心部負責人陳威，網商銀行基礎技術架構部負責人蔣易民，將分別帶來《金融核心云原生轉型探索與實踐》和《構建云原生架構-網商銀行SOFAMesh應用實踐》的主題演講。

廣度而論，從銀行、云廠商、ISV（獨立軟件開發商）三大角色出發，不同視角討論銀行核心系統與應用的云化改造；

深度而論，專場內容覆蓋銀行上云的標準與選型、成功上云實戰復盤、金融核心建設、云與AI的關系與內涵等多個方向。

本次實戰體驗營，為雷鋒網2021金融云峰會的首場線上活動。后續將有更多嘉賓加盟。

同時，《AI金融評論》也將圍繞銀行上云、核心系統建設、云金融等主題，陸續推出多篇深度稿件。

為銀行業乃至金融界，和科技圈，輸出最立體化、最具前瞻性和參考價值的銀行云、金融云內容，同時搭建高質量的微信社群，促進上下游企業交流探討。

關注《AI金融評論》，對話框發送關鍵詞“參會”，進入專家微信群，觀看直播。

嘉賓分享議程

開場致辭：劉偉光，阿里巴巴集團副總裁、阿里云新金融事業部總經理

嘉賓介紹：劉偉光畢業于清華大學電子工程系。曾負責螞蟻集團金融科技的商業推廣和生態建設工作，以及螞蟻鏈的商業拓展工作。

他在企業軟件市場深耕多年，曾經創建Pivotal軟件大中華區分公司，開創了企業級大數據以及企業級云計算PaaS平臺的市場先河。

在創建Pivotal中國軟件公司之前，劉偉光曾經擔任EMC公司大中國區數據計算事業部總經理，并在Oracle公司工作多年，曾經創建了Exadata大中國區的產品事業部并擔任事業部總監。

第一場：張曉丹，阿里云新金融事業部CTO

演講時間：1月19日（周二）20:00-21:00

演講主題：《新一代金融IT基礎設施：阿里云的金融云前瞻與實戰》

演講大綱：

• 金融IT基礎設施發展需求與趨勢

• 金融云應用場景 

• 打造安全、穩定、敏捷的云上金融

嘉賓介紹：曾任工商銀行總行部室副總級專家，先后在工行分行、數據中心、總行IT部門任職22年。

曾任恒豐銀行科技部總經理，期間建設了國內銀行業第一家多租戶的金融IAAS行業云，首次將一家全國性股份制銀行的應用系統全部遷移上云。

2018年，張曉丹加入阿里云。

第二場：吳守鈺，中電金信（原文思海輝）金融解決方案事業部產品總監

演講時間：1月21日（周四）20:00-21:00

演講主題：《建設基于金融云敏態業務系統的探索與實踐》

演講提綱：

• 從云下到云上，從穩態到敏態

• 云上敏態業務系統要點分析

• 云上敏態業務系統建設實踐

嘉賓介紹：擁有18年金融IT行業經驗，熟悉銀行互聯網金融、開放銀行、核心系統、支付結算等領域，有豐富的行業調研、架構設計、需求分析、產品研發等經驗，擅長云環境下的銀行解決方案設計，近年專注于數字化轉型方向產品研發與項目實踐。

第三場：陳威，阿里云新金融事業部金融核心部負責人

演講時間：2月2日（周二）20:00-21:00

演講主題：《金融核心云原生轉型探索與實踐》

演講大綱：

• 銀行核心系統云化轉型的訴求

• 核心云原生轉型的挑戰與應對

• 相關路徑與案例介紹

嘉賓介紹：現任阿里云新金融事業部金融核心部負責人，負責金融核心相關解決方案。曾從事企業級信息技術產業十余年，具備豐富的應用架構與設計，數據智能，云平臺，互聯網等領域的理論與大型復雜項目實踐，尤其在金融行業具有多年的交叉實踐經驗，服務于近百家大型機構與客戶。

第四場：蔣易民，網商銀行基礎技術架構部負責人

演講時間：2月4日（周四）20:00-21:00

演講主題：《構建云原生架構-網商銀行SOFAMesh應用實踐》

演講大綱：

1、網商銀行開業以來基礎架構的演進歷程 

2、網商銀行基礎架構演進和業務發展過程中的典型問題 

3、網商銀行基于云原生架構的應用實踐和展望

嘉賓介紹：負責全行基礎架構的規劃、落地以及全局穩定性保障，打造高可用，高并發的系統技術底盤，經過3年發展，將全行核心交易峰值能力由50TPS提升到50000TPS，從開業以來參與和見證了技術底盤的快速演進，完整經歷了“同城雙活”到“兩地三中心”再到“三地五中心”的發展歷程，主導了異地多活單元化、混合云彈性和云原生架構的落地，榮獲過人民銀行科技發展獎。

如何預約專場？

1、關注公眾號“AI金融評論”（ID：aijinrongpinglun）

2、在公眾號對話框回復關鍵詞“參會”，即可進微信群觀看直播，亦可與技術大佬們談笑風生。

本次活動面向的人群

• 銀行信息技術/IT部門，和研發部門團隊；

• 云服務供應商、金融科技公司高管；

• 傳統IT廠商和軟件供應商高層；

• 券商、險企等持牌金融機構IT建設部門；

• 高校計算機、軟件專業、人工智能教授與研究生

雷鋒網雷鋒網

但也正是因為這樣的“上云潮”出現，業界需要更加深入探討：到底銀行核心系統轉型的訴求是什么？價值又何在？到底有哪些成功案例可供借鑒參考？

核心業務系統，自然是銀行的“核心”。對銀行核心上云的討論，則是銀行云化升級進程里的“核中之核”。

為此，雷鋒網《AI金融評論》與阿里云聯合主辦“銀行系統云化升級”實戰體驗營，第三場演講由阿里云新金融事業部金融核心部負責人陳威帶來。

明晚8點，陳威將針對金融核心云原生轉型這一主題，帶來阿里云近年來的實踐探索經驗。

演講嘉賓

陳威，阿里云新金融事業部金融核心部負責人

演講時間

2月2日（周二）20:00-21:00

演講主題

《金融核心云原生轉型探索與實踐》

演講大綱

• 銀行核心系統云化轉型的訴求

• 核心云原生轉型的挑戰與應對

• 相關路徑與案例介紹

嘉賓介紹

陳威，現任阿里云新金融事業部金融核心部負責人，負責金融核心相關解決方案。曾從事企業級信息技術產業十余年，具備豐富的應用架構與設計，數據智能，云平臺，互聯網等領域的理論與大型復雜項目實踐，尤其在金融行業具有多年的交叉實踐經驗，服務于近百家大型機構與客戶。

近兩年，利用科技革命實現銀行產品和服務的線上化、移動化，成為大勢所趨。從渠道體系到核心系統，銀行正在經歷全面的數字化。

但是，2020年突發的疫情，讓銀行業從常態、穩態的運行環境中，切換到一個不確定狀態。

傳統集中式架構和分布式架構，兩者一直存在著技術爭論：分布式架構銀行由傳統IT架構支撐的核心系統，一時半刻不可能完全拋棄。但同時，銀行也希望像互聯網企業一樣，敏捷地支撐應用場景，敏捷地支撐業務開發。

敏捷響應，成為銀行金融服務能力的一大考驗。

作為中國電子旗下幫助金融行業數字化轉型的代表，中電金信（原文思海輝）在建設金融云敏態業務系統方面有著自己的心得。

中電金信金融解決方案事業部產品總監吳守鈺，從用戶域、產品域、支付域、公共域等四大基礎能力入手，分享了金融云敏態業務系統的架構和功能實現。

以下是吳守鈺的演講內容，雷鋒網做了不改變原意的編輯與整理。

大家好，很高興能夠參與本次的云峰會。我叫吳守鈺，任職中電金信數字銀行部產品總監。

今天，我分享的主題是《建設基于金融云敏態業務系統的探索和實踐》，主要分享我們在建設金融云敏態業務系統方面的一些理解和實踐。

近幾年，在金融新業態下，商業銀行面臨著新的挑戰：

一、經濟雙循環，引新與活存并重，To B領域持續創新，商業銀行需要快速適應市場變化；

二、監管趨嚴：近期金融監管政策不斷出臺，劃分厘清銀行與互聯網平臺的邊界，要求銀行回歸本源、服務實體、產業賦能；

三、新科技：ABCDMIX技術日益成熟，應用越來越廣泛，重塑金融科技。

在新背景下，商業銀行IT系統建設呈現出了六大方面的趨勢：

平臺型銀行，平臺化經濟實現價值提升；

開放型銀行，服務自營渠道、服務開放生態伙伴，能力和服務具有對內外共享開放屬性；

生態型銀行，建立生態圈和生態體系，拉近、拉緊與各類合作伙伴的距離和關系；

體驗型銀行，提升用戶體驗，構建用戶全旅程，提供個性化服務；

敏捷型銀行，具備從IT架構、業務能力、場景金融等多方面的快速適配能力；

智慧型銀行；

以上市場變化和系統建設趨勢，都指向了“敏”，敏態的技術平臺和敏態的業務系統；建設基于金融云的敏態業務系統正是對癥下藥的一劑良方。業務中臺是敏態業務系統的基礎設施之一。

業務中臺，實現上是對業務能力的綜合治理，可以分為三層，從下往上看：

最下層是基礎能力層。

根據領域化分可分為用戶、產品、支付、公共等能力域，每個域內部又包含若干基礎能力中心。

用戶域：解決平臺誰用的問題。建立開放用戶體系，對包括銀行內外的使用者、各類產品和服務的上下游等，進行統一的管理和治理；具體又可以分為用戶、合約、標簽畫像、營銷等能力中心；

產品域：解決平臺賣什么的問題。對各類金融、泛金融、生活服務等產品進行工廠化管理，建立分類的產品模型，實現產品組合、差異化定價、績效評估等。賬戶也可一類特殊產品納入產品域，包括資金賬戶、權益賬戶、關聯賬戶等，支持賬戶的組合和創新，如集團賬戶、錢包賬戶、創新存款等；

支付域：解決資金流轉及流轉過程中的控制問題。可分為支付、費用、額度、對賬等中心。其中支付中心實現線上線下一體化收單、聚合支付、資金劃轉撥付、代收代付等服務，通過模型化的訂單流轉和支付決策引擎實現標準、高效的流轉；費用中心實現費用計收、清分、分攤等功能；額度中心實現用戶、渠道、場景、產品等不同主題的限額管理；對賬中心實現實時、定時等的交易檢查、核對。

公共域：提供安全、消息、資源中心、審批和運營等功能能力。

第二層是場景構建工具。

我們稱之為服務編排，可分為兩大中心：交易中心和參數中心。

交易中心通過可視化流程編排IDE平臺實現對內外部微服務的編排，提供運行態的訂單化處理；

參數中心實現對能力、產品、流程、運營等參數的維護和管理，包含參數定義，更新、下發、訂閱、變更、同步等功能。場景構建工具讓業務人員、運營人員能參與到開發、運營過程中，看得懂、能維護。

通過以上兩層，實現強中臺、大中臺的能力支撐，及敏捷交付能力。

最上層是場景服務層。

包括銀行自營場景、開放銀行場景及其他合作運營場景。

有效的資產、服務的治理，通過標準流程、動態參數管理，實現前中后全流程的數字化管控，提升綜合服務能力。

敏態業務系統的實踐

下面介紹一些我們在阿里云平臺上構建敏態業務系統的實踐。

某省農信依托于阿里云，建設了行內敏態系統，該系統目標及定位如下：

提高系統的可用性和可靠性；

降低對基礎設施投入的成本，以及運維、管理的成本；

提升快速響應能力以及系統服務能力。

系統支持多法人、核心業務系統下移、分布式場景下的研發運維一體化、存量應用系統云化改造、三地多中心多活架構，以及分布式場景下的安全運維管理方案等。

業務中臺分為基礎能力層和場景層，既提供寬度、深度，也實現敏捷快速交付。

某城商銀行的數字化業務系統建設項目，技術底座采用阿里云平臺，建設范圍包括業務中臺、數據狀態、運營中臺等。業務中臺由基礎能力中心提供厚度，自營及開放場景服務中臺提供敏捷業務交付。

通過與阿里云效平臺集成，提供了從需求、設計、開發、測試、上線到運維的一體化服務。

中電金信是中國電子旗下的成員企業，是中國規模最大的銀行業IT服務公司，連續三年在中國銀行業IT解決方案市場排名第一。

中電金信員工超過26000人，擁有數字化業務、數字化營銷、數字化運營等的完整的金融解決方案體系和服務體系。

以上是我今天的分享內容，謝謝大家。雷鋒網雷鋒網

金融機構IT架構的“成長”中，有太多“陣痛”：

• 從集中式演變到分布式，標準化、開放化的建設是有了，應用人員要操心的事為什么更多了？

• 一臺大機支撐上萬臺服務器，是很節能環保，但研發周期太長、售價太貴，一個性價比更高、更敏捷開放的替代方案是怎樣的？
  

• 銀行如果不做全面上云，繼續長期維持雙模IT，不可行嗎？

• ……
  

在阿里云新金融事業部CTO張曉丹看來，談金融機構的IT建設，談云架構轉型，其實不只是在談一個技術問題，同時還是一個經濟問題。

這場IT架構的云化改造，不僅事關時間、人力、物力，更關乎金融機構的人員能不能擺脫復雜架構的束縛，更加專注業務和應用的創新。

“整個IT基礎設施交由專門的金融行業云承載，實現按需、敏捷、彈性獲得算力以支撐應用創新。”張曉丹這樣概括發展金融行業云的目標。

在雷鋒網《AI金融評論》與阿里云聯合主辦“銀行系統云化升級”實戰體驗營中，這些圍繞在金融云化周圍的疑問被一一解開。

本次實戰體驗營的首日分享中，阿里巴巴集團副總裁、阿里云新金融事業部總經理劉偉光帶來開場致辭，他表示銀行業正在全面應變，掀起線上化、數字化、智能化的變革，無處不在的銀行服務逐漸由藍圖變為現實。

此后，阿里云新金融事業部CTO張曉丹帶來了首場演講——張曉丹曾是工商銀行總行部室副總級專家，先后在工行分行、數據中心、總行IT部門任職22年；在恒豐銀行出任科技部總經理期間，建設了國內銀行業第一家多租戶的金融IAAS行業云，首次將一家全國性股份制銀行的應用系統全部遷移上云。

這次，他結合自身二十余年在銀行的IT經驗，分享金融IT基礎架構全面云化、機構應用遷云實錄等干貨。

以下為經雷鋒網AI金融評論編輯的張曉丹演講內容：

大家好，我今天分享的主題是《阿里金融云，新一代金融IT基礎設施》。

金融IT基礎架構的全面云化

整個金融行業正在面臨著向數字化轉型的大潮過程，這個階段中，我們不斷在發展在線化、數字化以及網絡化、平臺化以及智能化。轉型過程對金融IT基礎設施提出了更高的要求，需要我們能夠按需、敏捷、彈性的獲得更經濟和廉價的算力。

傳統的IT架構比較安全、穩定、可靠，但是其開放性、彈性、敏捷性、經濟性存在一定的局限性，所以需要不斷向云架構進行轉型和升級。

在這個過程中，私有云、行業云、混合云，還有公共云具備各自的優、劣勢。我們專門為金融機構建設一個行業云，跟現有的私有云進行混合，在提升金融云的監管合規、安全穩定的同時，最大限度地提升經濟效益。

• 為什么要向云架構轉型？

首先，降低成本，提高效率。

云本身，不僅僅是個技術問題，還是經濟問題。

通過規模化的運營、建設和共享實現規模效益，以獲得便宜、廉價的算力。通過軟件化、系統化和服務化，提升整個運行效率，間接降低成本。

第二，云轉型的核心就是要改變應用架構和原來的技術路線，廣泛采取近十年來發展起來的開放開源、分布式的互聯網技術路線，提升整個應用研發的敏捷性，促使研發和運行一體化以支撐業務的敏捷和迭代。

一旦IT能夠低成本，提升敏捷度與迭代，整個業務競爭力會躍上一個新臺階。以前長期的自上向下的建設，變成快速走向市場、并與用戶進行業務嘗試和迭代，在業務與客戶的互動過程中來升級業務系統，其中會不斷應用到一些分布式、微服務、云原生的技術。

第三，保持整個IT技術路線的現代化。長期不升級會帶來技術架構的老化，運行風險增加和效率低下，以及人才隊伍難以保持等問題。只有進行穩定、持續的架構升級，才能保證整個IT的能力。

云架構也是借助于云平臺化的效應，來拓展金融機構的業務邊界。通過開放銀行、開放證券、開放保險，和周圍的生態各方建立網絡化的連接，拓展自己的業務場景，從線下走向線上。

再者，利用高性價比的、豐富的按需可獲的資源，加上數據化處理能力，幫助金融機構在架構轉型的過程中，樹立起以積累數據資產為目標的客戶運營、流量運營的意識，提升企業運用數據智能的能力，提供高精準、更高效的客戶服務。

未來的競爭是數據智能的競爭，只有擁有更多的數據資產，建設強大的數據中臺，才能實時支撐好數據的智能并且發展業務。

IT架構的發展歷程，從最早的大型機、小型機等集中式架構，再到scale-up架構，基礎設施、應用架構、研發模式都發生了很大的變化。

隨著整個架構的演變，最大的問題是成本高，研發周期過長，一臺大機能夠支撐上萬臺的服務器的能力,節能環保。但研發成本周期長、成本高，售價太貴。

同時，傳統的應用架構技術比較封閉，生態沒有得到發展，而分布式云原生架構，目的就是更加開放，更加敏捷。

原來在一臺大、中型機以及小機里面，操作系統、應用軟件、中間件，數據庫都在一臺大機器里運行，是一種高度集中耦合的架構。

而分布式架構，開始用一堆的服務器來替代大機時，相應地，就從一個操作系統變成很多小的操作系統——如何將這些小的操作系統重新耦合起來，變成一個大的操作系統，就是IaaS云的使命。

• 全面上云怎樣降低IT基礎設施的總擁有成本？

上層從一個大的中間件，演變成一個分布式的微服務架構；從原來的SOA，進一步發展到分布式微服務，再發展到現在的服務網格。

集中式架構與云原生架構之間的分布式架構階段，存在一個問題：

當底層開始從幾臺大型機器，變成眾多的小型機器及服務器以后，上層做應用開發的人員，將要面對下面的分布式的計算架構。

因為下面的平臺封裝得不太好，能力不太強，所以使得上層原來只關注業務和邏輯的開發人員，開始更多關注下面的基礎架構。

雖然技術架構的建設更加標準化、開放化，但是應用開發更加復雜，應用人員要關心的事也越來越多。

進一步的云原生架構轉型，實際上是經過循環迭代以后，回歸到更高層次的平臺化、服務化水平。將分布式架構的復雜性封裝在整個云平臺，其中包括IaaS、PaaS、DaaS等各種技術，讓業務和開發重新回歸到業務邏輯，而不需要太關注下面的平臺。

最上層的業務中臺、數據中臺、協同平臺、AIOT平臺，以及支撐其的服務網格、湖倉一體、HTAP、流批一體等技術，都是為了把平臺越做越厚，讓基于分布式架構的應用開發越來越簡單。

底層是從大機、小機、物理機到虛擬機、容器，以及兼具容器和虛擬機的特性的安全容器。

原來的大機通過專有的網絡連接大容量的集中存儲陣列，到后面小機通過SAN網絡連接SAN存儲的計算存儲分離架構，發展到現在：沒有硬盤的神龍服務器，通過標準的以太網連接后面分布式的云盤，形成新一代的計算存儲的分離架構，從原來的兩地三中心發展到現在的兩地四中心、多地多中心的新的容災體系架構，對原有的體系架構進行全面升級。

在這個過程中，金融云的底層的平臺完全交給云服務商進行建設，使得金融機構的人員將專注力放在業務和應用的創新上。對金融機構而言，它有資本充足率的限制，寶貴的核心資本，實際上是要用于金融業務的發展更加高效。

銀行的核心競爭力實際上并不在IT基礎設施，而是在應用研發和業務的創新方面，幫助中小金融機構整個IT基礎設施交由專門的金融行業云承載，實現按需、敏捷、彈性獲得算力以支撐應用創新，是我們發展金融行業云的目標。

• 上行業云過程中，需要考慮的問題

從規模化建設和運營角度來看，我們持續在做規模化的運營，用液冷將機房的PUE下降到一點零幾的PUE，通過每年幾十萬臺服務器這種規模化的采購以降低其成本，甚至采購零配件自己組裝服務器，云服務價格每年持續的下降，可以給客戶帶來綜合的TCO（總擁有成本）的下降。

在對比TCO成本的時候需要考慮幾個因素：

第一，必須要全面上云。如果長期維持著雙模IT，而且是以過去老舊傳統架構為主的雙模IT，客戶長期維持兩套技術架構和運維體系，是很難節省成本的。

在全面上云的過程中，將原來的傳統的硬件F5、負載均衡、防火墻、DNS，加密機等專有硬件設備，都用部署在標準服務器上軟件集群來替代，通過NFV替代各種硬件網絡設備，以實現全面降本，效益將更加明顯。

在上云過程中還解決了軟件正版化的問題，不能用原來沒有采購跑量的授權軟件來與現在的云授權軟件做比較：同時IDC建設往往有很大的空閑面積和空閑資源的閑置成本。再將建設機房所用的變電站和維保核算進來，成本是很高的。

上云以后，降低成本的核心是on demand的能力。

On demand就是按需獲得資源，獲得資源后隨時可以釋放，所以上云以后一定是要把應用部署進行擴展，能夠彈性、敏捷得以進行。

其目的就是需要計算時，將整個基礎資源容器化全部拉起，計算完成以后，所有的資源釋放，不再繼續收費。現在的Serverless、函數計算都是這樣的目標，只有達到這個程度以后，才能最大限度的節省成本。

上云以后，底層的IT基礎設施這部分的容災、運維、高可用、切換都交給了服務商，實際上變相降低了人員成本。

未來數據中心、IT技術設施的建設和運營，包括在軟硬件上的投入和在人員上的投入，將會呈現出不同的比例。

未來當IT人員能夠占到像國外的金融機構的15%的比例，甚至占到金融科技公司40~50%比例時，人員成本會大幅高于軟硬件的成本。

我們進行云架構的轉型，核心目的就是節省人力成本。

• 中小保險&金融云

在金融云上，會構建出保險所需要的一些能力。我們會與中科軟、軟通動力、易寶、文思海輝等各種ISV合作，將他們的應用軟件和云上的IT基礎設施IaaS、PaaS提前對接，客戶在遷云過程中不需要自己全客支付改造成本，進行應用的兼容和適配。

同時與一些中保車服等行業云的客戶，一塊為中小保險提供服務。

保險業是一個監管比較開明的行業，將IT架構搬到云上，實際上會帶來很大的收益。

• 中小證券基金&金融云

由于證券業務的特殊性，券商對4個小時內高可用的要求很高，甚至超過銀行，所以對可能存在的交易敏感性，和出現故障的損失性，在合規符合性、系統安全可靠性沒有得到實際長期驗證之前，監管還是不放心進行集約化的、公有云式的管理。

對此，我們與上交所在三年前已經構建了一個合建的證券行業云，聯合建設、聯合運營，共同進行對外銷售和售后服務。

通過對這個行業云的建設，幫助中小型證券和基金，將其整個系統托管到離上交所交易所最近的機房，在本地建立一個同城多中心的容災架構，上面提供各式各樣的服務，中小金融機構和中小證券基金行業就不用再建設自己的機房了。

金融云XaaS的產品服務能力

金融云上整個的產品架構，基本上跟公有云上所有產品都是一樣的。

最底層是內部的數據中心的機房能力，再上層是IaaS能力，然后是DBaaS數據庫服務化的能力，還有包括 Paas層的各種能力。

• mPaas移動開發平臺何以“最受歡迎”？

在金融云上，除了Paas能力，我們還會提供一些特色的業務。

比如阿里最具特色、最受客戶歡迎的移動平臺——mPaas，很多機構使用這個平臺構建自己的手機APP系統，打造一個超級APP移動開發平臺，它甚至是一個開發、運行、測試、運營一體化的平臺。

它脫胎于支付寶強大的 APP底層能力，不僅提供安全穩定的開發管理，還將其變成一個客戶運營和流量運營的平臺。

這個平臺支持native的移動開發，提供一個小程序框架。客戶可以把支付寶等平臺上的所有小程序遷移過來，也可以利用小程序框架發展自己的小程序生態，讓周邊的生態合作伙伴不用開發非標小程序，直接將既有其他平臺上的小程序遷移過來。

• 不同成熟度應用的全面遷云

我們對金融行業也是支持不同成熟度的應用，都能夠全面的遷云。

現在的很多傳統應用還是處于傳統、標準和成熟的虛擬化的應用階段。我們希望這些應用能夠向云上進行遷移。

云上遷移并不是要做很多很復雜的改造，例如應用的自維護、自描述，是否進行分布式改造、服務網格改造，我們希望在虛擬化的標準化和成熟度狀態，做少量的適配、修改，就能夠遷移到云上，不同成熟度的應用遷到云上，可以獲得不同云上的紅利和特性。

云的原生化改造越強，就能更好的獲得云原生的特性。云原生實際上就是云的核心的按需自助，敏捷、彈性等方面的能力。

我們會在上云過程中對所有客戶的應用、可用性、連續性、容量性能都做一些分類和標準，根據它不同的要求，制定其上云的標準的部署模板，然后分批進行遷云。

近期，雷鋒網《AI金融評論》與阿里云聯合主辦“銀行系統云化升級”實戰體驗營，關注公眾號“AI金融評論”（ID：aijinrongpinglun），回復關鍵詞“參會”，立即進群觀看直播。

其中最受關注的IT建設問題之一，就是穩、敏雙態業務與金融云該如何“協同作戰”。

當銀行面對上云大潮，同時自身又有龐大業務擴展需求，云廠商和ISV服務商應該怎樣助力銀行？

基于此，雷鋒網《AI金融評論》與阿里云聯合主辦“銀行系統云化升級”實戰體驗營，邀請到多位頂尖行業專家線上分享，討論銀行核心系統與應用的云化改造，內容覆蓋成功上云實戰復盤、金融核心建設等方向。

今晚8點，中電金信（原文思海輝）金融解決方案事業部產品總監吳守鈺將帶來第二場演講，以18年金融IT行業經驗，分享敏態業務系統如何基于金融云進行探索與實踐。

近期，《AI金融評論》也將圍繞銀行上云、核心系統建設、云金融等主題，陸續推出多篇稿件，為銀行業乃至金融界，和科技圈，輸出最立體化、最具前瞻性和參考價值的銀行云、金融云內容，同時搭建高質量的微信社群，促進上下游企業交流探討。

欲了解更多活動詳情，可聯系負責人周蕾（微信：LorraineSummer）。

演講嘉賓

吳守鈺，中電金信（原文思海輝）金融解決方案事業部產品總監

演講時間

1月21日（周四）20:00-21:00

演講主題

《建設基于金融云敏態業務系統的探索與實踐》

演講提綱

從云下到云上，從穩態到敏態

云上敏態業務系統要點分析

云上敏態業務系統建設實踐

嘉賓介紹

吳守鈺擁有18年金融IT行業經驗，熟悉銀行互聯網金融、開放銀行、核心系統、支付結算等領域，有豐富的行業調研、架構設計、需求分析、產品研發等經驗，擅長云環境下的銀行解決方案設計，近年專注于數字化轉型方向產品研發與項目實踐。

但還有多少人的普遍認知只停留在“銀行應該上云”？

在這個肯定的答案背后，還有太多的疑問沒有被解開：

銀行怎么上云？怎樣才算上云？從核心系統到應用上云，定義、選型、場景、標準、優先級、與AI的關系、為數字化轉型創造的價值……

這些問題，不只是銀行要面對的“迷云”，更是所有金融機構未來數年必須直面的議題，也是金融科技助力一切業務和細分場景之前，最該優先解決的基礎設施建設問題。

五年前，銀監會就明確指示：截至“十三五”末期，銀行業面向互聯網場景的重要信息系統全部遷移至云計算架構平臺，其他系統遷移比例不低于60%。

過去的五年，是銀行云乃至整個金融云行業迅速發展、國產云廠商蓬勃成長的五年。但五年時間過去，這些眾說紛紜的疑問，仍未得到太確切的定論。

下一個五年已經到來，我們試圖找到解答。

基于此，雷鋒網《AI金融評論》與阿里云聯合主辦“銀行系統云化升級”實戰體驗營，邀請到四位頂尖行業專家線上分享：

• 廣度而論，從銀行、云廠商、ISV（獨立軟件開發商）三大角色出發，不同視角討論銀行核心系統與應用的云化改造；

• 深度而論，專場內容覆蓋銀行上云的標準與選型、成功上云實戰復盤、金融核心建設、云與AI的關系與內涵等多個方向。

本次實戰體驗營，為雷鋒網2021金融云峰會的首場線上活動。后續也將有更多嘉賓陸續加盟。

同時，《AI金融評論》也將圍繞銀行上云、核心系統建設、云金融等主題，陸續推出多篇深度稿件。

為銀行業乃至金融界，和科技圈，輸出最立體化、最具前瞻性和參考價值的銀行云、金融云內容，同時搭建高質量的微信社群，促進上下游企業交流探討。

欲了解更多活動詳情，可聯系負責人周蕾（微信：LorraineSummer）。

嘉賓分享議程

開場致辭：劉偉光，阿里巴巴集團副總裁、阿里云新金融事業部總經理

嘉賓介紹：劉偉光畢業于清華大學電子工程系。曾負責螞蟻集團金融科技的商業推廣和生態建設工作，以及螞蟻鏈的商業拓展工作。

他在企業軟件市場深耕多年，曾經創建Pivotal軟件大中華區分公司，開創了企業級大數據以及企業級云計算PaaS平臺的市場先河。

在創建Pivotal中國軟件公司之前，劉偉光曾經擔任EMC公司大中國區數據計算事業部總經理，并在Oracle公司工作多年，曾經創建了Exadata大中國區的產品事業部并擔任事業部總監。

第一場：張曉丹，阿里云新金融事業部CTO

演講時間：1月19日（周二）20:00-21:00

演講主題：《新一代金融IT基礎設施：阿里云的金融云前瞻與實戰》

演講大綱：

• 金融IT基礎設施發展需求與趨勢

• 金融云應用場景 

• 打造安全、穩定、敏捷的云上金融

嘉賓介紹：曾任工商銀行總行部室副總級專家，先后在工行分行、數據中心、總行IT部門任職22年。

曾任恒豐銀行科技部總經理，期間建設了國內銀行業第一家多租戶的金融IAAS行業云，首次將一家全國性股份制銀行的應用系統全部遷移上云。

2018年，張曉丹加入阿里云。

第二場：吳守鈺，中電金信（原文思海輝）金融解決方案事業部產品總監

演講時間：1月21日（周四）20:00-21:00

演講主題：《建設基于金融云敏態業務系統的探索與實踐》

演講提綱：

• 從云下到云上，從穩態到敏態

• 云上敏態業務系統要點分析

• 云上敏態業務系統建設實踐

嘉賓介紹：擁有18年金融IT行業經驗，熟悉銀行互聯網金融、開放銀行、核心系統、支付結算等領域，有豐富的行業調研、架構設計、需求分析、產品研發等經驗，擅長云環境下的銀行解決方案設計，近年專注于數字化轉型方向產品研發與項目實踐。

第三場：陳威，阿里云新金融事業部金融核心部負責人

演講時間：2月2日（周二）20:00-21:00

演講主題：《金融核心云原生轉型探索與實踐》

演講大綱：

• 銀行核心系統云化轉型的訴求

• 核心云原生轉型的挑戰與應對

• 相關路徑與案例介紹

嘉賓介紹：現任阿里云新金融事業部金融核心部負責人，負責金融核心相關解決方案。

曾從事企業級信息技術產業十余年，具備豐富的應用架構與設計，數據智能，云平臺，互聯網等領域的理論與大型復雜項目實踐，尤其在金融行業具有多年的交叉實踐經驗，服務于近百家大型機構與客戶。

如何預約專場？

1. 關注公眾號“AI金融評論”（ID：aijinrongpinglun）

2. 在公眾號對話框回復關鍵詞“參會”，即可進微信群觀看直播，亦可與技術大佬們談笑風生。

本次活動面向的人群

• 銀行信息技術/IT部門，和研發部門團隊；

• 云服務供應商、金融科技公司高管；

• 傳統IT廠商和軟件供應商高層；

• 券商、險企等持牌金融機構IT建設部門；

• 高校計算機、軟件專業、人工智能教授與研究生

雷鋒網

通過永安在線數據資產泄露風險監測平臺統計，金融行業是數據資產泄露的主要來源，占到了42%，而數據資產泄露高發的互聯網行業也只排名第二，占27%。出現這種情況是因為金融行業涉及到的人群大多是高凈值人群，數據轉化率高，變現能力強。

騰訊云數據庫TDSQL首席架構師張文認為：“雖然企業數據安全不只依靠數據庫，但數據庫一定要做這種最后一根救命稻草的保障。”

張文還介紹到，“數據的誤刪、誤操作，對于一些銀行客戶而言，可能一年或者幾個月都不會發生一次，但是，我們面對著云上的客戶，每天都有客戶誤刪、誤操作，在這方面TDSQL積累、總結了大量的經驗、教訓。對此，我們也有很多的解決方案包括SQL防火墻、透明加密、自動備份等——如何更快速的幫助用戶找回數據、恢復其可用性，經過這么多年的打磨，我認為我們是非常專業的。”

恰逢新年，雷鋒網《AI金融評論》邀請到張文參加「銀行業AI生態云峰會」，他分享了騰訊云是如何在「銀行數據庫」這一領域深耕發展；如何在國外商用數據庫的“壓力”下，突破求生，拿下多個銀行核心系統大單。

目前「銀行業AI生態云峰會」已成功舉辦4場，微眾銀行區塊鏈安全科學家嚴強、達觀數據聯合創始人紀傳俊、騰訊云數據庫TDSQL首席架構師張文、阿里云金融科技AI產品負責人王巍給觀眾帶來了十分精彩的演講，后續還將有360數科首席科學家張家興、融慧金科董事長兼CEO王勁、華為云FusionInsight首席架構師徐禮峰、摸象科技董事長高鵬等眾多大咖前來分享最新、最有貨的科技觀點。

以下為張文的演講內容，雷鋒網AI金融評論作了不改變原意的編輯：

大家晚上好，很高興能在雷鋒網這個平臺帶來關于分布式數據庫的分享，今天主要的議題是《騰訊云分布式數據庫在銀行核心系統的改造實踐》。

眾所周知，2020年12月24日，騰訊云數據庫官宣TDSQL品牌整合升級計劃，集中發力數據庫技術創新突破。騰訊云原有的TDSQL、TBase、CynosDB三大產品線統一升級為“騰訊云企業級分布式數據庫TDSQL”。全新升級后的騰訊云TDSQL將涵蓋金融級分布式、分析型、云原生等多引擎融合的完整數據庫產品體系。本次分享將主要以金融級分布式版TDSQL的實踐進行介紹，下述以“TDSQL”為簡稱。

基礎技術創新背景與當前行業趨勢分析

銀行的“核心系統”，對于數據庫廠商而言是一個比較大的挑戰。

銀行，我們都知道有核心系統和外圍系統，核心系統是銀行心臟中的心臟。

銀行的核心系統改造，對于數據庫廠商而言是一個很大的考驗。數據庫廠商需要面對包括數據的一致性、高可用，以及SQL的兼容性等等一系列復雜問題。

信息技術創新的大勢所趨

過去我們的核心系統，包括銀行核心，還有一些政務核心系統，對外國廠商的依賴度超過了90%，包括軟、硬件，硬件主要是依賴于國外的大型機，小型機。

軟件方面，像操作系統和數據庫軟件，整個一套技術架構都采用的是國外的產品。直到現在，在技術自主創新大趨勢浪潮下，從硬件到軟件，我們逐步在進行國產化的探索。

硬件上，我們開始嘗試用基于X86或者是ARM的國產化硬件，以構成底層的硬件平臺；軟件上，從操作系統到數據庫，包括一些中間件，在國產化方面近幾年涌現出了很多基礎類軟件。

所以，現在整體的技術導向是：從軟件到硬件整個基礎平臺開始向國產化的態勢發展，而不僅僅局限于數據庫。

金融級分布式數據庫的挑戰與難點

分布式數據庫的挑戰（技術層面）

對于分布式數據庫而言，如何迎合這樣的契機和挑戰？

為什么早期國外的商用數據庫和商用的基礎軟件，在國內的銀行、政務系統占據了大量份額？大部分企業選擇這些基礎軟件，主要訴求是其穩定性。以穩定性為口碑，經過多年打磨，因而國外廠商的這些軟件占據了壟斷性的地位。

這種壟斷性地位在短時間內是不容易被打破的，因為它有個長時間的市場效應，對于使用國外軟件的這些廠商而言，一旦涉及到替換或者升級，就容易產生一些兼容性問題，還有一些遷移成本和改造難度等問題。

對于國產的分布式數據庫，如果想要切入政務及銀行系統，首先需要打破長期被國外商用數據庫建立起來的一系列壁壘，這些壁壘對于國產物數據庫是一系列的挑戰點。

強一致性高可用

作為金融級數據庫，可用性和數據強一致性是至關重要的，因為在金融場景下，一條數據的價值是無法估量的，沒法評估它到底是錯了一分錢還是一個億，或者更多，所以金融級高可用是國產分布式數據庫首要面對的一個挑戰。

性能成本

在國產化方面主要基于廉價存儲，因為在分布式的架構下，可以實現線性水平擴展。但是數量對于分布式數據庫而言，并不是一昧的堆機器、堆存儲、堆計算，那樣實際上是很浪費資源的。分布式數據庫組成一個較大的集群，假如有上千臺機器，那么如果在性能方面提高20%，就能節省上百臺的機器，甚至能節省出來一個機房。

所以，性能成本也是分布數據庫一直在探索的以較低的成本獲取較高的性能，這也是我們追求的一個性價比。

水平伸縮

對于分布式數據庫，水平伸縮能力是必須要具備的，因為分布式數據庫在互聯網場景算是需要比較常態化的水平伸縮。

例如應對如雙11購物節、春晚紅包的突增流量，需要有一個迅速的彈性擴展能力以承載這些流量。而業務有峰值就有谷值，活動結束后，需要再將這些資源進行回收。這種水平伸縮能力，是分布式數據庫應當具備的基本點，任何分布式數據庫都需要具備這種可伸縮、可拓展的能力。

產品化程度

產品化程度是用戶能否快速上手的關鍵。

比如從一個傳統的集中式數據庫轉換到分布式數據庫，尤其是對于一些政企類、金融客戶而言，他們能否從傳統觀念或者傳統數據庫的環境下，過渡到分布式數據庫的環境和條件，這類客戶其網絡往往跟外網是隔離的，也就是在用戶出了問題之后，我們沒法第一時間登錄他的環境，幫助其進行調試，就需要他自助的完成。

如果沒有比較成熟且產品化的一套解決方案，用戶出了問題只能7x24小時找到廠商解決，非常低效。所以，產品化程度也是至關重要的。

早期那些國外的商務數據庫也是歷經多年打磨，才慢慢的讓這些傳統廠商的數據庫團隊、科技團隊接受的。

關鍵案例

前面幾點做得再好、再花哨，如果是沒有關鍵案例的驗證，一切都是竹籃打水一場空，“實踐是檢驗真理的唯一標準”，做得再好都需要有案例加以證明其可行性，對于分布式數據庫的挑戰，最重要的一點也是最為關鍵的一點，就是實實在在的案例。

如果沒有人用，大家都處于觀望狀態。關鍵案例是分布式數據庫面臨的最大挑戰，目前來看，國內的傳統廠商、銀行、政企，還是外企的份額居多，國內的分布式數據庫也是在近幾年才殺出一條血路。

所以，關鍵案例方面，除了需要TDSQL，也需要所有的友商共同探索，將關鍵案例不斷的迭代、鋪開，有了更多案例的證明，國產分布式數據庫的影響力也好，口碑也罷，包括大家的接受程度，才能慢慢地得到提高。

分布式數據庫的挑戰（非技術層面）

這里的非技術層次的挑戰更偏向于產品側，主要分為以下4個挑戰：

質量可靠

對于一款分布式數據庫，需要經過大量業務的驗證，產品在成熟或者說正式用于外部之前，一定需要經過內部的打磨和錘煉，像TDSQL數據庫，我們往往都是在內部打磨得非常成熟后才將其推向外部。

因為我們的內部場景非常多，騰訊也有很多業務線，例如在類金融場景、社交場景、醫療健康、互動娛樂，以及各種各樣的公有云的場景加以打磨。

我們秉承著對自己產品認真、負責的態度，先經過內部的打磨才推送到外部客戶。因為將產品推送到外部客戶時，實際上已經是一個黑盒的環境，要求我們一定要在內部盡可能的提前發現一些比較關鍵和顯而易見的問題，比如用戶的體驗性和一些使用方面的問題。

持續投入

數據庫的更新迭代非常快，從TB級PB級再到更高數量級的提升。

因為迭代更新比較快，所以要求廠商要有一個穩定的數據庫團隊持續地跟進演進。

對于TDSQL而言，作為騰訊內部唯一的自研數據庫品牌，我們團隊也要緊跟技術的演進和變化，除了服務外部客戶還要服務內部，因為無論是內部還是外部都是我們的關鍵的客戶，都是我們非常重視的使用場景。

像騰訊這種體量的互聯網公司，需要一支比較穩定，并且可以不斷緊跟著技術的演進和發展不斷迭代的數據庫團隊。

團隊建設

需要我們的數據庫有自己的生態，包括用戶從集中式轉換到分布式的配套工具，周邊文檔資料，人員的招聘，還有一些過渡保障措施。

TDSQL是兼容MySQL、PostgreSQL生態的，而這些生態是一個非常龐大的數據庫圈子，其文檔和資料，以及全世界的活躍社區都給我們提供了很多的學習參考的途經，我們一些技術水平比較高的銀行合作伙伴往往在出了問題之后，對于一些比較基本的問題，都是自己通過查閱相關資料加以解決。

對于我們的客戶而言，選用了一款分布式數據庫，它也要考慮自己團隊對新型分布式數據庫的維護能力。

服務能力

服務能力要求分布式數據庫的具有完善的服務機制與生態體系。比如用戶出了問題之后，能夠第一時間真的需要到現場，能夠第一時間去就近服務，包括一個完善的區域的合作伙伴的服務機制。

在服務能力方面，TDSQL也在全國培養了很多的技術支持團隊幫助，引導客戶解決問題。比如一些重大的節日保障，或者是涉及到一些重大變更，需要我們的合作伙伴立刻到達現場，做業務的割接、切換或者是大規模的災備演練。比如對一個機房進行斷電的容災演練，我們也有專門的團隊去支持，DBA團隊也有服務合作伙伴，共同為客戶保駕護航。

目前，我們在華東、華南、華北都有專門的服務團隊。

作為一款成熟的分布式數據庫產品，除了要在技術側加以打磨，還需要有足夠的案例輸出，同時在服務體系、整合能力還有持續演進能力方面，都要有與之相匹配的能力。否則，它就沒有辦法成為一個成熟完善的商業化產品。

TDSQL的發展歷程以及架構原理

騰訊的土壤

為什么在騰訊的土壤下能誕生出像TDSQL這樣的數據庫？

首先，騰訊是一個依托百億級賬戶數量的互聯網公司，其數據規模、場景相對而言比較有挑戰性。

例如，幾年前微信春節紅包的峰值超過了每秒20萬筆，對于任何數據庫而言都是一個比較大的考驗，如果不按照分布式進行拆分，那么，沒有任何一個大機或者小機能承載這樣的業務壓力。

眾所周知，互聯網業務營銷活動比較多，在活動前、活動后，其請求還有峰值都是指數級的數量，對數據庫的容量、伸縮能力是一個很大的考驗。

TDSQL，依托騰訊云這個載體，服務于政務、金融、電商、社交，還有智慧城市等等各種場景的打磨。另外，TDSQL在公有云上服務于各行各業和各種場景的用戶，這些都是對TDSQL各種場景的打磨。

最后就是持續的投入。

伴隨著TDSQL迭代的這10年，騰訊加以持續的投入，不斷的打磨產品。因為數據庫對于這種體量的互聯網公司而言至關重要。騰訊有著百億的賬戶，豐富的內部產品線和業務線，任何一個這種互聯網業務產品都會對數據庫有著強依賴。在數據庫方面，TDSQL不僅是作為外部的一個產品，在內部也是承擔了一個比較重要的作用。

在這里，詳細的介紹一下到底什么是TDSQL，其應對的主要場景有哪些？

按照官方最新解讀，TDSQL是騰訊推出的一款多引擎融合分布式數據庫品牌。

所以TDSQL覆蓋三類數據庫場景，分別是：分布式數據庫，云原生數據庫以及分析型數據庫。所以，TDSQL分為三個產品序列，分別是金融級分布式TDSQL、云原生共享存儲的TDSQL-C以及分析型數據庫的 TDSQL-A。

這樣的多引擎超融合體系針對數據庫場景的幾個關鍵領域，都提供了特定場景的解決方案，比如云原生數據庫，在存儲層基于共享存儲做分布式的就是TDSQL-C。

在面對金融場景或者政務系統的聯機交易和離線跑批場景，分別是分布式TDSQL和分析型TDSQL-A的兩個產品。實際上，TDSQL是騰訊整個一套分布式數據庫的解決方案，無論是在線聯機型的，還是離線分析型的，或者是基于共享存儲的分布式型場景，它都可以輕松應對。

核心特性

金融級分布式版TDSQL的核心特性包括以下幾點：

首先，數據強一致，因為在金融場景下，數據不丟不錯是至關重要的。

第二，金融級高可用，在金融場景至少要保證99.999%的可用性，因為金融除了其本身的行業因素外，更重要的是它還受到監管的約束。無論是對內還是對外服務，TDSQL是按照99.9999%的可用性要求的。高性能低成本，作為分布式數據庫，盡可能要讓所有的X86、ARM的廉價存儲方式榨干機器的資源，帶給整個分布式數據庫高吞吐量的增益效果。

再者，企業級安全，雖然需要實現企業級安全的不只是數據庫，但數據庫一定要做這種最后一根救命稻草的保障。比如數據的誤刪、誤操作，對于一些銀行客戶而言，可能一年或者幾個月都不會發生一次，但是，我們面對著云上的客戶，每天都有客戶誤刪、誤操作，在這方面TDSQL積累、總結了大量的經驗、教訓。對此，我們也有很多的解決方案包括SQL防火墻、透明加密、自動備份等——如何更快速的幫助用戶找回數據、恢復其可用性，經過這么多年的打磨，我認為我們是非常專業的。

線性水平擴展能力：分布式數據庫一定要具備伸縮、可擴展能力。

最后，便捷的運維——這套分布式數據庫交付到客戶手里，用戶要能夠自行掌控、操作。而不是出了問題后，只能7×24小時的給廠商打電話，這也不是我們的初衷和訴求。

產品體系

最底層的是資源池。

TDSQL既可以基于物理機部署，也可以基于虛擬機，我們可以將這個資源池簡單理解成一個iaas 服務層的概念，在資源池上方提供了兩種形態的存儲節點，一種是Noshard數據庫，另外一種是分布式數據庫，分別代表了單機版和分布式兩種形態。

作為分布式TDSQL，為什么還要有一種形態是單機版的？

對于一個廠商、一個銀行或者一個金融客戶而言，并非所有業務都會用到分布式數據庫，或者不一定所有的都是業務大表，它可能是多個業務之間有交叉，真正涉及到分布式的可能是一部分表，還有一部分可能是非分布式的。

在這種產品形態下，同時兼容分布式和非分布式，因為分布式下有一些使用限制，比如語法的限制、分布式事務的性能損耗，以及跨數據節點的join.

在分布式下，因為兩個數據節點是一定分布在兩個不同的物理節點上的，如果在這兩個物理節點之間的數據做join，很容易造成拉表，相當于是把兩個物理節點上的數據要統一匯總到一個節點上進行join，這樣的效率不是很高。

而單機版的則沒有這個問題，因為數據的拖拽都是在單臺物理節點的內存中，所以，Noshard的形態可以自由做表與表之間的join，但是在分布式上會有性能方面的消耗，這也說明了分布式和非分布式兩者各有優缺點。

所以，我們在存儲節點保留了兩種形態，用戶可以根據需要自行選擇，比如業務實例要求必須得做到分布式，需要將數據分散，包括將來考慮到業務的拆分，我們就要用分布式的；如果沒有強烈的訴求，我們提供單機版的就能滿足需求。此外，從單機模式轉換成分布式模式，TDSQL自帶的同步遷移工具也是支持的。

再往上是計算節點。

首先，OLTP型引擎主要包括了讀寫分離、SQL改寫、分布式事務以及關聯查詢。

除此之外，對于計算節點，需要處理一些比較復雜的SQL，需要對其進行拆分，包括將執行計劃下推等等，就屬于OLAP型的計算邏輯。

所以，計算節點在分布式下的工作相對還是比較復雜的，在內部，計算節點又被稱為SQL引擎，作為所有SQL的入口，它會對SQL進行分發，對一些復雜SQL拆解成對應的SQL，再發到對應的存儲節點，當存儲節點取完數據之后再回吐到計算節點，計算節點對其進行分類匯總，最后回吐到客戶端。

如果把計算節點、存儲節點、資源池比作一個黑盒，那么赤兔運營管理平臺就是一個用戶接口，所有的DBA操作都是通過赤兔管理平臺來操縱存儲節點、計算節點、資源池。

以往，DBA要做數據庫的變更，比如主備切換或者重啟，需要登錄到后臺，比如計算節點，存儲節點執行SQL命令，現在只要通過赤兔管理平臺頁面按鈕可以完成90%以上的操作，極大地減少了DBA的誤操作風險。

雖然有用戶界面，但是如果DBA確實是要登錄到后臺了解更詳細的信息也沒有問題，一樣允許登錄到對應節點的后臺進行查看。

赤兔運營管理平臺主要是為DBA提供用戶接口，它還對計算節點、存儲節點，包括機器IO、CPU網絡等各種信息的上百項指標進行統計匯總，并且當監控告警系統的指標出現異常時，可以在第一時間發出告警。

那么，“扁鵲”智能DBA平臺有什么作用？

打個比方，某天晚上發生了機房斷電，數據庫也發生了切換，第二天早上DBA收到一個告警，線上前一天晚上發生了切換（當然這個業務是正常切換過來了，然后對業務的影響也是可控的），DBA需要知道為什么會發生切換，只需要在智能DBA平臺上點一下“故障分析”，智能DBA自動到機器上分析操作系統和數據庫日志，原來是操作系統發生了重啟，這樣 DBA就不需要再手動登錄到機器上查看信息。

再比如上線了一個新業務，上線了新業務之后瞬間卡死不可用。這時就找到DBA投訴，“之前數據庫用得好好的，怎么一上新業務就不行了？”

實際上，可能是新上線的業務產生了一條慢SQL，慢SQL并發量又比較大，然后把數據庫連接耗盡。按照傳統的做法，這時DBA也是先分析日志，找到這條慢SQL，然后再一點點的進行分析。

而通過智能DBA平臺，可以進行一鍵診斷，智能DBA平臺可自動篩選出那條慢SQL，并且告訴DBA需要對這條慢SQL如何進行優化。

有了智能DBA平臺，就可以將我們從一些日常的、重復性的繁雜工作中解放出來，這套平臺也是我們對外口碑最好的一套平臺，尤其對于傳統客戶而言是非常受用的，能極大地提高DBA的工作效率，同時降低處理問題時在時間上的損失。

調度系統，負責整個集群的資源調度和管理，包括計算節點，如何組成一套數據庫實例，跟下方資源池里的資源如何進行重組、搭配，都是調度系統需要做的事情。

備份系統，沒有備份的數據庫屬于一個裸奔狀態，在這方面，TDSQL提供了豐富的備份策略，如全量的、增量的、物理的、邏輯的、日志的等各種各樣的策略。可以完成定點恢復、庫表結構恢復、指定表的恢復等等。

服務模塊，服務模塊屬于比較高級功能，主要應對一些特殊性場景，如：審計、數據訂閱、數據治理，以及SQL防火墻，數據遷移等等。

比如用戶需要從原生的MySQL遷移到TDSQL，或者從其它異構數據庫把TDSQL遷移到其中，都涉及到數據遷移，我們有專門的數據遷移模塊，包括TDSQL的兩種形態之間，包括從分布式到單機版，從單機版到分布式，都依賴于這樣的數據遷移。

數據遷移也彰顯了TDSQL不綁架用戶的一個初衷，這也是TDSQL開放生態的一個特點，基于MySQL生態的數據庫在遷移過來之后一定不用擔心將你綁架——也就是它不讓你遷出去，因為日志、數據結構都是開源的，有很多種工具提供了在線、離線的遷移方式。

如果用戶覺得TDSQL不好用，可以通過我們的遷移工具再將數據遷走，數據進出自由，并非綁死在TDSQL。

運營管理

• 赤兔監控：這里羅列的幾項指標，是SQL引擎請求量的對比，包括與前一日的對比曲線。

• 智能告警：如果報警標紅就會閃爍，如果只有監控而沒有告警，其實是起不到任何作用的，一定要將監控與告警關聯，才能起到預警作用。

• 扁鵲系統：其內部邏輯非常復雜，主要是基于騰訊多年來海量運維的經驗，形成的策略庫、語法庫。通過在這方面經驗的積累，對一些常見的故障進行分析和識別并處理。

• 一鍵運維：TDSQL赤兔管理臺的首頁，它包含的功能在我們看來如果DBA數據庫管理員有這套東西，基本上是可以做到只在頁面上完成所有的操作，不需要登錄到后臺進行變更、維護。

系統數據庫向國產分布式數據庫遷移與轉型實踐

第一個案例：微眾銀行

微眾銀行是在2014年開始籌建，最終采用了TDSQL，并搭建分布式架構核心系統。微眾銀行對于機房的部署是，在同城有5個機房異地有2個機房，按照傳統意義上的理解，這同城的5個機房如果做成1主4備，其余4個機房都有可能會浪費。因為只有1個機房沒有讀寫請求。

微眾銀行對上述機房的部署肯定沒法充分利用機房的資源。對此，又是怎么解決的呢？

首先，將數據庫規劃成一個個的 DCN，一個DCN模型就是一個小的微眾銀行的分行、網絡分行，一個分行只固定500萬的賬戶數，這500萬的客戶數也是經過了一系列的壓測驗證，至少這500萬放在這個單機版的TDSQL上是安全的，不會有性能的瓶頸。

如果超過500萬，比如客戶數到了600萬，就再加一個DCN，實際數據庫的實例層是由多個DCN組成了一套集群，而多個DCN之間相互沒有聯系，因為用的都是單機版的TDSQL。

那么，微眾銀行是如何利用這種單機版的Noshard模式實現整體的分布式呢？

微眾銀行還引入了一個組件GNS， GNS被稱作全局路由，業務訪問數據庫一定要經過GNS，之后，GNS告訴他所需要的數據在DCN的具體位置，業務再把對應的SQL發到對應的DCN。

所以，GNS解決了路由的問題。

在這種情況下，如果要做分布式事務該怎么辦？傳統的分布式數據庫，對于用戶側而言就是一個begin，然后增刪、改查、commit。

如果增刪、改、查里涉及到的多個DCN對業務是透明的，但是在這種情況下，實際上沒法做到完全的透明。

對此，微眾銀行又引入了一個組件RMB——可靠的消息隊列，是處理分布式事務的，也就是在一筆分布式事務到達后，首先要在RMB這里注冊一個分布式事務的總事務，之后再由RMB完成子事務的分發，最后它會確保所有的分布式事務所涉及到的 DCN在處理完成后，返回給業務端。

微眾的數據庫是怎么部署的呢？利用多個IDC交叉部署，第一個DCN的主放在IDC1，第二個DCN的主放在IDC2，以此類推，其所有DCN的主是交叉部署在這5個機房的。

如果最后是500個DCN，有5個機房，每個機房就放100個DCN，這樣的好處在于每個機房的讀寫流量是均勻的，并不會造成像原來所有的讀寫都壓在1個機房，其余4個機房都是stand by的角色。

所以，微眾銀行這套架構從整體上看，實現了5個機房資源的充分利用。

任何一個機房的故障都只會影響1/5的流量，不會造成系統性的宕機。

像以前這種1主4備的模式，如果主節點壞掉，整個全行所有的服務都會癱瘓，雖然最后也會切換，但是其過程對全行的業務是有影響的。

如果按照分散的方式，就會產生另外一個問題，一個節點壞掉之后，使得1/5的業務受到影響，而原來的1主4備的模式，如果壞掉的是一個備機，那正常業務就不會受到影響。所以，這其中存在著可用性和成本之間的博弈。

第二個案例：張家港銀行

張家港銀行是我們對傳統銀行核心系統進行的一次徹頭徹尾地改造。

首先，它是一家傳統銀行，并非新成立。其次，它的核心系統是針對傳統銀行打造的。從微眾銀行到張家港銀行已經過去大概5年的時間，整個TDSQL在產品迭代方面已經有了很大的變化。

對于張家港銀行而言，首要考慮的問題是性能，其早期的數據庫是Sybase數據庫，大概是10年前的一個架構。在張家港銀行在業務高峰期經常有卡頓、超時的問題，所以其訴求就是要升級成一個能滿足行里現在業務場景的數據庫。

第二，張家港銀行的量級相對較小，其訴求就是成本。

另外，改造的難度，在業務方面，微眾銀行在數據庫方面做了很多的自身的改造。

比如引入了GNS、RMB，這些都是微眾自己進行維護的。并且從一開始，微眾銀行基于自身的定位，更多地還是想參與金融創新，定位自身為一家金融科技公司。而張家港銀行更希望能快速地解決自身的問題并且把東西用起來。

所以，張家港銀行的架構圖就非常清晰和簡單，就是一個標準的分布式兩地三中心的架構，同城總行機房部署一組主節點和一組備機節點，同城的災備機房部署一組備節點，整個分布式實例采用一主三備四分片的架構。

此外，在異地還有一組異步節點。從整體看，沒有任何的復雜組件，張家港銀行采用的這種形態與微眾銀行的截然不同。

TDSQL有兩種形態——Noshard和shard，張家港銀行完全采用了后者的形態，這樣，張家港銀行就不需要引入諸如GNS、RMB等組件,因為我們的SQL引擎會助其自動做路由，以及分布式事務管理。

所以，張家港銀行直接使用分布式shard版的TDSQL，對于業務而言，只需進行細微的調整和改動，例如重新設計庫表。按照這種分片關鍵字，一些大表需要選擇其分片關鍵字。

再者，就是將之前用到的存儲過程、觸發器的一些計算邏輯，盡可能地上提到業務代碼中。因為在分布式數據庫下，數據庫盡可能的只做數據的存取，否則很容易產生性能問題。

按照這種策略和思路，對張家港銀行的改造大概歷時半年完成，改造完之后，整個性能提升非常明顯，查詢交易在100毫秒以內完成，高頻交易在300毫秒內完成，像貸款結息這種跑批業務與原來相比得到成倍的提升，體現出分布式的一個優勢。

性能方面，原來在硬件成本方面需要4~5000萬，現在不足1000萬。同樣的成本，在oracle下是8000的TPS而在TDSQL下是6200的TPS。

在整體性能差異不大的情況下，成本已下降到了不足原來的1/5。同時TDSQL可以通過繼續加機器來提高集群的吞吐能力，所以性能還可以不斷地提升，具備橫向擴展的能力。

第三個案例：平安銀行

平安銀行更具代表性。平安銀行的體量與張家港銀行相比又上升了一個數量級，同時其應用改造的難度相對而言也是一個比較有挑戰性的工作。今年，我們完成了支持平安銀行信用卡核心從傳統集中式架構的大型機下移至分布式平臺。

平安銀行采用了TDSQL Noshard和Groupshard兩種架構。為了配合此次改造，應用引入了微服務架構對應用進行了拆分和解耦。對賬號的分布進行了單元化劃分，以DSU為一個邏輯單元，單個DSU包含200萬個客戶信息，單個DSU同時處理聯機和賬務兩種業務。這樣做的好處：一方面避免跑批時段消耗資源過多對聯機交易的，另外一方面避免由于基礎架構的故障導致全局不可用。。

平安銀行也有統計分析類型的業務，如果按照Noshard架構，對應用開發要求比較高，需要將統計類的SQL拆分成多個子SQL分發給多個noshard實例。

groupshard架構更適合， 從邏輯上來看，Groupshard架構對于應用而言就是多個獨立的邏輯表，應用不需要關心數據是如何組織分布的。由于要對數據進行統計分析，數據訪問量較大。所以，這種場景下，在訪問需要的數據時，應用只需把SQL發給SQL引擎，SQL引擎會對SQL進行拆分、并行下推,再進行結果集的聚合。

同時，TDSQL Noshard和Groupshard兩套集群之間通過TDSQL自帶的同步組件完成實時數據同步。

政務系統

第七次全國人口普查的數據采集處理工作，對于我們的TDSQL而言也是具有重要意義的。

首先，其數據量的規模是10億級別的，峰值QPS是百萬級。

這種情況，無論在我們內部業務還是外部業務都是非常罕見的，對于TDSQL性能的要求，包括跨節點之間的通信、分布式事務的處理都是比較大的挑戰。

因為人口普查涉及到國家政務的敏感信息，我們不便將其詳細的架構圖畫出來。

但可以肯定的是，基于TDSQL多引擎融合技術，第七次全國人口普查穩健完成了數據采集處理工作。

欲了解更多活動詳情，可聯系負責人周舟（微信：18811172358）。

如果沒有實現平滑順暢的云架構轉型，銀行想要推出更多智能化應用、開展數智化賦能創新的想法，無疑是空中樓閣。

2020年10月，央行也發布了最新版金融上云配套管理規范，明確了金融云的建設標準、評測辦法、備案管理要求，以及金融機構上云的要求。這一規范的出臺，也足見監管層對銀行信息科技的重視程度。

值此新年之際，雷鋒網《AI金融評論》與阿里云聯合主辦“銀行系統云化升級”實戰體驗營，邀請到多位頂尖行業專家線上分享，討論銀行核心系統與應用的云化改造，內容覆蓋成功上云實戰復盤、金融核心建設等方向。

明晚8點，阿里云新金融事業部CTO張曉丹將帶來首場演講，結合自身二十余年銀行IT經驗，分享金融IT基礎架構全面云化、機構應用遷云實錄等干貨。

近期，《AI金融評論》也將圍繞銀行上云、核心系統建設、云金融等主題，陸續推出多篇稿件，為銀行業乃至金融界，和科技圈，輸出最立體化、最具前瞻性和參考價值的銀行云、金融云內容，同時搭建高質量的微信社群，促進上下游企業交流探討。

欲了解更多活動詳情，可聯系負責人周蕾（微信：LorraineSummer）。

演講嘉賓

張曉丹，阿里云新金融事業部CTO

演講時間

1月19日 20:00-21:00

演講主題

《新一代金融IT基礎設施：阿里云的金融云前瞻與實戰》

演講大綱

• 金融IT基礎設施發展需求與趨勢

• 金融云應用場景 

• 打造安全、穩定、敏捷的云上金融

嘉賓介紹

張曉丹曾任工商銀行總行部室副總級專家，先后在工行分行、數據中心、總行IT部門任職22年。

曾任恒豐銀行科技部總經理，期間建設了國內銀行業第一家多租戶的金融IAAS行業云，首次將一家全國性股份制銀行的應用系統全部遷移上云。

2018年，張曉丹加入阿里云。

如何預約專場？

關注公眾號“AI金融評論”（ID：aijinrongpinglun）

在公眾號對話框回復關鍵詞“參會”，即可進微信群觀看技術專場直播，亦可與技術大佬們談笑風生。

本次專場面向的人群

• 銀行信息技術/IT部門，和研發部門團隊；

• 云服務供應商、金融科技公司高管；

• 傳統IT廠商和軟件供應商高層；

• 券商、險企等持牌金融機構IT建設部門；

• 高校計算機、軟件專業、人工智能教授與研究生

而這一切都離不開一個產品——數據庫。

我們在朋友圈保存的文字和視頻、在銀行中儲存的數字化財產，我們對整個社會的管理、對經濟社會的維持，都是在成千上萬個數據庫的幫助下完成的。

于銀行而言，數據庫是“生命線”，它存儲著銀行多年來收集的數據信息，包括用戶的財務隱私、銀行的交易記錄等重要信息。

然而由于傳統數據庫在技術邊界、成本、可控性方面與時代技術、銀行業務創新需求而言越來越不相匹配，同時由于采購數據庫的來源單一，銀行一直陷入非常被動的處境，急需市場上出現更多類型的數據庫產品和廠商。

被卡住脖子的銀行

一位業內資深的數據庫專家最近感慨：數據庫，是銀行“命脈”，需要投入大量的人力、物力，非十年起步不可，非大廠不行。

1989年，Oracle正式宣布進入中國市場，很快成為銀行從業者眼中數據庫的代名詞。20多年來，銀行等金融機構只信賴和使用Oracle數據庫，金融拼的是長跑、誰活得久，而不是快跑、誰花樣新。對于把安全始終放在第一位的很多銀行從業人員來講，Oracle一直是第一選擇，而新興的國產數據庫廠商只是“備選”。

“用Oracle就是安全，時間和太多的實踐經驗證明了這一事實。”平安銀行分布式數據庫技術負責人李中原坦言。

想在金融這一領域和Oracle這樣經受過時間驗證的數據庫廠商競爭，國產數據庫廠商并不輕松。 

騰訊云副總裁李綱表示，“在和銀行客戶交流的時候，大家都信任Oracle，他們認為如果一個問題如果連Oracle都解決不了，那其他廠商也沒辦法。”

對于國內數據廠商來講，Oracle的強大和不可替代性，成為他們繞不開的話題。而對于銀行等金融機構而言，因為長期使用Oracle，他們形成了較嚴重的路徑依賴，輕易不會更換數據庫。除非出現了新的業務場景，而現有的技術不能很好解決，否則很難讓銀行下定決心。

“畢竟系統的遷移和重新建設，需要大量成本。”李中原說道。從單機變為多機群體，故障發生的故障發生的概率和維護成本都會加大，這對整體的系統運維也是一個極大的挑戰。

在這種情形下，2020年中國數據庫軟件市場規模200億元，Oracle等海外廠商市場占有率超過了80%。 

此前，《科技日報》總結出了中國35項被外國“卡脖子”的關鍵技術，數據庫位列其中。

但是，和Oracle等國外數據庫廠商相比，國產數據庫長期以來在安全性和可用性上，不具備足夠的競爭力。采購來源單一使得銀行不僅要付出更高昂的采購成本，還時時受制于人。

2020年5月，全國人大代表、合肥工業大學應用數學研究所所長檀結慶對《證券日報》記者表示，中國幾千家銀行，核心交易系統幾乎都采用了甲骨文或IBM的數據庫產品。

云廠商“破局之路”

Oracle在銀行業的影響力依然強大，但是云計算的出現，使得Oracle帝國堅固的城墻有了一絲縫隙。

云計算，讓國內外互聯網巨頭嗅到了打破Oracle常年霸占數據庫領域的契機，各大互聯網巨頭云廠商拔地而起，2006年亞馬遜AWS成立、2009年阿里云成立、2010年騰訊云正式對外提供云服務。

有業內人士認為，Oracle數據庫無疑是一個偉大的產品，但它和新興的云數據庫廠商相比，在成本和易用性上開始顯露疲態。

騰訊云的李綱認為相比Oracle等傳統數據庫，云化數據庫有成本低、容易擴容兩個特點：

一：云數據庫是分布式的，它的硬件要求、它的成本很低，任意一臺X86的PC服務器就可以運行。

二：云數據庫是橫向擴展的。因為云數據庫是分布式的，所以理論上它的橫向擴展能力是無限的。而用傳統數據庫的客戶，當面臨業務數據有了非常大的增加時，可能要再買一臺大型機。

目前，中國有幾千家銀行，每個銀行所處的階段千差萬變，金融科技能力也呈現不均衡的發展狀態，即使同一家銀行的不同業務它所要的技術需求也迥然不同。

廣闊的市場和部分可以超越傳統數據庫的技術優勢，給了國內數據庫廠商和Oracle數據庫競爭市場的機會。 

就拿騰訊云為例，它便一步步通過在金融領域的深挖，獲得了不少銀行訂單：

2013年及以前，騰訊內部計費業務，以及微信支付（財付通）成立，使得騰訊數據庫在偏金融的場景中獲得了初步的鍛煉。

2014年，騰訊牽頭成立的民營銀行——微眾銀行成立，騰訊集團第一次將數據庫產品TDSQL，放進銀行的核心系統中。這是騰訊云第一次“吃螃蟹”，從此正式開始了向金融行業拓展客戶的步伐。

2019年，張家港行將其核心業務系統放在了騰訊云TDSQL數據庫上，這是傳統銀行第一次將傳統核心系統應用在國產分布式數據庫。

從騰訊云數據庫的發展路線可見，互聯網云數據庫廠商一般先從自身偏金融業務開始，再嘗試向互聯網銀行發展，最后將數據庫產品應用并賦能到張家港行、平安銀行等傳統銀行。

其中，微眾銀行和張家港行在使用騰訊數據庫產品時，又有所不同。

微眾銀行是新成立的銀行，一開始便用的是分布式數據庫，不存在之前已有數據庫更換的問題。但是張家港銀行等中國大部分銀行，本身有自己集中式的數據庫。從集中式數據庫到分布式數據庫，這其中涉及到一個遷移的過程。

而“大機下移”相關業務，在很長一段時間內都是國產數據庫廠商需要重點攻堅的對象。

銀行業“求變”，國產數據庫加速發展

張家港行和平安銀行選擇國產云數據庫廠商這一現象，看似“不走尋常路”，其實是整個銀行業正在積極求變、努力“上云”的一個縮影。

基于云計算的應用程序，比傳統系統提供更多的連接和功能，銀行等金融機構可以因此獲得新興技術和高端技能。李綱認為：“用分布式技術，所有的架構對客戶來說都是透明的，客戶可以在上面加持自己的應用、靈活的去發展。”

前不久，平安銀行信用卡的核心系統完成切換投產，這一新核心系統也采用了國產數據庫。

關于平安銀行為何放棄Oracle，選擇國產數據庫廠商，李中原表示團隊內部也經歷了非常多的討論。

“信用卡這個項目在立項之處，平安銀行就花了三四個月的時間，專門研究選型的問題。在數據庫的選型上，選擇Oracle的呼聲最大，但最終通過各種論證，平安銀行最終選擇了騰訊云TDSQL數據庫。”

在選型的過程中，一方面需要讓所有員工思想統一，另一方面需要把技術方案的優劣遞交給上一級的領導“敲板”。

李中原認為有三個原因，讓平安銀行最終選擇了騰訊云TDSQL數據庫。

第一，云數據庫的橫向擴容能力，讓平安銀行可以快速的進行自動化擴容。

第二，兼具同城多活和數據強一致性。同城多活方案會給業務系統設計帶來更大復雜度，跨機房服務調用帶來的耗時增加、帶來成本上升，但是騰訊云數據庫很好的平衡了這一點。

第三，騰訊云可以在自動運維上給予平安銀行支持，比如在Oracle數據庫上，平安銀行如果要部署一個幾百套數據庫的集群來做統一管理是很難達成的目標。

成本，也是平安銀行推動更換數據庫的原因之一。

李中原表示，“從硬件建設來看，把大型機擴容到目前TDSQL同等規模處理能力，僅此一項需要多花費大約幾億元；而從后續的維保角度，每年大型機的維保費用也更高。”

使用分布式數據庫，對于鞏固平安銀行整個系統的穩定和培養分布式數據庫方向的人才也是一個很好的“試驗場”。

“整個分布式集群的產品組件非常多，精通掌握每個組件其實很困難，我們著力把這些做得更加自動化，我們團隊幾十人，每個人對系統的掌握不一樣，但是自動化可以最大限度保證系統運行和維護的效果是一致的。而這對于員工來說，就需要更深入的學習、接觸更大的技術面。而同時，TDSQL的運維自動化能力也讓后續的運維工作更加方便。”李中原說。

目前，有許多實力較強的銀行已經展開對內部分布式數據庫的人才培養計劃，2020年8月，中行便在官網上宣布對“軟件中心2020年云計算與分布式技術培訓項目”進行采購，培訓人數多達上百人。

一場“銀行數據庫國產化”浪潮

隨著國內云計算技術的發展，銀行有了更多數據庫產品上的選擇。

2019年中國人民銀行印發的《金融科技（FinTech）發展規劃（2019-2021年）》中指出，將有計劃、分步驟地穩妥推動分布式數據庫產品先行先試，形成可借鑒、能推廣的典型案例和解決方案，為分布式數據庫在金融領域的全面應用探明路徑，確保分布式數據庫在金融領域穩妥應用。

除了平安銀行等全國性商業銀行、張家港等地方性城農商行、微眾銀行等新成立的互聯網銀行外，四大國有銀行其實更是走在了變革一線。

比如在2020年7月，中國農業銀行分布式核心銀行客戶信息系統便順利投產，完成全行8.37億個人客戶信息數據下移和應用重構，實現架構轉型升級；

2020年9月，中國工商銀行采用國產數據庫，其對公理財系統完成從大型機到分布式架構的改造，在同業中率先實現大數據體系由傳統架構向自主可控、分布式架構轉型。

國有大行系統的業務體量非常巨大且并發極高，天然會有對新技術架構的需求。他們也可以深度地和BATJ等互聯網巨頭旗下云廠商進行更加深入和全面的合作。

而隨著互聯網乃至5G、物聯網的快速發展，將有更多銀行出現單一集中式架構無法較好滿足某項業務的場景，這就推動著銀行擁抱新的架構、選擇更符合業務發展的數據庫產品。（雷鋒網雷鋒網雷鋒網）

財報顯示，百度核心非在線廣告收入29億元，同比增長14％——百度點名智能云業務，稱該項增長“得益于智能云業務收入攀升，以百度智能云為代表的AI新業務為營收帶來的驅動價值凸顯。”

李彥宏對此點評：“第三季度，AI新業務穩健增長，特別是在智能云領域，百度憑借領先的AI解決方案形成了差異化發展路線。”

百度智能云之所以能在本季成為百度AI新業務的亮點之一，主要因為百度智能云持續在多個行業簽下大單，財報也對此有所披露：百度智能云在智慧金融、工業互聯網等領域，分別拿下了中國郵政儲蓄銀行項目和貴陽經濟開發區工業互聯網基礎設施建設項目。

尤其是在中國郵政儲蓄銀行項目中，百度智能云將通過機器學習和其他AI能力，助力其旗下近4萬個分支機構開展風控審計工作；貴陽經濟開發區工業互聯網基礎設施建設項目中，百度智能云將對區內400多家工業企業，實施工業互聯網改造。

不難看出，今年的百度正借著這朵智能云，在金融賽道奮起直追，其金融AI to B戰略布局的野心展露無遺。

• 與宇信強強聯合
  

2020年初，百度戰略投資宇信科技集團。雙方表示，將在金融云、大數據、人工智能、區塊鏈等關鍵領域展開合作，以百度大腦為核心，依托智能云，推動云+AI在金融行業大規模落地，加速金融產業智能化升級。

成立于2006年的宇信科技，已在金融IT服務領域深耕十余年，向金融機構提供咨詢規劃、軟件產品、應用開發、技術服務、運營維護、系統集成等全價值鏈服務。

而百度智能云也已打造完備金融云解決方案，全面服務于銀行、證券、保險、互聯網金融等金融機構的營銷、風控和運營各業務場景。

不僅輸出全鏈條自主可控、技術能力持續領先、高等級安全合規的金融互聯網核心，同時也提供覆蓋228多項領先AI能力的一站式金融智能引擎，還提供數據管理技術能力及對公金融服務。

此次合作被概括為“打通技術與場景，進行深度技術和產品整合”，面向金融業，在金融云、分布式數據庫、大數據分析平臺、智能金融大腦、區塊鏈、可信計算、智能交互等多個層面都將展開創新合作，充分發揮協同效應。

• 度小滿+百度智能云+億聯銀行的三邊共贏

今年4月，百度智能云、度小滿與億聯銀行在北京官宣戰略合作。

億聯銀行是東北首家民營銀行，也是國內四家取得互聯網貸款業務資格的銀行之一。

百度智能云將為億聯金融業務和服務提供“AI+云”技術能力，度小滿金融利用自身渠道和用戶資源為億聯提供流量支持。

兩方協同作戰，沿承了百度的技術基因和搜索場景優勢，利用私有云、AI技術等在金融領域布局，構建了包括智能獲客、大數據風控、身份識別、智能投顧、智能客服等多項核心能力，與億聯銀行形成三邊共贏的戰略合作，共同打造“未來銀行”新范式。

百度智能云事業群組副總經理、智慧金融事業部總經理李碩透露，其實在2019年，百度智能云就已經與億聯銀行在人工智能平臺、聲紋、NLP等領域取得諸多的合作成果，此后三方的合作會進入到“一個更加親密的‘鐵三角’狀態”。

• 發布未來銀行解決方案，落地浦發、百信

同樣是在上半年，百度智能云在ABC SUMMIT 2020百度夏季云智峰會上，還發布了未來銀行解決方案。

基于這一解決方案，浦發銀行和百度智能云聯合打造了數字人員工“小浦”，可出現在APP、網銀和各類服務終端上，為人們提供智能化的金融服務，用戶在家就能獲得真人一樣的情感交互體驗，以及“千人千面”的個性化定制服務。

據悉，除了與浦發合作的數字人，該解決方案還會在2020年上半年內落地百信銀行。

李碩介紹，百度智能云依托知識中臺，可以幫助金融機構將門類繁多的零售金融產品構建出一套知識體系，產品的銷售將基于這套智能知識體系，在手機App、營業廳坐席、商超里的服務大屏為每一位用戶提供最佳的銷售服務體驗。

每一臺手機、屏幕和ATM都能夠成為業務辦理和成交的終端，這相當于為每一位用戶在場景中配置了一位AI客戶經理。此外，通過百度的智能流程機器人、審核策略機器人，后臺業務處理也能實現秒批。

除了金融零售領域，百度智慧金融還為金融機構提供獲客、風控到運營的端到端智能化解決方案。據悉，百度智慧金融的基礎平臺以自主可控的軟硬件為底座，其中圖數據庫是新一代支撐知識圖譜應用的關鍵產品。在AI中臺和知識中臺的支撐下，銀行保險的大量產品實現數字化營銷，百度智慧金融的智能營銷與客服、數字員工等能夠幫助金融機構以統一的服務標準以及個性的服務體驗觸達用戶。

• 與捷信消費金融打造智能客服2.0
  

除了與銀行、金融IT廠商攜手，百度智能云今年還與消費金融公司保持著良好合作關系。

捷信消費金融上半年就曾公布，將與百度智能云通力合作，引進其業內領先的自然語言理解、對話管理、自然語言生成、知識圖譜等技術，并將它們應用到電銷、催收、咨詢服務等業務全流程。

之所以選擇百度智能云智能客服，捷信IT呼叫中心部長何子文透露，一是因為百度作為業界領先的科技企業，各方面的服務以及支持體系相應更加完善；第二是在項目選型時，“百度智能云的POC場景測試效果是最好的”。同時，在ASR engine方面，百度積累了大量數據，包括百度核心NLP引擎技術的表現也尤為突出。

• 為大智慧量身定制“上云”

百度智能云今年技術能力輸出的典型案例，還有為金融信息服務公司大智慧打造一套輕資產、易應用、彈性伸縮的云上數字化解決方案。

大智慧以軟件終端為載體、互聯網為平臺，向投資者提供及時專業的金融數據和數據分析，服務于國內的大量個人投資者和眾多金融機構。

但隨著業務范圍不斷擴展，用戶量和市場交易量快速增加，傳統的機房部署模式很難抵擋業務系統面對的壓力，既不能實現靈活部署，又需要投入大量硬件設施，自建機房運維服務容易在出現故障時不便于維護，讓用戶體驗度大打折扣。

為此，百度智能云從高并發、穩定性、成本三個關鍵要點出發，將大智慧業務無縫遷移到公有云中，以敏態的基礎架構，支撐彈性按需的業務，同時可以為大智慧分布于全國各地的分支機構，進行統一管理、統一運維。

百度智能云介紹稱，這一解決方案能讓資源靈活擴容，從容應對業務峰值，支撐系統平均每天千萬次的超高訪問量。

在更新金融資訊時，大智慧甚至可以使用標準模板自動化生成html文件后直接存入百度智能云對象存儲BOS系統中。同時利用BOS的靜態網站托管功能實現輕量化運維，并通過CDN對其進行加速，讓用戶享受極速、流暢、安全的訪問新聞資訊，穩定性高達8個9。

• 聯手太保、泰康，優化保險定損理賠環節

今年9月底，百度智能云與中國太保產險聯合發布車輛智能定損產品“太·AI”，實現了秒級的定損，將客戶理賠旅程從1天到數天，降至分鐘級。

百度智能云還聯合泰康保險，利用百度大腦OCR技術，解決了理賠中票據識別的關鍵瓶頸問題，實現了8類票據類型的智能化識別，促進泰康保險財務共享中心效率提升110%，實現了智能化理賠業務的升級。

據百度方面透露，目前，百度智能云已擁有200多家金融客戶、30多個合作伙伴，包括國有6大銀行、9大股份制銀行、21家保險機構，涉及營銷、風控等十幾個金融場景。

百度智能云打造的數字員工也已在75家客戶落地，自動化完成業務處理，助力客戶的運營效率提升50%以上；零售金融科技在28家行業客戶落地，廣泛應用于在信用卡智能營銷、信貸智能風控、保險理賠反欺詐、保險智能定價場景，其中貸款不良率低于行業均值相對值的10%。

值得一提的是，在今年夏天的ABC SUMMIT 2020百度夏季云智峰會上，百度智能云也披露了自身在數據中心、網絡、算力與芯片、云存儲、邊緣計算以及區塊鏈等領域的更多產品和技術優勢，發布了AI中臺、知識中臺以及新一代智能辦公平臺。

例如針對政務、金融等行業需求，百度混合云方案核心ABC Stack發布2.0，以契合企業云戰略升級需求，同時全面支持國產化芯片、操作系統和生態軟件，實現了完全的自主可控。

升級“天算”數據湖分析平臺、“天合”云原生平臺以及承載區塊鏈產業化落地的“天鏈”平臺。其中，升級后的“天算”數據湖分析平臺可以在滿足分析應用場景需求的情況下，為客戶的存儲成本降低50%以上，計算成本降低到了只有60%。目前，百度智能云在基礎云領域的這些技術方案已經廣泛應用在工業、商業零售等多個領域。

AI中臺則依托百度大腦的AI能力，包含AI能力引擎、AI開發平臺兩大核心能力以及管理平臺。百度CTO王海峰在會上透露，AI能力引擎為企業提供百度已有的250多項成熟AI能力，AI開發平臺擁有全球前三、國內第一且具備自主知識產權的深度學習開源框架“飛槳”。基于AI中臺，企業將擁有建設AI開發和應用的自主能力，集約化管理企業AI能力和資源，統籌規劃企業智能化升級版圖。

百度智能云智慧金融事業部算法負責人謝國斌，也曾做客雷鋒網公開課，分享百度智能云在金融領域的安全計算布局和技術思考，以及基于聯邦學習技術的百度金融安全計算平臺（度信）建設與實際應用，講述如何借力安全技術架構、脫敏方法和合規制度設計，在“用戶充分授權、數據來源合法合規”前提下，打破數據孤島，實現多方數據加密融合建模，助力金融企業業務的開展。（雷鋒網）

雷鋒網雷鋒網

IDC指出，進入5月之后，重點金融項目實施與交付加快，有力提振了上半年金融云市場；同時大型機構上云步伐并未被明顯延緩，包括核心系統、核心數據庫下移等項目均有序推進。

廠商方面，IDC報告指出，阿里云繼續領跑金融云市場，其中金融云(平臺)解決方案市場份額達到27.7%，大幅領先華為、騰訊等企業。

IDC預計，2020年金融云在整體金融行業IT解決方案市場中占比將接近20%，2024年這一比例將達到40%以上。

雷鋒網雷鋒網

近年來，在金融安全上升為國家安全的背景下，監管要求日益規范和嚴格。同時，銀行面對的市場競爭壓力日益加大，客戶對銀行產品需求也更加多樣化。在多重外界因素的作用下，銀行業實現管理創新、科技創新已成為未來的主要潮流，國產化數據庫的業務融合也成為銀行信息系統建設的必然選擇。

據了解，神州信息基于自身全棧金融信創產品和解決方案體系，已成為擁有行業最多金融信創適配應用案例的金融科技企業。其分布式核心系統及分布式技術平臺在浦發銀行、北京銀行、晉商銀行、重慶銀行、寧夏銀行、北部灣銀行、唐山銀行等實現廣泛應用。

站在“新基建”的風口上，面對金融行業數字化轉型帶來的考驗，今年9月，騰訊云發起金騰計劃，將與合作伙伴攜手打造深度開放共融的金融數字化合作生態，共同推動金融機構全面數字化轉型。此次，騰訊云聯手神州信息發布的“騰訊云分布式數據庫CynosDB（TDSQL）+神州信息分布式核心”聯合解決方案，正是雙方為滿足銀行業數字化轉型的全方位需求，交出的一份答卷。

通過騰訊云分布式數據庫CynosDB（TDSQL）與神州信息分布式核心系統的有效融合，聯合解決方案大幅提高了銀行系統的并發處理能力、高可用能力以及容災能力。此外，該解決方案結合銀行金融業務場景的特點，有效縮短了日常業務處理的耗時。在實際測試中，聯合解決方案可實現將常用賬務交易響應時間控制在150毫秒內、常用查詢類交易響應時間控制在60毫秒內。同時，基于解決方案，平常日跑批、季度結息跑批、年度結息跑批時間相比原有方案縮短20%，大大提升了銀行業務批處理的效率。

與此同時, 聯合解決方案基于神州信息分布式核心業務系統，不僅融入微服務理念實現系統功能的獨立部署和靈活組合，具有極強的可擴展性，幫助銀行打造多個高內聚、低耦合的中臺化微服務群，各業務形成完整的功能閉環，可獨立運行、擴展和升級。而且依托騰訊云分布式數據庫CynosDB（TDSQL）作為此次解決方案的核心系統承載，憑借巨大的數據吞吐、數據強一致性、數據高安全等性能優勢，以及高可用、高擴展等特性，面向金融行業分布式架構提供了跨區容災、多地多中心、故障自動恢復等功能，保障業務穩定高效運行。

其中，通過對數據庫內核的大量優化，CynosDB（TDSQL）極大地提高了系統處理性能，很好地滿足分布式應用系統的需求，同時為系統提供了?階段XA分布式事務，確保分布式事務的完整性。在擴展能力上，CynosDB（TDSQL）支持在線擴容數據庫節點，使分片數據自動按指定規則平滑過渡至新擴容節點中，且整個操作過程對應用系統無感知。針對數據安全，CynosDB（TDSQL）采用強同步機制來確保主從節點數據完全?致，同時，支持物理備份、邏輯備份等周期性備份方式備份數據，最大限度確保數據的安全性。此外，CynosDB（TDSQL）在數據的傳輸、存儲方面也添加了大量的安全機制來確保數據不被竊取、篡改。

近年來，中國金融行業數字化進程不斷加快。數據顯示，騰訊云服務的金融領域客戶已超萬家。其中，作為騰訊自主研發的金融級數據庫，CynosDB（TDSQL）正在成為眾多金融機構數字化升級過程中的“使命擔當”。目前，CynosDB（TDSQL）已經為超過600機構提供數據庫服務，客戶包括張家港行、微眾銀行以及省部級政務機構等，行業覆蓋銀行、保險、證券、第三方支付、政務等領域。

雷鋒網雷鋒網

騰訊金融云總經理胡利明在演講中表示，目前，騰訊云在金融新基建方面構建了涵蓋專有云、金融專區、數據庫、微服務治理、運維等在內的分布式基礎云平臺，以及移動中臺、業務能力中心、數據中臺、AI中臺等落地方案。

而在數字新連接方面，騰訊云提供基于微信生態的微金融渠道、云景開放金融平臺、云霖產業金融平臺等渠道升級解決方案，并打造了智能營銷和風控支撐平臺，為業務開展提供支撐，助推金融機構實現數字化渠道轉型。

在上個月發布的2020Q2財報中，騰訊就披露過“金融科技及企業服務”當季收入同比增長30%至人民幣 298.62 億元；云及其他企業服務收入同比、環比都在穩步增長，主要受互聯網公司及公共服務領域客戶的云服務用量提升帶動，強調“與金融機構及公共服務領域客戶簽訂了重大合同，同時擴大了在醫療、教育、會議及展覽等新興垂直領域的業務，協助客戶實現數字化轉型”。

而這些騰訊云與金融機構的合作細節，以及戰略升級之后的最新布局，也在胡利明的這次演講中有所體現。以下是胡利明演講全文，雷鋒網AI金融評論做了不改變原意的編輯：

首先給大家匯報一下騰訊金融云今年的主要的進展。經過5年多的發展，我們服務了超過150家銀行、幾十家的券商和保險公司，以及超過90%的持牌消費金融還有數量眾多的泛金融企業，付費客戶數超過了1萬。另外協助建行構建了集團云，幫助中行構建了全行的數據智能平臺，幫助交行建設了移動金融開發平臺。

今年我們又有更多的突破：幫助人保集團打造了多地多中心的全分布式基礎架構；幫助中國銀聯建設了超大規模的集團云，支持它的核心業務云化以及金融科技的輸出；和深交所深證通合作打造了資本行業新一代的金融云，降低了整個行業的創新門檻，加速了行業的數字化。

另外我們今年還有非常多的業務賦能的案例，典型之一是幫助龍江銀行快速地構建了網貸和風控的能力，放款規模在很短的時間內超過了80億的規模，打造銀行零售業務賦能的標桿；在產業金融方面，也幫助瀚華金控打造了它的區塊鏈加上供應鏈金融的平臺。

騰訊云眼中的金融業五大趨勢

對于金融行業未來變革的趨勢展望，我們聯合騰訊研究院共同打造了未來金融變革的藍圖，詳細材料會在騰訊研究院官網線上發布。

隨著技術的發展、市場大環境和客戶行為的變化，未來金融行業呈現以下幾個方面的趨勢：

第一、渠道的變革。疫情加速了整個行業的線上化，零接觸的模式成為重要的方向，渠道端是以移動端為主。

第二、利率市場化導致整個的行業利差降低，競爭加大，利潤降低。

第三、線上業務風控難度在加大，風險逐步地在累積，監管整個的政策也是在趨嚴。

第四、在零售端細分的一些客群，包括企業的普惠金融客戶，仍然存在非常廣泛的市場機會。

第五、金融產品同質化嚴重，市場呼喚具有差異化，尤其是具有地域特色的一些創新型的金融產品和服務。

在后疫情時代，因為這些趨勢，數字化的進程在持續地加速。

那么，什么是數字化？我理解是將客戶、場景、產品、服務等等轉化為數字形態，優化服務和流程，

提升整個的內在價值，增強創新力和競爭力，建立基于數據以及客戶體驗為中心的產品和服務。這張圖是我們圍繞行業的趨勢，打造的未來金融變革藍圖。

左側在新的消費端，像新的技術5G和IOT，就帶來整個終端的泛在化。除了手機以外，像眼鏡、手表、智能音響等等，越來越多的終端也將成為用戶的載體，客戶的體驗形態將會前所未有的豐富。比如說VR、AR，包括混合現實、沉浸式的社交等等，非常多的體驗方式慢慢會出現，就是應用于各類的場景。

在金融行業，其實也會很快地出現一些革新和變化。在這些新的體驗當中，需要金融服務的相應的場景也在指數級地增長。

右側在新的產業端，各個行業自身的數字化，也為金融供給側改革提供了基礎條件。區塊鏈、數據智能等等新的技術，它的采用幫助了金融機構在產業端的信用的評估、風險監控等等領域，提供了新的抓手。有機會更有效地推進產融結合，然后線上的管理、在線的辦公的出現，為2B2C開辟了新的場景。

線上的金融服務，比如說代發薪、財務報銷、銀企服務、企業保險等等，都可以綁定在線上的辦公、線上的管理場景進行植入。未來金融的企業，將打造敏捷、創新的新組織，具備強大的金融新基建的技術底座不斷創新，形成更個性化、普惠化的金融產品，通過無所不在的客戶的連接渠道，觸達和服務新的消費群體和產業金融、服務實體經濟。

我們認為，未來金融的核心要點，是打造新基建和新連接。在數字新連接方面，是幫助金融機構完成渠道升級和超越、驅動增長，要點包括四個方面：

第一，新體驗，基于5G、社交網絡和IOT之上打造像微信小程序、直播、視頻、虛擬人、包括AR、VR等新的體驗的方式。客戶的注意力也會越來越集中在一些更直接、更友好的交互形式當中，金融服務的體驗將被重塑。

第二，私域流量的興起。從以前以線下流量為主擴展為基于像微信的開放體系，12億用戶流量池，基于這個流量池，構建屬于這個金融機構本身特色的私域流量。

第三，場景金融。金融機構從以前的坐商以及被動的開放，轉變為主動嵌入到各類的生活的場景，包括企業經營的場景當中，甚至包括同業業務合作的場景當中去。

第四，互聯網運營。由以前的重建設輕運營的這個模式，升級為把互聯網運營的方法、工具和基因注入到金融機構運營的日常當中去。

金融新基建方面，主要是幫助金融機構練好內功，要點主要包括以下三個：

第一，在核心系統和業務系統方面，主要是瘦核心加上微服務的這個架構。

以前的巨型的系統升級為穩態的瘦核心，加上業務的微服務模塊的方式，通過技術建模、業務建模，使用這個微服務的模塊，快速地迭代業務的能力，逐步地積累和發展，再形成這個金融機構公司內部特色的業務中心平臺，服務于公司內部各個業務場景，進行復用。

第二，當前傳統的、局部的智能方式，將升級為全流程的數據智能，通過全公司的數據湖、數據治理平臺加上機器學習的平臺，共同形成一個決策大腦，作用于行業的各項的業務。

第三，也是最基礎的一部分。指的是自主核心的基礎架構的技術、傳統的金融機構核心技術，主要依賴于外部，甚至說國外的技術。將來會逐步升級為信創自主可控的技術平臺，比如說核心數據庫、分布式的中間件、云平臺，甚至更底層的硬件。

如何實現未來金融的藍圖落地數字化轉型？騰訊云從14年支撐微眾銀行全面采用云架構上線業務以來，那么從金融云的底層的基礎設施逐步地走向了上層的金融科技業務賦能，最終形成一個體系化、全面的數字化轉型，1+4+5的產品架構方案。

底層是一個自主可控的分布式云平臺，包括專有云、金融專區、包括數據庫、區塊鏈、微服務治理、金融安全等等的部分，都包含在這個基礎云平臺當中。

中間層是四大中臺，包括我們的移動中臺業務能力中心、數據中臺以及AI中臺。

在上層新連接的部分，包括三個渠道平臺，一個是微金融的渠道平臺；第二個是云景的開放金融平臺，以及產業金融側的云霖產業金融平臺。那在支撐這個渠道平臺的這個后端，是兩個非常關鍵的智能營銷平臺和智能的風控平臺。

整體上形成一個全渠道、新體驗的客戶的界面，具有敏捷進化、云智一體的特點，能夠抓住未來金融發展的脈搏。

「金融新基建」五大特色技術方案

接下來我展開介紹一下新基建和新連接方面，騰訊的特色的方案以及實踐在新基建方面。

首先是最底層的云平臺——TCE。TCE的全稱是Tencent Cloud Enterprise，它是基于我們久經考驗的公有云技術，把非常多的組建私有化形成全棧的一個專有云解決方案。

現在很多金融機構，包括金融科技公司需要支持集團云，包括對外輸出的生態云的模式，那么一朵云不僅服務于自己內部的業務，也服務于集團內的多個子公司，甚至包括對外部公司的一個輸出。

騰訊在這個場景方面，是走在業界的前列。我們成功地服務于像建行、人保、中行、微眾、銀聯等等非常多的大型機構，其中像微眾和建設銀行都是超過萬臺的一個非常大的服務器規模。

TCE今年也有很多增強和升級：

第一個方面是成本持續的優化，使得我們IT的成本相對于傳統的架構降低了80%；

第二方面，我們提供了像行業版、企業版、大數據版、敏捷版等等好幾種的版本，針對不同的場景進行了定制；

第三方面，我們全棧的產品支持了當前主流的國產化的操作系統以及芯片，實現了整個的平臺+底層的、技術的自主可控，這個在現在非常復雜的國際形式下是非常重要的。

新基建的第二個特色的核心技術，是分布式的金融交易數據庫——TDSql。它也是騰訊支付底層的交易數據庫，目前服務于包括中國銀行在內的500多家金融機構。

早在15年1月份，我們就支持了微眾銀行上線，微眾銀行目前總的賬戶數是超過了2.5億的客戶交易的最高峰值，達到了22.5萬筆每秒，這個是非常大的一個峰值。

在去年的9月份，我們也支持了張家港銀行，它的核心系統完成國產化的、分布式改造。這個案例也成為國內首個傳統核心，采用分布式數據庫的一個標桿。今年我們也和平安銀行進行了信用卡核心系統分布式改造。

TDSql除了極致的可靠性以外，也具有非常大的、非常強大的性能，支撐著騰訊內部超過300億的各類的賬戶。系統的性能支持最大500萬的QPS，整個的技術接口兼容mysql的這個接口，技術的門檻非常的低，體系非常開放。同時TDSql有非常完備的自動化故障診斷和恢復的工具。

新基建的第三個技術方案，騰訊云原生的解決方案——TCS云原生架構，近年來因為非常的靈活、輕便、部署簡單，而且配合，搭配了像devops和完善的微服務治理的能力，已經越來越成為了金融企業基礎架構的一個新的選擇。我們的TCS云原生平臺有幾個特點：

第一，是非常靈活。一臺機器就可以快速地部署；

第二，是我們把運維的應用模型進行了抽象，實現了運維模型的一個復用以及云端的運維；

第三，我們是以應用為視角，管理業務的生命周期取代了傳統IaaS，以虛擬化資源為視角的模式的業務交付，交付的效率整整提升了100倍；

第四，我們在這個平臺上，其實搭載了大量的騰訊云的PaaS和SaaS產品，比如說騰訊會議。

新基建的第四個方面，金融的分布式核心業務系統、核心業務系統是金融機構業務的心臟。我們聯合長亮推出了金融分布式業務服務框架TDBF，做到了整個的業務流程和核心能力的預置。開放業務調用的接口，可以靈活的疊加定制業務，極大地提高了業務系統的建設以及擴展的效率。真正地做到了金融業務系統即服務。

今年我們也還全新升級了架構，首創了業界領先的分布式核心技術底座的替換方案，為金融機構搭建自主可控、單元化、跨機房 多活的分布式核心貢獻騰訊力量。

新基建的第五個特色的產品就是移動金融平臺（TMF）今年也進行了全新的升級，我們幫助客戶開發的效率提升到150%，擁有更強大的移動端的生態和更智能的線上能力。

首先，今年新支持了線上業務流程的自動化和智能化，包括事中的實時質檢，事后的留證回溯，包括多端的數據分析洞察等等。

第二，對接了云景開放金融平臺，諸多的開放金融的場景。

第三，我們針對微信小程序平臺進行了深度的對接，提供了非常豐富的小程序組件，包括金融機構快速、安全合規的融入微信生態。

TMF已經服務了非常多的國內的頭部金融機構，覆蓋超過1億多的客戶。比如說我們今年幫助交通銀行的APP4.0上線，在兩個月之內它的日活用戶的增長超過了30%。

在新基建的數據智能創新方面，聯邦學習絕對是目前炙手可熱的方向，也是解決金融數據在合規的前提下合作難題的最好的解決辦法。

騰訊神盾聯邦計算通過密碼學和機器學習技術的結合，讓數據合作的雙方不需要在外傳自身數據的情況下，能夠合作建立機器學習的一個模型，聯手發揮出這個數據的價值。

神盾平臺計算不需要第三方，解除了第三方合謀的風險，同時通過非對稱的算法杜絕了像數據樣本泄露風險。我們也有非常多的專利研發了新型的同態的密文。讓整體的計算的時長減少了99%。

如何助力金融機構用好微信端流量紅利？

目前，其實金融機構大部分的客戶來源于線下的網點以及業務員。通過APP獲客非常的有限，目前流量成本在行業里面也越來越高。流量經過一些多輪的清洗之后，質量越來越差。銀行界里面近年來實踐的直銷銀行其實效果也不是太明顯現階段。

我們覺得最大的機會和紅利其實在微信端。微信有12億的月活用戶，有消費端的公眾號、小程序、直播 廣告、支付……非常多的生態。在產業端也有企業微信上百萬的企業以及騰訊云產業互聯網跨界合作的這個生態。

不管是在零售端的客戶還是小微企業的客戶，通過微信端的服務和推廣入口進來都可以快速導引到我們金融企業的私域的流量池。

這里舉個例子，像拼多多，在電商競爭已經非常紅海的情況下，把微信的社交流量發揮到了極致，快速地在幾年之內從0構建了一個擁有5.8億用戶的電商帝國。

其實在金融行業，哪一家公司能夠把微信端的私有化的流量池用好，將會是行業里面下一個拼多多，具有非常巨大的潛力和機會。

我們騰訊團隊會提供非常專業的互聯網的流量運營的經驗、方案和工具，來助力大家從用戶的獲取激活、存留、裂變、轉化等等整個的過程。

基于數據精細化、智能化，具體要怎么做呢？首先在直接觸達客戶的數字渠道方面，我們建議金融機構建立自己的微信小程序門戶，作為自己流量的陣地，運營客群，帶動業務，微信小程序有幾個優勢：

一，海量的微信用戶，天然已經在平臺上面。小程序的日活也超過了4億。

二，小程序是一個去中心化的入口，也是我們金融機構私域專屬的入口。

三，用戶使用小程序不用下載，不用更新，使用的門檻非常低。

四，小程序非常方便分享、傳播、裂變，和傳統的快消品、電商等等一些簡單的廣告推廣方式不同，金融的客戶和金融機構之間的連接，需要值得信賴的一個強連接，才能夠帶來好的轉化和存留。

微信端的連接恰恰非常得契合，并且社交的裂變相關的效果是出乎意料得好，整體的成本也非常非常得低。

在和某家股份制銀行合作的實踐當中，小程序的轉化的成本是他們以前APP渠道的十幾分之一。所以我們建議，金融機構要大力發展小程序端，成為和APP并列的一端，進入雙端時代。除了獲客轉化率的傳統的APP，還增加小程序這個強通路。

打造一個小程序門戶，加上多個業務功能矩陣。作為流量池的載體，快速地承接所有的線下線上推廣的渠道，也可以精準的關聯到單個的業務的場景。比如說繳費、信貸、理財等等對客戶來說非常得貼近場景。

我們也會向金融機構提供專業團隊，進行小程序的設計和開發的服務，通過業務模塊內容模塊相關的組裝，再加上企業特色的定制整體形成體驗領先的微信小程序門戶和矩陣。

另外一方面，員工或者客戶經理和客戶的連接其實也是目前金融機構主要的業務來源，非常需要通過數字化的方式來武裝和激活起來。大多數的客戶經理都通過個人的微信聯系客戶，那么有可能逐漸地變成一個私人的連接。

騰訊的企業微信加上微信它之間是打通的，通過這個關鍵的能力，我們打造了BC一體的客戶運營的工具。

社群通。客戶經理通過企業微信和客戶交流所有的數據，我們通過社群通的管理可以做到數據的可存檔、自定義的群發，包括客戶的可路由、再分配等等，真正的把客戶的關系沉淀到公司，實現一切溝通的內容均數字化。

獲客通。獲客通相當于是幫助客戶經理打造個人的專屬微信小店，除了認證的名片、金融的產品的展示以及權益推廣這些以外，我們還可以幫助客戶經理打造個人的人設，形成一個有溫度、鮮活有個性的人，對客戶形成非常專業、值得信賴的形象。

另外，在這個平臺內部也建立了客群的、精準的標簽，基于這些標簽去推薦最合適的業務以及呈現的資訊的內容。

第三，采用AI的策略話術，通過智能的NLP，提取相應的內容的觀點，這些工具給到我們的客戶經理去對客戶進行交流。

右邊呈現了某個農商行的客戶經理一天當中使用企業微信的整個的軌跡，可以看到從早到晚和客戶的所有的交流的互動、營銷的拓展，從公司的早會、記錄信息、總結等等，都能夠在企業微信的平臺上非常好地完成。所有的客戶關系、服務的信息都沉淀在公司的平臺當中。

在后疫情時代，零接觸金融服務的模式是非常明確的方向。

之前需要在網點辦理的業務，逐漸地都能夠遷移到線上。我們在去年年底就推出了，虛擬營業廳的產品，實現了7×24小時的移動視頻營業廳，能夠支持像私人銀行服務、信貸的初審、面簽、續貸、信用卡的營銷、對公開戶、理財風評等等超上百種業務。

截至目前，金融虛擬營業廳已經在57家銀行落地，從大行如工商銀行，到股份制如浦發銀行，到城商行、農商行。

在開放金融方面，我們有提供云景開放金融平臺，那數字化的金融一定是開放的。除了自身的私域流量構建以外，當然還需要全方位的，拓展合作方的場景。

騰訊在發展互聯網業務以及云+產業拓展的這個過程當中，形成了非常豐富的金融+互聯網、金融+產業生態，在云景開放平臺當中全部提供出來，包括像微信繳費等等非常多的場景。

在實現以上非常多的客戶營銷，和業務開展的業務場景過程當中，其實需要一個非常懂得客戶的后端營銷平臺。我們騰訊把多年互聯網客戶運營的經驗整合對外輸出形成了云隆金融營銷平臺，具備營銷自動化的能力，匯聚了騰訊系超過100多種特色權益。

同時我們最新打通了對微信支付營銷的這個接口，像支付優惠券，這些場景對于金融營銷是非常契合。此外平臺也能做到基于大數據的用戶畫像，千人千面的活動內容、定制化產品的推薦；內容上也提供10萬+素材，實現了營銷活動和內容的高效生產，整體提升客戶黏性。

舉一個小小的例子：在疫情期間，我們幫助某大行的分行持續地進行營銷的展演，累計生產了差不多超過100多場營銷的活動，帶來了超過31萬的微信新客戶的獲客，平均貸款的進件轉化率高達13%。

除了金融的零售業務賦能以外，為了應對產業互聯網轉型過程中，出現的金融的需求，我們推出了云霖產業金融解決方案，覆蓋了包括工業、交通、零售在內的十多個場景。

根據產業鏈的特性，我們在應用側推出了三大類，九個子類的行業解決方案，包括以供應鏈為主的供應鏈金融，依托量化數據授信為主的中小微企業解決方案，以及服務細分行業的保理云、租賃云、ABS云等等解決方案，為應用側提供基礎支撐，還有產業風控能力以及全棧的金融科技能力。

同時依托風控決策包括機器學習、區塊鏈以及AI工具箱，覆蓋超過2400條以上的產業鏈，形成了超過3500個以上的風控變量，能夠為產業金融業務的開展提供企業的風控畫像、產業鏈分析、全網的輿情以及產業智能風控服務。（雷鋒網）

雷鋒網

平頂山銀行是平頂山市委市政府主導的地方法人金融機構，是河南省僅有的5家城商行之一。2019年末，平頂山銀行資產總額突破千億元大關，成功邁入千億級銀行行列。

本次合作，騰訊云將為平頂山銀行提供符合公有云標準的金融級生態云平臺，并提供持續運營的基礎設施支持，包括完整的底層基礎設施、互聯網絡、安全防護、開發運維、運營管理等相關能力支持，保障云平臺的平穩建設和持續運營。

在金融業務基礎上，雙方將探索在數字化銀行、大數據精準營銷、用戶畫像、智慧風控、信貸科技、社區金融、農村金融、小微金融等領域的深度合作，共同提升服務平頂山市及河南省內客戶的整體服務水平，建設智慧銀行的標桿樣例。

除此之外，雙方還將在智慧政務、智慧教育、智慧社區、智慧醫療、智慧住建等多個層面展開深入合作。

目前，騰訊云已經服務了超萬家金融領域客戶，包括150多家銀行、數十家保險及證券公司、70%的持牌消費金融公司和80%的新籌保險公司，四大國有銀行中已經有三家和騰訊云進行緊密合作。

在疫情期間，為了幫助金融機構服務暢通，騰訊云緊急上線了虛擬營業廳抗疫情快速部署包，全力支持金融機構在線提供24小時營業廳、貸款和對公開戶面簽、視頻客服等能力，滿足疫情期間個人及企業的金融服務需要。

隨著5G、大數據、人工智能等在金融領域的普遍應用，加大金融科技投入已是行業共識。尤其是本次疫情中，當線下網點無法有效觸達客戶時，推動金融服務線上化、智能化的迫切性更加突出。

從多家銀行披露的年報來看，銀行普遍希望擁抱金融科技，按下數字化轉型的“快進鍵”，但是傳統IT架構卻成為了創新最大的“攔路虎”。

“國內銀行業信息化建設開始較早，總體以傳統集中式IOE架構為主，擴展性和更新速度受限，

已經無法跟上以互聯網化、在線化、數字化驅動的銀行數字化創新的高速發展。”阿里云研究中心高級戰略專家崔昊表示，將集中式IOE架構轉為開放的分布式x86架構，并逐步以云計算服務取代周期冗長的硬件建設，將為銀行創新提供強大的技術驅動力。

據上市銀行最新年報顯示，科技賦能金融已經成為銀行業共識，一些先行的銀行通過牽手阿里云等金融科技巨頭公司進行中臺架構轉型，以及核心業務全面上云，收獲了新技術帶來的紅利。

行業人士認為，以云計算為代表的數字新基建在銀行業的應用逐漸廣泛和深入，金融與科技將加速融合。

科技賦能金融成共識

近年來，金融監管機構持續推動科技賦能行業發展，金融科技的應用呈現逐漸開放的態勢，加上“互聯網+”概念在國內銀行業的認知不斷加深，國內各大銀行均已認識到用科技賦能金融的重要性，紛紛加大金融科技領域的布局。

2019年8月，中國人民銀行印發《金融科技（FinTech）發展規劃（2019—2021年）》，該規劃指出：強化統籌規劃、體制機制、人才隊伍建設等方面的戰略部署，為金融科技發展提供保障。明確要求金融機構要在年報及其他正式渠道中完整披露科技人員數量與占比。

日前，上市銀行年報密集披露，金融科技毫無意外成為年報高頻關鍵詞。不僅僅是六大國有銀行，諸多的股份制銀行以及城商行都在用大篇幅描述對金融科技的引入和投資。據統計，僅僅六家國有銀行在2019年在金融科技領域的投入達到了710多億元。粗略統計，全部上市銀行在金融科技領域的投資遠遠超過1000億元。

工商銀行在年報中提出，“金融科技是過去一年本行創新發展的重頭戲”。 2019年工商銀行發布智慧銀行生態系統(ECOS 1.0)，從生態、場景、架構、技術、體制等多端發力，促進科技與金融的深度融合。2019年年末，工商銀行還與阿里巴巴集團、螞蟻金服達成合作，將加強在云計算、數據智能、金融科技等關鍵技術領域的探索，加速金融產品創新。

作為股份制銀行的代表，民生銀行也在持續加大金融科技投入。2019年，民生銀行提出以分布式架構轉型為動力、以數據治理為抓手，為戰略實施和改革轉型提供技術“動能”、數據“賦能”和資源保障。

事實上，民生銀行早在2108年就借助用阿里云的分布式核心技術，完成了直銷銀行系統全部上千萬電子賬戶遷移，系統成本大幅降低，交易速度和能力明顯提升。

金融新基建紅利凸顯

梳理近期年報還可以發現，對于銀行而言，金融科技已不再停留于早些年的戰略討論階段，而是逐步滲透到業務運營之中，成為轉型的核心驅動力之一。少數率先深度使用金融科技新基建的銀行已經開始從科技轉型中謀得紅利。

以長沙銀行為例，2019年該行資產規模突破6000億元，營收、凈利潤均實現雙位數增長。2019年，被長沙銀行稱為是“數據驅動年”，全行加快了從“應用啟動”向“數字驅動”的動能轉換，通過牽手阿里云等廠商，逐步實現線上化、數字化和智能化轉型。

在對公業務競爭白熱化、利率市場化導致利差大幅收窄的背景下，深耕零售領域成為銀行尋找新增長點的重要抓手。而銀行業的金融科技轉型，零售業務也成為主戰場。

已經公開上市招股書的順德農商銀行日前公布攜手阿里云進行數字化轉型的階段性成果，基于阿里云輸出的mPaaS移動開發平臺和大數據風控平臺，實現個人貸款業務的全流程純線上操作就實現了零售業務的快速增長。

在廣東農信，金融科技的創新讓銀行與實體經濟更加緊密的結合在一起。廣東農信以云為“底座”，與阿里云一起落實數據中臺與業務中臺的 “雙中臺”架構，初步形成“厚中臺、薄前臺、穩后臺”的體系建設。

在服務某棉紗行業客戶時，廣東農信在相對同質化的金融服務之外，輸出云、APP、中臺的能力，幫助客戶構建了B2B電商交易平臺，不僅獲得了這一大業務規模、大資金流量重點客戶的金融服務業務，更與該棉紗客戶的業務流程緊密相連。

“金融科技將不再只是提供后臺技術支持、，而是直接關系到銀行利潤創造。”一家股份制銀行的高層表示，金融科技帶來了銀行業務重塑，這種重塑將對整個行業格局產生重要影響。

金融行業上云有望迎來拐點

麥肯錫研究發現，數字化業務逐漸成為傳統銀行的重要收入來源，因此數字化轉型升級也是銀行未來發展的必經之路。

首先，銀行業實體網點規模持續收窄，業務在線化需求日趨迫切。數據顯示，2016年-2019年，六大行三年內累計裁撤線下網點1749個，僅2019年，工商銀行就裁撤了220個線下網點。與此同時，科技決定銀行的未來已成業內共識，金融科技人員在銀行中變得不可或缺，2019年工商銀行披露其金融科技人員規模多達34800名，占比高達7.82%。

另一方面，縱觀全球金融行業，上云趨勢勢不可擋。國外，Capital One、高盛等銀行相繼與AWS合作“上云”，而國內民生銀行、南京銀行等上百家銀行也在跟阿里云等合作“上云”。權威市場研究機構IDC報告指出，阿里云位居中國金融云解決方案市場第一，成為支撐金融行業面向未來的關鍵數字基礎設施。

業內人士認為，在互聯網行業，云計算已高速發展到了“業務系統互聯網化”和“數據在線智能化”階段，而在金融業，云計算仍處于“非核心系統上云”和“基礎資源全面云化”階段。而持續至今的新冠病毒疫情可能是一劑催化劑，將加速銀行核心系統的上云步伐，迎來行業拐點。

以云為基礎，未來銀行將構建一個生長在平臺上的“數字（孿生）分行”。銀行將利用云端的能力和智能的技術開展金融服務，并且和多方建立新的基于數字技術的緊密連接、高效協同和場景創新，讓國內銀行業具備與互聯網公司一樣的快速迭代速度，吸引大量新鮮需求和創新場景。

“突發的疫情把銀行線上化運營和數字化經營推向了一個新的高度。”一家省農信社科技部高管指出，非接觸金融服務背后，IT技術的重要性比以往任何時候都更重要。

布萊特-金在《BANK4.0》這樣描繪未來的金融服務：“金融服務無處不在，就是不在銀行網點。” 顯然，洶涌而來的數字化浪潮中，金融科技新基建決定著銀行的未來。

雷鋒網雷鋒網

吳軍在《浪潮之巔》中揭示當下工業革命的范式：現有產業+大數據=新的產業。

如何正確得使用大數據，將公司現有的業務和市場規模變得更大，成為當代幾乎所有企業都必須思考的一個問題。而大數據平臺便是這個問題的解決方案之一。

對此，雷鋒網采訪了京東數科T1大數據平臺負責人。

他和我們分享了京東數科T1大數據平臺的產品特點和技術特色、在金融領域的服務情況以及在具體實施過程中遇到的困難等內容。

以下為對話實錄：

雷鋒網：T1大數據平臺是一款什么樣的產品？

T1大數據平臺是一個涵蓋數據采集、加工、處理，包括數據資產管理、數據服務和數據應用等一整套從底層到上層的、全生命周期的一站式大數據平臺。

平臺有兩個特點，首先它是一站式的平臺，從底層快速地幫助用戶搭建一整套的大數據體系，幫助客戶迅速完成數據的資產化和價值化，并且通過數據服務層的能力組合，比如數據接口或者畫像、標簽、相關的系統支撐各種業務場景。

第二，整個大數據平臺本身是一個配置式和自動化程度比較高的系統，能為用戶提供良好的操作體驗，大大降低用戶操作門檻。

雷鋒網：T1大數據平臺面向哪類型的客戶？

一般是金融機構，目前我們做的比較多的有民營銀行、股份制銀行和城商銀行，可以簡單的分為三類：

第一類金融機構，目前還不具備高效的實時處理和分析功能，它們需要建設一個實時的大數據處理平臺。

比如一家中型銀行，每年產生的數據量可以達到數十TB，涵蓋了應用數據、行為數據和系統日志等多種多樣的數據來源和格式。如果沒有合適的運營管控工具，這些數據只能“沉睡”在后臺，無法發揮價值。

第二類金融機構，具備傳統的數據倉庫，可以解決分析報表的需求，它們需要建設一個整體的大數據解決方案。

第三類金融機構，本身具備不錯的大數據平臺能力，但建設的比較分散、孤立，業務之間存在gap，它們需要一些產品，比如數據接口或畫像系統，在大數據平臺和應用之間架起橋梁。

雷鋒網：如果客戶本身已經有大數據平臺，再對接T1大數據平臺，會遇到哪些問題？

客戶在已有大數據平臺上再采購集成其他的大數據產品，主要會碰到的是兼容適配的問題。

相對于業內某些產品的封閉性和排他性，T1大數據平臺是一個開放式的架構，既可以把平臺整體輸出給用戶，也可以按需輸出某些子產品作為客戶的能力補充。

T1的子產品對外部依賴都做了兼容性的處理，也預留了一些對接接口，可以快速和客戶本身已有系統進行對接。比如T1大數據平臺曾輸出畫像產品給某家客戶，需要和客戶已有的ETL系統進行調度對接，由于畫像產品已經預留了調度對接的接口，所以非常順利地就完成了對接工作。

雷鋒網：金融機構十分注重安全性問題，京東數科對此做了哪些工作？

的確，金融公司對數據的歸屬性都比較敏感，T1大數據平臺提供私有化部署的服務，可以把大數據平臺部署到客戶的環境當中，將數據劃定在一定區域中，非公司內部人士不可能直接訪問到相關數據，從機制上保證了數據安全。

在使用大數據平臺時，對于企業客戶內部的操作人員，京東數科提供數據全生命周期的安全管理服務，對敏感數據進行分級分類。這種方式下，操作人員只能接觸到一定范圍內的數據，保障了操作時的數據安全問題。

雷鋒網：T1大數據平臺有直接對標的產品嗎？國外有Cloudera，Hortonworks，國內有神州信息、華為、星環、明略數據等大數據平臺產品，相比這些廠家，T1大數據平臺有哪些優勢和劣勢？

京東數科T1大數據平臺具備實時異構的海量數據處理能力，比如實時數據處理平臺，已經達到TB級的數據在線實時處理，并且能夠提供毫秒級的延時。

此外，京東數科T1大數據平臺還提供了一套新的數據服務架構，在以前傳統的架構中只能處理結構化的數據，而T1能夠對各種結構化、半結構、非結構化的異構數據，實現統一的數據接入、數據整合以及數據加工處理和分析。

雷鋒網：之前您說道，T1大數據平臺”是一個全套的解決方案，可以給我們講一講它“全”在哪里嗎？它比較特色的組件又在哪里？

T1大數據平臺的“全”主要體現在三個方面：一是產品功能覆蓋了從異構數據的采集、存儲、加工和使用的數據全生命周期的端到端的整體流程，具備采集的數據類型全，采集的時效性高和使用方式靈活多樣的特點。

二是產品操作方式覆蓋了大數據技能水平的所有用戶群體，既提供了拖拽式、智能化的不需要具備專業大數據技能的便捷操作方式，也為算法工程師、數據科學家等高階用戶提供了自由式的數據探索入口，讓平臺的作用最大化。

三是在大數據價值鏈的傳遞上能夠為數據應用的全場景提供良好的支撐，數據接口、標簽、模型等服務都可和上層數據應用場景做無縫集成和對接。

有不少比較有特色的組件或功能，比如數據復制組件可以實時解析采集MySQL、Oracle、DB2、HBase和Mongodb等多種主流數據庫的數據，在整個業界同類產品中功能也是非常領先和突出的。標簽畫像組件不僅僅具備標簽畫像的加工查看功能，還提供了和上層業務的快捷對接方式和應用效果評估，解決了使用上“最后一公里”的問題。

雷鋒網：對于一些本身體量較小或者目前數據量積累較少的公司，有人認為沒有必要搭建這一套系統，暫時先租用AWS和阿里云就夠了。對于數據量大，但數據分析需求較簡單的公司，可以直接買Tableau，Splunk，HP Vertica，或者IBM DB2等軟件或服務即可。您覺得數據量或者記錄規模大概達到什么級別就必須上大數據平臺？

大數據平臺的使用可能和數據量沒有直接的關系。

有的初創公司或者某些行業的公司，對于數據的使用和數據歸屬性的要求沒那么高；有些公司目前的需求是解決一些業務運營分析，它們的確可以去購買一些公共的服務。但是當這些公司發展到一定階段之后，如果想去更好的開展一些業務，比如說營銷拓客、在線個人信貸或者風控，是需要具備大數據平臺能力的。

雷鋒網：T1大數據平臺是開源的嗎？

T1大數據平臺的底層基于開源的生態體系來打造，這樣能幫助我們的客戶去利用到開源生態體系的一些能力，支撐業務的發展。但就產品本身來說，目前不開源。

雷鋒網：T1大數據平臺從開始定制到正式使用，一般需要多長時間？

目前，T1大數據平臺已經是非常成熟的一套標準化的產品。我們也提供了一鍵式安裝部署的服務，可以把T1大數據平臺以標準化的方式，非常迅速的融入客戶的IT系統中。基本上一周之內，它就可以實現投產運行。

雷鋒網：您提到，一周內可以完成產品的部署。那把產品從0到1部署到銀行原有IT系統的大致流程是什么樣的？你們這一周主要干哪些事？

T1大數據平臺為了保障對客戶的交付效率和體驗，更多的工夫會體現在這一周之外。從技術層面上，T1大數據平臺可以實現自動化和容器化的安裝部署模式；從交付方式上，專業的交付實施團隊會提前和客戶規劃好部署架構，并在T1大數據平臺的自有演練環境完成部署演練，從而達到在客戶現場最快速部署落地的效果。

雷鋒網：在這一周的部署過程中，你們需要幫銀行IT部門解決的最復雜的技術和系統對接問題，您認為是什么？

在真正部署的階段前，我們會同銀行IT部門一起來解決適配和對接的問題。在銀行落地過程中，主要會碰到基礎環境兼容、既有系統對接和客戶自有工作流程的銜接等問題，相對來說既有系統的對接是比較復雜的部分，T1大數據平臺各個子產品對可能發生外部交互的功能邏輯進行了抽象封裝，以接口化、插件化的方式實現最小化代價的對接。

阿里金融云總裁徐敏認為，新金融是一個云計算、大數據、AI、IoT、區塊鏈所支撐的數字金融，而新金融的實現以數據為紐帶的金融和產品指引。他也在近期的2018云棲大會上，分享了阿里云過去數年間在分布式微服務、人工智能和場景方面與金融機構合作的案例和心得。

以下為演講全文，雷鋒網做了不改變原意的編輯：

金融到底該被誰來定義？說實話，美國的華爾街金融定義影響了我們很多年。我認為華爾街金融最和諧的訴求是資產的保值和增值。但是資產增值，到底應該是目標還是結果？

“金融實現民主化和普惠，擴大化和人性化”，這應該是一個目標，增值保值是一個結果，要反過來思考。而今天，互聯網能夠幫助我們實現這一點，互聯網我們把金融服務帶給每個人，而不是用戶來這邊取。互聯網是能夠讓我們以更低成本服務更多的客戶，這一切正在發生。（雷鋒網AI金融評論注：本段所引用句子來自經濟學家Robert J. Shiller《金融與好的社會》）

新金融的三種發展方向

我認為新金融是一個云計算、大數據、AI、IoT、區塊鏈所支撐的數字金融，這五個方向我也認為是金融機構、金融科技的重要方向，而數字金融是新金融的本質。而新金融的實現以數據為紐帶的金融和產品指引，無論2B、2C，強調數字為代表，強調數字成為紐帶，強調直連。

今天想分享的這三個方向，是在過去幾年經過實踐，在今天已經基本成熟，能夠大規模利用，并且有很好業務效果了。

• 互聯網分布式微服務

微服務本身是一個IT概念，可以叫做SOA（Service-oriented Architecture，面向服務的架構）的升級版。我發現它的很多理念，不僅適用于IT，也適用于金融業務、金融服務。例如大中臺、小前臺，讓更多能力放在中臺，讓前臺變成以更靈活的方式來實現，強調能力的沉淀——這里說的是持續的沉淀。

我覺得微服務項目跟SOA項目最大的區別是：SOA是個項目，單做完之后打通之后就放走了；而微服務架構是要體系，強調用沉淀的能力來去賦能新的應用，形成體制和機制，而機制也能夠用在銀行業務之上。

另外就是業務打通和能力嵌置。過去數據的價值是我們應用的財富而已，但今天我認為，應用是數據的改革形式，主要是數據。在阿里巴巴，我們強調一切業務數據化，一切數據業務化。最重要的是，要強調從生產型模型向運營型模型來轉變。這什么概念？我們發現，花很長時間開發的系統就放著不動了，統一技術半年或者兩年變革一次。金融機構的產品也是這樣，做個產品放這邊，后面就沒有什么優化了。

但是擴展公司（的時候），強調運營，我們會用很快的方式上線一個項目，然后不斷迭代，項目來自銀行，現在我們能做到每天版本升級更新，核心上線才花4個月。這樣的模型我覺得對IT、對業務，都會有很大的幫助改變。

我認為分布式微服務架構能對經濟帶來一個所謂的乘法效應，就是交易的性能成倍提升，交易的成本也大幅降低，它是乘法效應，例如我們跟民生銀行一起來做分布式的銀行，交易能力從每秒7800筆到30000筆。包括廣發銀行，我們在做整個中臺的搭積木創新，性能提升幾十倍，整個的交易能力提升很多，成本降低五分之一。基于這個平臺的業務創新，一年交易量是過去10年總和，所以他們叫線上一年，線下十年。

同樣今天在廣東農信，包括杭州銀行、蘇州銀行，很多地方都在實踐，這是一個方向，通過微服務方式讓我們整個升級引擎、交易核心帶來乘法效應，同時做完之后帶動業務創新，讓業務也能逐步實現微服務化。

• 人工智能

拋開數據智能的倫理觀不談，我認為很長一段時間之內，將是人腦制定規則和機器執行規則，但關鍵是數據在線。而且我認為數據智能將會為金融機構帶來一個指數效應，因為分布式提升的是生產力，而數據智能和大數據改變的是生產資料和生產關系——這個變化才剛剛開始。

之前也做了一些實踐，例如和銀河證券合作，幫助銀河證券把整個理財的購買預測模型的性能提升了，包括優化證券開戶的全流程，之前30%的客戶會開戶不成功，現在降到百分之十幾。還有和南京銀行的合作。

我們做了幾個事情。一是營銷引擎，一家活動想清楚業務規模以后就上線了，今天一個平臺去做試算，做測試。我們一個月之內，做了差不多20個批次的營銷測試。在真正投入資源之前，用數據做測試。測完之后，我們就知道哪個效果更好了，才能把有限的營銷資源投入到更好的效果里面去。今天我們去發現客戶更加需要什么服務，比如用花唄來支付手機話費的方式把整個信貸的自用率提升了48%。

又比如國泰君安的很多客戶，我們進去以后做數據分析，去發現這個客戶的喜好是什么，例如客戶喜歡看優酷土豆，那就發一些優酷土豆的代金券吸引他，所以這是我們跟很多金融機構做數據方面的創新，這只是一個嘗試而已，才剛開始。另外也有跟中國基金行業做一個證券行業、投資行業的數據智能大賽。

• 場景

很多金融機構一直在說缺場景，但是久了你會發現，其實我們并不缺場景，缺的是場景的消化能力。例如有一家銀行他們的網絡金融部很厲害，把當地的運營商談好了，運營商線上買手機的時候可以利用貸款分期付款，但是銀行機構每天一千多筆交易進來之后，被風險部全部砍掉了，為什么？有風險我不能做。

我們目標是說，一方面我給金融機構帶來一些場景，在過程中我們和金融機構一起來合作，來把整個金融機構對風險、對流程的改造做起來。把這個流程做好以后，能夠消化場景之后，未來基于他可以吸收更多場景進來。

就像量子跳躍這個物理概念，電子吸收更多能量以后可以到更高的軌道上面去，我認為金融機構會發生（這樣的情況）。但那時候金融機構還是不是傳統的金融機構？需要思考。就像一個電子從這個軌道跳到那個軌道的時候，還是不是這個電子？這是不一樣的，但這個情況是一定會發生。

講幾個場景，比如天貓有阿里巴巴電商能力，包括移動、電信服務、銀行APP進來以后，可以通過銀行的收銀臺來支付買天貓商品，無論是積分還是信用付或是各種方式都支持。售后、物流我們搞定，通過這種方式把全世界最大的消費金融場景給到銀行、給到保險、給到券商，包括三大運營商，來做客戶運營，做消費金融一系列。通過這種方式，金融機構一方面活躍你的APP，有更多用戶使用。其次是面向2B場景的工具，比如供應鏈金融+區塊鏈。要把整個數字化中國結果對接的話，會加入IoT。

我認為做數字化中國，不僅僅是把產業的流程和一些線下的積累上線了，更是通過數據變成企業和外部交流的橋梁，所以數據將成為全社會企業面向內部、外部生態的協同調度橋梁。同時我們發現資源本身也是一種介質，在全社會范圍內調配資源，數據跟金融這兩者，在今天相遇了。

以阿里云的風險服務為例，客戶來買云計算的時候，可以獲得銀行貸款，分期付款，銀行基于一些像芝麻信用分數來看，今天到底應該給他多少信用額度，能不能放貸款。當客戶發生壞賬的時候，這時候我們可以通過云資源場景做資源保全，例如買了一年的云資源，第6個月發生了壞賬，我把云資源的錢還給銀行做這個事情。再例如企業采購平臺，里面有上萬家的大企業集采，員工福利可以通過他去買，同時那個場景下的金融需求可以跟金融云合作。

總結一下，今天金融行業的云會出現兩種形態，一是叫金融行業云，目標是讓金融機構本身數字化能夠推進；二是金融產業云，用金融視角看產業數字化的進程。在這之后，用金融機構力量來幫助產業做數字化升級；同時通過API的方式，把金融能力嵌入到產業里面去。最后是企業數字化之后，把結果帶回來。所以金融行業云跟金融產業云現在相遇了，這也是阿里云未來一兩年之內要做的事情。

創新、數據、開放……金融轉型的未來還需要什么？

最后講一點我個人對金融轉型的思考：

1.創新一定需要特區，必須有個地方能夠把金融創新業務和IT能夠完成。我們沒有足夠的時間去讓行業里每個人來配合我們。很多時候，我們跟銀行、保險、證券掌門人談的很好，他們決定方向要去做，但是到中一層，到某些部門都會卡斷，這是最大問題所在——最長木板決定方向，最短木板決定效果。

2.關于數據，“不知己豈知彼，不知所至豈知所需。”首先大家把自己的數據看清楚了，把里面的數據充分挖掘之后再引進來，同時一定要基于場景基于自身數據。

3.很多銀行和我們合作非常好，是因為他們（思維）更加開放，在整個合作中沒把自己當老大。自己不是老大，所以他們走得更遠。金融會用什么路徑實現創新，這個思維要想清楚了。我認為成為“平臺”不是唯一路徑，卻是最難的一條路。

更多金融科技資訊，請關注雷鋒網AI金融評論（公眾號：aijinrongpinglun）