我有一个用Kafka构建的微服务通信系统。在部署期间应该如何创建主题?
我看到两个选项:
。集中主题创建。有一个中心位置(存储库)，团队可以在其中添加微服务所需的主题。在这种方法中，部署将如下所示:
1. Deploy kafka
2. Deploy kafka topics artifact that contains the required topics for all microservices
3. Deploy microservices
二世。每个服务都部署自己的主题。部署如下所示:
1. Deploy Kafka
2. Deploy microservices. Within each microservice deployment the required topics are created.
我看到选项I的值。我可以看到部署的所有主题、分区、保留和压缩策略。这将有助于理解kafka的资源分配和配置。这个选项的缺点是潜在的耦合，我需要在运行的系统上部署单个微服务。在这种情况下，我需要部署一个新版本的Kafka主题工件和微服务本身。
这里的最佳实践是什么?
就我个人而言，这两种方法我都见过，这取决于你的审批流程工作得如何，以及你是否真的想微观管理服务器资源使用(配额、访问控制、可发现性等)。
例如，一个团队想要做一个Kafka POC，不想等待"Kafka admin批准";创建主题，因此他们在代码中使用AdminClientAPI来快速入门。然而，Kafka流，将它自己创建中间有状态主题，因此您不能始终如一地提前创建它所需的所有主题。
另一个例子- Kafka团队想要审计和控制如何/何时使用主题以及主题可以有多大，所以他们设置了像OpenPolicyAgent这样的工具来控制可以在中央仓库中定义的内容。他们还可以设置一个管理UI面板来创建/发现主题。
然后有一个中间地带-每个"团队/组织"一个回购;为主题。
注意:你可以使用Terraform, Kubernetes Operators, Ansible等来管理Kafka主题;不需要是"典型的"Kafka客户端工具。如果你使用这些工具，你并没有真正地"部署一个主题工件"。相反，你可以使用Jenkins, Github Actions等通过giitops流运行这些。
也许您可以根据开发环境制定方法。您可以在开发中没有任何限制，但在PROD中完全管理，您的测试环境可以是混合的。
从现实世界的经验来看，如何创建主题并不重要，但真正重要的是在其之上强制执行的约束。
- ACL(访问控制列表)用于治理，特别是如果您处于风险团队端到端审核整个流程的金融行业，那么第一个问题将是如何保护您的主题以及如何确保没有其他人可以访问您的主题。
- 配额，用于节省被主题的生产者/消费者过度使用的服务器资源。由于Kafka集群将是一个共享环境，因此有人可以运行批处理作业并为其他人设置集群节流。
因此，在Kafka充当中枢神经的组织中，大多数情况下，Kafka集群维护者会批准主题创建过程。他们维护一个git仓库，并要求其他团队签入主题配置，并在上面为主题运行一些工具。因此，它成为一个受控的环境，具有所有主题的单点来源，例如谁拥有它，可以检查所请求的配置是否正确，并可以要求解释。
根据集群的使用范围，这些都是有意义的。一个简单的场景是保留字节/时间。这显然是基于用例的。因此，管理员可以要求请求者减少配置为在集群中节省存储的默认值。