在生产环境中，开发者可以通过部署多个market-data服务实例来确保冗余度和水平扩展。负载均衡器将其他服务发出的请求分发给这些实例。在这种场景中，负载均衡器的作用有两个：第一，确定底层的哪些实例是健康的，是能够处理服务请求的；第二，将请求路由给不同底层的服务实例。
设计和部署的每个服务都应该实现合适的健康检查方案。如果某个服务实例不正常，那么这个实例就不应该再接受其他服务的请求了。对于同步的RPC服务，负载均衡器通常会每隔一段时间查询一下每个实例的健康检查端点。同样，异步服务也可以有一套心跳机制来测试消息队列与消息消费方之间的连接情况。
对于通过健康检查发现的重复性的故障或者系统级的故障，开发者通常希望能够触发告警通知发送给运维团队。
基于两个标准来对健康检查分类：存活性（liveness）和就绪性（readiness）。存活性检查通常只是简单地检查应用是否启动起来和是否正常运行。比如，HTTP服务会暴露一个端点——通常是/health、/ping或者/heartbeat，一旦服务运行起来，这个端点就会返回200 OK的响应结果。如果实例没有响应，或者返回一个错误消息，那么负载均衡器就不再向这个实例发送请求。
负载均衡器会持续地查询服务实例来检查它们的健康情况。如果某个实例出现异常，那么在其恢复之前，负载均衡器都不再会将请求路由到该实例。
与此相反，就绪性检查体现的是服务是否准备好处理通信数据，因为服务存活着并不意味着请求就会成功。一个服务还会有许多依赖——数据库、第三方服务、配置数据、缓存等——所以开发者可以使用就绪性检查来判断这些组件是否能够正确处理请求。
健康检查只有两种状态：可用或者不可用。如果负载均衡方案采用轮询策略来将请求分发到各个实例中，这种健康检查是很有效的。但是在某些情况下，服务的功能会被降级和出现时延增大或者错误率增高的问题，而健康检查并不能反映出这种状态。在这种情况下，如果负载均衡器能够感知实例的时延、性能、负载情况，然后根据这些信息把请求路由给性能更高的或者负载更低的实例，那么将有很大裨益。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论