如何设置发布/订阅命名空间的消费者组

学习如何在您的组件中使用基于元数据的命名空间消费者组

您已经设置了Dapr的Pub/Sub API构建块，您的应用程序正在使用集中式消息代理发布和订阅主题，实现顺畅的发布和订阅。 如果您想对应用程序进行简单的A/B测试、蓝绿部署，甚至金丝雀部署，该怎么办呢？ 即使使用 Dapr，这也可能很困难。

Dapr使用其发布/订阅命名空间消费者组构建解决了大规模的多租户问题。

没有命名空间的消费者组

假设您有一个Kubernetes集群，其中部署了两个应用程序（App1和App2），它们都部署在同一个命名空间（namespace-a）中。 App2发布到一个名为order的主题，而App1订阅了一个名为order的主题。 这将创建两个消费者组，以您的应用程序命名（App1和App2）。

Diagram showing basic pubsub process.

为了在使用集中式消息代理时进行简单的测试和部署，您需要创建另一个命名空间，其中包含两个相同的应用程序 app-id，App1 和 App2。

Dapr 使用个别应用程序的 app-id 创建消费者组，因此消费者组名称将保持为 App1 和 App2。

Diagram showing complications around multi-tenancy without Dapr namespace consumer groups.

为了避免这种情况，你需要在代码中加入一些“特技”的东西来改变 app-id，具体取决于运行的命名空间。 这种解决方法很繁琐且非常痛苦。

具有命名空间的消费者组

Dapr 不仅可以让您通过使用 UUID 和 pod 名称为消费者组的 consumerID 更改其行为，Dapr 还提供了一个位于发布/订阅组件元数据中的 命名空间结构。 例如，使用 Redis 作为消息代理：

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4.   name: pubsub
  5. spec:
  6.   type: pubsub.redis
  7.   version: v1
  8.   metadata:
  9.   - name: redisHost
  10.     value: localhost:6379
  11.   - name: redisPassword
  12.     value: ""
  13.   - name: consumerID
  14.     value: "{namespace}"

通过配置consumerID用{namespace}值，您将能够使用相同的app-id具有来自不同命名空间的相同主题。

Diagram showing how namespace consumer groups help with multi-tenancy.

在上面的图表中，您有两个命名空间，每个命名空间都有相同的 app-id，发布和订阅相同的集中式消息代理 orders。 然而，这次 Dapr 已经创建了以其所运行的命名空间为前缀的消费者组名称。

无需更改您的代码/app-id，命名空间消费者组允许您：

  • 添加更多命名空间
  • 保持相同的主题
  • 在各个命名空间中保持相同的 app-id
  • 保持您的整个部署流程完整

只需在你的组件元数据中简单地包含 "{namespace}" 消费者组构造。 您不需要在元数据中编码命名空间。 Dapr 理解它所运行的命名空间，并为您完成命名空间值，就像运行时注入的动态元数据值一样。

注意

如果您在之后将命名空间的消费者组添加到您的元数据中，Dapr会为您更新所有内容。 这意味着您可以将命名空间元数据值添加到现有的发布/订阅部署中。

例子

观看此视频以了解 pub/sub 多租户的概述:

下一步

  • 了解如何配置具有多个命名空间的Pub/sub（发布/订阅）组件 pub/sub namespaces。