Dapr 发布和订阅
它可解决的问题
发布-订阅模式的主要优点是松散耦合，有时称为临时分离。 该模式将发送消息的服务（发布服务器）与使用消息的服务（订阅服务器）分离。 发布服务器和订阅服务器都不知道彼此的存在 - 两者都依赖于分发消息的集中式消息代理。
在上图中，请注意模式的步骤：
- 发布服务器将消息发送到消息代理。
- 订阅服务器绑定到消息代理上的订阅。
- 消息代理将消息的副本转发给相关的订阅。
- 订阅服务器从其订阅使用消息。
工作原理
Dapr 发布和订阅构建基块提供了平台无关的 API 框架来发送和接收消息。 你的服务将消息发布到一个命名主题。 你的服务订阅一个主题来使用消息。
图 7-3。 使用 Dapr 的发布/订阅流。
在上图中，请注意流：
- 服务 B 的 Dapr 挎斗从服务 B（使用者）调用
/dapr/subscribe终结点。 该服务使用它想要创建的订阅进行响应。 - 服务 B 的 Dapr 挎斗在消息代理上创建请求的订阅。
- 服务 A 在 Dapr 服务 A 挎斗上的
/v1.0/publish/<pub-sub-name>/<topic>终结点发布消息。 - 服务 A 挎斗将消息发布到消息代理。
- 消息代理将消息副本发送到服务 B 挎斗。
- 服务 B 挎斗调用与服务 B 上的订阅对应的终结点（在本例中为
/orders）。该服务以 HTTP 状态码200 OK进行响应，因此挎斗将认为该消息已成功处理。
在示例中，消息已成功处理。 但是，如果在服务 B 处理请求时出现问题，它可使用该响应指定需要对消息执行的操作。 当它返回 HTTP 状态代码 404 时，将记录错误并删除消息。 对于 200 或 404 以外的任何其他状态代码，都会记录警告并重试消息。 或者，服务 B 可通过在响应正文中包含 JSON 有效负载，显式指定需要对消息执行的操作：
{
"status": "<status>"
}
The following table shows the available status values:
| Status | Action |
|---|---|
| SUCCESS | The message is considered as processed successfully and dropped.消息被视为已成功处理并被删除。 |
| RETRY | The message is retried.重试消息。 |
| DROP | A warning is logged and the message is dropped.将记录警告，并删除消息。 |
| Any other status | The message is retried.重试消息。 |
竞争使用者
扩展订阅某个主题的应用程序时，必须处理竞争使用者。 只有一个应用程序实例应处理发送到主题的消息。 幸运的是，Dapr 可处理该问题。 当具有相同应用程序 ID 的服务的多个实例订阅一个主题时，Dapr 仅将每条消息传递给其中一个实例。
使用 Dapr .NET SDK
