假设我有100个API，每个api与6个数据库进行对话。我正在考虑两种构建状态端点的方法。消费者不需要访问所有100个api来满足他们的业务需求，他们可以根据需要访问1或2个api。
1）每个api都有自己的/ status端点，该端点将检查它使用的所有6个数据库的连接性，如果一个失败，它将返回不健康，否则健康。在这种情况下，api使用者只访问他们使用的状态端点。在这种情况下，谁消费特定的api将访问其/状态终点以检查健康状态。
2）在这种情况下，消费者只访问1个端点，其中包含所有100个apis的状态，具体取决于6个数据库中的任何一个是否已关闭且api自身是否已关闭，因此如果api已启动且数据库如果数据库已启动且api已启动且api已启动并且正常，则消费者可以获得单个状态或所有api的状态（如果需要）来自该单个端点。每个api都有自己的内部/状态端点，无论其依赖的6个数据库的状态如何，它都将返回健康状态。我将为所有6个数据库添加6个不同的状态端点，如果连接不正常，它将检查连接并返回健康。
这两种方法中最好的方法是什么？
我非常感谢您的所有投入。
答案 0 :(得分：1)
不要这样做。如果他们看到30个集群微服务的运行状况良好变为红色只是因为某些依赖项（在这种情况下是数据库）的运行状况变为红色，那么你就会让sysops疯狂。您知道有数据库运行状况监视工具。 Sysops需要把注意力放在什么样的事情上，而不是注重什么样的事情。理想情况下，微服务甚至不应该关心依赖的健康状况。让事务保持在队列中，如果可以的话，让服务再次尝试（并再次......）。
在任何情况下，如果您使用实时分析设置了适当的聚合日志记录（您应该这样做！），那么sysops将会看到微服务和数据库（以及其他任何内容）之间的实时连接问题。理想情况下，微服务应该从数据持久性角度更加孤立。 100个微服务直接打击6个数据库？