消費(fèi)金融大規(guī)模分布式系統(tǒng)架構(gòu)

1、構(gòu)建靈活可靠的消費(fèi)金融大規(guī)模分布式系統(tǒng)行業(yè)及業(yè)務(wù)模式消費(fèi)金融系統(tǒng)架構(gòu)演進(jìn)歷程關(guān)鍵技術(shù)創(chuàng)新實(shí)踐總結(jié)與展望2消費(fèi)金融行業(yè)List 1List 2消費(fèi)金融是一種新的金融業(yè)態(tài)，處于產(chǎn)業(yè)鏈的核心環(huán)節(jié)，是連接消費(fèi)者和資金供給方的重要樞紐。3消費(fèi)金融行業(yè)4快速接入用戶場景，極速響應(yīng)請求快速響應(yīng)市場和監(jiān)管的變化快速自動(dòng)審批的能力穩(wěn)定可靠的資金來源 和支付通道十面埋伏的反欺詐引 擎和資產(chǎn)保全系統(tǒng)智能嚴(yán)謹(jǐn)高效的風(fēng)控模型核心競爭力消費(fèi)金融行業(yè)成立3年時(shí)間，發(fā)展迅速，業(yè)務(wù)規(guī)模和資產(chǎn)質(zhì)量 在行業(yè)處于領(lǐng)先地位正規(guī)持牌、股東陣容強(qiáng) 大，資金實(shí)力和風(fēng)控能力雄厚經(jīng)營良好，成立3年盈利 翻倍渠道資源豐富：自營APP 和BATJ流

2、量入口、郵政 郵儲(chǔ)4萬線下網(wǎng)點(diǎn)，O2O全面拓展業(yè)務(wù)中郵消費(fèi)金融公司6行業(yè)及業(yè)務(wù)模式消費(fèi)金融系統(tǒng)架構(gòu)演進(jìn)歷程關(guān)鍵技術(shù)創(chuàng)新實(shí)踐總結(jié)與展望7中郵消費(fèi)金融的發(fā)展歷程8消費(fèi)金融2.0 2017年-2018年未來4.0消費(fèi)金融3.02018年至今消費(fèi)金融1.02015年-2016年集中式、單體結(jié)構(gòu)，商 業(yè)中間件集成，性能、 可靠性、靈活性差分布式事務(wù)管理、服務(wù) 快速集成、容器化、自動(dòng)化，靈活性和可擴(kuò)展 性提升智能化、去中心化、高 度自治核心系統(tǒng)重構(gòu)、分布 式、大規(guī)模服務(wù)化、交 易和流程異步化、基本 去商業(yè)中間件，性能和 可靠性提升系統(tǒng)架構(gòu)演進(jìn)過程系統(tǒng)架構(gòu)演進(jìn)過程 1.0應(yīng)用架構(gòu)技術(shù)架構(gòu)指標(biāo)日交易峰值：3萬

3、筆處理效率：3000筆/小時(shí)貸款審批時(shí)長：大部分30分鐘新產(chǎn)品研發(fā)周期：2-3個(gè)月 軟件成本：2400W特點(diǎn)純商用軟件；建設(shè)成本和維護(hù)成本極高；集中式商業(yè)中間件（ESB、流程引擎、規(guī)則 引擎等），交易同步處理過程多，單點(diǎn)的資 源壓力極大，不可控；煙囪式、交易型系統(tǒng)，創(chuàng)新困難，彈性差；數(shù)據(jù)不共享，形成孤島，整合利用困難。系統(tǒng)架構(gòu)演進(jìn)過程 2.0指標(biāo)日交易峰值：30萬筆處理效率：1.2萬筆/小時(shí)貸款審批效率：90%的申請10分鐘內(nèi)完成新產(chǎn)品研發(fā)周期：1.5個(gè)月 軟件成本：2000W（人力成本）特點(diǎn)自主研發(fā)為主，成本有所降低，但新產(chǎn)品研發(fā)效率仍然不高；去除商業(yè)中間件，替換為分布式開源中間件，可擴(kuò)展性

4、和性能顯著提升，自主可控；交互型系統(tǒng)，實(shí)現(xiàn)大部分業(yè)務(wù)領(lǐng)域服務(wù)化，交易和 流程異步化解耦，快速創(chuàng)新，有一定彈性，但經(jīng)常 出現(xiàn)數(shù)據(jù)不一致性的問題；數(shù)據(jù)共享容易，大數(shù)據(jù)前移到中臺(tái)，提供實(shí)時(shí)應(yīng)用系統(tǒng)架構(gòu)演進(jìn)過程 3.0指標(biāo)日交易峰值：130萬筆 處理效率：5萬筆/小時(shí)貸款審批效率：95%的申請2分鐘內(nèi)完成，大部分秒批新產(chǎn)品研發(fā)周期：2-4周 軟件成本：4000W特點(diǎn)賬務(wù)核心系統(tǒng)向分布式演進(jìn)，通過分布式事務(wù)管理器解決數(shù)據(jù)不一致的問題容器部署和容器集群管理，基礎(chǔ)設(shè)施靈活可擴(kuò)展；微服務(wù)在線化，支持快速集成，靈活程度提升DevOps，自動(dòng)化部署和測試，開發(fā)效率提升顯著。14行業(yè)及業(yè)務(wù)模式消費(fèi)金融系統(tǒng)架構(gòu)演進(jìn)歷

5、程關(guān)鍵技術(shù)創(chuàng)新實(shí)踐總結(jié)與展望13演進(jìn)過程遇到的主要痛點(diǎn)01020403微服務(wù)跟蹤和監(jiān)控微服務(wù)調(diào)用關(guān)系錯(cuò)綜復(fù)雜，難 以識(shí)別主流程，出問題難以定 位和排查。解決方案：全鏈路跟蹤監(jiān)控產(chǎn)品研發(fā)效率不夠高服務(wù)化沉淀了大量構(gòu)件，但構(gòu) 件組裝仍然代價(jià)較高，仍然需 要大量的編碼工作，開發(fā)、測 試、部署效率不高。解決方案：容器化、微服務(wù)集 成和DevOps數(shù)據(jù)一致性保證問題單體應(yīng)用拆分成多個(gè)系統(tǒng)，數(shù)據(jù)狀 態(tài)從持久化到一個(gè)數(shù)據(jù)源變成多個(gè) 數(shù)據(jù)源，保證數(shù)據(jù)一致性是一個(gè)巨 大的挑戰(zhàn)解決方案：分布式事務(wù)管理器交易吞吐量需要最大化貸款屬于長交易，前端需要及時(shí)受 理和響應(yīng)，后端流程大部分可以異 步化，要求交易吞吐量最大化。

6、 解決方案：消息中間件服務(wù)調(diào)用及監(jiān)控p 基于Springboot的微服務(wù)應(yīng)用p DubboUX RPC服務(wù)間調(diào)用p Springboot+ Jersey開放Restful微服務(wù)，Nginx負(fù)載均 衡，向APP和WEB前端提供服務(wù)p 服務(wù)注冊中心使用Zookeeperp 使用部分Spring Cloud組件服務(wù)調(diào)用及監(jiān)控p分布式系統(tǒng)面臨的挑戰(zhàn) 系統(tǒng)越來越多，性能問題如何發(fā)現(xiàn)？ 服務(wù)多層次、嵌套調(diào)用，出現(xiàn)問題如何定位？分布式服務(wù)錯(cuò)綜復(fù)雜，主流程如何識(shí)別？需要全鏈路跟蹤和監(jiān)控微服務(wù)！16全鏈路跟蹤系統(tǒng)架構(gòu)關(guān) 鍵 點(diǎn) ： 日志埋點(diǎn)加入TraceId JavaAgent字節(jié)碼修改實(shí)現(xiàn)應(yīng)用開發(fā)無感知的 日

7、志埋點(diǎn)基于OpenTracing標(biāo)準(zhǔn)實(shí)現(xiàn)跟蹤，而非私有化 API17高效可靠的消息系統(tǒng)18Kafka匹配消費(fèi)金融的主要痛點(diǎn)：每筆貸款申請都是長交易，需要盡量異步化不需要實(shí)時(shí)給出結(jié)果，但必須實(shí)時(shí)受理和響應(yīng)，要求低延時(shí)、高性能、高吞吐必須技術(shù)穩(wěn)定、支撐有力、并且自主可控功能Kafka(1.0.0)RabbitMQRocketMQActiveMQ社區(qū)活躍度(GitHub)547612462541372可靠性同步刷盤異步刷盤同步刷盤異步刷盤同步刷盤異步刷盤同步刷盤異步刷盤消息投遞低延時(shí)有一定間隔有一定間隔有一定間隔消費(fèi)模型Long PollingPush / PullPush / PullPush /

8、 Pull事務(wù)消息支持不支持支持支持消息堆積能力百億級別 不影響性能影響性能百億級別 影響性能影響性能消息堆積查詢支持支持支持支持消息重試不支持支持支持不支持性能（常規(guī)）非常好 百萬級QPS一般 萬級QPS非常好 十萬級QPS一般 萬級 QPSJMS客戶端不支持支持支持支持高效可靠的消息系統(tǒng)實(shí)踐：構(gòu)建基于Kafka的可靠高效消息處理機(jī)制p 設(shè)置transactional.id以支持事務(wù)Producer。p 設(shè)置enable.idempotence為true以支持Producer冪等發(fā)送消息。 p 設(shè)置Consumer只讀取committed的消息（isolation.level設(shè)為read_c

9、ommitted）。 p 設(shè)置Broker端配置總副本數(shù)replication.factor至少為3。 p 設(shè)置Broker端/Topic配置最少同步副本數(shù)min.insync.replicas為2。 p 消息不丟失（持久化可靠性）保證通過足夠多的2副1 本數(shù)保證實(shí)踐：構(gòu)建基于Kafka的可靠高效消息處理機(jī)制20高效可靠的消息系統(tǒng)Producers消息醫(yī)院KAFKASDK消息醫(yī)院數(shù)據(jù)庫后臺(tái)管理系統(tǒng)消息處理模塊DLQRDQConsumerSDK1. 消費(fèi)失敗，發(fā)送消息到DLQ2. 消息醫(yī)院接收錯(cuò)誤消息4. 監(jiān)聽恢復(fù)消息，Cloud Bus ID過濾，重做處理3. 往指定的Cloud Bus服務(wù)I

10、D發(fā)送恢復(fù)、重做消息5. 監(jiān)聽恢復(fù)通知，Cloud Bus ID過濾，默認(rèn)通知消息醫(yī)院DLQ監(jiān)聽模塊監(jiān)聽故障消息存儲(chǔ)RDQ處理模塊構(gòu)建消息發(fā)送消息管理后臺(tái)角色權(quán)限管理消息管理統(tǒng)計(jì)查詢消息處理重做線下處理通知處理應(yīng)用（SDK 2.0)統(tǒng)一配置統(tǒng)一認(rèn)證高效可靠的消息系統(tǒng)21實(shí)踐：消息醫(yī)院異常消息的統(tǒng)一收集和處理，作為at-least-once消息投遞保 證的必要措施。數(shù)據(jù)一致性實(shí)踐：分布式事務(wù)解決方案：兩階段提交、TCC、可靠消息投遞、SAGA（補(bǔ)償事務(wù)新變種）pSAGA = Long Lived Transactions p每個(gè)子事務(wù)都有一個(gè)對應(yīng)的補(bǔ)償事務(wù) p其中一個(gè)事務(wù)出現(xiàn)異常時(shí)自動(dòng)調(diào)用其他子

11、事務(wù)的補(bǔ)償事務(wù)pApache孵化項(xiàng)目ServiceComb：支持SAGA 和TCC的事務(wù)管理器，Omega客戶端和Alpha協(xié)調(diào)器（分布式結(jié)構(gòu)）pSAGA和TCC的區(qū)別？22對比維度兩階段提交（2PC）補(bǔ)償事務(wù)（SAGA）補(bǔ)償事務(wù)（TCC）可靠消息投遞模式隔離性、一致性強(qiáng)隔離性、強(qiáng)一致性如果事務(wù)被回滾，存在隔離性（臟讀問題）追求短時(shí)間內(nèi)達(dá)到 一致性準(zhǔn)隔離性、追求短時(shí)間內(nèi)達(dá)到 一致性read_committed可以保證 隔離性，最終一致性，時(shí) 間跨度較大可用性犧牲可用性，CP支持，AP支持，AP支持，AP應(yīng)用層面資源層服務(wù)層服務(wù)層服務(wù)層性能需要加全局悲觀鎖，低本地事務(wù)，Lock時(shí)間短，高本地事務(wù)

12、，Lock時(shí)間短，需要 兩次調(diào)用，較高高恢復(fù)方式回滾沖正 + 對賬 + 人工介入取消 + 對賬 + 人工介入狀態(tài)回滾、應(yīng)用掃表補(bǔ)償業(yè)務(wù)耦合度低中高低實(shí)現(xiàn)難度需要底層資源層支持，復(fù)雜， 故障點(diǎn)多，實(shí)現(xiàn)難度高可框架支持，但每個(gè)子事務(wù)均需 要實(shí)現(xiàn)對應(yīng)的沖正事務(wù)，開發(fā)成 本較高可框架支持，需要設(shè)計(jì)嚴(yán)謹(jǐn)?shù)?中間狀態(tài)保存和取消機(jī)制，開 發(fā)成本高需要消息中件間支持，中應(yīng)用場景需要強(qiáng)一致性，容忍高開銷 的場景補(bǔ)償是可行的；快速響應(yīng)結(jié)果； 業(yè)務(wù)執(zhí)行結(jié)果未隔離，補(bǔ)償不完 整帶來的風(fēng)險(xiǎn)與成本可控的場景要求一定隔離性和一致性的業(yè) 務(wù)；執(zhí)行時(shí)間較短的業(yè)務(wù)對一致性時(shí)間敏感度較低， 被動(dòng)方處理結(jié)果不影響主 動(dòng)方處理結(jié)果，需

13、要保證 最終業(yè)務(wù)完成的場景23分布式事務(wù)方案對比開戶放款1開資金戶2額度占用4支付放款Saga/TCC 事務(wù)協(xié)調(diào)器實(shí)踐：全方位的分布式事務(wù)處理機(jī)制TXStartTXEndAccountService HttpCreditService DubboSmsService Kafkaread_committedPaymentService Dubbo發(fā)生異常，2、3，4未執(zhí)行，不需要補(bǔ)償發(fā)送短信Topic-1開 資 金 戶 補(bǔ) 償-2取 消 額 度 占 用-3支付放款補(bǔ)償發(fā)生異常，重試一定次數(shù)，仍然失敗則 事務(wù)協(xié)調(diào)器調(diào)用-1進(jìn)行補(bǔ)償4發(fā)生異常，事務(wù)協(xié)調(diào)器調(diào)用-1、-2進(jìn)行補(bǔ)償，回滾3未提交的消息3啟

14、用事務(wù)消息，發(fā)生異常，重試一定次數(shù)失敗后，事務(wù)協(xié)調(diào)器調(diào)用-1、-2進(jìn)行補(bǔ)償3 發(fā)送短信保證可靠 消息發(fā)送Exactly-once保證At-least-once消費(fèi)事務(wù)注冊 TXID24思考：TCC、SAGA能解決所有問題嗎？ 強(qiáng)事務(wù)一致是客戶真正的需求 嗎？ 立等結(jié)果？ 借貸平衡？ 差錯(cuò)可調(diào)？ 風(fēng)險(xiǎn)可控？ 最實(shí)在的實(shí)踐：查詢確認(rèn)狀態(tài)再 作打算、一定要對賬！需求那點(diǎn)事， 樹和千秋的故 事研發(fā)效率提升：微服務(wù)快速集成系統(tǒng)集成架構(gòu)候選方案編排系統(tǒng)調(diào)用統(tǒng)一管理, 并有明確的流程順序.由一個(gè)中心“大腦”控制典型的編排技術(shù)架構(gòu)：ESB、activiti協(xié)同職責(zé)分明, 細(xì)節(jié)獨(dú)立.每個(gè)系統(tǒng)收到信號(hào)后啟動(dòng)事件驅(qū)

15、動(dòng)的方式，高效、低耦合優(yōu)點(diǎn):l調(diào)用簡單l流程清晰l數(shù)據(jù)狀態(tài)實(shí)時(shí)同步缺點(diǎn):l“中心大腦”服務(wù)任務(wù)過重,容易形成瓶頸l輔助服務(wù)的資源沒有有效利用l性能耦合太重, 性能隨著流程復(fù)雜度的增加而明 顯下降優(yōu)點(diǎn):l顯著消除耦合l各服務(wù)的資源利用率高缺點(diǎn):l看不到業(yè)務(wù)流程的進(jìn)展l需要額外的工作來監(jiān)控跨服務(wù)的流程, 以保 證其正確運(yùn)行l(wèi)事件必須得保證送達(dá)26研發(fā)效率提升：微服務(wù)快速集成27研發(fā)效率提升：微服務(wù)快速集成研發(fā)效率提升：微服務(wù)快速集成示例：開戶放款1、封裝成輕量級springboot服務(wù)，以代理服務(wù)的 方式注冊到Spring Cloud Data Flow2、可視化協(xié)同集成微服務(wù)，形成流程，服務(wù)間以

16、Kafka 異步消息的方式通信3、以服務(wù)聲明的方式打包成Docker鏡像并推送到K8S平 臺(tái)3，1 由K8S平臺(tái)對服務(wù)進(jìn)行容器編排和自動(dòng)部署。研發(fā)效率提升：微服務(wù)快速集成擴(kuò)展：額度占用時(shí)觸發(fā)營銷活動(dòng)，營銷微服務(wù)捕捉事件進(jìn)行消息推送基于事件進(jìn)行業(yè)務(wù)的擴(kuò)展將變得更容易和 靈活提高服務(wù)組件的重用性、開發(fā)效率可擴(kuò)展性強(qiáng)、高可用特性容易實(shí)現(xiàn)分支、判斷：通過增加中間節(jié)點(diǎn)進(jìn)行判 斷，后面的節(jié)點(diǎn)自行先判斷是否執(zhí)行流程可作為重量級流程引擎、ESB的輕量級替 代方案30系統(tǒng)靈活性提升：應(yīng)用容器化容器特征虛擬機(jī)容器硬件接口模擬仿真直接訪問OS類型通用Linux運(yùn)行模式用戶模式內(nèi)核模式隔離策略HypervisorCG

17、roup、Namespace資源損耗5%-15%5%啟動(dòng)時(shí)間分鐘級別秒級別鏡像尺寸GB-TBKB-MB集群規(guī)模100+10000+高可用策略備份、異地容災(zāi)，遷移彈性伸縮，負(fù)載均衡虛擬機(jī)更輕量、更快速、更好的可移植性更容易實(shí)現(xiàn)自動(dòng)化、更方便的配置、更容易管理簡化打包和部署，保持測試環(huán)境的一致性，減少人工維護(hù)成本容器化實(shí)踐： 搭建容器云PaaS平臺(tái)配置項(xiàng)：容器鏡像、容 器實(shí)例數(shù)、所需資源、 彈性伸縮機(jī)制健康探針 LivenessProbe、 RedinessProbe應(yīng)用商店研發(fā)模式的轉(zhuǎn)變 DevOps和持續(xù)集成北京數(shù)據(jù)中心新數(shù)據(jù)中心OracleOracle Oracle數(shù)據(jù)庫同步SWIFTSWI

18、FT中間件 同步配置中心配置中心配置信息k8s集群1應(yīng)用A Pod應(yīng)用B Pod同步鏡像 同步k8s集群n鏡像倉庫鏡像倉庫.存儲(chǔ)Ceph 磁盤存儲(chǔ)Ceph 磁盤DNS應(yīng)用C Pod應(yīng)用 Pod應(yīng)用D Pod應(yīng)用E Pod應(yīng)用F Pod應(yīng)用 Podk8s集群1應(yīng)用A Pod應(yīng)用B Pod應(yīng)用C Pod應(yīng)用 Podk8s集群n應(yīng)用D Pod應(yīng)用E Pod應(yīng)用F Pod應(yīng)用 Pod下一步：Kubernetes異地多集群容災(zāi)多集群面臨的挑戰(zhàn)：統(tǒng)一管理界面多集群應(yīng)用交付多集群統(tǒng)一監(jiān)控跨集群資源調(diào)度跨集群流量分發(fā) 鏡像倉庫、配置 信息、中間件數(shù) 據(jù)、存儲(chǔ)和數(shù)據(jù) 庫的同步行業(yè)及業(yè)務(wù)模式消費(fèi)金融系統(tǒng)架構(gòu)演進(jìn)歷程關(guān)鍵技術(shù)創(chuàng)新實(shí)踐總結(jié)與展望35總結(jié)與展望36 中郵消費(fèi)金融系統(tǒng)發(fā)展歷程1.0時(shí)代：解決從0到1的問題，單體結(jié)構(gòu)，商業(yè)中間件集成，性能、可靠性、靈活性差2.0時(shí)代：分布式重構(gòu)、服務(wù)化、去除商業(yè)中間件，性能、可靠性得到明顯