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();
}
});
}