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