两个微服务，用于读写一个数据库表

Question

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

以下情景：

  

来自mqtt设备的大量传入消息。客户可以阅读消息的休息api（大多数只是其中的一部分）。

我的想法是，创建一个用于将消息存储在数据库表中的微服务。还有第二个带有rest api的微服务来读取这些消息。 我想这样做，因为缩放问题。 （进入的存储部分需要比读数休息api更多的功率）

我读到“完美”的微服务应该是唯一一个在数据库中访问其数据的人。因此，其他微服务应该通过其API而不是数据库级别来请求这些数据。 所以我的方法不是完美的。我看到了一些处理这个问题的方法：

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

但是所有这些对我来说并不好看。

您的意见是什么？

此致 马库斯

Answer 1

实际上，除非您在读取或写入时做一些计算密集的事情，否则您的数据库IO可能会成为您的争论焦点。我会强烈考虑构建你的系统＆＃34;完美＆＃34;，然后运行容量测试以查看阻塞点的位置。不要忘记唐纳德克努特的话：＆＃34; Premature optimization is the root of all evil＆＃34;。

如果您决定需要扩展服务，请查看是否可以横向扩展读取和写入（制作组合服务的更多实例）。

如果这无法为您提供所需的性能，那么请查看更复杂的扩展要求，例如另一个回答者proposed。

Answer 2

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?

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:

• No contention between database writes and reads
• Writes can be scaled independently.
• Your written data can be stored in relational format
• Customer data can be read in the manner which most simplifies retreval and display concerns (eg denormalised, aligned with 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.