- 优雅发布概念
主要考虑的两方面:系统应用无损,业务无损。 - 优雅发布流程
首先看下一个应用内大致包含哪些组织形式。
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. 应用监控,报表,自主恢复
监控报警,故障报告及影响范围,自主恢复(能自动化的一切自动化处理)