实现 api 状态端点的最佳实践是什么？ [关闭]

Question

假设我有 100 个 API，每个 api 与 6 个数据库通信。我正在考虑两种构建状态端点的方法。消费者不需要访问全部 100 个 api 来执行他们的业务需求，他们可以根据需要访问 1 或 2 个 api。

1) 每个 api 都有自己的 /status 端点，该端点将检查与它使用的所有 6 个数据库的连接性，如果一个失败，它将返回不健康的，否则会返回健康的。在这种情况下，api 使用者仅访问他们使用的状态端点。在这种情况下，曾经使用过特定 api 的人将访问其 /status 端点以检查运行状况。

2) 在这种情况下，消费者仅访问 1 个端点，该端点包含所有 100 个 api 的状态，基于 6 个数据库中的任何一个是否已关闭并且它自己的 api 是否已关闭，因此如果 api 已启动且数据库is down 表示该特定 api 的状态不正常，如果数据库已启动且 api 已启动，则 api 已启动且健康，如果需要，消费者可以从该单个端点获取单个状态或所有 api 的状态。每个 api 都有自己的内部 /status 端点，无论它依赖的 6 个数据库的状态如何，它都会返回健康状态。我将为所有 6 个数据库添加 6 个不同的状态端点，它会检​​查连接并在连接不健康时返回健康。

这两种方法中最好的方法是什么？

非常感谢您的所有意见。

Answer 1

也不要这样做。如果系统操作员看到 30 个运行良好的集群微服务的健康状况因为某些依赖项（在本例中为数据库）的健康状况变成红色而变成红色，他们就会发疯。您知道有一些数据库运行状况监控工具。 Sysops 需要将注意力放在出现故障的地方，而不是运行良好的地方。理想情况下，微服务甚至不应该关心依赖项的健康状况。让事务保持在队列中，如果可以的话，让服务稍后再试一次（再一次……）。

在任何情况下，如果您使用实时分析设置了适当的聚合日志记录（您应该这样做！），那么系统操作员无论如何都会看到微服务和数据库（以及其他任何东西）之间的实时连接问题。另外，理想情况下，微服务应该从数据持久性的角度更加孤立。 100个微服务直接争6个数据库？