作者回复: 有两个措施防止你说的问题： 1. healthchecks.io对ping的频率有限制，我记得最小粒度是1分钟间隔。 2. check可以设置grace period，也就是允许ping迟到的时间范围。

作者回复: ping一般只能检测简单的存活，开发定制的健康检查端点可以获取更细粒度的健康信息，如SpringBoot支持用户开发定制的健康检查逻辑，可以定制磁盘利用率，数据库连接，缓存连接等更细粒度的健康检查信息。

作者回复: SaaS公司开始起步，一般都是一套DB逻辑隔离，简单成本低。到了一定的规模，有钱有人了，可以考虑私有部署物理隔离，这时候成本复杂性也上去了。通常做法是对用户分层，免费和低端用户使用共享的逻辑隔离，中高端付费用户进行私有部署物理隔离。

作者回复: SaaS = Software as a Service，把传统的软件产品，做成多租户通用版，部署在云端提供共享服务的形式，就可以称为SaaS。 healthchecks.io是一个轻量级的SaaS服务，它把对周期性任务(scheduled job)的健康检查，做成了一种云服务，大家可以共用，不需要每个企业再去部署一套。 healthchecks.io属于监控类SaaS产品。同样，sentry.io也是监控类SaaS产品，它把异常日志监控做成了一种云服务。还有auth0.com把企业身份认证做成了云服务，launchdarkly.com把功能开关做成了一种云服务，等等。

作者回复: 如果checks数量非常多，DB会成为瓶颈，这个时候有两个办法： 1. 采用类似killbill common queue的sticky polling技术，每个机器只处理本机写入的checks，这样相当于把 checks做了逻辑分组和负载分摊。 2. 对DB进行分片sharding，然后不同的告警检查任务(alert checker)分别处理不同的DB shard，分摊负载。