上篇文章讲了ElegantOfflineReleaseStability-ElegantOffline，今天我们来说说ElegantOnline优雅在线也叫：“无损在线”，“延迟发布”，“延迟曝光”。相反的自然是：“lossylaunch”、“directrelease”。什么是优雅启动？先说说什么不是优雅启动。应用启动时，没有检查系统的健康状态，导致调用失败。这些情况都会对用户造成影响，就是上网不优雅。对于任何在线应用来说，发布、扩容、缩容、重启等操作都是不可避免的。这个时候服务不可用，必须把流量去掉，比如批量发布的时候，放到别的机器上。等到应用恢复正常，再把流量拿回来，让应用继续提供服务，优雅在线。无论是HTTP应用还是RPC应用，优雅的在线逻辑在发布和启动时都是一样的。如下图，发布过程中服务不可用，提取流。服务发布完成后，将重新分配流量。Dubbo优雅上线有两种方式：延迟发布和Qos命令1.延迟发布是指延迟暴露Dubbo服务。比如你的服务需要一些初始化操作才能对外提供服务，比如初始化缓存、redis连接池等相关资源到位，可以使用delay进行延迟曝光。在Dubbo2.6.5之后的版本中，所有的Dubbo服务都会在Spring初始化完成后暴露出来。您可以自行配置延迟曝光时间。配置如下：Dubbo官方文档中延迟暴露：DelayedExposure#DelayedExposure5sdubbo.provider.delay=5000源码分析Dubbo实现了Spring的ApplicationListener接口，监听ContextRefreshedEvent事件，即在Spring容器之后开始暴露服务启动后，源码分析如下：ServiceBean://监听ContextRefreshedEvent事件，然后执行export暴露服务@OverridepublicvoidonApplicationEvent(ContextRefreshedEventevent){if(!isExported()&&!isUnexported()){if(logger.isInfoEnabled()){logger.info("Spring服务已启动。service:"+getInterface());}出口（）;}}ServiceConfig类：//公开服务publicsynchronizedvoidexport(){checkAndUpdateSubConfigs();如果（！shouldExport（））{返回;}//判断是否配置了延时释放时间，如果配置了则启动一个Thread，等待对应时间后执行doExport方法if(shouldDelay()){DELAY_EXPORT_EXECUTOR.schedule(this::doExport,getDelay(),TimeUnit.毫秒);}埃尔斯e{做出口（）;}}privatebooleanshouldExport(){Booleanexport=getExport();//默认值为真returnexport==null?真：出口；}@OverridepublicBooleangetExport(){return(export==null&&provider!=null)？provider.getExport()：导出；}//判断是否延迟曝光privatebooleanshouldDelay(){Integerdelay=getDelay();返回延迟!=null&&延迟>0;}//获取配置的延迟曝光时间@OverridepublicIntegergetDelay(){return(delay==null&&provider!=null)?provider.getDelay()：延迟；}2.QOS命令在线Dubbo官方文档QOS命令操作手册：QOS操作手册配置如下，服务启动时不会发布到注册中心.provider.register=falsedubbo.application.qos-port=22223dubbo.application.qos-enable=truedubbo.application.qos-accept-foreign-ip-compatible=tRue这里配置的时候遇到了一个问题：按照网上的方法配置dubbo.registry.register=false，防止服务发布到注册中心，但是qos命令也没用。根据我上面的配置，Qos还是可以的。因为此时还没有发布服务，所以不会有请求。我们可以在服务健康检查后手动发布服务。我们可以通过telnet命令或者http请求方式onlineHTTP来发布所有的服务。curllocalhost:22223/online流程如下图所示。延迟释放（delay=5000）不释放+QOS命令释放（register=false）在实际企业应用中，需要结合具体场景使用。当大型应用中服务较多时，可以使用QOS命令分层发布服务，即每次发布一定数量的接口，而不是一次性全部发布。总结：关于服务发布的稳定性上面已经谈得风生水起，但是在实际工作中仅仅做好这两件事是远远不够的。具体情况需要具体分析。下一篇继续讲稳定性的内容：流量预热。
