有些通讯工具具有一种消息推送能力，服务器通过一个生成的 URL 借助某个代理向客户端推送它想推送的消息。
你关注了很多公众号，有没有更新如果靠自己一个一个号去点一下刷新会很麻烦，但是我们可以看到产品会做成红点提示的方式让我们知道哪些号有新内容。
这种消息触达是被动式的，不是我们主动去点才获取的。传统的 C-S (client - server) 模式是我们输入 URL 浏览器穿过千山万水来到目标服务器获取数据，而这种方式几乎是反过来，它把数据推给你，客户端用监听的方式获得。
这就是 WebHook 技术的常见使用场景。
我们还能列出很多这样的场景
- 持续集成流水线的触发
- 更新公告触达
- 游戏事件通知
等等
WebHook 的实现原理：
我们假设 数据交换双方有一个客户端 Client ，和一个服务器 Server；
传统拉数据的方式，是客户端 Client 通过 Server 提供的API 主动 向 Server 拉数据；
Webhook 的方式是客户端或者代理客户端 (Proxy) 提供一个webhook 的url，当服务器有新数据的时候，往这个 url 发数据，客户端监听，就能随时收到客户端发来的数据。
- 听起来是不是很像异步回调技术？
在 C++ 里我们把一个函数的指针交给一个函数，函数在进行一些自己的计算之后，某一时刻调用回调函数，回调函数的逻辑得以触发； - 异步化，最常见的是使用多线程，线程执行结束后，调用回调函数。
类比：webhook url类似异步回调的回调函数指针，回调函数处理逻辑是客户端，什么时候调用回调函数的逻辑在服务端。
安全问题
hook url如果暴露是很危险的，意味着有一些好事者向这个地址发一些乱七八糟的，甚至有危害的数据，所以 webhook url必须通过一些技术做权限校验，防止第三方恶意使用。
常见的方法有:
- 增加 token 机制
- 增加auth认证
- 只接收对应服务端domain或IP请求
- 数据签名
Webhook消息积压问题
一般有两种积压现象出现：
-
服务端积压
events
某公司内部代码平台提供了一系列Webhook 事件定制功能，当发生对应的事件时，触发设定的 hook url 。许多内部持续集成和devops工具依赖这个功能。
有一天出现这种情况： 托管平台的底层sql执行超时引起的队列消费线程阻塞。故障导致托管平台发送给第三方的 hook 延迟发出，依赖改平台的 hook的工具平台流程受阻。
- 客户端积压
如果 Webhook 发出大量请求, 可能会造成客户端应用阻塞。
网友评论