深度可用性监测，在定期实时检测跨进程资源可用性时，对超时设计、而本进程线程池资源限制方面是否有什么设计模式？

[matepi]

需求：

通过监测系统，监测一个 web 服务（内含跨进程/非本地外部调用）的整体（含外部调用）可用性。

问题：

监测系统定期（ 15 秒一次）发起检测请求； web 服务中的外部服务调用请求等一般为 30 秒超时、且此设置依照实际业务情况决定，并不由监测系统决定、不由监测系统决定、不由监测系统决定。

当外部服务调用请求发生不可用时，会因为监测系统的检测请求，在 web 服务中不断积累起对应的检测线程，最终导致 web 服务线程过载。

进一步地，当 web 服务内可能有多个外部调用时，情况更为复杂。

简单的考虑，监测系统定期的时长必须>Max(所有外部调用超时)，又似乎不能满足监测及时性。

目的：

寻求一个设计模式经验，并有合适的规则理由，明确检测定期的时长、外部超时的时长、对整体服务资源（如线程池）影响可控。

一些已有服务设计模式的说明，但都较为简单
https://iambowen.gitbooks.io/cloud-design-pattern/content/patterns/health-endpoint-monitoring.html
https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints.health
都没讲到深度检测时的超时<->线程资源，这个肯定会涉及到的设计点。

[shuimugan]

本质就是一个 C10K 的问题,当你想用多线程搞线程池的时候已经错误了,要用全链路异步的方案.

通常纠结这个问题的一般是纯 java 系程序员,换个带异步语言会豁然开朗了.

[lsk569937453]

服务可用性的深度检测有必要吗？

k8s 的 LivenessProbe （存活探测）和 ReadinessProbe （就绪探测）不能满足需求吗？

服务中的接口有些是不能做深度检测的，比如支付。难道让所有的接口都做幂等性限制？
服务中的接口使用了 HTTP 中不同的 Method 。你难道让所有的用户去你的平台上配置 Method+Param ？

[matepi]

@shuimugan 难点在于，设计的是监测系统，而不是被监测系统。不能因为要上个监测系统，存量的被监测系统就要做一个新的非线程、异步化的方式来处理。这种思路是不太能解决问题的。