java - Webhook 与发布者和订阅者

Question

我遇到了称为 webhook 和发布者/订阅者的概念。在 webhook 中，第三方应用程序在依赖应用程序发生更新时发送信息，第三方将向您的应用程序的提及 URL 发送 HTTP post 请求，在发布者和订阅者中，订阅者将注册主题，发布者在该主题上写然后注册商(如第三方)将根据订阅的主题将信息发送给订阅者。

两者相同还是不同？

我很困惑谁能解决这个问题？

Answer 1

好吧，从概念上讲，这两种方法都用于在事件发生时通知客户端。但实际上我会在两种不同的情况下使用它们。网络钩子(Hook)(来自维基百科):

A webhook in web development is a method of augmenting or altering the behavior of a web page, or web application, with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application. The term "webhook" was coined by Jeff Lindsay in 2007 from the computer programming term hook.

当您想要将第三方之间的异步更改或更新传达给您的后端服务器时，webhook 方法是相关的。
这意味着第3方需要为每个客户端注册webhook地址，并触发http请求，其中包含需要通信的信息。
使用 webhook 的一些注意事项是，在 webhook 地址没有响应或任何给定的临时故障的情况下的故障处理，重试责任和处理由发布者完成。
以下是几个使用 webhook 方法的例子:
- SendGrid.com - 一种电子邮件服务，可让您通过 API 发送电子邮件和 Activity 电子邮件。如果您想在后端公开一个 webhook，例如您希望在每次用户取消订阅列表时收到通知。
- Braintree.com - 一个计费网关，可让您向客户收取他们在您网站上购买的产品的费用 - 例如，您在后端公开一个 webhook，以便在每次成功执行定期付款时获得通知

当谈到发布者/订阅者时，这更像是一种消息传递模式(来自维基百科):

In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

Advantages
Loose coupling
Publishers are loosely coupled to subscribers, and need not even know of their existence. With the topic being the focus, publishers and subscribers are allowed to remain ignorant of system topology. Each can continue to operate normally regardless of the other. In the traditional tightly coupled client–server paradigm, the client cannot post messages to the server while the server process is not running, nor can the server receive messages unless the client is running. Many pub/sub systems decouple not only the locations of the publishers and subscribers, but also decouple them temporally. A common strategy used by middleware analysts with such pub/sub systems is to take down a publisher to allow the subscriber to work through the backlog (a form of bandwidth throttling).
Scalability
Provides the opportunity for better scalability than traditional client–server, through parallel operation, message caching, tree-based or network-based routing, etc. However, in certain types of tightly coupled, high-volume enterprise environments, as systems scale up to become data centers with thousands of servers sharing the pub/sub infrastructure, current vendor systems often lose this benefit; scalability for pub/sub products under high load in these contexts is a research challenge. Outside of the enterprise environment, on the other hand, the pub/sub paradigm has proven its scalability to volumes far beyond those of a single data centre, providing Internet-wide distributed messaging through web syndication protocols such as RSS and Atom. These syndication protocols accept higher latency and lack of delivery guarantees in exchange for the ability for even a low-end web server to syndicate messages to (potentially) millions of separate subscriber nodes.
Disadvantages
The most serious problems with pub/sub systems are a side-effect of their main advantage: the decoupling of publisher from subscriber.
I would recommend the following post for further info about pub/sub :

• > pub-sub-messsaging using aws
• > Pub sub on Wikipedia