健康检查

最好要有健康检查模块，能够保证扩容后的实例是可以正常 work 的，要不然扩容了也没用。同时如果服务异常，那么需要及时摘掉。当然，其他基础模块也会对服务做健康检查，这个设计就要根据整体架构做取舍，看是否有更合适的健康检查模块，如果没有，那么健康检查放到哪里更为合适。

如果是在自动伸缩架构中的健康检查，那么需要检测：

业务程序是否部署成功？需要有一个探测接口用来探测业务程序是否正常运行业务服务是否能够对外提供流量操作系统级别是否出现了异常

在 k8s 容器平台下，健康检查一般会有两个地方来保证：

K8s 本身的 kubelet 来保障负载均衡代理层来保障

服务优雅关闭

当我们要自动缩容服务实例的时候，一个非常关键的地方就是，实时运行的服务，如果直接关闭，势必会对流量有损，这样对业务服务、对客户都有一定的影响。作为一个极致的技术人，我们必须要能够保证服务可以优雅关闭、优雅下线。

一般会有如下几个方式：

通知服务退出的时候，服务延迟退出，先摘掉流量，不让新的请求进来，然后预留时间把当前正在处理的任务继续处理完毕之后再退出。 这个就要求业务服务和弹性伸缩架构能够配合联动起来，需要设计这么一个机制。K8s 就有这样的机制，当收到 TERMINATED 退出信号之后 Pod 可以不马上退出，而是可以延迟一定的时间后再退出

自定义指标来执行弹性伸缩

一般来说，通过 CPU 、内存的使用率来进行弹性伸缩是最常用的功能，也挺有效果；在此基础之上，我们还可以自定义一些指标，可以更贴合业务，比如 QPS，通过这些个指标来进行弹性伸缩。

比如我们的 K8s 平台，我们就扩展了 QPS 指标，还有一些比如流量带宽之类的，但是 CPU 和 QPS 指标是最常用的弹性伸缩指标。

缩放比例尺设计

使用弹性缩放比例时，删除实例时，应用程序将具有一定的缩放比例。应用程序必须妥善处理要删除的实例。以下是处理 scalein 的一些方法：

最好可以监听关闭（退出）事件，然后优雅关闭。服务的客户/消费者应支持瞬时故障处理和重试。对于长时间运行的任务，应该使用检查点或“ 管道和过滤器”模式来分解工作。将工作项放在队列中，以便另一个实例可以接管工作（如果在处理过程中删除了一个实例）。

卸载资源密集型任务

尽可能将需要大量 CPU 或 I/O 资源的任务移至后台作业，以最大程度地减少处理用户请求的前端负载。

确定整个系统的瓶颈

扩展并不是解决每个性能问题的灵丹妙药，要先确定整个系统中哪个环境是瓶颈，这样才能更好的扩展。

推荐阅读

推荐阅读我的其他文章：

《高并发架构和系统设计经验》