- 优雅发布概念
主要考虑的两方面：系统应用无损，业务无损。 - 优雅发布流程
首先看下一个应用内大致包含哪些组织形式。
2.1.1. 集群流量承载评估
在发布前用前，需要对应用整体流量进行评估。
发布过程需要停止应用，停止应用这个期间，剩下的应用集群是否能满足当前流量的承载。（避开高峰）
发布启动后灰度引流期间，新的服务引流的使用量，是否能承载引流的业务容量。
2.1.2. 应用停止
业务停止应用，切记不能直接Kill -9操作，也不能直接使用shundown操作。
被杀死的客户端jboss或tomcat是无法及时告知服务端自己是否还存活，还是否能处理正常请求。
客户端内还有残留的请求（同步、异步）未被处理、线程池中线程还在运行状态未被释放、文件处理到一半、本地事务还未执行完成等等。
最经典的场景就是同步请求超时（RPC同步请求，MQ同步发送。RPC的OneWay和MQ也可以设置异步模式，这两种是异步请求，异步请求不需要给应答，所以也无法保证是否接收到，速度比较快，一般用于可容仍丢失，如监控）。超时分两类，可能是应用发送方阻塞超时（请求未送达，客户端超时），应用接收方收到请求后应答送不回去（请求已送达，并处理，返回未送达，客户端超时）。本质上超时问题是无解的，只有通过重试来解决，重试必然需要幂等，还会带来多几倍的网络开销，如果是后一种超时，可能应用接收方会被打死（必须限制重试次数、考虑降级或服务端限流）。
所以应用停止前，需要做以下处理：
2.1.2.1. 摘除外部通讯
摘除Http同步请求，图1代理集群模式，应从负载均衡处摘除。
摘除RPC同步请求，图2客户端集群摘除请求，应用分布式资源调度服务中通知客户端进行服务摘除。
摘除MQ订阅，图3消息队列，需要进行解除订阅，让消息暂时持久化到消息队列中
注意：启动的时候，需要一切资源准备好后（RPC通讯连接、Redis、数据库、文件等等），最后启动消息订阅、服务加入集群（这里也分业务先后，看业务场景，如消息里面有依赖服务调用，应先注册服务，再开启消息订阅），不然可能发生异常
2.1.2.2. 释放长连接
释放Redis连接池、数据库连接池、文件连接（SFTP或分布式存储）、MQ连接池、RPC通讯框架连接池。图5，图6（这里比较好的是，spring框架本质都帮我们做了，在bean初始化的时候都提供了destroyMethod）
2.1.2.3. 释放本地资源
释放本地线程池、文件句柄、事务处理。图4（这里要注意，使用容器（jboss，tomcat）关闭本质已经帮我们做了，如果自己实现的jar应用是没有容器的，所以要实现shutdownhook进行处理（或者使用springboot可执行包））。
2.1.3. 应用测试
0灰度测试
2.1.4. 应用发布
灰度发布
微服务发布的策略方式（4台、8台、16台……，预先评估业务场景，VM可以使用jenkins进行编排，Docker可以使用K8S进行容器编排）
单元化发布，按整个单元可用为主。
2.1.5. 应用投产
生产业务验证
2.1.6. 应用监控，报表，自主恢复
监控报警，故障报告及影响范围，自主恢复（能自动化的一切自动化处理）
