在数字化商业浪潮汹涌澎湃的当下，商户们都在积极寻求更高效、更灵活的方式来融入各类强大的平台，以提升自身竞争力。而 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消息投递通知到商户或服务商。

免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。

责任编辑：kj005

文章投诉热线:157 3889 8464  投诉邮箱:7983347 16@qq.com