热加载及滚动发布对服务的影响测试报告

港控/mmm° 2022-10-28 04:56 156阅读 0赞

--------------------

# **热加载及滚动发布对服务的影响测试报告** #

*  **编写目的**

随着场景应用服务的增多，及需求的快速迭代，升级上线比较频繁。为减少服务迭代升级对用户的影响，降低运维人员及开发测试人员的人力成本。对灰度发布做简单说明及现有的服务迭代滚动升级对服务的影响做以测试。

该测试是基于新版本服务无异常的情况下，对nginx热加载和微服务滚动发布对服务的影响测试。

*  **适用范围**

运维人员，开发人员

*  **发布方式**

在项目迭代的过程中，不可避免的需要上线升级。上线对应着部署，或者重新部署，部署对应着修改，修改则意味着风险。现对常用布署方案做一个简单整理。

*  **蓝绿部署**

蓝绿部署是不停老版本，部署新版本然后进行验证，确认OK，将流量切到新版本。

缺点：蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70][]

*  **滚动发布**

滚动发布：一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。

问题：

1、因为是逐步更新，那么我们在上线代码的时候，就会短暂出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容的问题。

2、在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的。那么在滚动升级期间，整个系统就处于非常不稳定的状态。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70 1][]

*  **灰度发布**

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。  
当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。  
如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70 2][]

*  **测试报告**

根据现有的部署方式，对nginx热加载和微服务滚动发布对服务的影响做测试。

*  **测试用例**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70 3][]

*  **测试结果**

在正常操作时，nginx热加载和微服务滚动发布在新版本服务正常的情况下，基本不会对服务造成影响。

1.  **nginx热加载**

先部署新版本服务，验证通过后，使用nginx -s reload进行热加载流量切换。** **

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70 4][]

错误率为0，说明正常操作不会对服务造成影响。

![20210205154855844.png][]

1.  **微服务滚动部署**

先部署注册新版本节点，验证无异常后滚动发布其他节点。

注意当前微服务注册心跳时间默认为5s,当eruka发现新注册节点5s后才会分发流量到新节点。

![20210205154902371.png][]

错误率为0，说明正常操作不会对服务造成影响。

![20210205154909794.png][]

*  **总结**

对相应的应用服务，运用相对适用的发布方式，妥善运用灰度发布，就再也不需要加班到深夜进行停机升级了，在白天就可以放心大胆地、安全地发布新版本。

该测试是建立在新版本服务无异常的前提下，但实际生产环境中，对现有的蓝绿部署，及微服务的滚动发布，当新版存在问题时，都会对部分流量造成一定影响。

后续需要妥善运用灰度发布，降低新版本问题对服务的影响。

## **附录  kill 与 kill -9 的区别** ##

kill 和 kill -9 是常用的命令，都可以用来杀死进程。

*  **kill**

kill命令默认的信号就是15，也就是 kill -15 ,被称为优雅的退出。

kill -15信号只是通知对应的进程要进行"安全、干净的退出"，程序接到信号之后，退出前一般会进行一些"准备工作"，如资源释放、临时文件清理等等，如果准备工作做完了，再进行程序的终止。但是，如果在"准备工作"进行过程中，遇到阻塞或者其他问题导致无法成功，那么应用程序可以选择忽略该终止信号。

这也就是为什么我们有的时候使用kill命令是没办法"杀死"应用的原因，因为默认的kill信号是SIGTERM（15），而SIGTERM（15）的信号是可以被阻塞和忽略的。

大部分程序接收到SIGTERM信号后，会先释放自己的资源，然后在停止。

*  **kill -9**

和kill -15相比，kill -9就相对强硬一点，系统会发出SIGKILL信号，他要求接收到该信号的程序应该立即结束运行，不能被阻塞或者忽略。

所以，相比于kill -15命令，kill -9在执行时，应用程序是没有时间进行"准备工作"的，所以这通常会带来一些副作用，数据丢失或者终端无法恢复到正常状态等。

**总结**

所以，在非必要时，不要使用kill -9命令，尤其是那些web应用、提供RPC服务、执行定时任务、包含长事务等应用中，因为kill -9 没给spring容器、tomcat服务器、dubbo服务、流程引擎、状态机等足够的时间进行收尾。

参考：

kill -9的原理都不知道就敢到线上执行

[https://mp.weixin.qq.com/s/qBKaRt34zeSI0OzBEAnu7g][https_mp.weixin.qq.com_s_qBKaRt34zeSI0OzBEAnu7g]

什么是灰度发布

[https://blog.csdn.net/qq\_42234452/article/details/90906692][https_blog.csdn.net_qq_42234452_article_details_90906692]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70]: /images/20221024/407fa2fcf79f48b9a77edd61b51c7803.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70 1]: /images/20221024/4fc5e266b4e8430caf90956aae276aa8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70 2]: /images/20221024/d338aea0af69477ca346d5c2f97e421f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70 3]: /images/20221024/361c12fdf83c4bb7b5c1ab470f1b328e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnB6_size_16_color_FFFFFF_t_70 4]: /images/20221024/04d13729d3014165823b086d436e7c05.png
[20210205154855844.png]: /images/20221024/75825125f5cc4dc790bd8d6b1a1089b0.png
[20210205154902371.png]: /images/20221024/8bf721f1949544bb83e46970b03e655e.png
[20210205154909794.png]: /images/20221024/fffd0af00f804660b711d5743671c09e.png
[https_mp.weixin.qq.com_s_qBKaRt34zeSI0OzBEAnu7g]: https://mp.weixin.qq.com/s/qBKaRt34zeSI0OzBEAnu7g
[https_blog.csdn.net_qq_42234452_article_details_90906692]: https://blog.csdn.net/qq_42234452/article/details/90906692