本篇内容主要讲解“sprng cloud怎么安全下线微服务节点”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“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}/

心里安慰    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();
            }
        });
    }

到此，相信大家对“sprng cloud怎么安全下线微服务节点”有了更深的了解，不妨来实际操作一番吧！这里是天达云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！