两个微服务，用于读写一个数据库表 [英] Two microservices for read and write to one database table

问题描述

我对微服务最佳实践方法有点困惑.

I'm a little bit confused about the microservice best practice approach.

以下场景:

来自 mqtt 设备的大量传入消息.一个rest api，客户可以在其中阅读消息(大部分只是其中的一部分).

Massive incoming messages from mqtt devices. A rest api where customers could read the messages (mostly only a part of them).

我的想法是，创建一个微服务来将消息存储在数据库表中.还有一个带有休息 api 的微服务来读取此消息.由于缩放问题，我想这样做.(传入的存储部分需要更多的权力，比阅读休息api)

My idea was, to create one microservice for storing the messages in a database table. And a second microservice with a rest api to read this messages. I want to do this, because of scaling issues. (The incoming storing part needs much more power, than the reading rest api)

我读到完美"微服务应该是唯一一个访问数据库中数据的微服务.因此，其他微服务应该通过其 API 而不是数据库级别来请求这些数据.所以我的方法不是完美的.我看到有几个选项可以处理这个问题:

I read that the "perfect" microservice should be the only one, who accesses his data in a database. So other microservices should ask for this data, via its API and not on database level. So my approach would be not the perfect one. I see a few options to handle this:

• 只有一个微服务，用于存储和读取
• 在存储微服务中创建一个 api，其余微服务可以在其中获取数据.

但所有这些对我来说都不好看.

But all of them, doesn't look good for me.

你有什么看法?

问候，马库斯

推荐答案

我将推荐一种方法，该方法在某种程度上取决于以下问题的答案:

I am going to recommend an approach which to some extent would depend on the answer to the following question:

从消息提交到数据库到消息可供客户查看的最大可接受时间延迟是多少?

What is the maximum acceptable time delay from the time when a message is committed to the database to the time the message becomes available for a customer to see it?

如果这个问题的答案是>10 毫秒后，您可以考虑使用 读写分离 - 您的似乎是一个很好的用例.

If the answer to this question is > 10ms then you could consider using read-write separation - yours would appear to be a good use-case.

虽然这可能会给您的解决方案带来更多复杂性，但这种方法的好处包括:

Although this would arguably introduce more complexity into your solution, the benefits of this approach would include:

• 数据库写入和读取之间没有争用
• 写入可以独立缩放.
• 您的书面数据可以以关系格式存储
• 可以以最简化检索和显示问题的方式读取客户数据(例如非规范化、与视图模型对齐)

将此应用于您的架构，即使不使用某种持久队列传输，它仍然是可能的，但更难实现读写分离.与其利用事件，不如让整个事物由命令驱动.

Applying this to your architecture, even without the use of some kind of durable queuing transport it is still possible but more difficult to implement read-write separation. Rather than capitalise on events you would have to make the entire thing command driven.

这里的主要区别在于您需要强制执行可交易性"；跨主数据库写入和对负责更新读取模型的服务的后续调用.

The main difference here is that you would need to enforce "transactionability" across your main database write and the subsequent call to the service responsible for updating the read model.

这篇关于两个微服务，用于读写一个数据库表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！