聊聊sprng cloud优雅安全下线微服务节点

spring cloud 在国内应该兴起于2015年，当时业界还面临着是doubbo还是spring cloud 的争论。实践是检验真理的唯一标准，目前doubbo应该只能生活在遗留项目之中。

spring cloud是什么已经高频面试题。本文不准备回答这么高大上的问题，只简单探讨一下spring cloud业务节点下线的问题。

节点非安全下线可能导致的问题

一般来说在生产环境不会无理由的offline一个节点，其场景通常中异常宕机，部署发布，本次主要从灰度发布这个场景来理解非安全下线的隐患。其主要特征是数据不一致及业务中断。

下线服务手段及优缺点

可手段	优点	缺点
kill	快，Shutdown hook	除了快都是缺点
/shutdown	和方式一类似	和方式一类似
/service-registry/down（推荐）	标记eureka状态down	只能控制服务发现流量
/pause	标记eureka状态down	开启helthcheck后冲突 只能控制eureka流量
delete /eureka/apps/{application.name}/{instanceId}	心里安慰	Eureka客户续约后状态变更为up
DiscoveryManager.getInstance(). shutdownComponent();	支持手写下线接口	shutdown之后如果想start就比较困难 只能控制服务发现流量
PUT /eureka/v2/apps/appID/instanceID/status?value=OUT_OF_SERVICE（推荐）	强制下线	可修改为up恢复状态 只能控制服务发现流量

一个正常的下线流程建议是1.修改eureka状态，但服务仍可运行。2.监控节点流量。3.物理下线。这个写一个自动化工具或者人工确认完成。

流量入口多样化挑战

以user-serivce为例，一般服务的流量入口为外部流量负载均衡nginx，内部流量eureka以及来自于消息驱动的kafka/rabbit之类。

上述控制eureka的手段仅能解决loan-service等内部流量的问题，假如将eureka状态修改为out_of_service此时消息队列仍然会进行消费，监控流量可能会漏掉对消息队列的监控，从而导致物理下线期间消费消息线程被kill，如果消息消费确认机制不恰当产生消息丢失。

消息队列pause

以kafka为例进行消息pause

    @Autowired
    private KafkaListenerEndpointRegistry kafkaListenerEndpointRegistry;
    
    public void pause() {
        kafkaListenerEndpointRegistry.getListenerContainers().forEach(c->c.pause());
    }
    
    public void start() {
        kafkaListenerEndpointRegistry.getListenerContainers().forEach(c->{
            if(c.isRunning()) {
                c.start();
            }else {
                c.resume();
            }
        });
    }