民生銀行分散式架構實踐分享
關注一下，更多精彩等著你！
關注一下，更多精彩等著你！
當前，在科技金融快速發展的大趨勢下，銀行業掀起了一場科技引領的服務轉型升級浪潮。傳統銀行必須加快科技創新，對內提升研發效能和數據驅動能力，對外提升客戶體驗、構建生態圈，全方位轉向網路化、數字化、智能化的科技金融服務。「萬丈高樓平地起」，科技金融銀行建設必須打好系統架構地基，而傳統集中式的IOE架構已無法適應科技金融銀行的發展要求，新的科技體系將基於分散式架構，支撐起未來全面數字化的海量客戶請求和龐大數據運算任務，成為一個能夠處理超大規模、超多渠道、超高並發、超多金融業務融匯交叉的智能有機體。
一、傳統銀行架構的問題和分散式架構的特點
隨著社會信息化的快速發展，金融服務呈現出海量用戶增加，個性產品定製、實時風控決策、快速敏捷響應等新特徵，這對銀行信息系統架構提出了更高的要求。而傳統的IOE技術架構，已無法滿足未來科技金融銀行發展的要求。
一是以業務部門或業務系統為維度，導致系統數量多、分散、獨立，數據共享度低，應用模式無法滿足整體IT戰略發展需要。
二是缺乏靈活的水平伸縮能力，性能瓶頸明顯，且容易碰到硬體信息的天花板，進而制約業務發展。
三是不能快速應對瞬時爆發的海量請求，特別是秒殺、促銷等爆發的瞬時海量交易。
四是典型的重資產模式，採購成本高，維護成本高。
五是缺乏自主掌控，高度依賴供應商支持，加重了科技研發壓力，加大了生產運行風險，無法快速響應市場變化，限制了業務模式創新。
與傳統IOE架構形成鮮明對比的分散式架構體系，自2004年以來由互聯網應用需求推動，逐步發展成熟，並在互聯網大型應用服務中獲得了充分驗證。該架構以分散式計算框架和分散式數據存儲為基礎，支持大規模、突發性、高並發場景，能夠以低成本，快速應對億級用戶數和PB級數據量的應用場景。近些年銀行業對分散式技術的研究和技術積累，使得構建基於分散式架構的核心業務系統成為科技金融銀行發展的必然選擇。
二、民生銀行分散式架構應用實例
這個是一個整個的核心架構，在這個架構裡面，我們可以分為幾個部分，一個是分散式客戶的管理系統，分散式階梯管理系統，分散式憑證，還有我們的這種賬戶管理系統，以及我們對私、對公等等，都是整個的應用的架構，這個架構我不展開講了。
我們分層架構就是說我們希望分為幾層，第一層是應用的一種分層，就說是在第一層裡面我們是A層，A層裡面我們主要是說來解決一個協議的處理，然後B層是一個組裝，C層是原子的服務，D層是持久。其實大家都知道，沒有分散式之前，我們常用架構是什麼?我們通常用的都是外部serverless我們通常會加一些一個F5，F5做負載均衡。分散式就在於說，外部式serverless之後，就不需要走F5了，走的是一個軟的東西，這個軟的東西就是我們整個分散式裡面最核心的東西，就叫分散式服務的框架，這個分散式框架是一個最核心的東西，這是一塊。
我覺得在這塊框架我們大家知道，阿里有一套叫dubbo的東西，在2013年的時候，阿里將dubbo開源給我們，我們一看發現，設計的理念架構很先進，但是場景不一樣，電商的場景跟金融的場景不一樣，沒辦法，得重改、重寫。
所以說這裡面有幾個底層的一種框架，第一層最核心的就是一個分散式服務的框架，B層就是服務主張，C層原子，D層持久化，也就是說分為這四層，這四層裡面分散式平台提供組建支持和核心應用，應外通過介面AP來使用一些組件。這個事情我們現在已經上線了，其實我們從2014年開始做的，這個事情也做了三年半，這個過程當中也趟過了很多坑，也是不斷的實踐，所以本來想去年11月份上線的，但去年11月份，剛好趕到我們29家村鎮銀行的核心要上收放了，要開放重疊到一起，一直到今年的1月23號，目前上完線以後，現在的情況是我把我們的一千二百萬的電子賬戶遷過來了，電子賬戶不支持二三類，我們電子賬戶這個是直銷銀行是一類、二類、三類賬戶都有，為什麼我們要遷過來呢?因為我們直銷銀行要獨立，它要獨立的話，他可能相當於成為子公司，他的核心系統必須要做，遷過來之後，現在的交易量大概多少呢?大概是一天一千八百五十萬筆左右，我們現在整個的系統的交易量是一天差不多八千九百萬筆左右。
我現在正在做的一件事情是什麼東西呢?我現在正在把我的底層的這一部分正在做改造，我們預計在明年的差不多九、十月份，我就把我的整個的老核心系統我就幹掉了，直接全部遷到我們分散式上面，這是這樣的一個邏輯。現在嚴格來說，我這個跑的核心，每天只有一千九百萬。一千個百萬也差不多了，因為我五年前，新核心上線的時候，我那個時候一天的交易量是兩千三百萬筆，也基本上差不多，所以這是整個一個邏輯。
另外一點就是說，因為它可以提供橫向擴展，所以說我上午也講了，我現在就跑在24台華為伺服器上，我也沒存儲，過去買存儲，現在直接就是機器自身帶的硬碟，然後機器壞了直扒拔掉重新換，所以說可以支持橫向擴展，隨便擴展，用的mysql的資料庫，而且現在就說是核心業務單點功能我們可以按周交付，而且現在成本也挺好，原來的成本每個帳戶兩塊二，現在六分錢，所以說這是整個的一個進展。
下面我主要講一下整體的架構設計，大家可以看到，他分為幾部分，第一部分叫應用層，第二部分叫數據層，第二部分叫基礎設施層，在應用層主要是提供一種多活的分散式服務的治理能力，還有這個批處理的作業能力，以及應用的監控的能力，分散式交易的服務能力。這裡面分散式消息是非常重要的一塊，但是多個伺服器之間調度的時候，必須有一套準確的消息機制，我現在可以這樣說，我在我所有的整個架構裡面，我都實現了自主，我現在唯一沒有實現的就是這個分散式消息。分散式消息現在我們要重寫它，需要一年半的時間，我才能寫，但我們時間有限，所以就這一塊用的是阿里的，其他的東西全部是重寫的，全部是我們自主研發，自主來做的一個事情，所以這是應用層。
將來分散式消息這塊是非常重要的，第二個就是一個分散式持久化能力和分散式資料庫服務能力和大數據能力，分散式和傳統的集中式架構在交易方面有一個最關鍵的一個區別就在於說，一個叫強一致性，一個叫最終一致性，這兩個是有區別的，最終一致性叫什麼意思呢?也許我這個交易跨越了ABCDE，我中間失敗了以後，我有的實施要靠我自身的補償機制來實驗，所以往往會發現，咱們在講銀行架構的時候，我們講分散式不是我光底層做個分散式資料庫就OK了，那不行的，至少我認為在當下的資料庫不行，也就是說，你把所有的希望寄託於一個點，分散式資料庫來實現，我認為這是不完美的，你只能是什麼呢?每一層都要分散式，就是最前端的全局的路由，分散式服務的框架，到中間這一層，每一層都要分散式，如果說我只是前面實現了，後面沒實現，那你分庫分表這一層就可以不要了，過去很多的分散式都有這種技術。在這裡面，分散式持久化能力、分散式資料庫服務能力、大數據平台，包括基礎設施層都有這樣一個。
也就是說，這裡面有幾個分散式資料庫訪問，我上午講了，我是說銀行的應用場景，總結下來就分為這幾類，第一類叫通道型的應用系統，什麼叫通道型呢?手機銀行、網銀，這些都叫通道型，因為它只是一個過程記錄，在這一層你完全可以做雙活，你只要把一些全局的表，定期的一度的單做一個統一就行了，這一層是很好做的，這一類型叫通道型。
你放兩個資料庫，放在兩個機房裡面，這個壞了，你把那個卡斷，給他弄過來，這就很快了。第二個叫可以讀寫分離型的。因為銀行總有業務場景，說白了，你梳理一下你每天top 10應用場景不就行了嗎，對於讀寫分離型的，OK，你讀寫給他做一下分離，第三類，分庫、分表型，有一些表，就是過一陣子他就變得很大怎麼辦呢?這種時候就需要分庫分表型的。第四種，強賬戶依賴型的，所以你會發現，阿里在去IOE架構的時候你會發現它有一個最核心的賬戶，一定要最後去，為什麼?因為你最終無論手機銀行和幹嘛，它只是一個渠道和通道而已，他進來以後最終你要落實到那個賬戶上，交易上，這個就叫強依賴性，你分為這幾種場景，要針對不同的解決方式，這一種叫分散式數據訪問。
第二個分散式事物，你要知道，最終一致性和強一致性，強一致性就是我們傳統的，就像過去我們大機上用的，也可以靠資料庫來實現交易的一次性回滾。但是在分散式裡面有的時候要靠一個，對分散式你要實現一個最終的一致性，也就意味著，當我發現有一筆交易有問題的時候，我要靠應用，我要寫一筆交易把它沖正，把它補償，分散式服務的框架與管控，這是非常致命的一塊，也就是是說，我們通過服務的框架來做服務的訪問限制和限流，服務的跟蹤，我認為這是我們整個下一步要做微服務治理非常重要的一塊。這也就是我剛才跟大家說的，目前在這塊可能是國內阿里的那一塊dubbo做得不錯，但是dubbo他們現在內部好像也又用另外一套架構。
分散式批量作業調度，大家都知道，銀行每天晚上我要做批處理，第二天早上領導要看頭寸、看報表，這個東西也非常關鍵，分散式配置管理，當有N台伺服器的時候，這些配置傳統的我要裝機，交易中心這是最要命的，分散式緩存，以及我的交易的迷等性和統一的重正，在分散式環境下，我們要建一個全局的唯一的序列，幾個核心的要點，我們可以看到，分散式架構的基礎架構的設計，首先在服務的接入層，實現服務的路由及管控能力，支持服務與數據單元化部署，我們可以到在服務的接入層，包括服務路由，訪問控制，服務的限流，交易的迷等性，以及在應用層我們實現分散式服務式框架，消息中心、註冊全局系列，配置中心，分散式P處理的框架，這是這一層。因為我覺得今天來得都是咱們專家和行業的比較資深的，所以我講到就不展開了，因為技術的細節我相信大家都影響是非常熟，再加上時間有限也就30分鐘。
第二個叫分散式服務，我們要建立分散式服務的框架，集成分散式消息及批處理的框架能力，其實在分散式資料庫訪問的時候，大家可以看到，我剛才講的，你要根據場景，數據層、資料庫有讀寫分離的，有分庫、分表的，以及再往下就是我們整個的devops的分散式運維的基礎能力來支持分散式應用的持續的集成和部署。
關鍵技術，在這裡面服務的治理能力分為服務的線上治理、服務監控、服務管理，服務的線上治理大家可以看到這裡面訪問控制，很重要的一塊，黑白名單、流量控制、印花控制、故障處理、服務發現、服務路由、服務調度、負載均衡、服務降級，我剛才跟大家講了，過去我們很多時候是靠傳統的，傳統的叫業務是靠什麼?靠F5，但是F5裡面，其實你對你服務很多東西的一些微觀的治理可能就缺少，你看我們再舉個例子叫做有一句話叫服務限流，叫流量控制。
這一套東西其實我覺得，我們整個下來，過去我們常常說，我們要做微服務什麼東西，我覺得傳統那一套架構難度挺大的，我們也是通過這一次分散式的東西，把整個的服務治理，相對來說從底層、架構層梳理的就比較清楚，其實這就叫做整個銀行IP架構的一個底層技術的轉移，涉及的理念我們可以看到這是技術的架構，在這個架構裡面可以看到把每一個配置分離，動靜分離，一點接入，集中管理，動態識別，動態賦能，也就是我們有一個叫做服務的消費者，也就是傳統的服務應用，到我們的網關，到我們的服務治理的客戶端，然後在整個的一套邏輯和框架，也就是註冊中心是負責物理地址的註冊，變更和變更時間的同步通知，配置中心是管理所有的靜態配置，負載分攤應用配置獲取的壓力，治理中心是統一門戶，所有超出的入口、承載，服務自己的流程，記錄所有變更，變更時間的發起者，地址伺服器是提供一點接入的，命名和身份識別的服務，實現組建動態附加能力，管理地址、位置和功能影射的關係，而且大家可以看到，在這一塊，我們還有一個日誌分析平台，過去，我們在上我們那一套核心的時候，因為我們自身的人員不足，我找了28家開發公司開發的，結果用了無數的平台，我在底層處理日誌的時候非常痛苦的一件事，因為大家日誌格式不統一，帶來很多的麻煩事，我們在這次的時候，直接在底層一個大數據的日誌分析平台。
這個日誌分析平台，我同時對這個日誌分析平台在做運維的大事件分析，所有的事情都可以任何事件我覺得有了那個日誌分析，我們是說風起於清平之間，浪乘於蔚藍之間，所有的東西我都可以給他做一個預判和預測，過去我很難做到，解決問題，服務的接入要提供服務的統一入口，並將外部請求的路由的相應服務上，提供細力度的服務訪問安全控制，確保系統的安全生產運行，提供多維度的服務限流，有效的來解決瞬間爆發的高並發訪問，我們要支持交易的迷等性，防止同一筆交易重複處理，所以這裡面也就幾塊，服務限流、交易冪等性、服務網關、訪問控制，平台應用，這裡面就是一個解決問題，分散式通信。分散式通信工業提供面向遠程過程調用的服務框架和面向消息通信的消息中心。這個我剛才講了，這個不是說傳統的MQ了，傳統的MQ更不行了，因為它本來就不是解決分散式，我們也看了市場上一些開源的東西，還是不行，所以說這個產品是非常關鍵的，分布格式的配置管理來解決分散式場景下大量應用結點配置管理和變更複雜的問題。
分散式批處理，我覺得每家銀行都有這個問題，批處理。因為交易量越來越大，系統越來越複雜，外界的模塊越來越多，每個環節都會有可能造成你整個批處理的延時，所以分散式批處理也是非常關鍵的，集中應用於數據分散式之後批處理作業開發與運行的運行機制，配置中心難點解決問題，分散式配置管理解決分散式環境下大量應用結點配置管理和變更複雜的問題，他的難點是配置分發的延時控制和多結點的一致性控制，大家可以看到這樣的一個示意圖，也就是說，我們客戶端一個應用，它根據本地的配置，去配置伺服器批量下載配製多本地倉庫，它要去註冊中心、註冊並監控，然後根據接收到的變更配置信息，然後再通過我的一些介面，然後去我配置服務端去下載，完了以後這個伺服器所以說這是一個集成到管控平台的一個液面，這個也是一個重要的難點。
數據訪問，我們叫做分散式資料庫訪問，它實現資料庫水平擴展，完成分庫分表，讀寫分離的C口自動路由，對應用透明性能高，關於分庫分表，市場上有這麼幾種工具，第一種就像我們原來最早用的是支付寶的分散式的訪問介面，後來我們發現，做得挺好的，但是還是跟銀行的場景不符合，因為電商的場景跟這個場景沒辦法，後來我們就重寫。淘寶也有一個工具叫淘寶的分散式的數據訪問介面，騰訊也有一個自己的介面，百度也有一個，這是一個很難的，你為什麼做這一層，你不做這一層，你不就是單點了嗎，你不就是傳統的架構了嗎?所以這一層肯定是要做的，這一層就叫做分庫分秒的一個東西，所以說我們自己也是重寫這一塊東西，而且我們不光寫了這塊，還在最前端寫了一層全局路由，這個分庫分表，這個東西就是跟我們傳統集中式的架構裡面一個很大的不一樣。
有人會說我用一個分散式資料庫也可以，但是分散式資料庫有它一個缺陷，這個產品N年前就有，但是我覺得，現在我看到華為正在研發一個分散式資料庫，我們現在也正在合作，但是我始終覺得，分散式的東西你不能把所有東西集中在一個點，你需要在每一層都做這個事情，因為我本身就是搞資料庫的，所以說我對這個問題也是不停的在思考。分散式數據訪問層，路由負載均衡，改寫、執行、合併，管理的模塊，再到後面高可用的資料庫的資料庫，寫庫、讀庫，分片、分區等等。
應用的分庫分表，解決的問題是資料庫層支持橫向的擴展，避免分散式事物應用透明降低運維的複雜度，這個裡面我們也可以看到，我們產品的服務組建裡面有ABCD，有N個業務的處理的單元，在這個業務處理單元，我們的客戶的信息，我們的分區建，我們的分區演算法都有，其實嚴格來說，就需要你對銀行的場景，就像我剛才講的，抓住主要矛盾，你每年梳理一下，你銀行裡面top 10的交易都是什麼，對每一種交易的場景，對每一中業務的一個邏輯給它梳理清楚，找到一個每一種場景的一種最合理的一種方式。
一致性保障機制，大家可以看到，本地事物應用微服務和組建化的設計思想,充分應用最大程度避免分散式收入。第二，冪的一致性，服務提供方，實現服務處理的冪等性，避免重複提交事物，最終一致性，就是說應用通過對帳，一致性檢查等補償手段來確定業務完整性和最終一致性，我們這一次裡面最終一致性是我們用到的。所以，為什麼呢?因為過去民生銀行在上一代核心的時候是用SOA架構，客觀傳統的銀行核心系統裡面包括了很多，我們就不是的，我們的核心裏面就包括卡，BP，MM和我們的存款，我把很多的支付就剝離出來了，還有安保也剝離出來了，我們過去就面臨這樣一個問題，我做一筆交易的時候，這個交易跨越了ABCDE5個系統，我做到A的時候，CDE還沒有到怎麼辦，所以，當時就開發了一個異常處理平台，這個異常處理平台，一定要靠應用在前端補償機制弄掉。所以，很多情況是分散式不是拿回來直接用，而是都是結合我們的場景來做一些這種開發和定製，自動化運維和部署提供分散式系統開發到運維全生命周期管理，提供分散式核心應用批量部署和變更，提供分散式系統的監控，預留管理控制台，我們要持續地集成，進行代碼，每一日的自動的編譯打包運行，根據編碼的規範進行代碼掃描併產生結果，自動執行代碼的測試，應用發布，我們支持應用的多環境管理，支持應用的在線發布和負載均衡配製，支持應用版本管理，我們上完線以後，就像在直銷銀行手機客戶端，我們完全支持白天都可以做這個事情。
因為我是分散式的，大不了這個功能現在開放給一部分的用戶，因為我過去一部分的架構很難實現，運維管理也就是說提供監控與日誌管理，提供服務的跟蹤機制，提供分散式系統管理控制台。容器元和大數據技術，解決問題，那麼，基於容器實現一個全流程管理，支持多環境部署，實現應用環境的隔離，支持應用滾動的升級與發布，這個我覺得就是什麼呢?我原來每一周發布一次已經夠頻繁了。但是也沒有辦法用，客戶恨不得每天變更一次，還有，基於大數據技術實現日誌的採集存儲處理和更新就是我剛剛講的，我們現在每一步在做的時候有一個統計的日誌一個處理平台。
就是交易鏈路核心業務盡量在同中心完成，關聯應用交易數據同中心發布，交易鏈路非核心業務跨中心非同步完成。單元劃分，分成業務單元，以客戶為統一維度進行交易鏈路的服務管理，分區的單元劃分分區模式，保證核心業務客戶均勻分布不同的分級單元，核心業務盡量自包含，共享業務單元不可以按照同一拆分為劃分。然後，被核心業務高頻訪問，因為現在都是一種多活的一種架構，當然，多活是同城，異地很難做到，異地是一個網路的同步的延遲很難做到，但是，我們在同中心，我們在60公里的時候，做的就是這樣的。所以，對於這種方式來說不存在什麼呢?我那邊出情況了，我就是能力下降了一點而已，這個是一種多活的。
我們可以看到也就是說整個利用架構，數據中心A和B就是負載均衡，全局共享基於服務接入，全局系統，同城共享期，還有在底層。在沒有做這個之前我們是怎麼做的呢?因為核心已經上線了，上線了以後，其實最好的解決方案是什麼了?是這個應用在上線的期間，就要把它的情況想清楚，在很多東西靠應用端實現，底層來實現，我們沒有辦法，核心政治任務要上線，上先了以後拿回來做測試也是不現實，我就是盡量不動業務系統，所以，我們做的就是資料庫層面的，所以，這個在國內也是大規模批量應用，在60公里的地方每天就這樣跑著，我最重要的系統就是這樣跑著，有問題嗎?有問題。什麼情況之下?我發生鏈路抖動的時候有問題，我做大規模地批處理的時候就有問題，你不用怎麼會積累經驗呢?我們這幾年用了幾年，也積累了豐富經驗，針對這個情況怎麼解決，共享了該很好，我們傳統情況怎麼切換?我們編一個劇本，我們過來喊一聲口令，這個就是某種情況之下是大家都明白的，你都是不知道什麼時候會發生，這個就是傳統。
傳統這個東西問題在於什麼?把所有希望都寄托在資料庫裡面，這個裡面還存在著鏈路抖動，今天用這個方式地層都是分庫分表的，我原來做的方式就是像把rac放在同一機房，一跟線，10幾米拉到60米，就是這樣一個問題，今天完全是這個架構實現，不是有這個架構就可以隨便弄，還不是的，還是儘可能地要把一些核心的業務能在同一個中心就在同一個中心，不可以在同一個中心就退而求其次，這些東西都是要開始都思考清楚的。
我們看一下運維的支撐體系，分散式系統如何運維?包括核心系統如何運維?原來一個是分散，幾百個分散式應用實例，單應用，幾十台應用伺服器，數據分散，N個庫拆為N個表，M乘N個庫，過去大家想想，我們做備份做災備的時候有底層，第一層底層傳輸。第二層，要麼我在數據層層面做一個，今天我們沒有存儲了，存儲都是用在機器帶的硬碟裡面，這個分布在N上面備份怎麼做?這個裡面就比較的複雜。所以，數據分散，
第二個，就是服務層次複雜，這個裡面包括很多。路由，應用伺服器，還有應用關係複雜，還有系統狀態一個複雜。因為我們現在跑什麼?我現在是這樣的，因為3年之內準備把銀行系統80%的系統分散式化，大家不要為了分散式而分散式，有一些系統就讓他待著，為什麼一定要分散式，所以，做的過程當中剛剛可以解決掉就解決掉。這個是這一點，我們民生銀行有15%左右的系統是分散式，我今年明年做的科技三年規劃裡面希望可以解決70%80%的系統，這樣我每年的成本都可以大幅度下降，應用，服務多，配製多，我們可以看到，我們要解決一個服務治理，分散式管控平台，應用的查詢，運維的試點，硬體，起動監控平台，運維操作的自動化，持續交互，分散式一個平台，機房切換一個自動指揮平台，應用排除可視化，實時交易分析，實時鏈路分析，運維架構可視化，還有雲服務系統，包括服務跟蹤的智能化，日誌分析一點清，還有服務跟蹤，我們做到這樣一些體系。
第一個運維操作自動化，快速起動時間，172個硬實例實現秒級流量切換，今年春節最後一天，我們董事長覺得這個分散式核心做的比較好，就到這邊來慰問一下大家，請大家酒吧，我們去機房現場切換一下，白天現場可以做這個事情。過去不會這樣的，過去還是有一點難度的，這個是這個，可以秒級別地切換。應用集，主機集，集成集和機房集，可信部署，結果，部分包括自動對這個進行檢查，這個裡面是這樣一個層次結構，大家可以看到，運維管理集中化，這個是針對運維試點，這個裡面有一個視圖，這個裡面可以看到整個數據存儲做的分布分表，一個表1024張，不一定非得1024張，這個都可以的。只不過我們表比較大，資料庫做了集中查詢，1024表可以視為一張表等等。
其實這一塊兒東西不知道原來大家有用過嗎?傳統資料庫都是有一些產品，有一個DPF的一個產品，它其實就是解決什麼呢?就是N年前一個產品，就是一個分區的，但是那個時候更多解決一個數據倉庫，數據倉庫，這個消息機制比較的複雜，他更多是面向一個ORUP應用，如果假設裡面東西比較多就有問題了，這個消息廣播連接非常的複雜，還有一個技術可視化，我們可以看到，我們第一步可以看全景，看系統之間一個調用感到，系統下一個交易量，點擊系統的視圖，第二查自己，性能分析，交易量分析。第三步，追別人，交易的系統調用關係，各個步驟的耗時，二維碼，交易在各個系統的耗時分布，這個就是一目了然，所以，這個是整個這樣一個節奏。其實大家也都是知道，我們現在有很多的行也用一些流量分析的軟體，市場上面也有的但是，他這個是第一個層次，如果你要想深入地來去做，沒有標準的產品，只可以靠自己。首先要有足夠的信息做資源化。組件的功能， 這個追蹤每一個完整的鏈路，包括應用鏈，消息中心，資料庫等跨接點的調用，收集調用鏈路每一次調用出入差，用於異常分析，收集鏈路上面每一次調用的性能數據，這個就非常的方便，我排錯的時候。
現在提了一個要求，為什麼呢?因為我原來是數據中心老總，後來不小心當了老了，我就提了一個要求，你必須要雙10，你必須要10分鐘之內找到問題的原因，10分鐘之內解決，要求比較高，但是，只有高壓力人才會有動力。我給你說，我過去那種架構做不到，但是，一種新的架構裡面，因為很多東西可以寫的很詳細才可以這樣做的。所以，架構實施建議，改造要點，科技業務能力分層，渠道層，客戶場景服務層，集成層，產品層，數據層，技術開放能力層雲化資源層。
第二，應用業務要分類，哪一些是渠道型應用，什麼是分離型應用。配製型應用，什麼是狀態應用?分布，分秒型，多活，舉一個例子。安保平台，這個系統就是典型的查詢非常的多，相對非常靜態的，你不可以把跟網銀系統分一起，這個都是有不同的講究的。其實銀行系統要說它簡單，他還是不簡單。但是，做一個統一方法分論，這個邏輯梳理出來，應用拆分，狀態型業務功能下沉，實現應用層無狀態化，第一階段，就是架構的X86改造，第二，就是雲化基礎設施改造，第三雲化服務。設計的原則，總則，就是進行垂直平分切分，進行一個垂直垂平切分，垂直切分優先，並盡量分拆成流水型應用，狀態型應用，狀態型業務集中下沉，垂直切分原則，業務高，子系統兼數據隔離，原服務能力可以由子系統獨立完成，水平切分原則，就是客戶為度。同一個客戶關聯放同一個資料庫裡面，統一交易原則服務操作同一個風險業務邏輯，這個裡面包括總體的工程，建議副工程，連接交易工程，公共工程，每一個工程有介面實現的這個過程。
以及整個分散式的架構，這個裡面大家可以看到，整個的一些接入層，包括業務服務層，包括應用技術開放能力層，包括一個雲化資源層，這個是這樣一個願景架構。
三、分散式架構實施建議
（文章根據會議記錄整理，文章略有改動）
（來源：互聯網金融工作委員會）
TAG:金融時代網 |