文海问津创新实训项目记录（六）

前几周我的主要工作集中在功能开发和系统架构搭建上而本周主要做项目部署与线上环境维护。随着功能逐步完善系统开始频繁部署到云服务器ECS进行测试因此我们也遇到了许多在本地开发阶段难以发现的问题。最初我们认为只要代码能够正常运行上线过程就不会有太大困难。但在实际部署过程中我们陆续遇到了页面更新不生效、接口偶发 502 错误以及中文内容显示异常等问题。虽然这些问题本身并不复杂但排查过程往往十分耗时因此我们开始整理和总结部署经验希望将线上发布流程固化为一套可重复、可恢复、可验证的标准流程。在部署策略上我们明确区分了“构建”和“运行”两个阶段。前端项目统一在本地执行构建生成 dist 目录后端项目则在本地完成 jar 包打包。服务器只负责接收构建完成的产物并通过 Docker Compose 完成容器替换和服务启动。这样既避免了服务器环境与开发环境差异导致的问题也降低了线上构建失败带来的风险。在部署流程中我们特别强调发布后的验收工作。除了检查服务是否启动成功之外还会通过健康检查接口验证服务状态并对核心业务接口进行抽检。例如检查文章接口、评论接口以及关键页面能否正常访问确保系统真正处于可用状态而不是仅仅“容器在运行”。本阶段遇到的最典型问题是线上偶发的 HTTP 502 错误。现象表现为通过网关直接访问接口时能够正常返回数据但经过前端代理访问时却会随机出现连接失败。经过日志排查后发现问题出现在 Nginx 与 Docker 容器之间的通信环节。由于网关容器重建后 IP 地址发生变化而 Nginx 缓存了旧的解析结果导致代理请求被转发到失效地址从而触发 502 错误。针对这一问题我们一方面通过重启前端容器快速恢复服务另一方面在代理配置中引入 Docker DNS 动态解析机制使 Nginx 能够定期重新解析容器地址而不是长期使用旧缓存。经过调整后接口访问稳定性得到了明显改善。除此之外我们还遇到过“前端已经重新部署但页面依然显示旧版本”的问题。起初怀疑是浏览器缓存导致但进一步检查发现服务器上的静态资源实际上并未完成替换。后来我们增加了构建产物校验流程通过比对 index.html 和静态资源文件的版本信息快速确认线上资源是否真正更新大大提高了问题定位效率。编码问题也是本阶段的重要经验之一。在部分数据上传过程中中文内容出现乱码甚至显示为问号。经过排查后发现问题发生在数据传输阶段而非数据库存储阶段。最终通过统一采用 UTF-8 编码并在请求头中显式声明字符集成功解决了中文内容异常的问题。为了降低线上故障带来的影响我们还制定了回滚策略。当系统出现异常时优先回滚单个服务而非整个系统。例如优先回滚前端代理服务再根据情况处理网关服务从而尽量缩小故障范围并减少恢复时间。通过这一阶段的工作我逐渐认识到一个项目不仅需要完善的业务功能也需要稳定可靠的部署体系。部署规范、健康检查、故障排查以及回滚机制虽然不像功能开发那样直观却是保证系统长期稳定运行的重要基础。目前我们已经形成了一套较为完善的云端部署流程为后续功能迭代和持续交付提供了可靠保障。