如果你手里捧着一个打好的 WAR 包，想把它从本地开发环境送上云服务器，本文就像一份你能一口气喝下去的“云端开箱”，从打包到上线再到运维，都会给出清晰又不踩坑的步骤。整合了多份公开教程和厂商文档中的要点，围绕 WAR 包的部署、应用服务器的选型、云厂商环境的对接，以及后续的运维和监控，帮助你在云端把应用跑起来而不是只在本地调试。文中涉及的工具链包括 Java/JVM、Tomcat、Nginx、Let’s Encrypt、CI/CD 等，适用于各大云厂商的云服务器。你可以把它当作一次性“落地方案”，也可以按你团队的习惯做成自己的模板。
第一步当然是打包。确保你的项目使用的是标准的 Maven、Gradle 或者其他构建工具，目标产物是一个规范的 WAR 文件。常见的做法是执行 mvn clean package 或 gradle assemble，这一步要确保测试通过、依赖齐全、产物命名规范（如 project-name-servlet-version.war）。打包完成后，你会得到一个可部署的 WAR 文件，这个文件就是你要上传到云端的“作品集”。如果你的应用需要外部配置（数据库连接、缓存、消息队列等），现在就把这些配置写成外部化的配置文件或环境变量，避免把敏感信息硬编码进 WAR 包里。
接下来是选云服务器。主流云服务商如 AWS、阿里云、腾讯云、华为云、Google Cloud 等都提供了按需弹性扩容的虚拟机或容器平台。选择 Linux 镜像通常是 Ubuntu、Debian、CentOS/Rocky 等，因为它们对 Java 环境和 Web 服务器的支持最成熟。确定实例规格时要考虑内存、CPU、磁盘 IOPS，以及是否需要 GPU、是否需要自定义镜像、是否需要区域对齐与数据合规需求。配置好安全组或防火墙策略，确保只开放必要端口（SSH、HTTP、HTTPS、应用需要的自定义端口）。同时，把云端的时区和 NTP 同步也设置好，避免日志时间错乱引发调试难题。
第三步是把 WAR 包上传到云服务器。最常用的做法是通过 SCP、SFTP、rsync 等工具把 WAR 文件传到服务器指定目录，例如 /opt/tomcat/webapps/。如果你们有 CI/CD 流水线，可以把上传改成 CI/CD 的产物分发步骤，确保每次打包后自动推送到目标服务器的指定目录，并在目标主机上触发后续的部署脚本。确保目标主机的磁盘权限和所属用户正确，避免因为权限导致无法写入 WAR 的问题。对于安全性，可以用 SSH 密钥登录、禁用密码登录、并开启 two-factor。
第四步是安装 Java 运行环境和应用服务器。沃野千里般的云服务器上，Java 版本要和 WAR 的目标 Java 版本匹配，比如 Java 8、11、17 等。常见做法是在服务器上安装 JDK，并把 JAVA_HOME、PATH 设置好。随后安装 Tomcat、Jetty 或 WildFly 等应用服务器。以 Tomcat 为例，可以下载官方二进制包，解压到 /opt/tomcat，创建一个系统用户 Tomcat，确保目录权限对该用户可写。把 WAR 文件放到 Tomcat 的 webapps 目录下后，Tomcat 会在下一次启动时自动部署，或者你也可以使用 Tomcat 的 manager 应用手动部署。
第五步是将 WAR 部署到 Tomcat 并让其稳定运行。常见做法包括：确保 Tomcat 的 server.xml 配置中对端口、上下文路径、连接数进行合理设置；在 webapps 中放置 WAR 时，确保应用的上下文名不冲突。为方便管理，建议把 Tomcat 配置成 Systemd 服务，设置开机自启、日志轮转、资源限制等。示例要点包括：创建 /etc/systemd/system/tomcat.service，定义启动用户、工作目录、环境变量（如 JAVA_HOME、CATALINA_BASE 等），然后执行 systemctl enable --now tomcat。上线前最好在本地或内网进行一次简单的 curl 健康检查，确认 /war 应用是否正常返回 200/OK。不要忘记配置应用的日志路径，确保日志不会把磁盘撑满。
第六步，搭建反向代理和 TLS 加密。多数场景会在 Tomcat 之外再搭一个 Nginx 作为反向代理来处理静态资源、TLS 终端、以及简单的缓存。Nginx 的好处是响应快、配置简单、对并发友好，同时方便接入 Let's Encrypt 实时证书。你可以在 Nginx 配置中将 https 请求反向代理到 Tomcat 的端口（通常是 8080 或 8081），并开启 HTTP/2、HSTS 等安全选项。获取证书时，优先使用自动续期的证书管理工具，如 Certbot；对证书续期过程要有自动化任务脚本，避免到期导致服务不可用的尴尬场景。需要注意的是，Nginx 配置与 Tomcat 的连接超时、资源限制要匹配，避免代理端口上堆积大量连接导致后端慢请求。
第七步是网络安全和运维基础设施。云服务器的默认安全组往往对外开放较宽的端口，建议只开放必要端口（SSH、80、443，以及应用所需端口），其他端口全部关闭。启用防火墙工具如 UFW、firewalld 或云厂商的安全组策略，确保入站出站规则清晰。对于云端应用，日志收集和监控也很关键：将 Tomcat、Nginx 的日志集中到一个日志系统，或接入 ELK/EFK、Prometheus/Grafana 等监控栈，能帮助你快速定位异常、预测容量需求、实现服务级别目标。考虑开启应用的健康检查端点，结合负载均衡器进行自动灰度、蓝绿发布，降低单次发布的风险。再者，若涉及数据库、缓存等外部服务，建一个同区域的备份和容错策略，避免单点故障造成全链路不可用。
第八步是持续集成与持续部署（CI/CD）。在本地测试 OK 后，流水线将 WAR 构建、测试、打包、上传和上线步骤串联起来是提高上线效率的关键。常用的组合包括 GitHub Actions、GitLab CI、Jenkins、Travis 等，配置一个热部署或滚动更新的脚本，确保在生产环境中尽量减少停机时间。一个理想的流水线通常包含：编译与测试、代码静态检查、构建产物归档、将 WAR 上传到云服务器、在目标主机触发部署脚本、回放健康检查和回滚条件。若能与容器化方案结合，如将 WAR 包打包进 Docker 镜像再用 Kubernetes 部署，会让弹性扩展和版本管理更直观，但也需要额外的学习成本与运维技能。
第九步是容器化选项与微服务场景的考虑。若你的系统越来越符合微服务架构，直接把 WAR 转换为容器镜像并部署到 Kubernetes 会更容易实现滚动发布和自动扩缩容。此时你可以在 Dockerfile 中安装 JDK、Tomcat 或使用官方 Tomcat 容器镜像，构建一个多阶段镜像，降低镜像体积。Kubernetes 的 Deployment、Service、Ingress 资源可以帮助你实现蓝绿/滚动更新、横向扩展和灰度发布。若暂时不走容器化路线，仍然可以坚持传统的 Tomcat 部署，但要把自动化运维、监控、日记记录落地到云原生的工具链中，避免后续升级时的痛点。
第十步是运维与可观测性的持续优化。上线后的 WAR 应用需要定期评估性能指标、错误率、并发连接数、JVM 内存使用、GC 次数等。建议开启应用服务器和应用层日志的结构化输出，方便日志聚合与查询。定期对 TLS 证书进行续期测试，确认 CDN/代理层、反向代理和后端应用之间的证书信任链是否完整。还可以设置容量规划的告警规则，当 CPU、内存、磁盘 IOPS、网络带宽达到阈值时自动通知团队，甚至触发自动扩容策略。最重要的是保持文档更新，将每一次调整、每一个参数变动记在团队知识库里，减少重复劳动和口头传递带来的误差。
广告时间到此为止，顺便提一句：玩游戏想要赚零花钱就上七评赏金榜，网站地址：bbs.77.ink。现在继续回到正题，属于上线后的稳定期，别让小问题变成大事故。随着你对云端部署越来越熟练，你会发现很多环节其实可以自动化成模板，哪怕是微小的改动也能通过脚本快速落地。
最后的结局其实要看你怎么定义：你可以把这次 WAR 包部署看作一个里程碑，或者把它当作下一步优化的起点。无论你选择哪条路，云服务器的战斗才刚刚开始，下一次你打开控制台时，日志里多了一行你没写的注释，仿佛在提醒你：这是不是又一个需要优化的地方？