引言：
在數(shù)字化商業(yè)浪潮洶涌澎湃的當(dāng)下，商戶們都在積極尋求更高效、更靈活的方式來融入各類強(qiáng)大的平臺(tái)，以提升自身競爭力。而 Webhook 技術(shù)的出現(xiàn)，為SaaS、軟件公司和商戶與斗拱之間搭建了一座便捷、高效的橋梁，讓集成變得輕松自如。
Webhook介紹
Webhook 是一種輕量級(jí)的、基于 HTTP 協(xié)議的事件通知機(jī)制。簡單來說，當(dāng)特定事件在斗拱平臺(tái)發(fā)生時(shí)，平臺(tái)會(huì)自動(dòng)向商戶預(yù)先設(shè)置好的 URL 發(fā)送 HTTP POST 請(qǐng)求，將事件相關(guān)的數(shù)據(jù)一并傳遞過去。商戶的系統(tǒng)接收到這個(gè)請(qǐng)求后，就能依據(jù)接收到的數(shù)據(jù)迅速做出響應(yīng)，執(zhí)行相應(yīng)的業(yè)務(wù)邏輯。這種機(jī)制無需商戶頻繁地去查詢斗拱平臺(tái)是否有新事件發(fā)生，大大節(jié)省了資源和時(shí)間，實(shí)現(xiàn)了真正的實(shí)時(shí)交互。
圖片來源：企業(yè)供圖
Webhook的優(yōu)勢
·數(shù)據(jù)實(shí)時(shí)同步
傳統(tǒng) API 依賴商戶主動(dòng)調(diào)用獲取數(shù)據(jù)，如同一次次敲門詢問，效率低且易因請(qǐng)求頻率不當(dāng)浪費(fèi)資源。Webhook 則是平臺(tái)主動(dòng)推送數(shù)據(jù)，類似平臺(tái)主動(dòng)將新內(nèi)容送上門，大大提升數(shù)據(jù)交互實(shí)時(shí)性，讓商戶能迅速響應(yīng)平臺(tái)事件，抓住商業(yè)契機(jī)。
·高度靈活
傳統(tǒng) API 接口和數(shù)據(jù)格式固定，商戶業(yè)務(wù)流程稍有變化，如需特定事件額外數(shù)據(jù)，往往需平臺(tái)方額外開發(fā)或復(fù)雜改造現(xiàn)有接口，過程繁瑣耗時(shí)。Webhook 允許商戶自主訂閱感興趣的事件，依據(jù)自身業(yè)務(wù)邏輯自由解析、處理數(shù)據(jù)，無論是新增業(yè)務(wù)環(huán)節(jié)還是優(yōu)化現(xiàn)有流程，都能靈活應(yīng)對(duì)，有力支持商戶創(chuàng)新發(fā)展。
·接入門檻低
開發(fā)傳統(tǒng) API，商戶需深入學(xué)習(xí)平臺(tái)特定接口規(guī)范，處理認(rèn)證、調(diào)用邏輯及接口版本兼容等復(fù)雜問題，開發(fā)難度大、周期長、成本高。Webhook 基于簡單的 HTTP 協(xié)議，開發(fā)人員無需耗費(fèi)大量時(shí)間學(xué)習(xí)復(fù)雜接口知識(shí)，僅需專注處理平臺(tái)推送的數(shù)據(jù)，極大降低開發(fā)門檻和成本，使更多商戶能夠快速實(shí)現(xiàn)與平臺(tái)集成。
·降低系統(tǒng)間耦合性
Webhook 打破了傳統(tǒng)系統(tǒng)間剛性連接的束縛，實(shí)現(xiàn)了一種松耦合的連接模式。其基于事件驅(qū)動(dòng)架構(gòu)，系統(tǒng)間的交互由明確的事件觸發(fā)。每個(gè)系統(tǒng)僅需關(guān)注自身產(chǎn)生的特定事件以及對(duì)感興趣事件的響應(yīng)，無需對(duì)其他系統(tǒng)的整體運(yùn)行狀態(tài)保持緊密關(guān)注。各系統(tǒng)僅在特定事件發(fā)生時(shí)，依據(jù) Webhook 傳遞的信息進(jìn)行交互，交互邊界清晰明確，減少了不必要的系統(tǒng)間依賴，降低了耦合度，實(shí)現(xiàn)了柔性連接。
助力商戶靈活接入
作為一家第三方支付公司，我們依托公司的全棧支付處理、數(shù)據(jù)集成、運(yùn)營服務(wù)與軟件開發(fā)PaaS平臺(tái)——斗拱，為各行各業(yè)的廣大行業(yè)客戶與中小微商戶提供支付服務(wù)，同時(shí)助力其實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型。
斗拱沒有在交易的主流程上通過Webhook來同步狀態(tài)，交易主流程注重高性能，高穩(wěn)定性，要求定義清晰，實(shí)現(xiàn)規(guī)范。而對(duì)于非交易流程來說，其業(yè)務(wù)和系統(tǒng)就非常的靈活多變，且可能非常繁雜。這些系統(tǒng)同樣依賴斗拱平臺(tái)上的數(shù)據(jù)與狀態(tài)，此時(shí)他們同樣需要去對(duì)接斗拱接口API或者跟商戶自己的交易系統(tǒng)同步狀態(tài)。
在這種情況下，商戶的對(duì)接工作就非常的不靈活，且對(duì)接工作繁重，系統(tǒng)間的耦合性也會(huì)越來越大。所以，斗拱內(nèi)部的數(shù)據(jù)與狀態(tài)全面支持Webhook, 將大量的事件標(biāo)準(zhǔn)化定義，靈活的提供給商戶選擇。
目前，通過Webhook技術(shù)，商戶的各類子系統(tǒng)僅需配置一個(gè)Webhook訂閱，就能輕松同步各類狀態(tài)的完整變化，實(shí)現(xiàn)靈活接入斗拱系統(tǒng)。同時(shí)也賦予商戶系統(tǒng)自主演進(jìn)的活力，商戶的各個(gè)系統(tǒng)得以根據(jù)自身業(yè)務(wù)發(fā)展的獨(dú)特需求，獨(dú)立開展功能迭代與技術(shù)升級(jí)工作。不同系統(tǒng)的開發(fā)團(tuán)隊(duì)可以按照各自的節(jié)奏推進(jìn)項(xiàng)目，無需擔(dān)憂對(duì)其他關(guān)聯(lián)系統(tǒng)造成不必要的干擾或影響。
·Webhook場景示例
商戶做完交易后，除了交易系統(tǒng)，其他系統(tǒng)同樣也依賴交易相關(guān)的狀態(tài)與數(shù)據(jù)，以進(jìn)行業(yè)務(wù)的流轉(zhuǎn)和推動(dòng)。比如，商戶財(cái)務(wù)系統(tǒng)訂閱結(jié)算類事件，銀行入賬類事件；商戶CRM系統(tǒng)訂閱入駐類事件（子商戶） 等等。
如果采用傳統(tǒng)的對(duì)接Api的方式，商戶開發(fā)人員需要閱讀大量接口Api文檔，并且逐個(gè)系統(tǒng)進(jìn)行接口對(duì)接。同時(shí)還要設(shè)計(jì)高效可靠的輪詢保證數(shù)據(jù)能夠有效獲取。這種方式，在實(shí)時(shí)性方面是低效的；在對(duì)接成本方面，是高開銷的；在后續(xù)可維護(hù)性方面，由于其復(fù)雜性，也是非常不利的。
圖片來源：企業(yè)供圖
用戶訴求與解決
隨著數(shù)字化進(jìn)程的深入，我們的用戶（接入商戶）也在飛速發(fā)展，他們的功能也越來越多元化，Webhook系統(tǒng)需要能支撐和應(yīng)對(duì)用戶各種場景的訴求。在實(shí)際的使用過程中，我們也遇到了很多問題，下面我們從用戶實(shí)際業(yè)務(wù)場景出發(fā)，來看看我們是如何幫助用戶解決這些問題的。
● 商戶故障恢復(fù)：
問題描述：接入的商戶，在其自身系統(tǒng)出現(xiàn)故障，并且故障不能短暫處理好的情況下，我們的Webhook默認(rèn)重試機(jī)制（重試三次）走完后，會(huì)認(rèn)為系統(tǒng)不可達(dá)，而放棄投遞。從商戶角度來看，很多的訂單狀態(tài)或者付款狀態(tài)是不完整或者已經(jīng)丟失了的，在商戶系統(tǒng)恢復(fù)后，還得和我們的系統(tǒng)對(duì)接，雙方排查數(shù)據(jù)手動(dòng)補(bǔ)齊狀態(tài)，使得商戶的恢復(fù)工作增加了很多復(fù)雜性。
我們需要減少商戶系統(tǒng)掛掉恢復(fù)以后的數(shù)據(jù)不一致性，所以不同的商戶，我們應(yīng)能提供適合于其自身情況的重試策略。
解決：很容易想到，可以使用延時(shí)消息來支持用戶任何間隔策略的重試。但其帶來了每次重試，都要發(fā)送一次延時(shí)消息的額外開銷。在普通場景里，他的開銷并不大。但在一些熱點(diǎn)系統(tǒng)故障時(shí)，會(huì)出現(xiàn)大規(guī)模的重試，從而導(dǎo)致很大量的消息投遞。
本文中出現(xiàn)的Archer是指匯付自研的分布式消息平臺(tái)。
圖片來源：企業(yè)供圖
有沒有可能既滿足重試要求，又不增加額外的開銷？
我們注意到，盡管用戶重試的策略會(huì)很靈活，但并不是完全沒有規(guī)律的。比如，重試間隔設(shè)置為 1h03m(一小時(shí)零三分)是不太有意義的，在重試場景中，完全可以使用1h(一小時(shí))來替代。據(jù)此，我們統(tǒng)計(jì)出用戶常見需要的時(shí)間間隔，并將這些間隔讓用戶自由選擇，同樣可以實(shí)現(xiàn)靈活的重試間隔。
可選間隔如下：1s 2s 3s 5s 10s 20s 30s 1m 90s 2m 3m 5m 10m 20m 30m 1~23h 1~3d
這個(gè)間隔，我們通過定制消息系統(tǒng)（Archer）來實(shí)現(xiàn)。在Archer中通過設(shè)定特殊化的消息重試時(shí)間的方式，使得Webhook的事件重試，不需要自己重新發(fā)送。
圖片來源：企業(yè)供圖
使用舉例：假設(shè)商戶需要初始 3分鐘，后續(xù)每次間隔一小時(shí)的重試，總共一天。則其可以將重試策略配置成 3m,1h,1h,1h… 重復(fù)24次。最終，我們通過提供靈活且長時(shí)間的重試策略，最長可達(dá)三天，在商戶遇到較大故障時(shí)，仍能保障其最終的訂單能夠得到正確的處理，減少其在系統(tǒng)恢復(fù)過程中的復(fù)雜性和工作量。
● 事件通知時(shí)效性：
問題描述：商戶對(duì)于交易狀態(tài)的推送，時(shí)效性要求非常高。 比如某連鎖行業(yè)的商戶事件推送非常多，通知延遲對(duì)他的影響是用戶付款排長隊(duì)，該情況是無法接受的，又比如在小微商戶接入場景中，有非常多的商戶，但他們同樣要求及時(shí)的推送。我們遇到過同一個(gè)商戶不同訂閱系統(tǒng)之間推送互相影響，也遇到過大量小商戶之間互相搶占資源的問題。
解決：因?yàn)橄到y(tǒng)的資源是有限的，所以在給商戶推送過程中，假如有商戶的訂閱地址失敗或者非常慢，那么在交易量較大的情況下，必定產(chǎn)生大量的積壓事件，無法通知出去，同時(shí)也可能影響其他商戶的通知。我們無法對(duì)數(shù)萬、甚至數(shù)十萬的商戶訂閱都做完全的隔離并分配資源，即不能僅通過擴(kuò)大資源規(guī)模來解決問題。我們采取了以下方式來緩解積壓問題:
1、失敗隔離
我們將失敗的推送重試和正常推送完全隔離，因?yàn)槭〉耐扑椭卦嚂?huì)大量占用資源。通過隔離，正常的推送邏輯能極大的改善性能。
2、自動(dòng)降級(jí)
我們通過制定平均耗時(shí)、失敗率、事件推送積壓數(shù)等一系列指標(biāo)來判定商戶訂閱的健康程度，并據(jù)此自動(dòng)應(yīng)用相應(yīng)的降級(jí)策略。系統(tǒng)會(huì)自動(dòng)統(tǒng)計(jì)一段周期內(nèi)商戶事件推送的各項(xiàng)指標(biāo)，并根據(jù)預(yù)先設(shè)置好的閾值來判斷商戶狀態(tài)，狀態(tài)包括以下三種：健康、亞健康、不健康。
對(duì)于不健康的商戶，我們會(huì)將其資源和正常資源隔離，使之不會(huì)影響正常商戶的事件推送，并通知運(yùn)營人員關(guān)注。而亞健康的隊(duì)列，我們暫不對(duì)其降級(jí)處理，但會(huì)發(fā)出通知進(jìn)行持續(xù)關(guān)注。通過自動(dòng)降級(jí)措施，使主推送流程減少了大量的問題商戶推送，提升了整體推送的及時(shí)性。
3、VIP 商戶
我們的商戶，通過一定的策略，會(huì)分配相應(yīng)的推送資源，默認(rèn)情況下，多個(gè)商戶共用推送資源，存在互相影響的可能性。
我們對(duì)于重點(diǎn)商戶，訂單量大的商戶，提供重點(diǎn)保障，給與VIP待遇。VIP商戶的推送資源是獨(dú)立的，不共享的，可以杜絕突發(fā)情況下的互相影響，最大程度的保證VIP商戶的推送及時(shí)性。
4、快速黑名單
在緊急情況下，我們可以手動(dòng)設(shè)置拒絕某些出現(xiàn)問題的商戶的訂閱的推送。以保障其余部分商戶推送的時(shí)效性。被黑名單拒絕的事件推送，在商戶問題恢復(fù)后，后續(xù)仍可以進(jìn)行補(bǔ)推。
通過以上方式，我們大大提升了在大量商戶，海量事件推送情況下的時(shí)效性，成功解決了連鎖行業(yè)推送既多又快的性能問題，也基本解決了大量商戶之間推送互相影響的問題。在實(shí)際使用過程中，基本已經(jīng)不再出現(xiàn)商戶事件大量延遲投遞的現(xiàn)象。
● 商戶下屬機(jī)構(gòu)訂閱：
問題描述：商戶通常根據(jù)商戶號(hào)來訂閱屬于自己的事件，不可以訂閱其他不相關(guān)商戶的事件。但是在渠道商，代理商或者pos機(jī)服務(wù)商擁有很多接入斗拱的子商戶的情況下，他們想做一些自身體系內(nèi)全局統(tǒng)一的功能時(shí)，比如費(fèi)用計(jì)算，統(tǒng)一分潤等，就需要獲得所有子商戶的入駐，功能開通，交易，付款等等信息。在這種場景下，我們就要支持商戶訂閱所有其下屬機(jī)構(gòu)的事件。
解決：我們注意到，此功能需要依賴完整的商戶層級(jí)信息，也就是依賴于商戶管理系統(tǒng)。我們試圖同步商戶的完整層級(jí)信息，在事件發(fā)生時(shí)，通過儲(chǔ)存的商戶層級(jí)信息，查詢匹配符合條件的所有訂閱商戶（包括所有父商戶）進(jìn)行投遞。這不是一個(gè)好的選擇，一來增加了系統(tǒng)的外部強(qiáng)依賴，對(duì)后續(xù)的修改也非常不友好。二來通過接口同步的信息，在頻繁變更的情況下，保證一致性的代價(jià)很高。
最終我們將這塊邏輯重新定義成統(tǒng)一接收下屬機(jī)構(gòu)Webhook事件的通用功能。在事件產(chǎn)生時(shí)，其生產(chǎn)方，也就是斗拱系統(tǒng)，就增加對(duì)應(yīng)的商戶層級(jí)信息，在Webhook系統(tǒng)投遞處理時(shí)只需查看這些相關(guān)商戶的訂閱是否開啟接收下屬機(jī)構(gòu)，便可以判斷具體需要投遞的訂閱商戶有哪些。
圖片來源：企業(yè)供圖
● 流量爆發(fā)增長：
問題描述：商戶在進(jìn)行大促，秒殺之類活動(dòng)的時(shí)候，會(huì)帶來流量的突發(fā)巨幅的增長。就比如最近某連鎖品牌的聯(lián)名促銷活動(dòng)，給我們帶來瞬時(shí)流量暴增百倍的挑戰(zhàn)。
解決：基于這樣的挑戰(zhàn)，我們的架構(gòu)必須穩(wěn)定高效，同時(shí)也需要能快速靈活的伸縮來適應(yīng)暴增的流量。
·穩(wěn)定高效
在Webhook中，我們的事件發(fā)送都會(huì)由前置應(yīng)用路由到Archer消息隊(duì)列，然后由發(fā)送集群接收消息并完成投遞過程。 Archer作為匯付自研的分布式消息平臺(tái)，經(jīng)過多年持續(xù)的投入建設(shè)，具備高吞吐，毫秒級(jí)響應(yīng)，高穩(wěn)定性等卓越能力。通過Archer的能力加持，保證了Webhook系統(tǒng)能應(yīng)對(duì)海量事件推送，具備高性能處理，低延時(shí)響應(yīng)，極高穩(wěn)定性等特點(diǎn)。
圖片來源：企業(yè)供圖
·靈活伸縮
在流量暴增的場景下，系統(tǒng)資源往往是不夠的。在這種情況下，我們一定要有靈活伸縮能力，使得系統(tǒng)能夠快速的擴(kuò)容至所需容量，以應(yīng)對(duì)商戶需要。
Webhook 通過前置應(yīng)用，可以靈活地將流量分配到不同的Webhook發(fā)送集群，不同的Archer消息集群，不同的數(shù)據(jù)庫上。單個(gè)數(shù)據(jù)庫，單個(gè)消息集群，能力再強(qiáng)，都有上限，我們消除了所有能導(dǎo)致資源瓶頸的單點(diǎn)。
我們支持 Webhook集群內(nèi)部擴(kuò)容和集群間擴(kuò)容兩種擴(kuò)容方式。集群內(nèi)部擴(kuò)容通過在小范圍（集群內(nèi)）增加發(fā)送應(yīng)用節(jié)點(diǎn)數(shù)量，來提高集群的吞吐能力。集群間擴(kuò)容通過增加一個(gè)或若干個(gè)集群使整體服務(wù)能力得到增長。通過k8s的能力，我們能靈活的擴(kuò)容出所需要的應(yīng)用節(jié)點(diǎn)，劃分出新的集群，再通過前置應(yīng)用的路由能力，可以靈活的將流量引入新的集群。
通過分鐘級(jí)的擴(kuò)容能力，我們可以應(yīng)對(duì)各種商戶活動(dòng)場景的爆發(fā)流量，保障商戶活動(dòng)的正常進(jìn)行。
圖片來源：企業(yè)供圖
實(shí)施效果
通過以上這些場景的處理，我們滿足了用戶的訴求，提供給商戶靈活且完善的Webhook能力。
目前我們的Webhook系統(tǒng)支持匯付斗拱平臺(tái)上百種交易的自定義事件、百萬級(jí)商戶訂閱事件，可承載斗拱平臺(tái)日均億級(jí)的交易量，支持億級(jí)Webhook消息投遞通知到商戶或服務(wù)商。
