阿里云服务器怎么搭建

万能生活指南

那是一个阳光明媚的周一早晨，我刚端起手边的咖啡，还没来得及喝上一口，HR小姐姐就笑眯眯地出现在我面前：小米，下周去面试一家大厂吧？他们挺喜欢你的项目经验。

我一愣——面试？这可是我一年多没换工作的第一个挑战。于是我火速打开IDEA，开始复习八股文。JVM、Spring、Redis、MySQL……复习得正欢，突然一个题目跳了出来：

Tomcat 有几种部署方式？请详细说明。

我心里一惊：这题看似简单，实则暗藏玄机。要是答war包放进去就完事，那可就太浅了。

于是，我决定亲自重新走一遍 Tomcat 的部署之旅。

第一幕：传统的拷贝 WAR 包部署

我首先打开熟悉的 apache-tomcat-9.0 目录，眼神瞄准那个经典的 webapps/ 文件夹。

这可是 Tomcat 的老家伙了——把一个 war 包丢进去，Tomcat 自动解压并部署。

比如我有个项目叫 myapp.war，只要把它放到：

然后启动 Tomcat，浏览器访问http://localhost:8080/myapp，就能看到熟悉的Hello World。

这种方式虽然简单，但有几个注意点：

启动时自动解压，第一次加载会稍慢；重新部署时可能残留旧缓存；不适合频繁更新的线上项目。

老一辈程序员最爱这招，简单、稳、无脑部署。但对于我这种天天迭代的小米来说，总觉得——太慢啦！

第二幕：解压后直接放文件夹

我心想：那能不能不每次都打 WAR 包？

当然可以！

我们可以直接将项目解压成文件夹，比如 myapp/，然后直接扔进 webapps/：

里面包含：

Tomcat 启动后会直接把这个文件夹识别为一个 Web 应用。

优点：

无需打包，方便调试；修改 JSP 或静态资源后立即生效；适合开发阶段使用。

缺点也明显：

文件太多可能混乱；不利于统一版本管理；生产环境部署容易出错。

这让我想起大学那会儿，我的第一个 JSP 项目就是用这种方式部署的。那时我不知道什么 CI/CD，只会用 Ctrl+C + Ctrl+V。

每次看到 Tomcat started on port 8080，都觉得自己是世界上最厉害的程序员。

第三幕：配置文件部署（server.xml）

后来，我进入了职场，项目逐渐庞大，公司也不允许每次都手动丢包。于是我学会了更高级的方式——通过server.xml来定义部署路径。

打开 conf/server.xml，在 标签内添加：

这里的几个关键点：

path：访问路径；docBase：项目实际路径；reloadable：是否自动加载修改。

重启 Tomcat 后，无需放在 webapps，也能直接访问。比如访问http://localhost:8080/myapp。

这种方式让部署更灵活，可以指定任何位置的应用目录，非常适合部署多个项目。但有风险！

修改 server.xml 属于全局配置，如果写错，Tomcat 整个实例都可能起不来。

我记得有一次凌晨上线，我多写了一个斜杠 /，结果整台测试环境的 Tomcat 启不动。被Leader质问：你这是给Tomcat打绊子呢？

所以这招得谨慎使用。

第四幕：context.xml 部署（推荐生产使用）

后来，我发现还有一种更优雅的方式：通过 context.xml 单独配置每个应用。有两种做法：

1、在项目内部配置

在项目的 META-INF/context.xml 中定义：

当项目部署到 Tomcat 时，Tomcat 会自动读取这个配置文件。

2、独立放置配置

在 Tomcat 的 conf/Catalina/localhost/ 下，新建一个文件：

内容为：

云服务器ces

Tomcat 启动后就会自动部署这个应用。

最酷的是——文件名 myapp.xml 就决定了访问路径 /myapp！

这种方式有三大优势：

不改 server.xml，安全；方便做版本切换；不需要放在 webapps 下。

这也成了多数公司生产环境的标准做法。

我面试的时候，只要聊到这一块，面试官一般都会点头：

嗯，小伙子，对Tomcat挺熟。

第五幕：命令行 & Manager 管理页面部署

后来我进入了一家创业公司，后端五六个人，测试服、预发服、线上服全靠我一个人维护。

那时候，我最怕的事就是手动复制包。于是我学会了Tomcat Manager 部署。

Tomcat 自带一个管理后台（需在 tomcat-users.xml 中配置账号）：

启动后访问：

登录后台，就能看到Deploy按钮。你可以直接上传 WAR 包或输入远程 URL：

本地上传：选择文件，点击 Deploy；远程部署：填写 WAR 包地址，Tomcat 自动下载并部署。

甚至还支持命令行部署，用 curl 或 Ant 执行远程更新。对于有CI/CD流程的团队，这方式非常友好。

我记得当时写了个简单的脚本：

一键执行，Tomcat自动部署。

那种感觉就像从手工时代迈向自动化文明——再也不用为丢包焦虑啦！

第六幕：热部署（IDE集成方式）

作为一个懒到骨子里的程序员，我当然不会满足于上传 WAR 包这种操作。我想——能不能直接在 IDEA 里点个按钮就部署？

答案当然是：能！

在 IntelliJ IDEA 或 Eclipse 中配置 Tomcat 服务器后，只要点击Run或Debug，IDE 就会自动：

启动 Tomcat；部署应用；热加载修改后的文件。

这种方式其实是基于 Catalina 的热部署机制，底层通过监听 Context 变化实现。在开发阶段简直神器，改代码立刻生效！但也别太飘——在生产环境千万别这么玩。IDE 部署仅适合本地调试。

线上环境必须有严格的包管理、备份和日志监控机制。

总结：Tomcat 的六种部署方式

尾声：面试的那一刻

面试那天，面试官笑着问我：Tomcat 有几种部署方式？

我轻轻放下手中的水杯，微微一笑，说：

常见的有六种：拷贝 WAR 包、直接放文件夹、修改 server.xml、配置 context.xml、使用 Manager 页面、以及 IDE 热部署。

面试官点点头，又追问一句：那你推荐哪种？

我不假思索：

生产推荐 context.xml，配合 CI/CD 自动化部署，既安全又灵活。

他笑了笑，合上笔记本，说：不错，你通过了。

那一刻，我心想：

原来，真正的面试题，考的不只是记忆，而是理解与实践的积累。

END

Tomcat 的部署方式，其实就像一个程序员的成长历程：

从拷贝 WAR 包开始，笨但实用；逐步学会配置与脚本；最后掌握自动化与热部署。

每一种方式，都是我们与 Tomcat 并肩作战的印记。

当你能根据场景灵活选择，那你离架构师的味道，也就不远啦！

阿里云服务器增加磁盘

如果你喜欢这种技术+故事的写法，记得点个赞和在看呀～

我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号软件求生，获取更多技术干货！

山东云服务器租用