microservices - 微服务消息传递数据库分配的标识符

Question

我工作的公司正在研究从我们当前的单一 API 迁移到微服务。我们当前的 API 严重依赖于 spring，并且我们使用 SQL Server 来实现大多数持久性。我们的微服务调查倾向于 spring-cloud、spring-cloud-stream、kafka 和多语言持久性(每个微服务的独立数据库)。

我有一个问题，关于在微服务架构中通常如何通过 kafka 进行消息传递。我们计划在微服务集和我们的客户端应用程序之间建立一个协调层，它将协调不同微服务之间的事件，并将客户端与微服务 API 的更改隔离开来。我们读过的关于使用 spring-cloud-stream 和 kafka 的大部分内容都表明我们应该在协调层(源)使用流来进行资源更改操作(插入、更新、删除)，而微服务是其中的一个消费者消息。

我一直遇到麻烦的地方是插入。我们大量使用数据库分配的标识符(标识列/自动递增列/序列/代理键)，它们通常作为发布请求的一部分分配并返回给调用者。协调层可能正在使用不同的微服务保存多个事物，并且通常需要从一个插入中分配的标识符，然后才能继续进行下一个操作。在协调层和微服务之间使用消息传递进行插入使得协调层无法从插入操作获得响应，因此它无法获得所需的分配标识符。此外，流中的其他消费者(即向数据仓库发布数据的消费者)确实需要消息包含分配的标识符。

人们如何处理这个问题？数据库分配的标识符是微服务中的反模式吗？我们是否应该公开返回数据库分配标识符的单独微服务端点，以便协调层可以在调用异步插入之前进行同步调用以获取标识符？我们可以使用 UUID，但我们的 DBA 不喜欢将它们用作主键，并且它们不能用作订单号或其他面向用户的生成 ID。

Answer 1

如果您可以在从消息源接收时更早地以编程方式创建标识符，则可以将标识符作为消息 header 的一部分嵌入，然后在数据库插入期间和任何其他使用者中使用消息 header 信息。

但这种方法需要其他消费者针对数据库进行单独验证，以仅处理已提交的事务(如果您只关心处理插入)。