Microservices 实现api状态端点的最佳实践是什么？

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

1） 每个api都有自己的/状态终结点，该终结点将检查与它使用的所有6个数据库的连接，如果其中一个数据库出现故障，它将返回不正常或正常。在这种情况下，api使用者只访问他们使用的状态端点。在这种情况下，使用特定api的用户将访问其/status端点以检查健康状态

2） 在这种情况下，使用者仅访问1个端点，该端点包含所有100个api的状态，这取决于6个数据库中的任何一个数据库是否已关闭，并且api本身是否已关闭，因此，如果api已打开且数据库已关闭，则该特定api的状态不正常；如果数据库已打开且api已打开，则api已打开且正常，如果需要，使用者可以从该单一端点获取单个状态或所有api的状态。每个api都有自己的内部/状态端点，并且无论它所依赖的6个数据库的状态如何，它都将返回正常状态。我将为所有6个数据库添加6个不同的状态端点，它将检查连接，如果连接不正常，则返回正常

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

---

我非常感谢您的所有意见。

也不要这样做。如果仅仅因为某个依赖项（在本例中是数据库）的运行状况变为红色，而看到30个正常工作的集群微服务的运行状况变为红色，那么你会让系统操作疯狂。您知道一些数据库运行状况监视工具。系统操作人员需要将他们的注意力放在哪些方面，而不是运行良好的方面。理想情况下，微服务甚至不应该关心依赖项的健康状况。将事务持久化到队列中，如果可以的话，让服务稍后重试（再重试…）

在任何情况下，如果您使用实时分析设置了适当的聚合日志记录（您应该这样做！），那么sysops将看到微服务和数据库（以及其他任何东西）之间的实时连接问题。此外，理想情况下，从数据持久性的角度来看，微服务应该更加独立。100个微服务直接对抗6个数据库