事件消息对接

概述

开发者应用下的设备产生的动检报警、上下线时间、各类智能事件消息等，可以通过两种平台消息方案进行对接。分别是：

方案一：开放平台主动推送事件到开发者的消息接收地址，即平台主动推送（推送模式）；
方案二：开发者通过消息通道方案，按需来开放平台消费事件，即消息通道订阅（拉取模式）。

当开发者的后台接收到开放平台事件消息后可进行后续的处理，如再次推送到自己的终端用户侧。

方案对比和推荐

对比维度	平台主动推送（推送模式）	消息通道订阅（拉取模式）
消息实时性	高，近乎实时。平台一旦产生消息，会立即主动发送给开发者。	较低，存在延迟。消息临时存储在通道中，等待开发者下次拉取。拉取间隔直接影响实时性，文档建议间隔需在30秒以内。
服务端资源消耗	较高，有峰值风险。平台需处理大量并发推送，开发者服务器也需应对突发的高流量推送。	可控，较低。开发者根据自己的节奏拉取，服务器压力平稳。但需要维护与消息通道的长连接。
开发与运维复杂度	较低。开发者只需提供一个标准的Webhook回调地址来接收POST请求，实现一个消息处理接口即可，无需关心消息存储和状态管理。	中等。需实现拉取逻辑、管理消费者实例和偏移量，并处理状态管理。例如： 1. 每个消费组最多3个消费者，需自行管理其生命周期。 2. 需正确处理偏移量，避免消息重复或丢失。
可靠性	依赖开发者服务。若开发者服务宕机或网络故障，消息可能推送失败。	高。消息在通道中保留2天，给开发者充足的时间来处理故障和恢复消费，不易丢失。
安全性	需额外加固。开发者需暴露一个公网可访问的URL。	较高。开发者主动发起连接，无需向平台暴露内部服务入口，减少了攻击面。
适用场景	适用于对实时性要求极高的场景，如安全告警、紧急事件通知、交易状态变更等，需要秒级触达。	适用于对实时性要求不高、消息量大且平稳、或开发者服务能力有限的场景。例如，批量处理设备上报的每日统计数据。

方案选型建议 综合来看，选择哪种方案取决于您的具体业务需求，您可以参考以下因素进行判断：

1、如果您业务有以下要求，推荐优先选择“平台主动推送（推送模式）”的方式：

您的业务要求消息必须被立即处理，例如接收到“人员倒地”或“区域人数超限”等报警消息后需立刻响应。
您希望降低开发复杂度，只需实现一个消息接收接口，而不用处理复杂的拉取、偏移量管理等逻辑。
您的开发者服务器具备足够的性能和弹性，能够应对平台推送的流量高峰。

2、如果您业务有以下要求，推荐优先选择“消息通道订阅（拉取模式）”的方式：

您的业务可以容忍秒级甚至分钟级的延迟。
您希望最大化消息可靠性，即使自身服务短暂故障，重启后也能从通道中拉取到积压的消息。
您希望降低服务端资源消耗，按需拉取，避免被突发流量冲垮。
您希望简化安全配置，无需对外开放服务接口。

3、如果您的业务同时包含实时告警和批量数据处理两种需求，也可以考虑将两种方案结合使用：既用平台主动推送方式，接收关键告警事件；又用消息通道订阅方式，定时拉取非关键事件。

一、平台主动推送（推送模式）

参考平台主动推送（推送模式）教程，进行对接。

二、消息通道订阅（拉取模式）

申请消息通道权限

先提交技术工单申请开通消息通道权限；或通过联系我们渠道，进行项目咨询申请权限。

申请审批通过后，参考消息通道订阅（拉取模式）教程，进行对接。