微服务架构中的数据库基础故障

返回错误？但什么是错误？500 ?

是返回错误。从您的微服务返回错误并没有错。如果您的数据库出现故障，通常“500 Internal Server Error”是正确的错误。这是 Rest API 的标准行为。

但是微服务架构不应该避免这种类型的耦合吗？我们应该让系统更加松散耦合吗？

我认为这里存在混淆。与其自身数据库的微服务通信不被视为耦合。使用其赢得的数据库 micro-service-A-database 的微服务 A 被视为一个逻辑单元或垂直。如果没有数据库，微服务 A 就没有多大用处，反之亦然。这完全没问题，您可以以与标准 WebApplication 类似的方式查看其前端、后端（类似于您的服务）和数据库。应避免跨不同微服务的耦合。例如，微服务-A 不应与微服务-B 或微服务-C 紧密耦合。每个微服务都应该是原子的，并且尽可能独立，但不能独立于它的数据库、缓存或类似的东西。您可以将数据库视为它的逻辑部分。

微服务是否应该将数据保存在本地文件或队列中并重新尝试插入数据库？

不，预计数据库可能会失败，或者至少您还必须处理该选项。从用户的角度来看，您只会返回错误代码 500。至少在大多数情况下，这将是预期的行为。在某些特殊情况下，您希望不惜一切代价保存数据，而不会因该请求而丢失数据（也有处理此问题的方法）。

但是用户呢？

如果它是标准的 Web 用户，那么他会重试几次，如果问题仍然存在，则可能稍后再试（此处返回错误 500 没有错）。如果用户指的是另一个微服务正在调用，那么调用者微服务必须预料到可能会发生故障。现在这取决于你在这里做什么？示例考虑微服务-A 使用 Http 请求调用微服务-B：

• Get Call：在这里你可以在微服务-A 中构建重试策略，如果微服务-B 在重试后响应 500，你可以向调用微服务-B 的用户返回错误。
• Post/Put/Patch Call：在这里您也可以尝试与 Get Calls 类似的方法，但前提是涉及 1 个服务。如果你有 micro-service-A 调用 micro-service-B 然后是 micro-service-C，如果一个调用成功（保存了一些数据）而另一个调用失败，你必须考虑 Sagas（如果操作应该是事务性的） .

想象一下事件总线崩溃了……如果是这样，消费者也会在微服务中崩溃。

如果您的本地微服务数据库崩溃，那么所有其他渠道也应该崩溃。如果您无法将实体保存在本地微服务数据库中，为什么还要进一步执行诸如将消息发布到队列之类的操作？数据/实体的真实来源是数据库（至少在大多数情况下）。因此，如果数据库失败，您应该抛出异常并向调用者/用户返回错误。

如果 db insert 发生，生产者无法将事件发送到事件总线......所以数据丢失了？那么生产者是否应该将数据保存在其本地存储中以供重试？

因此，如果您将数据/实体保存在数据库中并且队列不可用，您可以简单地将消息/事件保存到数据库中的表中，然后在队列再次启动并运行时发布消息/事件。实际上，这是在这种情况下非常常见的模式。例如，您的实现可能是事务性的：

1. 将实体保存到其表中并
2. 将事件/消息保存到事件表。这样，如果失败，操作将被回滚。

您可以让后台工作人员（取决于您用于后端的技术）以异步方式将消息发布到队列中。