Architecture 两个微服务，用于读取和写入一个数据库表

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

以下场景：

来自mqtt设备的大量传入消息。一个RESTAPI，客户可以在其中读取消息（大部分只是其中的一部分）

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

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

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

但所有这些都不适合我

你怎么看

问候,，

---

Markus

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

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

如果这个问题的答案是10ms，那么你可以考虑使用-你的似乎是一个很好的用例。 尽管这可能会给您的解决方案带来更大的复杂性，但这种方法的好处包括：

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

将这一点应用到您的体系结构中，即使不使用某种持久的队列传输，仍然可以实现读写分离，但更难实现。与其利用事件，还不如让整个事情都由命令驱动

---

这里的主要区别在于，您需要在主数据库写入和随后对负责更新读取模型的服务的调用中强制执行“transactionability”。

实际上，除非您在读或写时进行计算密集型操作，您的数据库IO可能是您的争论点。我会强烈考虑建立你的系统“完美”，然后运行容量测试，看看扼流点在哪里。别忘了唐纳德·克努特的话：“

如果您决定需要扩展服务，请查看是否可以水平扩展读写（创建更多组合服务实例）

---

如果这无法获得所需的性能，那么请像另一位回答者那样考虑更复杂的扩展需求。

更具体一点。比如说，五月的信息是来自飞机的GPS位置。rest api将使飞机（航空公司）的所有者能够查看所有飞机的当前位置或一架飞机的时间范围内的位置跟踪。对我来说，这些信息进一步说明了需要两个数据库的情况。查看基于时间的跟踪的要求自然会导致一个优化的模式，用于重新修改和显示粒度写入数据。如果我将其分离，这意味着我有一个非常大的表，其中包含位置（来自写入微服务），另一个非常大的表用于读取微服务。（每天有数百万条新条目）。所以我认为，对于较少的数据，这个概念是有意义的。但对于非常大的数据来说，这可能是个问题。我认为，在一个微服务中结合读写的“简单”方法更合适。我当然同意过早优化的观点。事实上，在设计中使用微服务很容易被认为是过早的优化。通常有必要快速构建一些东西，然后，正如你所说的，找出痛点在哪里。