微服务-坚持到RDBMS并在事务中排队

Question

我有一个REST服务-它的所有请求都保存在其自己的关系数据库中。到目前为止，还不错。但是，还有一个小业务功能（电子邮件通知，短信警报）应在新接收/更新的数据上运行。为了使此过程在后台处理数据，需要某种方式来了解持久数据-消息队列可以解决该问题。我看到的三种常见设计方式，

1. REST服务也插入数据库，也发布到队列中。

   • 这里的问题是，分布式事务-在一个事务中组合不同的类型-关系数据库和队列。有些工具可能支持，有些可能不支持。

2. 与往常一样，REST服务仅持久存在于其数据库中。此外，它还将数据插入到另一个表中，该表将查询预定作业，并将其发布到队列中（后台作业应从该表开始工作）。

   • 我看到的问题是调度程序-不响应，不进行批处理，受时间限制，不是实时，缓慢等。

3. REST端点将数据直接发布到topic。使用者将其持久化到数据库中，而另一个则在后台对其进行处理。

   • 诸如事件外包之类的东西。 TMU，随着服务数量的增加，实现起来有点复杂。同样，如果数据库关闭，则持久服务将无法保存数据，但是后台服务（例如，电子邮件程序）将发送功能错误的电子邮件。这可能会导致服务之间以及功能上的不一致。

我还考虑过读取数据库transaction-logs，但它似乎更复杂，需要配置工具才能使其正常工作，而且，对于数据处理系统而言，似乎比对我们的用例来说更合适。

您对此有何想法-我错过了什么吗？您如何管理这种情况？应该寻找什么？想{@ {1}}是被动的吗？

抱歉，这看起来很幼稚，但我不得不问。

Answer 1

我认为最好的方法是使用像debezium这样的CDC（更改数据捕获）系统2。

请参见[https://microservices.io/patterns/data/transactional-outbox.html][1]

Answer 2

如果您不需要在写一致性后立即读取，通常建议使用选项3。如果数据库记录仍未通过其处理的消息更新，则后台作业应重试。

您的帖子说明了为什么不应将队列用于这些类型的场景。它们非常适合传递分析数据或日志，但对于任务流程开发人员，每次都必须重新设计轮子。

更好的方法是使用诸如Cadence Workflow之类的任务编排系统，该系统可以消除您所描述的问题，并使多服务编排更加简单。

请参阅this presentation，其中介绍了Cadence编程模型。