Node.js躬行记（22）——Node环境升级日志

　　公司之前所有的 Node 项目，其环境都是 8.9.4 版本，发布于 2018 年的一个比较古老的版本。

　　老版本有两个比较明显的问题：

1. Node 高版本的特性和方法都无法使用。
2. 有些第三方新版本的包无法安装和升级，该包可能依赖比较高的 Node 版本。

　　之前在开发项目时就遇到第三方包自身的问题，必须升级或换个包才能解决，但因为 Node 版本的原因，无法替换，只能用其他方式来修补漏洞。

　　为了提升维护性和开发体验，还是决定升级 Node 版本，2021年升级过一次，升级到 14 版本。

　　但是因为一些奇怪的问题加上业务繁重，没有时间细究，就又回滚了，一直拖到今年的 7 月份，才继续推进升级的事情，本次会升级到 16.15 版本。

　　目前总共有 4 个 Node 环境需要升级，测试资源紧张，在升级后，是没有人力来验证是否有问题发生，所以只能靠自己想办法安全升级。

1）分项目阶梯升级

　　在 4 个待升级的项目中，有 3 个是对外的项目，有 1 个是对内的项目。

　　那么先升级对内项目的 Node 版本，这样有两个好处：

1. 即使出问题了，影响范围也能最小。
2. 响应也能最及时，因为有问题的话，在公司内部能马上反馈到我们组。

2）分环境阶梯升级

　　我们每个项目都会有 3 套运行环境：测试、预发和生产。

　　首先将测试环境升级，测试环境都是开发人员使用，影响最小，反馈最快。

　　观察一段时间后，再升级预发，预发环境与生产环境最为接近，数据库采用的也是一套。

　　最后才是生产，给真实用户使用，再获取反馈。

3）邀请内部人员体验

　　首先升级的是那个内部项目，所以在飞书上建了个群，将各个组的负责人拉进来。

　　邀请他们在预发环境体验各自的业务，再给出反馈。

　　在验收时发现了时区的问题，纠正后，再让他们验收。

4）部署自动错误告警

　　让人来验收，难免会有遗漏，所以让运维给加了个自动错误告警。

　　每分钟有 5 个 500 以上的错误，就自动在飞书上发告警信息。

　　这类规则比较适合接口，而定时任务的规则比较特殊。

　　因为任务可能是 5 分钟运行一次，那么报错的频率不会那么高。

　　因此改成 5 分钟内有一个错误就告警，免得告警太多，也比较烦人。

5）增加单元测试流程

　　在将对内的项目升级完成后，公司员工在访问一个服务时报错。

　　让运维查看后，发现是因为连接地址配置错了。

　　为了避免这种问题的发生，就需要有地方可以测试服务连接是否异常。

　　手动测试比较繁琐，最好的办法是在发布代码的流程中，加一环服务连接。

　　若成功，那么就继续后面的流程，否则就中断。

　　公司使用的是阿里云提供的发布系统，里面可以加一步单元测试。

　　服务连接是测试的一个场景，未来可以再加其他各类测试，保证项目质量。

　　从开始升级到全部项目升级完成，前前后后操作了 20 多天，因为在一个环境或项目升级后，就要观察几天，然后再升级另一个环境或项目。在升级完成后，还部署了阿里云提供的一款 Node 监控系统。