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

问题描述

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

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

以下情况:

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

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

我的想法是，创建一个微服务以将消息存储在数据库表中.另一个带有REST 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:

• 仅一个mircroservice，用于存储和读取
• 在存储微服务中制作一个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?

如果该问题的答案是> 10ms，则可以考虑使用读写分离-您的用例似乎很好.

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:

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

将其应用于您的体系结构，即使不使用某种持久性排队传输，仍然可以实现，但实现读写分离更困难.不必利用事件，而必须使整个事情由命令驱动.

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屋！