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

【问题标题】：Two microservices for read and write to one database table两个微服务用于读取和写入一个数据库表
【发布时间】：2016-08-07 03:57:50
【问题描述】：

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

以下场景：

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

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

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

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

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

你有什么意见？

问候，马库斯

【问题讨论】：

标签： architecture microservices

【解决方案1】：

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

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

如果这个问题的答案是 > 10 毫秒，那么您可以考虑使用 read-write separation - 您的用例似乎很好。

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

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

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

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

【讨论】：

更具体一点。假设消息是来自飞机的 GPS 位置。其余 api 将使飞机（航空公司）的所有者能够查看所有飞机的当前位置或一架飞机的时间范围内的位置轨迹。
对我来说，这些信息更加证实了您需要两个数据库的情况。查看基于时间的跟踪的要求自然会导致优化架构，用于检索和显示粒度写入数据。
如果我把它分开，那意味着我有一个非常大的带有位置的表（来自写入微服务）和另一个非常大的用于读取微服务的表。（每天有数百万个新条目）。所以我认为，对于较少的数据，这个概念是有道理的。但对于非常大的数据，它可能会出现问题。我认为，将读写结合到一个微服务中的“简单”方法更适合。

【解决方案2】：

实际上，除非您在读取或写入方面进行计算密集型操作，否则您的数据库 IO 可能会成为您的争论点。我会强烈考虑将您的系统构建为“完美”，然后运行容量测试以查看阻塞点在哪里。不要忘记 Donald Knuth 的话：“Premature optimization is the root of all evil”。

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

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

【讨论】：

我当然同意过早的优化论点。事实上，在设计中使用微服务很容易被认为是过早的乐观。通常需要快速构建一些东西，然后如您所说，找出痛点所在。