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