【第四章】24-如何平滑升级与扩展_运维平滑发版原理-CSDN博客

        任何升级操作，都不能随便的定义，若新版本不能给你带来提升，就不要升级。

        通常情况下，软件的每一个release都是针对某一类模块进行优化，或增加某一类功能，如果优化的点或新增的功能不能给你业务带来性能，资源提升，运维人员都会选择不升级，宁愿不要暂时“鸡肋”的功能与性能，也不要升级带来的风险。

        升级给运维带来的痛不知道有多少次，但仍然有一部分运维或开发不分情况的进行升级，这是运维思想没有落实到位，什么是运维思想呢？就是要为了线上稳定而稳定，一切都要以用户的稳定为主，任何未知的风险都认为是灾难性的，切不可忽视。

一、如何平滑版本升级

1.1 版本选择

官网地址：
- 版本公告：http://nginx.org
- 下载地址：Index of /download/
版本选择原则：
- 生产环境优先选择 Stable 版本（如 nginx-1.20.2）
- 测试环境可选 Mainline 版本尝鲜新功能
- 禁止使用非官方渠道获取的版本

1.2 升级准备

1.2.1 升级的背景

任何升级操作，都不能随便的定义，若新版本不能给你带来提升，就不要升级。

通常情况下，软件的每一个release都是针对某一类模块进行优化，或增加某一类功能，如果优化的点或新增的功能不能给你业务带来性能，资源提升，运维人员都会选择不升级，宁愿不要暂时“鸡肋”的功能与性能，也不要升级带来的风险。

升级给运维带来的痛不知道有多少次，但仍然有一部分运维或开发不分情况的进行升级，这是运维思想没有落实到位，什么是运维思想呢？就是要为了线上稳定而稳定，一切都要以用户的稳定为主，任何未知的风险都认为是灾难性的，切不可忽视。

那么什么的情况下才需要升级呢？

从两点来说，一是性能上的提升，比如mysql5.6升级到5.7，新版本带来了并行复制，新的优化参数，mongo从3.2升级到4.0，带来了集群瘦身，详细的数据输出，更高的性能，这种是以功能，性能为目的的升级，是为了解决线上问题。二是，正常的业务迭代更新，业务代码进行了多次迭代，使得业务代码调用的模块，扩展，第三方软件版本都得到了升级，他们依赖于基础服务，基础服务不升级，他们的业务代码就不能正常迭代，这种事为了满足业务需求而升级，类似这种的多数是系统版本升级，像系统版本升级到centos7，内核升级到4.4，都是为了业务容器化。

1.2.2 升级流程制定

1.3 升级实施

1.3.1 标准操作流程：

# 1. 获取旧版本编译参数
nginx -V 2>&1 | grep 'configure arguments'

# 2. 下载并解压新版本
wget http://nginx.org/download/nginx-1.20.2.tar.gz
tar zxvf nginx-1.20.2.tar.gz && cd nginx-1.20.2

# 3. 保留原有编译参数并编译
./configure --prefix=/usr/local/nginx --with-http_stub_status_module...
make  # 注意不要make install

# 4. 热替换二进制文件
cp -f objs/nginx /usr/local/nginx/sbin/
kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`

# 5. 旧进程优雅退出
kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`

1.3.2 验收Checklist：

验收清单：

检查项	验收方法	合格标准
服务状态	`systemctl status nginx`	Active (running) 活动（正在运行）
版本一致性	`nginx -v`	目标版本号匹配
配置文件兼容性	`nginx -t`	Syntax OK 语法正常
QPS波动	监控平台对比	波动<5%
错误日志	`tail -f error.log`	无crit级别错误

二、如何平滑增加扩展

2.1 扩展管理规范

模块选择原则：
- 官方模块 > 知名三方模块（如 ngx_cache_purge）
- 验证标准：
  - GitHub Stars > 500 GitHub Stars > 500 强
  - 最近1年有更新记录
  - 有企业生产环境使用案例

2.2 平滑增加扩展

1）查看旧版nginx的编译参数

[root@web-test-205-239 nginx-1.15.3]# /usr/local/nginx/sbin/nginx  -V
nginx version: nginx/1.15.3
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --with-http_v2_module --with-http_stub_status_module --with-http_ssl_module --with-http_realip_module

2）编译新版本Nginx源码包，安装路径需与旧版一致，注意：不要执行make install

[root@web-test-205-239 src]# tar -zxvf ngx_cache_purge-2.3.tar.gz
[root@web-test-205-239 src]# tar xf nginx-1.15.3.tar.gz && cd /usr/local/src/nginx-1.15.3/
[root@web-test-205-239 nginx-1.15.3]# ./configure --prefix=/usr/local/nginx --with-http_v2_module --with-http_ stub_status_module --with-http_ssl_module --with-http_realip_module --add-module=/usr/local/src/ngx_cache_purge-2.3
备注：编译的时候使用“-add-module=”增加新的模块，跟上地址模块的路径即可。
类似于：--add-module=../echo-nginx-module-0.61，这种都是nginx默认安装的，真正增加扩展的时候，该类不需要放在./configure上
    --add-module=/usr/local/src/ngx_cache_purge-2.3
[root@web-test-205-239 nginx-1.15.3]# make

3）备份二进制文件，用新版本的替换

[root@web-test-205-239 nginx-1.15.3]# mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old

4）找到新版本路径下面的nginx二进制文件

#openrestry :
cp /usr/local/src/ngx_openresty-1.7.0.1/build/nginx-1.7.0/objs/nginx /usr/local/openresty/nginx/sbin/nginx nginx 
cp objs/nginx /usr/local/nginx/sbin/

5）确保配置文件无报错

[root@web-test-205-239 nginx-1.15.3]# /usr/local/nginx/sbin/nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

6）配置重启

[root@web-test-205-239 nginx-1.15.3]# /usr/local/nginx/sbin/nginx -s reload