雖然今天一提起IT，很多人首先想到的是互聯網。其實，銀行是IT技術的首批重度用戶之一，也因此，銀行有大量的遺留系統，有些“恐龍級”系統甚至有超過30年的歷史。所以，銀行系統給人的刻板印象總是老舊、臃腫、用戶體驗差。

一、遺留系統的問題

遺留系統經歷了很多代人在上面“添磚加瓦”，其代碼早已經是一團亂麻。維護難，變更成本高。

1、強監管導致開發求穩

銀行是一個強監管、不允許出錯的行業，長期以來，其系統設計、開發節奏的原則就是求穩，快速應變一向不是傳統銀行系統要考慮的事情，這些特性也深深根植在遺留系統中。

但是面對快速變化的市場環境和業務需求，特別是互聯網金融的沖擊，近年來，銀行也要探討如何更敏捷地交付和實現DevOps。這些遺留系統顯然不能適應新時代的要求。

2、難以一次性替代遺留系統

然而，要一次性替代遺留系統又談何容易呢?由于系統已經深深根植在銀行的生態中，每個系統和周邊系統都有千絲萬縷的關系，剪不斷理還亂。

3、數據遷移緩慢

數據遷移也是一件頭疼的事情。我們其中一塊業務要把原來的系統替換掉，光是數據遷移就花了兩年的時間，而這個項目我們原本的計劃的時間是一年，也就是說，它實際延期了整整一倍的時間，成本也大大超出預算。這種現象幾乎發生在所有銀行系統的升級、替代項目中。因此遺留系統的替代成本很高，也蘊藏著巨大的風險。

4、員工成就感不高

對于員工來說，外面的世界都在談論微服務、互聯網，甚至是人工智能、區塊鏈等新技術，而長期維護這些系統的IT工程師完全沒有機會接觸到這些新技術，他們很容易感覺到自己與外面的世界完全脫節，工作成就感不高，對公司來說，也不利于人才培養和團隊穩定。

5、系統間交互重度依賴落地文件

除了以上問題，我們的系統間交互重度依賴落地文件。每一個落地文件除了要滿足對方的數據要求外，還要完全匹配格式的要求，這就導致每當需要一個新的接口文件時，都可能需要進行定制化開發，成本高，周期長。特別是要和其他外部客戶進行數據對接時，這樣的定制化開發導致我們接入新客戶的周期變長，影響了業務開展的時間，錯失市場機會。

在我們的一個項目中，我們的系統需要和20多家臺灣的托管銀行進行數據對接，其實大家所需要的數據都差不多，但是因為沒有統一的文件格式，我們不得不為每一家托管銀行開發落地文件接口。因此，我們的業務也在推動客戶通過API和我們交互數據。API的好處是，我們只需要滿足對方所需要的數據，如何“消費”數據完全由對方自己處理，實現了解耦。

二、解決方案

在這個契機下，我們產生了通過在遺留核心系統外圍搭建自主研發的API微服務系統的思路：

• 一方面可以加快接入新客戶的進程;
• 另一方面可以逐步降低對遺留系統的依賴，并借此機會讓我們的IT工程師接觸和掌握***的微服務技術和框架。

由于是全新系統，我們采納了***Spring Cloud全家桶和Spring Boot框架：

• Spring Cloud提供了微服務網關所需要的所有組件，如路由、服務注冊、熔斷、配置中心等。
• Spring Boot具有“開箱即用”的特性和大量強大的Starter組件，大大加快了開發微服務應用的速度。

同時，我們也利用其它***的開源框架如ELK做分布式日志跟蹤、Grafana做服務監控、Zipkin可視化請求訪問鏈路等，實現了系統的現代化。

我們采納微服務架構是為了實現DevOps，而在API開發過程中，我們采用了大量DevOps工具棧實現持續交付。

• 基于Spring Cloud Contract的契約測試解耦上下游開發——通過契約，我們作為API提供者與API消費者在開發前就約定了對接口的期望，這樣雙方不必等對方都完成了開發才能進行集成測試，而是可以圍繞契約按照自己的步伐進行開發和測試;
• 通過FitNesse實現驗收條件驅動開發——與業務人員在需求階段把具體的驗收條件確定下來，并通過FitNesse的文檔固化下來，然后編寫相應的測試代碼把驗收測試自動化，成為持續集成的一部分。實現了交付的閉環;
• 通過Ansible實現自動化部署和基礎設施即代碼，實現快速部署。

由于數據全部來自遺留系統的數據庫，而遺留系統的數據結構也非常復雜，比如獲取基金信息，背后可能需要整合幾十個數據表。

我們通過設計領域模型對系統能提供的數據進行了抽象，形成領域模型，并以此劃分微服務應用的邊界，使每個微服務應用可以提供一個獨立的領域數據，確保服務的隔離性。

按照目前的設計，我們將提供基金、投資者、銷售機構、交易數據等的領域數據，并整合到銀行的API商店服務外部客戶。

通過微服務架構，整個系統的伸縮性也得到了保證，當某些服務需要更多資源時，如交易數據服務，其數據量大，請求頻繁，我們可以根據流量，通過部署多個交易數據微服務應用來進行橫向容量擴展。

我們也在研究系統上云的可行性，云部署將為我們提供更好的彈性和一步到位的容器化解決方案，降低運維的難度并提高可靠性。

三、從想法到現實

我們有了思路和想法，但是要使它得到認可并變成現實需要經歷一個反復溝通的過程。我們的架構設計需要得到架構委員會的評審和認可，在可行性、災備、技術棧上都要考慮周全。

繼而我們也請了一些不了解我們業務和系統的外部專家來進行評審，我們要說服這些“外人”明白我們想做什么、怎么做以及為什么要做，這樣也能讓這些專家提出一些我們未考慮到的點。

然后我們要和其他要做API的部門開展API工作坊，確保大家在網關、技術棧、安全機制上有統一的規范，將來實現更好的融合。

而最最重要的是，我們目前還是基于項目立項的，沒有單獨為產品立項的機制，所以要把這個產品做出來，還需要尋找一個合適的項目，通過項目實施把它實現出來。經歷了半年的歷程，我們的想法已經成為目前某個重要項目的實施過程。

四、總結

大量遺留系統是銀行普遍的痛點，我們通過在遺留系統外圍搭建自主研發的微服務系統來逐步降低對遺留系統的依賴。

系統間交互重度依賴落地文件，我們通過用API取代落地文件來解耦上下游的開發依賴。

通過這些手段，我們將加快接入新客戶的進程，也會提升自身的敏捷性，創造更多讓員工接觸、掌握***技術的機會，實現銀行系統的現代化，更好地適應快速變化的市場環境和業務需求。

以上是我關于銀行遺留系統痛點的分享，后續我將著重解析基金服務API微服務系統的構建過程與技術實現，歡迎大家持續關注，有想要了解的內容也可留言告訴我。