V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
matepi
V2EX  ›  程序员

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

  •  
  •   matepi · 2023-09-04 16:31:02 +08:00 · 840 次点击
    这是一个创建于 446 天前的主题,其中的信息可能已经有所发展或是发生改变。
    需求:

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

    问题:

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

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

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

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

    目的:

    寻求一个设计模式经验,并有合适的规则理由,明确检测定期的时长、外部超时的时长、对整体服务资源(如线程池)影响可控。
    第 1 条附言  ·  2023-09-04 17:06:40 +08:00
    一些已有服务设计模式的说明,但都较为简单
    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
    都没讲到深度检测时的超时<->线程资源,这个肯定会涉及到的设计点。
    3 条回复    2023-09-08 08:48:23 +08:00
    shuimugan
        1
    shuimugan  
       2023-09-04 17:18:17 +08:00
    本质就是一个 C10K 的问题,当你想用多线程搞线程池的时候已经错误了,要用全链路异步的方案.

    通常纠结这个问题的一般是纯 java 系程序员,换个带异步语言会豁然开朗了.
    lsk569937453
        2
    lsk569937453  
       2023-09-04 17:32:16 +08:00
    服务可用性的深度检测有必要吗?

    k8s 的 LivenessProbe (存活探测)和 ReadinessProbe (就绪探测)不能满足需求吗?

    服务中的接口有些是不能做深度检测的,比如支付。难道让所有的接口都做幂等性限制?
    服务中的接口使用了 HTTP 中不同的 Method 。你难道让所有的用户去你的平台上配置 Method+Param ?
    matepi
        3
    matepi  
    OP
       2023-09-08 08:48:23 +08:00
    @shuimugan 难点在于,设计的是监测系统,而不是被监测系统。不能因为要上个监测系统,存量的被监测系统就要做一个新的非线程、异步化的方式来处理。这种思路是不太能解决问题的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2657 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 05:13 · PVG 13:13 · LAX 21:13 · JFK 00:13
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.