??2018年12月5日，由金融科技創(chuàng)新聯(lián)盟、交通銀行、中國建設銀行、華為科技有限公司聯(lián)合主辦的金融分布式架構技術研討會在交通銀行成功舉辦。
研討會上，民生銀行信息科技部資深專家黎育龍進行了題為“中國民生銀行分布式建設實踐”的主題發(fā)言。
首先非常感謝張總、江秘書長、伊總能夠給我這個機會匯報一下中國民生銀行在分布式架構上做的一些工作。
我分兩部分跟大家匯報一下：第一，民生銀行在分布式建設方面的成效；第二，分布式技術的交流。
為什么我要先和大家介紹一下分布式介紹的成效呢？今天上午建信金融的邢磊也講了業(yè)務驅動技術變革的背景，民生銀行的核心系統(tǒng)用的是德國SAP系統(tǒng)，SAP系統(tǒng)原來是ERP里的核心系統(tǒng)，并不是存款產品。當時民生銀行在做新一代的時候選了這個系統(tǒng)，但目前來看突出了很多問題，比如說在容量和交易量的增長上，在硬件成本上持續(xù)上升，授權費用特別高等問題。
SAP是傳統(tǒng)集中式架構，沒有擴展性的，數(shù)據(jù)庫是單點的結構，是基于DB HA架構，總體來說性能達到了瓶頸。國內大部分銀行都有這樣的問題，我們的交易量是全世界第一的，我們作為SAP核心系統(tǒng)的客戶也是這樣，我們面臨的很多問題在他們德國實驗室也是第一次面臨，所以很多問題需要優(yōu)化時都要提到德國開發(fā)中心去，流轉流程特別長，根本達不到交付的要求。我們自己后面也培養(yǎng)了很多SAP的專家，但是跟我們的期望差距還很大，并且技術是封閉的找不到人，基于這些壓力我們覺得要把核心系統(tǒng)重新做。
在2018年1月份時存款核心上線了，分布式改造上線對我們來說意義很大，實現(xiàn)了民生銀行技術架構的轉型，全行都向分布式架構轉進。通過此也沉淀了分布式技術體系、架構規(guī)范、分布式設定模式，用于支撐全行分布式架構的改造需要。另外在現(xiàn)在金融壓力的大情況下實現(xiàn)了降本增效，所有服務器全部是X86服務器，也提高了資源利用率。另外現(xiàn)在很強調自主可控，系統(tǒng)是我們自主研發(fā)的，所以完成了自主掌控，也擺脫了對廠商的依賴。
在業(yè)務方面能夠支撐10億級客戶容量，并且能夠在交互方面按照周來做功能發(fā)布。單帳戶管理成本從SAP的2.2元降到6分錢，我印象中馬老師說原來支付寶單賬戶成本6毛錢，而我們單帳戶可以達到6分錢。通過項目的建設我們得到了國家銀監(jiān)會、人民銀行的很多獎，也申請了18項專利。
講一下分布式具體機制的交流，我們覺得科技金融的關鍵基礎門部式肯定是一個方向，無論從外部來看市場環(huán)境、國家戰(zhàn)略、行業(yè)背景，還是從內部核心系統(tǒng)、成本控制、把控能力上都需要走分布式架構的這條路。
原來民生銀行是集中式架構（存儲+小型機（主備災）），現(xiàn)在全部的服務器都是X86的，可以實現(xiàn)流量靈活調撥，并且做到橫向擴展，也可以實現(xiàn)多數(shù)據(jù)中心多活的架構。
我們啟動項目是由2014年四部委聯(lián)合發(fā)布“分布式技術與金融云的研發(fā)與探索”，當時民生銀行以分布式核心作為項目去發(fā)布。這是當時建設分布式核心的幾個目標，要打造國產化自主銀行系統(tǒng)，另外要建設全行分布式架構能力。
在實施策略上先建設了一套分布式技術平臺（DAP）平臺，以分布式核心作為第一期試點，下一期把SAP核心存款全部遷移過來，應用核心系統(tǒng)直銷銀行在2018年1月份已經上線投成，目前預計比較平穩(wěn)。其實直銷里也有一類戶，傳統(tǒng)SAP里的現(xiàn)金重空管理在今年1月19日也會上線，明年年底全量SAP直接下線，全遷過來。
對分布式架構整體能力規(guī)劃分成三層，目標是要實現(xiàn)全部資源彈性擴展能力：第一層，基礎設施層，在計算能力、存儲能力、安全、云管理等實現(xiàn)彈性，現(xiàn)在用了容器化技術。
第二層，數(shù)據(jù)層，實現(xiàn)彈性計算能力，在存儲引用了對象存儲、分布式文件系統(tǒng)、文件傳輸、分發(fā)、非結構化等都已經做了改造，運維管控運維服務能力實現(xiàn)了分布式事務、分布式平臺的功能大數(shù)據(jù)作為分布式建設方面，包括分析計算、實時跟非實時計算。
第三層，應用層，實現(xiàn)了單位化多活的分布治理能力，有多活的分布式接入層，以及服務的注冊發(fā)現(xiàn)、服務的配置管理。批處理方面建立了適配分布式架構建立了相應的平臺，可靠消息發(fā)布能力。同時有開發(fā)運維管理能力，實時工藝、規(guī)范文檔等，和DevOps體系在一起配套建設。
銀行最重要的是業(yè)務連續(xù)性，所以我們把高可用的能力根據(jù)三層架構進行分配，在基礎設施層能實現(xiàn)云化資源、虛擬化。在數(shù)據(jù)層通過客戶分區(qū)和分庫分表分散風險。在應用層通過微服務化的解耦應用、無狀態(tài)支持快速擴展，通過流量控制、服務降級、客戶分區(qū)多活的方式實現(xiàn)應用層高可用的能力。
這是民生銀行在分布式建設過程中沉淀的分布式技術平臺，技術平臺主要沉淀了幾項能力：1.分布式數(shù)據(jù)訪問（CDAL）；2.分布式事務；3.分布式服務框架；4.作業(yè)管理；5.配置中心；6.緩存等，這就是分布式平臺提供的能力，所以分布式應用是在平臺上進行建設的（長在平臺上）。
這是平臺的四層架構，最下層的DevOps是配套的管控，在分布式平臺上主要分成接入層、應用層、數(shù)據(jù)層，接入層主要負責一些服務接入、流量調撥，在應用層配置管理、流水、配置中心、技術中心、應用還有全局路由、全局區(qū)列。數(shù)據(jù)層主要是通過獨立的數(shù)據(jù)件實現(xiàn)了分布數(shù)據(jù)讀寫分離的能力。
這是在建設分布式平臺時實現(xiàn)的同城雙活單位化架構，把應用分成三類，有點類似于傳統(tǒng)銀行3A、AQS、ASS）架構，我們分成全局區(qū)、機房共享區(qū)、分區(qū)單位應用，通過應用的切分實現(xiàn)了全行應用單元化多活架構，這樣所有的數(shù)據(jù)中心都是對外提供服務的，任何一個數(shù)據(jù)中心的故障都不會造成全行整體應用的不可用，并且目前在同城能實現(xiàn)RTO接近于零的容災切換。在去年春節(jié)前的時候董事長視察時還做過一次毫無任何準備切換，切換在瞬間完成，無一筆失敗。
分布式核心的應用架構，藍色框里是分布式核心。民生銀行的技術架構在核心之前是有支付引擎，還有NPS，NPS是指非帳戶類的交易系統(tǒng)，往下是存款的核心，里面有客戶信息、對公存款、對私存款、卡管理、帳戶管理、管控等，這里面實現(xiàn)了產品工廠的能力。核心業(yè)務都可以通過產品分享進行配置化的上線。
分布式核心核心應用分層架構分成了ABCD，A層是協(xié)議層，B層是組合交易層，C層是原子層，D層是數(shù)據(jù)訪問層。在B層進行服務的流程組織，全部配置化，所以通過這一套層級架構切分新業(yè)務功能可以按周上線。
簡單介紹一下在分布式建設中主要做了哪些關鍵的能力建設，在服務接入方面建設了服務網關、服務限流等。平臺應用主要建設服務框架、配置中心、批處理框架、消息中心。消息中心目標完全基于開源自主開發(fā)的。
服務框架描述的模型是服務注冊和發(fā)現(xiàn)的能力，主要解決服務的調度還有服務最高發(fā)現(xiàn)以及軟負載和容錯能力。配套的服務框架里落地了服務治理能力，主要實現(xiàn)線上治理、服務監(jiān)控、服務管理。線上這部分能力基本上全部是在服務框架里，有故障的隔離處理。監(jiān)控是在服務框架層面、服務治理SDK里進行數(shù)據(jù)的采集，只有服務的管理是通過大禹治理中心（音）實現(xiàn)的。
這是服務治理的技術架構里面比較核心的幾個模塊，民生銀行原來也是有很多異構架構，協(xié)議也不是完全統(tǒng)一的，所以做服務治理的時候分布式可以直接通過治理框架來接入的，但其他的還有服務網關有點類似于Service Mesh架構。整個治理方面管控端的監(jiān)控、分析、配置中心、治理中心、監(jiān)控中心等全部都是企業(yè)級的。
數(shù)據(jù)訪問層是自主開發(fā)了一套CDAL，能夠實現(xiàn)數(shù)據(jù)分庫分表和讀寫分離的能力，提供了兩種方式：1.SDK，SDK是直接和應用打包在一起的，可以使用負載均衡、SQL解析、SQL重寫、SQL路由、SQL執(zhí)行、結果集聚合合并等。所有的數(shù)據(jù)庫分布分表對應數(shù)據(jù)訪問層也有一套管控平臺，里面是企業(yè)級多租戶的架構，可以通過界面化的勾選配置實現(xiàn)。
2.CDAL Proxy，這和SDK能力上是差不多的，但更強大一點，可以獨立運行實現(xiàn)多套應用共享、資源共享的方式。目前共享部署上并不是很推薦這種方式，因為很多時候不同的應用開銷資源是不一樣的，要做到資源完全隔離風險還是比較大的，目前還是一套應用部署一套。為什么要建設這個呢？有些應用沒法進行重寫，如果有中間件存在的話可以把分布式改造屏蔽掉，應用基本上可以實現(xiàn)零修改實現(xiàn)分布式數(shù)據(jù)庫的分庫分表和讀寫分離能力，在存儲引擎方面我們可以支持MYSQL、Oracle、DB2。使用CDAL Proxy后，應用可以在面對多個數(shù)據(jù)庫存儲時，就像面向一個數(shù)據(jù)庫一樣。
原則上講要避免分布式事務的存在，建議CAP里追尋AP，盡量柔性思路和最終一致性。在能力上支持可靠消息的最終一致性和反向處理策略?，F(xiàn)在我們發(fā)現(xiàn)只是基于這一套東西有很多問題，因為某種意義上就是把復雜性拋給應用開發(fā)了，我們自己在開發(fā)一套分布式事務框架，盡量把分布式事務復雜性從應用中剝離出來，只是在做的時候比TCC做的簡單一些和少了一些浸入性，我們把這一塊兒給剝離出來。
這是分布式消息中心，消息中心基于開源技術開發(fā)的，但是結合了金融場景，比如說有些時候并不是所有產品都是組件對組件或者說系統(tǒng)對系統(tǒng)的，比如，有些時候需要客戶跟客服人員要進行一對一的消息傳遞，需要更貼近銀行業(yè)務場景。因此我們的消息中心，不僅是一套消息中間件，更是一套EDA的架構，并且完全貼合銀行業(yè)務做的工作。
我非常贊同今天上午邢磊講的分布式是給應用運維帶來很大的復雜性，所以我們也建設了一套DevOps體系。簡單談一下分布式核心運維體系，分布式系統(tǒng)怎么運維？一開始在建設過程中我們發(fā)現(xiàn)挺復雜挺多挺麻煩的，跟原來集中式比設備肯定要多，應用也要多，因為我們使用的是微服務的架構，服務、配置肯定要多的多，微服務后原來的傳統(tǒng)核心是整個存款都放在一起，但現(xiàn)在只是把核算放在外面，在這樣的情況下應用有16個。無論從建行體系還是民生體系都有全局路由、交易分發(fā)，微服務之后所有的服務是一個串一個或者一個串好幾個，交易的組合順序也不一樣，系統(tǒng)狀態(tài)復雜性要多得多，因為流量是在多數(shù)據(jù)中心之間進行切換的。
因此，我們建立了十大運維工具：運維管理集中化，基于CDAL進行開發(fā)；自動化工具；交易監(jiān)控平臺，云服務系、全鏈路跟蹤系統(tǒng)等。通過ZIPKIN，不僅在服務鏈路上做到全鏈路跟蹤，同時還可以做到服務方法級調用。簡單總結一下十大工具，主要想做到的能力是全面掌控、精確定位、快速響應，防患于未然。我們數(shù)據(jù)中心給我們的要求是“雙十”，十分鐘定位問題，十分鐘解決問題。
我給大家匯報的就是這些。????
