90年代初期國內銀行業蓬勃發展，早期各個分行都是人工記賬，定期由省分行統壹報送總行系統，隨著國內經濟的快速發展，銀行的業務量也隨之暴漲這樣的工作模式已經無法滿足需求了，所以90年代初4大國有銀行都紛紛加強科技部的研發投入，參考美國、英國銀行系統建設經驗開始建設現代化銀行系統，其實在那個年代大家對計算機的印象還非常陌生，在每個櫃面都架設計算機，當時的櫃面系統都是統壹的命令行模式，沒有可視化界面，後臺系統采用的是集中式的架構，如下圖所示：
當時的銀行系統基本都是這樣的集中式架構，大型國有銀行壹般也都是這種簡單架構，當時大部分行業的系統也都是這樣的架構。在這樣的架構下櫃面前端和後端系統采用的是CS架構，胖客戶端的模式，每次客戶端升級都需要將安裝包提前壹天下發給各個網點，現在看起來還是比較low的。銀行後端是大核心的模式，即核心系統承擔了主要的功能，賬戶、存貸款、總賬、對賬、支付、來賬等功能都在集中式的大核心系統中，只有很少的壹部分功能被剝離出核心系統，歸屬於外圍系統。這些外圍系統壹般都是市面上有壹些軟件公司提供了現成的產品，只需要簡單的二次開發就可以滿足需求，這樣壹方面降低了開發成本，另壹方面也加快的系統實施的進度。但是這種架構的系統承載能力還是比較有限的，隨著交易量的快速上升很快就滿足不了需求了，聽行裏的前輩介紹當年的場景，就是他們科技部每天都很忙，交易量每個月都會有大幅增長，每個季度的計息日批量和年底的年終決算都會讓所有人忙通宵，這些記憶也成為了所有那個年代銀行人痛苦的回憶。
集中式的系統已經逐漸滿足不了高速增長的業務需求了，所以規模比較大的國有銀行就開始考慮將現有的總行集中式系統分別在各個省分行分別都部署壹套，每天晚上再通過批量的方式將各省數據進行集中，這種架構的方式能夠最快的解決聯機性能問題，但是又會引發新的問題，那就是跨省轉賬交易無法實時到賬，就算是同壹家銀行的跨省轉賬壹般也無法做到。所以90年代中後期的系統架構圖如下圖所示：
看圖就可以發現，和之前的架構區別主要就是將總行集中式的部署架構調整為了各省分布式的架構，但是這種分布式架構並不是我們現在討論的互聯網分布式架構，當年還沒有比較成熟的分布式架構方案，所以當時的分布式其實只是簡單的將原先總行部署的壹套核心系統和配套的外圍系統分別在各省科技部分別部署，分別獨立運維，就好像機構在整體行政關系上是壹體的，但是實際科技系統是分開的，沒有必然的聯系，只是每天會進行數據交換來實現跨省轉賬、票據承兌等業務，所以很多銀行業務的效率比較低，很難滿足壹些比較急迫的客戶需求，最後出現了壹些現象就是壹個客戶為了給壹個跨省的客戶匯款，最快的手段是先用自己本地的卡取現金，再人肉帶到異地，有朋友要問了為什麽不到當地再取，因為那個年代跨省取現不但取現時間、金額受限制還有高額的手續費。
2000年互聯網高速發展，銀行的科技水平也在這幾年中高速發展，各家行的水平也逐漸拉開了差距，之前老的各省分布式部署的業務問題也漸漸凸顯，由工行率先將之前分布式部署的省行系統進行總行上收，系統上收可不是那麽簡單，當年為什麽要各省分別部署？就是因為集中式系統架構已經無法承載每天高速發展的業務量，如果再將各省的數據上收，那就意味著可能每天核心批量還沒跑完還沒來得及分發給外圍系統就已經到第二天開門營業時間了。這麽做科技部門需要承擔的壓力還是非常大的，需要解決很多問題，主要有以下問題：1）數據結構統壹，數據映射，各省數據上收，數據遷移；2）新系統開發工作；3）系統上收對上收省份日常業務的影響；4）分行員工新系統的培訓工作；5）新舊系統的平滑遷移，新舊系統的日常兼容性交互；6）整體的投產遷移方案、回退方案。我當時在中國銀行也有幸經歷了這壹過程，整個過程持續了快4年，從整體的方案設計到系統的實施再到後面的系統遷移上線等等壹系列工作，這個過程是艱難的，基本上加班成為常態，但是在這個過程中也學到了很多東西，也是成長比較快的壹個時期。整個改造的壹個核心架構思路就是對核心系統進行瘦身，將核心系統精簡化，以此來提高核心系統的業務處理吞吐量，並采購最新的大型機來保證處理性能和IO性能，將大部分的業務都單建系統拆離出核心系統，基本上這樣的整體架構在當時評估的時候能保證未來10－20年的業務發展量。下圖為當時的整體架構圖，但是從這個架構圖中可以發現，整體架構核心系統和外圍系統，再和渠道系統之間都是非常混亂的，系統間是完全的網狀結構，圖裏還沒有完全畫完，因為畫完以後基本是沒辦法看的，非常復雜的蜘蛛網。有個別系統因為是外包采購的系統的報文結構和其他系統都是不壹樣的，這樣壹旦某個系統要和這些奇葩系統進行對接就會遇到這樣的問題，需要把這些奇葩接口的報文全部處理壹遍，這就導致了很多重復的工作。
大部分銀行很快就意識到這種集中式網狀架構的缺陷，當時也正好流行ESB總線架構，所以銀行系統也不免俗的紛紛去實現ESB總線。總線架構就是在渠道系統和核心、外圍系統之間建立了壹個ESB總線橋梁，所有的外圍和核心系統的接口都註冊發布到ESB總線上，由總線對外提供完全統壹的接口標準協議，這樣就避免了每個系統接入都是同壹套標準接口，不用重復去實現不同的報文協議。這樣的架構看起來就非常清爽了，不管是渠道系統還是外圍系統調用各個系統的接口的時候都比較方便。這樣的架構在銀行系統中實施了很長時間，包括目前大部分的銀行還都是采用這種架構模式，雖然現在看起來非常普通，但是當時看起來此種架構還是非常完美的。而且這種架構對於中小銀行就算現在使用起來也是非常合適的。
隨著互聯網的發展網上銀行、手機銀行、直銷銀行紛紛成為新的渠道，人們也開始快速接受這種新興的互聯網渠道，互聯網總線架構和之前架構的最大差別在於安全架構，後面會再單獨寫兩篇關於安全的文章。其他方面的架構基本沒什麽變化，但是會發現壹種現象就是，因為核心系統不新增大功能的情況下，不斷新增外圍新產品，當時中國銀行壹***有壹百多個外圍系統，還沒算壹些快下線的系統。隨著業務量的不斷上升，核心系統的業務量不斷上升，總線的壓力也逐漸上升，總線機器不斷的橫向水平擴展，在走之前總線的集群就擴展到了100個節點。
到了2012年以後隨著facebook、amazon開放平臺獲得的巨大成功，BAT都逐步將自己的接口開放出來，都實施了開放平臺生態圈戰略，從而推動了SOA服務化的更快速發展。銀行之前也壹直在研究服務化的實施方案，但是由於ESB總線架構運轉的非常穩定，也沒出什麽問題，所以導致各個行進行服務化改造的動力不是很強，而且這種整體架構的調整涉及到的部門和業務影響都是非常大的，壹般銀行這樣比較穩妥的公司也都不敢有大的動作。我也是有幸在銀行趕上了中國銀行試點互聯網金融，對新建的互聯網金融系統實施服務化架構，下面就是當時中國銀行的互聯網金融服務架構，這個架構其實是壹個傳統銀行互聯網金融的壹個妥協架構。
從架構圖中可以看到，左邊是之前的傳統銀行集中式總線架構，右邊是互聯網服務化架構，包含了開放平臺、服務註冊和發現、服務化產品系統。為什麽這樣設計，這是因為傳統銀行的各個產品系統是比較穩定的，而且在銀行系統待過的同學都知道傳統銀行要新建壹個系統或者新實施壹個需求都是要經過很長的周期，傳統銀行都是瀑布式開發方式，各種評審、審批流程，導致從需求提出到功能上線基本上3個月過去了，效率還是挺低下的。根本滿足不了互聯網金融快速叠代的需求，因為當時我們不但試點新的soa架構，同時也在試點叠代開發，所以將互聯網金融產品單獨排期實施，單獨部署，產品系統如果涉及到調用傳統銀行產品接口的地方全部通過ESB總線來調用傳統銀行產品系統接口。所有的互聯網金融產品系統全部將接口服務化註冊到服務註冊中心，當時我們所有的互聯網金融產品系統全部基於阿裏的dubbo開發，系統將接口都註冊到zookeeper上，兩個系統直接的服務交互采用RPC模式；通過開放平臺對外提供接口暴露，可以發現這種架構在保障傳統銀行系統穩定性的同時也可以滿足互金需求的快速叠代實施，並且也使用了新興的互聯網分布式技術，來降低開發和運維的成本，目前我了解到的很多銀行都在采用這種架構在實施互聯網金融業務。
最近兩年隨著容器技術的不斷發展，私有雲平臺、devops也逐漸在銀行系統中進行試點，目前我所在的壹家小型民營銀行正在進行這方面的技術試點，底層采用docker進行鏡像管理、構建、發布，在系統層面全部采用服務化架構，目前我們使用的是springcloud整體的解決方案。這樣的架構看起來也是比較清晰，而且擴展性也很強，能夠很好的滿足未來業務發展的需求，隨著docker技術的不斷成熟，後續的devops也是逐漸會替代大部分的人工運維，之前我待過的壹家互聯網電商，80多個產品系統只有3個運維人員，所有的日常監控、版本部署都是自動化的，基本不需要人工幹預，這種模式也是後續銀行需要的壹種開發和運維的方式。
今天只是大概介紹了下銀行系統的歷史變遷，真的只是非常簡單的介紹，其實每個架構都有很多故事，都可以寫很多，等到後續有時間會再把其中發生的很多細節寫給大家看：）