閑魚同城第三方對接架構(gòu)設(shè)計
時間：2021-08-19 16:29:55
手機看文章
掃描二維碼
隨時隨地手機看文章
[導(dǎo)讀]背景閑魚同城作為閑魚本地生活的主戰(zhàn)場，維護閑魚基本盤閑置物品的同時，還針對閑置時間和閑置空間場景進行相關(guān)的孵化。于買家而言：淘到經(jīng)濟實惠的閑置物品（二手?jǐn)?shù)碼），打發(fā)閑置時間（兼職，服務(wù)）去掙錢。于賣家而言：閑置物品（二手?jǐn)?shù)碼）賣錢，閑置空間（二手房租賣）換錢。閑置時間（兼職）和閑...
背景
閑魚同城作為閑魚本地生活的主戰(zhàn)場，維護閑魚基本盤閑置物品的同時，還針對閑置時間和閑置空間場景進行相關(guān)的孵化。于買家而言：淘到經(jīng)濟實惠的閑置物品（二手?jǐn)?shù)碼），打發(fā)閑置時間（兼職，服務(wù)）去掙錢。于賣家而言：閑置物品（二手?jǐn)?shù)碼）賣錢，閑置空間（二手房租賣）換錢。閑置時間（兼職）和閑置空間（租房）區(qū)別于同城傳統(tǒng)的閑置物品，閑置物品為傳統(tǒng)的C2C的商品，也就是買賣雙方均為C端的用戶。但是對于兼職、租房等業(yè)務(wù)來說，需要供應(yīng)商入駐提供供給。因此一旦涉及到第三方提供的供給，就不得不面臨以下問題：
- 隨著業(yè)務(wù)的不斷發(fā)展，必將有越來越多的供應(yīng)商入駐。為了能讓供應(yīng)商快速接入，除了必備的接入文檔之外在技術(shù)側(cè)應(yīng)該能有一套動態(tài)響應(yīng)機制，防止在供應(yīng)商接入的過程中被問題頻繁的打斷（雙方數(shù)量對不齊、同步失敗原因等）。
- 每個供應(yīng)商的供給質(zhì)量和技術(shù)水平存在差異，如何控制好供給質(zhì)量的同時保證服務(wù)的穩(wěn)定性成為另一大關(guān)鍵因素。
技術(shù)方案
整體架構(gòu)
整體架構(gòu)設(shè)計會復(fù)用中臺的一些基礎(chǔ)能力，比如用戶、商品、交易等。抽象出三個領(lǐng)域，商家域、審核域和獨立業(yè)務(wù)域（每個業(yè)務(wù)可以單獨劃分）。安全生產(chǎn)層面，為了保證系統(tǒng)的穩(wěn)定性，圍繞限流（高并發(fā)下限流重試） 監(jiān)控（對異常的狀態(tài)出對應(yīng)的報警） 數(shù)據(jù)安全（重試下情況下保證冪等性）展開。數(shù)據(jù)對賬
注：- 審核：復(fù)用了審核中心的能力（機審 人審）。機審：預(yù)置過濾規(guī)則，不滿足過濾規(guī)則的判定為審核失敗。
- 開放接口能力：提供查詢商品審核、校驗操作日志。
異?；卣{(diào)
- 收到同步消息后會對數(shù)據(jù)進行校驗，包括不限于數(shù)據(jù)字段合規(guī)性校驗（長度、枚舉值等）、夾帶違禁詞、狀態(tài)更新異常（已經(jīng)下架的寶貝執(zhí)行下架動作）等。
- 針對上述初審?fù)ㄟ^，會進入審核中心二次審核，審核主要內(nèi)容為語義違規(guī)。
通過catch(LocalBizException e)的方式，將e.getCode()**和e.getMessage()**封裝為response進行返回，不需要對不同的異常進行單獨catch讓異常邏輯在業(yè)務(wù)回調(diào)側(cè)閉環(huán)。供應(yīng)商獲取到錯誤信息后根據(jù)錯誤信息修改信息進行二次同步。定時播報
采集狀態(tài)變更日志表和業(yè)務(wù)商品表將對應(yīng)的一個小時內(nèi)發(fā)生狀態(tài)轉(zhuǎn)化的商品數(shù)量（上架、下架、編輯、審核不通過等）最后以釘釘消息播報到釘釘群中（按照釘釘?shù)臋C器人api）。兼職中主要關(guān)心的指標(biāo)項為上下架成功與否、是否審核失敗等指標(biāo)，兼職播報架構(gòu)如下圖所示：開放接口
與此同時開放的接口能力提供查詢商品審核、校驗操作日志。接口定義如下，提供時間范圍、同步id、類型、分頁參數(shù)等信息。注：涉及圖中狀態(tài)日志表和商品表的插入部分參見下一章節(jié)“穩(wěn)定性”。穩(wěn)定性（安全生產(chǎn)）
穩(wěn)定性治理一直是一個系統(tǒng)繞不開的話題，在這個場景中涉及到第三方之間的交互，誰都無法確定對方是如何調(diào)用己方的系統(tǒng)。這種情況下，穩(wěn)定性的重要性更加不言而喻。流量控制
在數(shù)據(jù)同步時，將請求打入隊列對于第三方的同步請求使用異步返回。打入隊列的好處就是可以利用隊列實現(xiàn)流量控制，削峰填谷。限流這部分依賴于阿里開源的Sentinel框架，網(wǎng)上對于Sentinel的分析很多這里不多加贅述。數(shù)據(jù)一致性保證
由于存在重試操作，所以必然需要在重試過程中保證數(shù)據(jù)的正確性。- 狀態(tài)變更日志表：數(shù)據(jù)庫采用的是nosql的數(shù)據(jù)庫，這邊會根據(jù)參數(shù)生成唯一id，進行覆蓋插入保證數(shù)據(jù)的唯一性。
- 業(yè)務(wù)商品表：采用先查后插的方式，同時利用分布式鎖 itemId唯一鍵沖突保證數(shù)據(jù)的唯一性。
異常監(jiān)控告警
攻擊流量通常會偽裝成正常流量進入。在這種情況下，系統(tǒng)會一直無法消費此異常消息，所以這邊設(shè)置一個消費重試閾值，如果達到上限后對消息進行丟棄，同時進行系統(tǒng)告警（有的場景是需要強一致性保障，此時報警后需人工接入排查）。兼職業(yè)務(wù)的告警場景包括：- 限流觸發(fā)報警（持續(xù)時間超過10分鐘）：限流期間被限制的消息業(yè)務(wù)會主動進行重試，控制重試n次整體持續(xù)時間不會超過10分鐘，如果限流超過10分鐘認定為異常情況會進行告警。（通常來說是供應(yīng)商大批量上下架崗位導(dǎo)致，未通知前提下認定為他們系統(tǒng)問題）
- 狀態(tài)更新失?。ǔ掷m(xù)時間超過5分鐘，每分鐘數(shù)量大于n）：小批量的更新失敗可以理解為是垃圾數(shù)據(jù)，持續(xù)時間過于長可以理解為供應(yīng)商系統(tǒng)異常。
總結(jié)和展望
本章節(jié)主要介紹了閑魚同城業(yè)務(wù)在“閑置時間”和"閑置空間“場景下針對與第三方系統(tǒng)對接的過程中開發(fā)資源和穩(wěn)定性問題展開。通過上述方案也解決了在開篇提到的2個問題：- 動態(tài)響應(yīng)機制：商品同步時通過實時回調(diào)和異步回調(diào)的方式將商品的每個異常狀態(tài)返回給供應(yīng)商；提供了小時時間維度的統(tǒng)計播報，最后以釘釘消息通知至釘釘群中，如若發(fā)現(xiàn)異常也可根據(jù)開放接口去查詢商品歷史變更狀態(tài)。這樣就能很大程度上解放開發(fā)，不會因為對賬的問題被頻繁的打斷。
- 穩(wěn)定性治理：通過接口限流保證異常流量打滿線程池進而影響系統(tǒng)；通過接口冪等保證數(shù)據(jù)的安全唯一性；通過監(jiān)控（搭配合適的報警規(guī)則）去監(jiān)控異常場景，如若出現(xiàn)問題人為介入。
- 抽象出獨立業(yè)務(wù)域中的共同點，推動業(yè)務(wù)完善路徑：完善租房的訂單和履約路徑，統(tǒng)一抽取出訂單域和履約域。
- 針對不同業(yè)務(wù)的不同商家統(tǒng)一商家管理平臺，現(xiàn)階段每個業(yè)務(wù)都有自己的一套接入方式。
下載文檔
