前段时间我们把 CI 的构建失败通知从公司群挪到了自己手机上改动只有一行 curl。真正麻烦的不是怎么发而是选谁企业微信、钉钉、飞书、Slack、Discord、Telegram、ntfy、Pushover、Bark、Server酱、PagerDuty、Alertmanager、n8n、Apprise……名字列出来能占半屏。但它们其实不是同一层的东西。有的负责往群里喊有的负责把消息顶到你手机通知栏有的负责帮你把一次事件路由给值班的人还有的只负责把一堆异构通道收敛成一个调用。把它们平铺在一起比较就像把公路、快递公司和门铃放在同一张表里。这篇先把地图画出来外部消息通道一共分几层、每一层有哪些可选、各自的关键限制是多少以及最后一张什么场景选什么的对照表。后面两篇再讲传统业务代码里怎么把它做稳以及 Agent 时代为什么用法要重写一遍。1. 先把 Webhook 这个词拆干净很多人说接个 webhook其实指的是两件方向相反的事。出站 Webhook我主动喊别人 入站 Webhook别人喊我 业务事件 -- HTTP POST -- IM 群 GitHub PR -- HTTP POST -- 我的服务 通知 回调 / 触发器这两条链路共用一套底层动作一个 HTTP POST 一段 JSON 一个签名但设计要点完全不同出站关心可靠性与刷屏控制入站关心验签、幂等、快速响应。本篇盘点的是嘴巴出站那一侧入站会在第二篇展开。至于为什么大家都选 HTTP 而不是 MQ 来做这件事——简单理解Webhook 是跨组织的、零依赖的 RPC。对方不需要引你的 SDK、不需要开你的端口、不需要装 broker给你一个 URL 就能对接。代价是没有持久化和回溯所以任何正经系统都还要在 Webhook 之外补一层队列。Q1群机器人 webhook 和开放平台应用有什么区别这是国内 IM 特有的一个分水岭差别很大群自定义机器人企业应用应用消息 / bot创建成本群设置里点几下1 分钟拿到 URL要在开放平台建应用、申请权限、走审核鉴权方式URL 里的 key / token 就是全部凭证corpid corpsecret换 access_token还会过期能发到哪只能发它所在的那个群能发到指定人、指定部门、指定应用会话能不能收基本不能钉钉/飞书需另配回调能支持消息回调、机器人对话卡片与交互有限完整按钮回传、流式更新、卡片回调典型用途CI、监控告警、脚本提醒审批、工单、客服、Agent 对话入口做通知群机器人是性价比最高的起点做对话或需要私聊到人才值得上应用。先把这十几个名字按层摆开每层各答一个问题2. 第一层IM 群机器人——最省事的嘴巴这一层的定位是团队协作场景里的一群人同时收到不是精确叫醒某一个人。平台接入形式消息类型官方/公开口径的关键限制企业微信 群机器人POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyXXXtext / markdown / image / news / 图文 / 模板卡片约20 条/分钟markdown 子集不支持表格钉钉 自定义机器人Webhook timestampsigntext / link / markdown / actionCard / feedCard约20 条/分钟超限会被临时限流安全设置三选一关键词 / IP 段 / 加签飞书 自定义机器人POST https://open.feishu.cn/open-apis/bot/v2/hook/xxxtext / post / image / share_chat /interactive 卡片100 次/分钟 且 5 次/秒请求体≤ 20KB支持关键词 / IP 白名单 / HmacSHA256 签名Slack Incoming Webhooks每 channel 一个 URLtext Block Kit按钮、菜单、下拉单条正文约 40 000 字符上限速率按 team 计Discord Webhooks每 channel 一个 URLcontent embeds attachments单 webhook 约5 次 / 2 秒embed 有字段数上限Telegram Bot APIsendMessage?chat_idtext / MarkdownV2 / HTML InlineKeyboard需要 bot token全局约30 条/秒同一 chat 约 1 条/秒Microsoft Teams WorkflowsFlow 生成的 URLAdaptive Card老 Connector 已被 Workflow 取代这里有一个很容易被忽略的事实国内三家的卡片能力差距不小。飞书早期就把 interactive 卡片放进自定义机器人钉钉的 actionCard 也能带按钮而企业微信群机器人的 markdown 至今是受限子集表格、代码块高亮基本别指望。同一份告警文案在三个平台上的呈现效果可以差出一个档次。文案 -- 飞书 interactive 卡片字段/按钮/颜色齐活 -- 钉钉 actionCard能带按钮跳转 -- 企业微信 markdown子集复杂排版要靠模板卡片或退化成纯文本同一条文案背后是六套不同的限制横着摆开对照最后一条边界六家共用3. 第二层个人推送通道——绕开群直接顶到通知栏群机器人有个死穴它只能对着人群喊。半夜三点构建失败你在 200 人的群里被 和你在自己手机上被叫醒是两件完全不同的事。工具形态触达特点ntfy.sh开源HTTPPOST /topic即推送iOS/Android/Web无需注册、无鉴权也能用主题名就是密钥可自建服务器Bark开源iOS自己的 iPhone一个 URL 调用的 APNs/标题/内容可自建PushoverSaaSiOS / Android / 桌面一次性买断制稳定、送达率高运维圈老标配Server酱SaaS微信服务号一行 GET 就能推到微信国内脚本党常用Turbo 版按量收费PushDeer开源 云服务iOS / Android / 微信APNs 通道客户端自己也能起服务WxPusher基于公众号微信支持给订阅了的人分组精准推Gotify自托管Web / Android内网告警常用完全自主可控邮件SES / SendGrid / ResendSMTP 或 API邮箱富文本、附件、审计留痕最强实时性最差短信 / 语音外呼Twilio / 阿里云短信API手机号唯一一定会被看到的通道成本和合规也最高选型逻辑其实很简单——按必须多快被看到倒推分钟级可接受 -- 邮件 / IM 群 要被听到 -- App 推送ntfy / Pushover / Bark 必须打断我 -- 短信 / 电话 / 值班平台的 escalateQ2为什么个人推送大多要先自建或者注册一个 token因为任何能推到我手机的 URL本质上都是我的隐私入口。拿到你的 ntfy topic 名就等于能在你手机上弹任意通知。所以这类工具的默认设计都是URL 即凭证一旦提交进 Git 就等于把通知栏公开了——这也是第二篇会单独讲密钥管理的原因。4. 第三层值班与告警平台——通知只是它们的一层如果你的诉求不是发一条消息而是确保有一个人被这件事叫醒并处理完那就不该自己拼通道。这一层自己多了四件上层业务的能力事件去重、分组、静默、升级escalation。产品定位关键能力备注PagerDuty事件响应标杆值班表、多通道、Ack、升级链价格偏贵国内网络可达性一般Opsgenie曾是主流选择同上注Atlassian 已宣布 EOL服务将在 2027-04-05 终止官方指引是迁往 Jira Service Management。新项目不建议再选。Grafana OnCall / Alertmanager开源自建路由树、group_by、inhibit_rules、silenceAlertmanager 只做路由分发不做值班表夜莺 Nightingale国产开源可观测内置钉钉/飞书/企微/短信/电话等大量通知渠道适合已有监控体系直接接Uptime Kuma轻量可用性监控自带 90 通知类型可视化配置一个容器就能起个人/小团队首选Flashduty国产商业值班跨云告警聚合、降噪国内可达性好判断标准就一句话你需不需要值班表这个概念。需要就用这一层不需要自己写的重试限流就够了。5. 第四层编排与统一封装——把 N 个通道收敛成 1 个调用真正的痛点在这里如果每条通知逻辑都要写四遍企微、钉钉、飞书、邮件代码一定会烂掉。工具类型适合ApprisePython 库 / CLI用统一 URL schemetgram://、dingtalk://、mtps://…一次接100 服务最轻的方案notifyGo CLI命令行 cat msgn8n流程编排可自托管需要条件分支、审批、多路分发AI 圈用得很多Activepieces开源编排n8n 的开源替代MIT 系Make / ZapierSaaS iPaaS非技术同事也能拖数据出境和合规要评估自研 Notify Center内部服务业务方只调POST /notify {scene, payload}路由/频控/模板全在服务端业务代码 -- Notify Center一个入口-- 路由场景/严重级别/收件人 -- 渲染模板 IM 各自的 markdown 方言 -- 治理去重 / 聚合 / 频控 / 失败降级多通道大厂的消息中心基本都是这个形状。它的价值不在于少写几行 HTTP而在于把该不该发、发给谁、发几次这件事从业务代码里彻底剥离出去。6. 常见疑问Q1Slack、Discord、Telegram 在国内用不了还有必要了解吗有。原因是它们的设计更超前而国内平台在往这个方向抄。Block Kit / Adaptive Card 定义的结构化消息 交互按钮 回调这套范式如今已经是飞书卡片、钉钉 ActionCard 的模板。理解了 Slack 的 Block Kit再看飞书的卡片 JSON Schema会发现有相当多概念是逐层对应的——学习成本能复用。而且 Agent 场景里工具链默认支持的通道往往就是 Slack/Discord/Telegram能自托管的 n8n、Activepieces 也把它们列为一等公民。Q2为什么同一个 webhook 通道有时限流 20 条/分钟有时 100 条/分钟因为限制的作用域不一样有的按机器人算有的按群算有的按企业算有的按token算。钉钉的自定义机器人是每个机器人维度飞书是每个 hook维度且叠加秒级Telegram 是全局 30 条/秒外加单 chat 约 1 条/秒。别把官方文档里那个数字当成你系统的吞吐上限先确认作用域再用令牌桶把发送压到线以下。这是第二篇要讲的重点之一。Q3作为后端 / 架构我应该关注哪几个点关注点为什么Webhook URL 的保密与轮换它等于凭证泄露即可冒充你的系统对员工群发要能一键作废通道限流的作用域决定你的令牌桶放在客户端、服务端还是网关消息格式方言三家 IM 的 markdown 不通用必须有一层模板/渲染送达的可观测HTTP 200 ≠ 用户看到了要落库、要有失败重试和降级刷屏即事故告警风暴能把一个群打成废群聚合与抑制比发送本身更重要最后总结群机器人企微 / 钉钉 / 飞书 / Slack5 分钟接入、零鉴权成本做团队级通知的默认选择边界是只能发群、没有回执。个人推送ntfy / Bark / Pushover / Server酱真正能叫醒某一个人的通道其中 ntfy 和 Bark 可以完全自托管适合个人项目。值班平台PagerDuty / Grafana OnCall / 夜莺 / Uptime Kuma只有当你需要值班表、升级链和降噪时才引入Opsgenie 已进入 EOL 倒计时2027-04-05新项目别选。统一封装Apprise / n8n / 自研消息中心一旦通道超过两个这一层就从可选变成必需。对我个人后端 架构来说选择策略很固定场景我的选择团队 CI / 监控播报飞书或钉钉自定义机器人 加签只给一个人看的定时脚本ntfy 自建 或 Bark生产事故Alertmanager 路由到值班不自己实现一个服务要发 3 个以上通道抽一个 Notify Center业务侧只留一个调用把这五行摊开成一张表每行标上它落在哪一层、为什么这么定、顺序反过来会踩什么一句话结论先确定要发给一群人还是一个人再确定要不要值班和降噪通道自然就选出来了——顺序反过来一定会返工。下一篇讲传统业务代码里怎么把这条链路做稳出站签名、入站验签、幂等、退避重试、聚合抑制和限流。参考资料 致谢[1] 飞书开放平台-自定义机器人使用指南[2] 企业微信开发者中心-群机器人配置说明[3] 钉钉开放平台-自定义机器人发送群消息[4] 钉钉开放平台-自定义机器人安全设置[5] Slack API-Sending messages through incoming webhooks[6] Discord Developer Documentation-Webhooks[7] Telegram Bot API[8] ntfy.sh 文档[9] Apprise 项目主页[10] Prometheus Alertmanager 文档[11] Uptime Kuma 项目主页[12] Atlassian Opsgenie 迁移与停服说明[13] Hyperping-Opsgenie end of life timeline