?對于IT系統(tǒng)，系統(tǒng)安全穩(wěn)定運行與快速的敏捷交互業(yè)務功能，似乎有一些矛盾，互聯(lián)網(wǎng)公司落地實踐證明，技術能力的平臺化是應對穩(wěn)定性和交付效率的有效手段。對于金融行業(yè)更加嚴格的監(jiān)管要求，平臺化落地又具有自身的特點。

本次分享希望從研發(fā)的視角看金融科技平臺化落地的探索和實踐，將通過行業(yè)背景、整體策略及思路、落地實踐的回顧，總結平臺化落地的經(jīng)驗。

一、行業(yè)背景

?1、金融監(jiān)管對系統(tǒng)研發(fā)的要求

金融監(jiān)管對系統(tǒng)研發(fā)的要求包含業(yè)務要求和技術要求兩方面。

1）業(yè)務要求

業(yè)務要求對于銀行系統(tǒng)來說更多體現(xiàn)為一些功能性的需求，前些年稅改費、自貿(mào)區(qū)等政策引起的相關需求涉及多個核心銀行關鍵系統(tǒng)的變更，如果出錯就是賬務問題，同時時間緊，要求高，不能有任何的閃失，那么這種需求對于金融機構而言屬于最高優(yōu)先級的剛性需求。

2）技術要求

技術要求較多體現(xiàn)為非功能的需求，如目前正在推進的災備體系建設、信創(chuàng)要求，這類要求也是必須完成的。

?2、新場景、新技術、國產(chǎn)化帶來的挑戰(zhàn)

隨著金融科技應用的快速發(fā)展，目前系統(tǒng)的穩(wěn)定性也面臨新場景、新技術、國產(chǎn)化等諸多變化因素帶來的挑戰(zhàn)。

1）新場景

對于當前賬戶出海、智慧政務、智慧社區(qū)等新場景，原先從事銀行系統(tǒng)研發(fā)的人員相關領域經(jīng)驗不足，在特定場景下可能會出現(xiàn)業(yè)務架構設計和系統(tǒng)架構設計帶來的一些不確定因素，最終導致業(yè)務流程設計、系統(tǒng)擴展性和非功能方面的考慮略顯不足。

2）新技術

云計算、云原生、微服務、人工智能、大數(shù)據(jù)等新技術如何應用到應用場景中？

各技術領域的應用設計模式、最佳實踐、底層技術的掌控能力不足，也會給系統(tǒng)的穩(wěn)定運行和架構設計的合理性帶來一些不確定因素。

3）國產(chǎn)化

由于國外技術的受限，國產(chǎn)化技術成為必然的選擇，但是國產(chǎn)化技術普遍商用的時間較短，成熟度有待提升，國產(chǎn)化技術的適配性、供應能力也給應用研發(fā)帶來了一定的挑戰(zhàn)。

?3、“平臺化”是應對挑戰(zhàn)的必然選擇

根據(jù)國內(nèi)外互聯(lián)網(wǎng)公司的實踐證明，技術平臺化是應對以上挑戰(zhàn)的可行之路。百度百科對于通用技術平臺的定義提到，平臺化能夠帶來提升效率、降低風險和降低成本多方面的紅利。

大型金融企業(yè)一般都有復雜的企業(yè)級架構，從我們在日常工作中的實踐證明，平臺是承載效率、成本、質(zhì)量的最佳選擇，而我們更多關注能力的復用、團隊的協(xié)作、領域的聚焦、研發(fā)框架的統(tǒng)一和技術資產(chǎn)的沉淀，以上都將成為降本增效和平臺需要解決的關鍵性問題。

基于平臺化的思路，也根據(jù)我們多年對金融行業(yè)應用研發(fā)的理解，我們對應用研發(fā)支撐能力進行了建模，理清了狹義的框架、平臺與應用之間的關系，進一步明確了技術能力建設的方向，框架是承載應用研發(fā)和應用邏輯的核心。

應用開發(fā)人員使用IDE工具，基于框架編寫應用邏輯，與框架共同組成了應用組件的運行版本包。平臺主要提供運行版本包的管理功能，例如運營運維的支持，以及支撐應用運行的業(yè)務領域和技術領域的通用功能。

二、平臺化整體策略及思路

?1、金融企業(yè)系統(tǒng)平臺化的典型歷程

接下來我回顧一下銀行在系統(tǒng)平臺化建設的路徑。

場景的拓展、架構復雜度的提升、應用規(guī)模的增加、新技術的引入和數(shù)據(jù)量的激增都會帶來平臺功能和形態(tài)的演進。從整體的時間線來看，典型銀行在系統(tǒng)平臺化建設的路徑大概分為5個階段。

1）2000年之前，由于系統(tǒng)規(guī)模不大，更多以單體應用為主，系統(tǒng)內(nèi)的復用則更多以公共庫的方式承載。

2）2000～2011年，隨著系統(tǒng)數(shù)量的增加，系統(tǒng)間的協(xié)作需求也增加，但是此時系統(tǒng)內(nèi)部的架構是相對異構的，通過應用集成總線實現(xiàn)異構系統(tǒng)的連接，即可滿足應用之間銜接的需求。

3）2011～2017年，開始建設新一代核心銀行系統(tǒng)，從業(yè)務的流程建模、數(shù)據(jù)建模和產(chǎn)品建模著手，技術上實現(xiàn)了統(tǒng)一的標準規(guī)范。應用采用企業(yè)級統(tǒng)一的標準框架進行研發(fā)，系統(tǒng)內(nèi)部標準的同構也帶來系統(tǒng)間交付的通訊協(xié)議報文規(guī)范的同構。應用之間的交付也不需要再通過統(tǒng)一的應用集成總線的中心化方式進行連接，我們建立了ESB的服務總線，它是一種服務注冊發(fā)現(xiàn)的機制，能夠?qū)崿F(xiàn)直接的通訊進而提升效率。同時，因普通的應用研發(fā)人員和要求趨同，在應用研發(fā)上也實現(xiàn)了人員的互動，提高了效率。

4）2016～2020年，隨著金融科技的出現(xiàn)，開始建設面向不同領域如微服務、大數(shù)據(jù)、人工智能等相關的金融科技平臺，這些平臺也承載了一些相關領域的通用經(jīng)驗。

5）直到2021年，隨著專業(yè)領域的平臺能力相對比較成熟，以及云原生、服務化、多租戶能力的需求，我們開始將各方向的技術能力平臺進行拉通，以技術中臺的方式統(tǒng)一對外進行供給，降低應用研發(fā)人員的門檻，提升研發(fā)的效率。

?2、平臺化落地的整體思路

平臺化落地來自于領導、架構、研發(fā)、運維、運營和支持人員的一些相關需求，他們各自有不同的關注點。

1）從方案入手

在落地的方面，我們更多結合各方的需求，從應用方案入手，拆解出對平臺的需求、研發(fā)的規(guī)范，以保證我們平臺落地的成果能夠?qū)由蠎醚邪l(fā)的需求。

2）問題驅(qū)動

平臺的落地也是問題的驅(qū)動，我們不斷挖掘應用研發(fā)的痛點，將痛點落地到平臺中，提升研發(fā)的效率，降低運行的風險。

3）三態(tài)合一

所謂三態(tài)就是開發(fā)態(tài)、測試態(tài)和運維態(tài)。因為金融行業(yè)開發(fā)和運維需要一定程度的隔離，這種隔離會給敏捷的交互帶來一定的影響，所以在平臺落地時我們要充分考慮這個特點，再結合運維合規(guī)性、穩(wěn)定性的要求，在平臺設計上實現(xiàn)開發(fā)態(tài)、測試態(tài)到運維版本交互流暢的銜接，以提升我們版本交付的效率。

4）流程閉環(huán)

所謂閉環(huán)更多是談到類似于運營的一些能力，因為我們前期在平臺建設時，更多考慮平臺能力的建設，當平臺能力相對成熟和完善時，就面臨大規(guī)模平臺能力的推廣，那么就需要通過運營的手段，從運營平臺上獲取相關的運營數(shù)據(jù)，識別出應用研發(fā)的更多痛點，達到持續(xù)提升平臺能力的目的。

三、金融科技落地實踐

?1、驅(qū)動平臺演進的因素

1）新業(yè)態(tài)

從商業(yè)銀行發(fā)展的階段來看，新業(yè)態(tài)也是驅(qū)動平臺演進非常重要的因素。銀行從以銀行網(wǎng)點為主的1.0狀態(tài)，到經(jīng)歷電子化和電算化的以網(wǎng)點為主、網(wǎng)上銀行為輔的2.0階段，再經(jīng)歷銀行業(yè)務移動化，客戶在任何時間和地點都能享受到銀行服務的3.0階段。目前銀行已經(jīng)進入4.0階段，主要特點就是銀行的服務已經(jīng)無處不在，嵌入到千行百業(yè)，融入到大眾百姓的生活之中，進而導致一些新的需求產(chǎn)生，比如APP的安全和圖片存儲服務等方面的需求，我們也逐步在平臺中豐富和完善這樣的能力。

在原先APP和小程序不多的情況下，我們可能通過手機銀行等比較集中的渠道，在應用層面即可解決一些安全性、數(shù)據(jù)埋點分析和文件服務的問題。但是隨著APP的增多和小程序的出現(xiàn)，我們希望通過平臺化將很多基礎能力沉淀到平臺中，以提升研發(fā)的效率和解決運維的安全問題。

2）企業(yè)架構

企業(yè)架構對平臺的整體演進也產(chǎn)生了較大的影響。《軟件架構模式》一書提到5種軟件架構模式，分別是分層架構模式、基于事件的模式、微內(nèi)核模式、微服務架構，以及基于空間的架構模式。在每一種架構模式上都有一些架構的關鍵要素，基于架構的治理和可視化方面，平臺需要重點考慮這些要素，否則難以較好地承載該架構模式下的架構要素。

典型銀行的平臺化落地也離不開企業(yè)架構視角的變遷。在單體架構的模式下更多的是系統(tǒng)內(nèi)部的公共庫，而像異構的系統(tǒng)集成方面，更多需要提供EAI總線的能力，到了SOA的架構下，需要在平臺層面提供統(tǒng)一的服務目錄和注冊發(fā)現(xiàn)的機制。到了微服務的階段，隨著銀行系統(tǒng)規(guī)模的增大，我們采用一些分布式技術解決高并發(fā)大流量的問題，則出現(xiàn)了單元化等概念，單元化也需要在架構治理和可視化方面對架構予以承載。

到了云原生架構階段，云原生隨著容器、PaaS等技術的出現(xiàn)，帶來了一些新的解決方案，如POD、Service，在架構層面也按照云化的方式，出現(xiàn)了控制面、數(shù)據(jù)面等概念，這些都會對平臺的落地帶來影響，主要體現(xiàn)在以下三方面：

• 一是應用架構流程、項目協(xié)作、系統(tǒng)架構設計變化；
• 二是架構規(guī)范、架構標準固化到框架平臺；
• 三是新架構帶來設計、開發(fā)、測試、運維等開發(fā)過程的影響。

3）云計算技術

云計算技術也驅(qū)動了平臺的演進，從開始的云機房到云就緒，再到現(xiàn)在的云原生，云計算關注的重點逐步向應用靠攏，以應用為中心。我們在平臺的建設上也重點落地了面向金融體的穩(wěn)定應用模型、云原生的基礎組件，以及針對金融級的穩(wěn)定性要求，實現(xiàn)了容器網(wǎng)絡的部分隔離以及跨機房綜合部署的部分能力。隨著架構和云計算的演進我們在平臺上增強了以上功能。

4）敏捷研發(fā)技術

我們的敏捷研發(fā)技術經(jīng)歷了三個階段：

• 第一個階段：2006年左右，我們開始探索引入CI的工具，以解決項目組內(nèi)部局部的編譯打包問題和代碼泄露問題。

• 第二個階段：基于新一代核心銀行數(shù)字化轉型的要求，我們在企業(yè)級項目里更大規(guī)模地使用了DevOps等能力。

• 第三個階段：隨著金融科技戰(zhàn)略TOP 1.0和2.0的建設，我們更加大規(guī)模地將DevOps等能力從項目級提升到了企業(yè)級，以支撐敏捷交付方面的需求。

到去年為止，由于開源技術本身的不可控，我們需要通過平臺的設計進行規(guī)避。而基于針對開源軟件本身，我們也需要通過安全的測試、功能和非功能的完整測試發(fā)現(xiàn)開源軟件的問題，在平臺的設計上進行規(guī)避，在使用平臺通過開源軟件的包裝提供的應用時，我們需要同時提供三方面的能力：

• 一是相關配套的使用規(guī)范、配置規(guī)范和最佳實踐等方面；
• 二是以PaaS化的方式提供針對開源軟件的云化和快速交付；
• 三是開源軟件本身出現(xiàn)問題時，需要提供技術兜底和技術支持方面的能力。

?2、平臺應用效果

在平臺應用中，我們也收到了非常好的效果。通過平臺供給鏈我們可以收集到以下數(shù)據(jù)：典型銀行的代碼倉庫有7000+個，而有1.7萬條CI/CD流水線支撐，覆蓋1400+個系統(tǒng)等，我們平臺的成熟度達到了信通院的優(yōu)秀級。

四、經(jīng)驗和教訓

1）示范應用的總結和尋找

示范應用可以更好地驅(qū)動平臺的發(fā)展。

2）現(xiàn)有流程的銜接

大型企業(yè)的流程非常重要，如果與流程銜接不好，會直接影響到平臺落地的效果。

3）兼容性的設計

一般金融科技的變遷與互聯(lián)網(wǎng)相比時間相對較長，因此兼容性的考慮非常重要，它也會直接影響到平臺落地的效果。

4）技術的研究和工程化的落地并行

在保證平臺的大規(guī)模落地和技術的先進性之間可以找到一個好的平衡點。

5）運維能力的設計

對于穩(wěn)定性方面是必須滿足的要求。

6）針對推廣知識體系的建設

平臺技術的落地從0到1和從1到100有不同的要求。

7）運營體系的建設

可以保證平臺持續(xù)地提升。

以上就是我們在平臺化落地的一些總結，供大家參考。?