銀行IT人在充滿危機感的時代永不言敗

1、 寫給轉(zhuǎn)型陣痛期的銀行 IT 人：在充滿危機感的時代，永不言敗！ | 2020年度策劃 又是一季風(fēng)云幻過，趨勢似乎在遙遠的地方，卻又總是好像隨風(fēng)而至。twt社區(qū)邀請同行中冷靜睿智的觀察者，把他們各自感悟到的崗位趨勢告訴我們，讓每個社區(qū)同行都能知己知彼地度過2020這一年。twt 社區(qū)出品第19期【摘要】分布式與云計算架構(gòu)對于傳統(tǒng)的銀行IT從業(yè)者來說，可以說是一整套復(fù)雜龐大的技術(shù)棧。作者作為一名從傳統(tǒng)集中式架構(gòu)轉(zhuǎn)變?yōu)榉植际郊軜?gòu)的從業(yè)人員，希望借此文談?wù)勛约旱那猩砀惺?，同時希望能夠幫助有志于轉(zhuǎn)向分布式架構(gòu)的傳統(tǒng)崗位同行，對分布式和云計算有提綱挈領(lǐng)的理解，逐步完成從集中式架構(gòu)到分布式架構(gòu)的華麗轉(zhuǎn)身。

2、【作者】杜瑞，現(xiàn)任職于中國民生銀行信息科技部。豐富的分布式架構(gòu)與項目實施經(jīng)驗，參與民生銀行分布式核心系統(tǒng)的整個建設(shè)過程。專注于微服務(wù)、數(shù)據(jù)分布式架構(gòu)與DevOps，對于銀行核心系統(tǒng)向分布式轉(zhuǎn)型有深入的研究。加入民生銀行之前就職于中國惠普有限公司，擔(dān)任技術(shù)顧問職位。1 背景銀行IT系統(tǒng)經(jīng)歷了從總分行數(shù)據(jù)分離，到全行數(shù)據(jù)大集中架構(gòu)，再到基于SOA的服務(wù)化架構(gòu)，目前已經(jīng)走到了基于云計算的分布式架構(gòu)轉(zhuǎn)型的路口。中國金融業(yè)信息技術(shù)“十三五”發(fā)展規(guī)劃指出，金融機構(gòu)主動探索系統(tǒng)架構(gòu)完善升級，繼續(xù)深入研究數(shù)據(jù)中心“雙活”、“多活”模式應(yīng)用。在鞏固集中式架構(gòu)安全穩(wěn)定運行的基礎(chǔ)上，綜合成本、效率、資源等方面，以業(yè)

3、務(wù)適用性為原則，研究分布式架構(gòu)應(yīng)用的可行性。我們可以看到無論是從監(jiān)管指導(dǎo)還是銀行自身實踐，都已經(jīng)有大量的銀行已經(jīng)或者正在進行集中式向分布架構(gòu)甚至云計算架構(gòu)的轉(zhuǎn)型。分布式與云計算架構(gòu)對于傳統(tǒng)的銀行IT從業(yè)者來說，可以說是一整套復(fù)雜龐大的技術(shù)棧。作為一名從傳統(tǒng)集中式架構(gòu)轉(zhuǎn)變?yōu)榉植际郊軜?gòu)的從業(yè)人員，希望借此文談?wù)勛约旱那猩砀惺?，同時借助自己對分布式和云計算的理解，希望能夠幫助對于有志于轉(zhuǎn)向分布式架構(gòu)的傳統(tǒng)崗位同行，對分布式和云計算有提綱挈領(lǐng)的理解，逐步完成從集中式架構(gòu)到分布式架構(gòu)的華麗轉(zhuǎn)身。2 銀行架構(gòu)轉(zhuǎn)型的必然性從集中式架構(gòu)向分布式架構(gòu)轉(zhuǎn)型，可以實現(xiàn)IT系統(tǒng)的“自主掌控、降本增效”。縱觀近幾年尤其

4、是最近的國際環(huán)境，“自主掌控”的必要性已經(jīng)毋庸置疑；而銀行面對外部激烈的競爭，IT系統(tǒng)“降本增效”也顯得日益重要。2.1 應(yīng)對外部競爭帶來的沖擊從當(dāng)前銀行所處的外部環(huán)境來看，互聯(lián)網(wǎng)公司已經(jīng)越來越多的切入金融業(yè)務(wù)，從開始的余額寶到現(xiàn)在的各種支付方式、以及場景化金融等等。傳統(tǒng)銀行為了適應(yīng)這個沖擊也都很迅速的跟進，從各個直銷銀行到場景化金融，金融場景越來越互聯(lián)網(wǎng)化，對于銀行IT系統(tǒng)提出了新的要求：“如何解決三個海量問題：海量客戶、海量賬戶、海量交易”。顯然，傳統(tǒng)集中式架構(gòu)在應(yīng)對三個海量問題方面捉襟見肘，采用分布式架構(gòu)是業(yè)務(wù)發(fā)展的必然選擇。另外，從當(dāng)前國際大環(huán)境和監(jiān)管指導(dǎo)來看，基于國產(chǎn)化或開源軟件、采

5、用x86服務(wù)器的分布式架構(gòu)在自主掌控、知識產(chǎn)權(quán)保護方面有著天然優(yōu)勢。2.2內(nèi)部降本增效提升競爭力銀行業(yè)已經(jīng)過了日進斗金、躺著賺錢的年代，迫于經(jīng)營壓力也需要后臺部門降本生效。相對于集中式架構(gòu)需要采購商業(yè)軟件、價格昂貴的大型機、小型機等硬件，分布式與云計算架構(gòu)通?？梢曰陂_源軟件、廉價的x86服務(wù)器，大幅降低IT采購成本。同時，采用云計算之后，應(yīng)用開發(fā)部署涉及到基礎(chǔ)環(huán)境準(zhǔn)備時間將會大大縮短，甚至可以做到開箱即用、沒有等待期，極大提升IT系統(tǒng)研發(fā)效率，更好的服務(wù)企業(yè)業(yè)務(wù)發(fā)展需求。3 集中式架構(gòu)向分布式架構(gòu)演化路徑The art of scalability一書中，提出了一個系統(tǒng)擴展模型（scale

6、cube），描述了分布式系統(tǒng)彈性擴展的三個維度：X軸：代表運行多個負載均衡器之后運行的實例，即通過應(yīng)用服務(wù)器集群提供系統(tǒng)的處理能力和可用性，但數(shù)據(jù)庫層面不支持水平擴展；Y軸：應(yīng)用功能分解，將應(yīng)用層和數(shù)據(jù)模型層的垂直切分，實現(xiàn)微服務(wù)架構(gòu)。各應(yīng)用可以獨立的進行水平擴展，單一應(yīng)用內(nèi)部數(shù)據(jù)庫層面仍然無法實現(xiàn)水平擴展；Z軸：數(shù)據(jù)分片，對應(yīng)用內(nèi)的數(shù)據(jù)進行分庫分表，實現(xiàn)數(shù)據(jù)庫層面的水平擴展。這三個維度的劃分，在一定意義上也代表了一個單體系統(tǒng)向分布式系統(tǒng)演進的一個路徑：第一階段：單體應(yīng)用，通過應(yīng)用服務(wù)器集群來提高系統(tǒng)的可用性，支持應(yīng)用層級的彈性擴展。但是，隨著數(shù)據(jù)量的不斷增大，開發(fā)人員已經(jīng)使用了緩存、讀寫分離

7、等策略，仍然會達到單一數(shù)據(jù)庫集群處理能力瓶頸，無論再怎么增加應(yīng)用服務(wù)器都無法提高系統(tǒng)的處理能力，這是系統(tǒng)往往會演進到第二階段；第二階段：微服務(wù)應(yīng)用，應(yīng)用和數(shù)據(jù)庫按照業(yè)務(wù)領(lǐng)域獨立部署，形成多個微服務(wù)應(yīng)用集群。該階段一定程度上緩解了系統(tǒng)壓力，能夠提供更好的性能；同時，各微服務(wù)應(yīng)用之間相互獨立部署，在交付周期和故障隔離方面能夠提供更高的靈活性。但是，每個微服務(wù)應(yīng)用由于還是使用單一數(shù)據(jù)集群，在系統(tǒng)的容量、高并發(fā)等方面，存在著無法逾越的瓶頸；第三階段：數(shù)據(jù)分布式，領(lǐng)域數(shù)據(jù)庫進行分庫分表或者讀寫分離，在數(shù)據(jù)庫層面提供水平擴展能力?；跀?shù)據(jù)的分布式，可以有效的解決數(shù)據(jù)庫瓶頸問題，讓系統(tǒng)處理能力形成進步一的提

8、升；第四階段：采用邏輯數(shù)據(jù)中心設(shè)計來實現(xiàn)系統(tǒng)容量的無線擴容，并同時保持恒定的交易響應(yīng)時間。輯數(shù)據(jù)中心的含義是：對物理數(shù)據(jù)中心進行邏輯上的劃分，每個邏輯數(shù)據(jù)中心相互獨立；每個邏輯數(shù)據(jù)中心部署相同的應(yīng)用，但應(yīng)用數(shù)據(jù)庫通過分庫分表之后均勻分布在每個邏輯數(shù)據(jù)中心中；每個客戶的交易請求只會在一個邏輯數(shù)據(jù)中心內(nèi)處理。由于每個邏輯數(shù)據(jù)中心里可以穩(wěn)定支撐固定數(shù)量的客戶交易請求，當(dāng)系統(tǒng)容量達到上限時，可以通過增加新的邏輯分區(qū)實現(xiàn)系統(tǒng)容量的提升，滿足更大的數(shù)據(jù)量、更高的并發(fā)量。在完成分布式架構(gòu)轉(zhuǎn)型的過程中，相關(guān)的DevOps配套設(shè)施也必須同步建設(shè)完成；與此同時，云原生和云計算已經(jīng)變得炙手可熱，Docker容器和K

9、8S的使用也是我們需要掌握的必備技能。4 銀行IT研發(fā)崗位面臨的新挑戰(zhàn)作為一名從集中式架構(gòu)轉(zhuǎn)型為分布式架構(gòu)的IT開發(fā)人員，從我自身感受看來，轉(zhuǎn)型面臨的困難主要表現(xiàn)在以下幾個方面：多：需要掌握的技術(shù)棧激增。從集中式架構(gòu)下，只需要掌握一門開發(fā)語言（如Java），數(shù)據(jù)庫使用（如DB2、Oracle）和Web容器（weblogic、tomcat），轉(zhuǎn)變?yōu)樵诜植际郊軜?gòu)下，需要從分布式的理論、微服務(wù)架構(gòu)、數(shù)據(jù)分布式、DevOps、容器與K8S等多個方面的技能領(lǐng)域；而在每一個領(lǐng)域下又有眾多的細分技能點（例如微服務(wù)架構(gòu)就包含了微服務(wù)網(wǎng)關(guān)、RPC服務(wù)框架、注冊中心、配置中心、服務(wù)跟蹤等多個必須的技術(shù)組件）。同時

10、，分布式涉及到的技術(shù)棧中，通常采用的是JAVA語言，但也會涉及到GO、C和Scala等各種語言。對于技術(shù)平臺、應(yīng)用開發(fā)和系統(tǒng)運維方面的不同崗位，需要結(jié)合自己崗位的特點，有針對性的進行學(xué)習(xí)?？欤杭夹g(shù)更新迭代快，需具備快速與持續(xù)學(xué)習(xí)能力。由于多采用開源技術(shù)，兼受益于近年來分布式技術(shù)的快速發(fā)展，各個領(lǐng)域、各種技術(shù)迭代飛速、層出不窮。往往是剛剛研究完微服務(wù)又出現(xiàn)了云原生，剛看完Swarm風(fēng)向又轉(zhuǎn)向了K8S。對于開發(fā)人員學(xué)習(xí)強度大，疲于應(yīng)付。難：開發(fā)難、運維難。對于應(yīng)用研發(fā)人員，應(yīng)用微服務(wù)改造，如何切分合適的微服務(wù)粒度；數(shù)據(jù)分布式存儲，采用何種分布式策略、如何處理分布式事務(wù)、如何進行數(shù)據(jù)分布式之后的匯聚

11、查詢，都需要精心設(shè)計。對于系統(tǒng)運維人員，除了需要學(xué)習(xí)分布式相關(guān)知識，還需要掌握如何運維大規(guī)模應(yīng)用和數(shù)據(jù)庫集群；如何形成完善的服務(wù)治理體系以應(yīng)對復(fù)雜的服務(wù)調(diào)用，出現(xiàn)服務(wù)調(diào)用問題是如何快速定位故障。5 轉(zhuǎn)變心態(tài)，充實自我，擁抱變化面對技術(shù)的快速變更，IT從業(yè)者唯一的不變就是變，時刻保持一顆持續(xù)學(xué)習(xí)的心?；畹嚼蠈W(xué)到老，對于IT從業(yè)者來說太適合不過。那么，如果需要向分布式與計算架構(gòu)轉(zhuǎn)型，我們需要學(xué)習(xí)哪些方面的知識來不斷提升我們自己呢？本節(jié)主要對分布式技術(shù)進行提綱挈領(lǐng)的介紹，希望能給大家有所幫助。5.1應(yīng)用微服務(wù)架構(gòu)現(xiàn)階段，大多數(shù)銀行已經(jīng)完成IT架構(gòu)SOA化轉(zhuǎn)型，在已經(jīng)實現(xiàn)IT系統(tǒng)服務(wù)化的情況下，微服務(wù)

12、架構(gòu)能給銀行帶來什么好處，我想主要可以歸納為以下幾點：更快：敏捷迭代，快速響應(yīng)業(yè)務(wù)需求；更穩(wěn)：故障隔離，業(yè)務(wù)連續(xù)性高；更省：按需擴容，資源利用率高。目前業(yè)界主流的微服務(wù)架構(gòu)主要有以下幾個流派，各自起源與發(fā)展側(cè)重點各不相同：Spring Cloud：Spring生態(tài)圈面向微服務(wù)架構(gòu)的開源框架，涵蓋了微服務(wù)架構(gòu)中必須的注冊中心、配置管理、服務(wù)調(diào)用跟蹤等主要組件；Dubbo生態(tài)圈：阿里巴巴開源的微服務(wù)框架，目前已經(jīng)以“Spring Cloud Alibaba”的方式融入了SpringCloud生態(tài)圈；其提供的dubbo、nacos、Sentinel等組件已經(jīng)有廣泛的應(yīng)用，面向微服務(wù)體系下分布式一致性

13、的Seata也在快速發(fā)展；SOFAStack：螞蟻金服開源的微服務(wù)框架，有其獨立的RPC、服務(wù)注冊、服務(wù)跟蹤等組件。由于直接來源于金融行業(yè)，其宣傳的特點是一套用于快速構(gòu)建金融級云原生架構(gòu)的中間件，也是在金融場景里錘煉出來的最佳實踐。就目前實際使用情況來看，國內(nèi)企業(yè)使用Dubbo起步早、應(yīng)用廣泛，加之現(xiàn)在也積極融入Spring Cloud生態(tài)圈，可以重點關(guān)注。5.2 分布式數(shù)據(jù)訪問中間件與分布式數(shù)據(jù)庫數(shù)據(jù)分布式涉及到兩種不同類型的實現(xiàn)邏輯：基于中間件+傳統(tǒng)關(guān)系型數(shù)據(jù)庫的實現(xiàn)方式、基于新興的分布式數(shù)據(jù)庫（例如OceanBase等）。兩種實現(xiàn)方式各有優(yōu)勢：自主掌控能力：中間件+關(guān)系型數(shù)據(jù)庫模式對于企

14、業(yè)的技術(shù)儲備要求低，在傳統(tǒng)關(guān)系型數(shù)據(jù)庫的基礎(chǔ)上，只需在對數(shù)據(jù)訪問中間件有深入的研究即可，通常只需投入一兩人即可實現(xiàn)源碼級掌控；而分布式數(shù)據(jù)庫涉及到復(fù)雜的分布式理論、一致性算法等技術(shù)，作為使用方很難做到自主掌控，對廠商的依賴較重；使用復(fù)雜度：分布式數(shù)據(jù)庫在底層對分布式事務(wù)、跨數(shù)據(jù)分片查詢等提供了天然的支持，應(yīng)用在使用時無需考慮太多的限制，使用簡單；而中間件模式則需要自行處理相關(guān)跨分片的場景。5.2.1 數(shù)據(jù)訪問中間件第一種基于中間件+傳統(tǒng)關(guān)系型數(shù)據(jù)庫方式，具體實現(xiàn)原理如下：1.數(shù)據(jù)存儲：采用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫（例如：Mysql、Oracle等），按照一定的策略對數(shù)據(jù)進行分庫分表或讀寫分離存儲；2

15、.數(shù)據(jù)訪問：通過數(shù)據(jù)訪問中間件屏蔽底層數(shù)據(jù)庫分布式存儲策略，應(yīng)用開發(fā)人員還可以使用傳統(tǒng)ORM工具訪問數(shù)據(jù)庫，分庫分表等策略對應(yīng)用開發(fā)人員透明。常見的中間件分為兩種類型：SDK和獨立代理模式。SDK模式中間件，使用廣泛的開源組件有Apache ShardingSphere，阿里的TDDL等。SDK模式的優(yōu)點是與應(yīng)用一起部署，應(yīng)用之間連接數(shù)據(jù)，沒有中間代理環(huán)節(jié)，效率與可用性都高；缺點是各種語言的SDK需要重復(fù)編寫（目前大部分只支持Java），對應(yīng)用有一定的侵入性。獨立代理模式中間件，典型的有MyCat和DRDS。該模式支持?jǐn)?shù)據(jù)庫原生協(xié)議，跨語言，跨平臺；應(yīng)用在使用時只需要將原先的數(shù)據(jù)庫鏈接，直接修

16、改為代理提供的數(shù)據(jù)庫鏈接即可。該模式的缺點一方面是應(yīng)用與數(shù)據(jù)之間添加了一個代理中間環(huán)節(jié)，性能會有一定的下降；另一方面是需要充分考慮代理服務(wù)器的高可用，避免因為代理服務(wù)器故障導(dǎo)致應(yīng)用無法訪問數(shù)據(jù)庫。5.2.2 分布式數(shù)據(jù)庫隨著阿里OceanBase的崛起，分布式數(shù)據(jù)庫也迅速進入人們的視野。最早的分布式數(shù)據(jù)庫是Google Spanner，而國內(nèi)則有阿里的OceanBase、PingCAP的TiDB、華為的GaussDB和中興的GoldenDB等。國產(chǎn)的幾個分布式數(shù)據(jù)庫在銀行業(yè)都有一定的應(yīng)用，可以重點關(guān)注大廠出品的產(chǎn)品。5.3 DevOps在分布式架構(gòu)下，DevOps成為了一個必不可少的基礎(chǔ)平臺，

17、貫穿了從開發(fā)的代碼管理、持續(xù)集成、持續(xù)發(fā)布，到運維的監(jiān)控、告警等方方面面。5.3.1 開發(fā)從開發(fā)視角來看，應(yīng)用微服務(wù)化之后會有大量的應(yīng)用出現(xiàn)，每個應(yīng)用都應(yīng)有自己獨立代碼倉庫；而應(yīng)用的編譯、集成、單元測試和打包都需要DevOps平臺提供流水線支持。對于應(yīng)用代碼的管理，可以使用成熟的SVN或GitLab，而對于應(yīng)用的從編譯到發(fā)布的整個流程，可以基于開源的Jenkins進行定制化開發(fā)，形成符合企業(yè)自己需求的工具、規(guī)范和流程。5.3.2 運維從運維視角來看，將面臨更加巨大的挑戰(zhàn)：多：應(yīng)用集群和數(shù)據(jù)庫規(guī)模呈指數(shù)級增長，發(fā)布、維護工作量劇增；亂：應(yīng)用間服務(wù)調(diào)用關(guān)系縱橫交錯，服務(wù)治理難度增加；難：一次交易請

18、求經(jīng)過多個服務(wù)調(diào)用，出現(xiàn)故障排查困難；數(shù)據(jù)分布式之后，快速查詢到數(shù)據(jù)困難。那么，在分布式架構(gòu)運維方面，我覺得最重要的一個字就是“合”。運維人員看到的是各個視角的合集：配置管理：獨立于應(yīng)用部署包的應(yīng)用配置管理，便于統(tǒng)一的配置管理和配置變更即時推送，可以參考阿里開源的Nacos、攜程的Apollo和百度的Disconf等；數(shù)據(jù)查詢：對于分布式存儲之后的數(shù)據(jù)，能夠提供一個便捷的跨分片數(shù)據(jù)查詢工具；主機管理與應(yīng)用發(fā)布：集中的應(yīng)用部署主機管理和統(tǒng)一的應(yīng)用發(fā)布管理，能夠快速的完成大規(guī)模應(yīng)用發(fā)布；服務(wù)調(diào)用：展示從服務(wù)入口到微服務(wù)之間相互調(diào)用、調(diào)用數(shù)據(jù)庫、調(diào)用緩存等所有產(chǎn)生分布式調(diào)用、甚至應(yīng)用內(nèi)部調(diào)用的完整調(diào)

19、用鏈路。服務(wù)鏈路跟蹤起源于Google的Dapper論文，目前已經(jīng)形成OpenTracing規(guī)范，可以關(guān)注大量優(yōu)秀的開源實現(xiàn)，如zipkin、Skywalking、Jaeger等；日志：大量應(yīng)用節(jié)點產(chǎn)生的海量日志，需要通過ELK等工具匯聚起來，供運維人員方便快捷的查看；監(jiān)控：這里說的監(jiān)控主要是指Metrics，通過Metrics可以洞察到應(yīng)用運行的每個細節(jié)，如JVM情況、CPU、數(shù)據(jù)庫連接池、請求處理情況等?？梢躁P(guān)注CNCF的Promethues和Grafana，很好很強大。5.4容器與K8S提到分布式與云計算，Docker容器和K8s是必須了解的內(nèi)容。自Docker問世以來，圍繞容器服務(wù)編排就出現(xiàn)了Mesos、Swarm和K8S三雄鼎立的局面。隨著CNCF的強勢崛起，最終K8S一統(tǒng)天下，成為了事實上的標(biāo)準(zhǔn)。當(dāng)前互聯(lián)網(wǎng)大廠已經(jīng)廣泛的采用了K8S，并在其上通過ServiceMesh技術(shù)（ISTIO等）開始向云原生架構(gòu)進行演進。而在銀行業(yè)內(nèi)的使用情況來看，K8S已經(jīng)進入了實質(zhì)性的應(yīng)用階段，ServiceMesh技術(shù)則處在一個觀望期，并沒有太多實際的落地案例。對于傳統(tǒng)運維崗位的人員來說，K8S幾乎已經(jīng)是一個必須掌握的技能，而對于技術(shù)平臺與應(yīng)用研發(fā)人員來說，如何適配K8