事件驅動型微服務架構的實踐-畢成功.pdf

《事件驅動型微服務架構的實踐-畢成功.pdf》由會員分享，可在線閱讀，更多相關《事件驅動型微服務架構的實踐-畢成功.pdf（22頁珍藏版）》請在三個皮匠報告上搜索。

1、事件驅動型微服務架構的實踐華泰證券/畢成功刪除水印WondersharePDFelement背景簡介哈爾濱工業大學07級計算機碩士。在十余年的職業生涯中，致力于軟件開發和團隊管理工作，涉足過搜索、手游、O2O、電商、金融等多種領域，并有過多次創業經歷。2021年加入華泰證券，帶領FICC平臺架構團隊，負責大象交易系統的平臺架構工作。目前主要著力于建設具有“超低延時、內存計算、事件驅動”的金融型架構體系。畢成功大象交易平臺大象交易平臺是FICC多資產實時定價、做市和風險對沖平臺。在量化做市交易領域以“極速交易極速交易”、“實時風控實時風控”、“策略驅動策略驅動”和和“投資管理投資管理”四項核心能

2、力為服務底座，提供了覆蓋境內外、跨市場、全資產交易品種的低延時極速交易與風控能力、全自動量化定價與策略做市報價能力以及實時全景風險指標監控與風險對沖能力。大象平臺建設了“交易員工作站交易員工作站”、“風險與投資管理中心風險與投資管理中心”和和“策略研發工作策略研發工作室室”三大應用終端，為相關部門固定收益做市交易各崗位用戶提供專業用戶體驗。平臺支持公司現券、IRS、國債期貨、債券通等做市業務快速發展，做市報價數量、質量及市場大幅波動時風險控制能力都極大增強，綜合報價能力位居同業前列。近期榮獲中國人民銀行頒發的金融科技發展一等獎 2023年斬獲中國外匯交易中心“年度市場影響力機構”和“市場創新業

3、務機構”等獎項 榮獲三家政策性銀行頒發的“優秀做市商”.共計14個獎項榮譽榮譽CONTENTS01經典微服務架構的問題The problems of traditional MS-Arch02事件驅動型架構的方案T h ed e s i g n so fE D A03事件驅動型架構的問題T h ep r o b l e m so fE D A04總 結 和 推 薦 建 議S u m m a r ya n dr e c o m m a n d s01 經典微服務架構的問題這真的是銀彈嗎？耦合問題p上下游服務強依賴 服務的穩定性差 要降級處理地方的太多p調用鏈長 穩定性進一步下降 接口性能下降p數

4、據庫依然是中心節點 數據庫的穩定性影響大 數據庫是整體瓶頸，難擴展接膨脹問題數據操作的場景多調用關系復雜不同場景技術選型的權衡VS互聯網場景高吞吐快速開發易擴容.金融交易場景低延遲高穩定性復雜業務的易維護.02 事件驅動型架構的案模塊化和簡單性是軟件工程的基石。蒂姆伯納斯李EDA主要特征本質上是對數據依賴的解耦！服務之間的關系發生變更p轉變一：異步化 無需同步等待 支持一對多p轉變二：數據自治 自主訂閱，本地保存 本地數據調用DB依賴接口膨脹避免了上下游依賴調用鏈長避免了事件的類型與特征DataQueryCommand有狀態變更無狀態變更Data驅動Request驅動tradeorder()g

5、etOrders()不用RPC?數據：存哪里天然的CQRS（Command Query Responsibility Segregation）命令對數據的影響p模式一：本地緩存l 數據讀取加速l 避免對上游的依賴p模式三：可選快照文件l 數據獲取加速p模式二：旁路集中存儲l 獲取未緩存的數據l 內存狀態的恢復數據：存儲結構流水物化(materialization)Data1(v1)Data2(v1)Data3(v1)Data1(v2)Data2(v2)Data1(v3)Data1(v1)Data2(v1)Data3(v1)Data1(v2)Data2(v1)Data3(v1)Data1(v2)

6、Data2(v2)Data3(v1)Data1(v2)Data2(v2)Data3(v1)Data4(v1)Data1Data4Data2用于歷史回放用于查詢或快速恢復Data1Data2Data1append-only modeupsert mode數據：怎么獲取原則：用統一的方式獲取上游數據，不論是query還是sub（非OLAP場景）推論一：數據獲取都采用SQL描述l 總線的訂閱分發模式不支持SQL，需要改造l query就是對歷史數據的sub推論二：sub和query用同一個SQLl 但query歷史數據比sub會多一個范圍條件l query與sub的能力對等，query需要閹割可用性

7、：內存狀態的異?；謴蛁&s（query and subscribe）即組合查詢和訂閱的邏輯實現原子語義，用于服務重啟后的內存狀態恢復。p方式一：從流水恢復 query要增加范圍條件 與sub的邏輯完全一致p方式二：從快照恢復 query條件要映射到對應的快照文件 query的數據要定制處理邏輯可用性：有狀態服務的高可用同步消費狀態同步優勢：主備獨立、無交互，運行延遲最低劣勢：需要支持內存的日志同步 同步過程會有額外代價，可采用事后異步+補償 臨界會有重復消費保證不丟，所以對冪等性有強要求復用回放恢復的邏輯數據庫主備復制的邏輯劣勢：要保證兩邊執行的一致性，有些情況只能串行，一方面對開發有侵入性，

8、另外限制了并發能力 難以對賬機制，問題難發現，也難做補償 主備切換需依賴總線能力支持優勢：對代碼邏輯侵入性低，支持并發處理 通用性強，不依賴總線支持03 事件驅動型架構的問題如果我不能比這世界上最聰明的人更能反駁這個觀點，我就不配擁有這個觀點。查理芒格事務難以支持分布式+異步A：AtomicityC：ConsistencyI：IsolationD：DurabilityBASE是常規思路需要支持Batch能力msgIdclassTypeserializationTypebatchIdbatchCntbatchSeqpayload數據包頭client.pub(,);void onSubMessag

9、e(,);批量回調&事務寫入異步通訊更需要管理p開發態定義 統一管理 規則嚴控矛盾點：異步就是為了松耦合，那如何避免用亂了?圍繞Topic&DTO進行管理p運行態生產/消費 增強可觀測性 流控（兜底保護）總線天生的集中式風險 每個場景一套自己專用的總線，避免有任何的互相交叉。但這要求業務場景本身天然存在這種劃分。最好是完全隔離 每個服務根據自己的使用場景，接到對應的總線上，能保證在效率上是最優的。但這要求對應的配套管理能力要跟上，避免混亂和使用上的復雜性。正常采用多接 橋接會增加整個鏈路的復雜度以及延遲，而橋接服務本身又是一個穩定性的風險點。建議只有主路對旁路的數據拷貝才采用此種方式。旁路采用橋接總結和推薦建議建議一必須能接受最終一致性的場景 采用EDA模式進行開發，以異步通訊來避免同步等待 把高可用、高擴展等特性放到第二目標建議二開始時局部使用，但上下游要包含進來 異步帶來運行上的靈活性，也帶來了管理上的復雜性，需要有中臺來在開發階段進行約束 市面上沒有成熟的EDA架構，很多能力還依賴于自研建議三若想真正提升生產力，中臺投入是必須的 此架構與傳統差異較大，對開發模式是有沖擊的，推廣是存在較大難度 需上下游整體切換才能更好的發揮EDA架構的優勢在復雜業務場景中才值得考慮前提