命名Kafka主题的最佳实践是什么？

Question

我们对kafka还不太熟悉，有几个团队在开发几个应用程序，这些应用程序之间要发布/订阅事件。由于kafka主题名称将在多个团队之间共享，因此是否有最佳实践的命名方式？

基本上，我们不希望看到A团队以 companyname-appname-events 命名主题，而B团队则以完全不同的样式命名另一个主题 productname_functionB。

欢迎提出任何建议！

请注意，这可能听起来更像以下问题： Kafka的主题和分区应该采用什么命名约定？ 然而，那里的作者问的是更具体的问题。

- Faraway

Answer 1

https://cnr.sh/essays/how-paint-bike-shed-kafka-topic-naming-conventions 对我们回答了同样的问题，提供以下建议：

总而言之，本文建议按照命名数据库和表的类似最佳实践，并提供以下额外的建议：

1. 避免使用基于变化的主题名称
2. 避免使用基于其他位置存储的信息的主题名称
3. 避免使用基于计划的消费者/生产者的主题名称。这从本质上讲是第一个建议的特例:D。
4. 尽早决定具体大小写形式，并考虑强制执行或至少检查/监控它。这样您可以及早发现违规者。

- ankon

---

消息类型应该反映出消息的结构。(日志)表示具有很多动态和一些稳定元数据的相对较小的消息。(队列)表示一个稳定的元数据，是正在进行的集合中的众多元数据之一。 - phreed

我看到有些人建议在主题中添加动词。根据发布的链接，我想澄清一下：我们永远不应该这样做吗？例如，如果我们删除一个联系人，我们应该将取消操作发布到主题 queue.address_book.contact 中的数据中，如 { change: 'deleted', other: 'data' }。我们应该避免像 queue.address_book.contact.deleted 这样的主题吗？ - ahong

我想可以说“如果在你的世界中有意义，也许可以这么做？”但通常话题会被一个实体所消耗，将所有描述该实体的事件放在同一个话题中会更有用。使用单个主题的重要原因是：只有当它们在同一个主题（和分区！）中时，您才能依赖于事件顺序通过偏移量。将某些需要相对排序的事件拆分到不同的主题中意味着您需要找出一种明确排序它们的方法 :) - ankon

@ahong 我同意 @ankon 的观点，在这种情况下你应该使用单一主题。另一个原因是事件实现类通常以层次结构组织。因此，你可以有一个 ContactEvent 作为 ContactAddedEvent、ContactDeletedEvent 等的超类。 - Paulo Merson

我对博客文章中使用应用程序名称并不满意。从架构角度来看，您应该避免通过应用程序名称耦合到应用程序。这在项目开始时可能不是问题。但是软件将在某个时候被替换、扩展等...如果不是每个应用程序都必须因为新主题名称而事后进行修改，那真的会很有帮助。 - Ben

Answer 2

我想提供一种替代方案，这个方案在实践中表现良好，不会导致与产品或应用程序名称的耦合。 我的建议:

1. 使用业务域和子域，例如:

public.sales.ecommerce.shoppingcarts

private.risk.portfolio.analysis.loans.csvimport

2. 此外，可以使用“私有”标记内部主题或“公共”标记外部主题（即在进行质量保证之后）。另一个例子:

private.risk.portfolio.pricingengine.assetpricing

域和子域的数量以及是否需要将流程标记为公共或私有显然取决于组织的规模。始终避免过度设计。

我撰写了一篇博客文章“主题命名约定：如何命名我的主题？5个建议和示例”，其中包含更多详细信息。

- Ben