我们背诵的“Web是静态的，WAS是动态的”这个公式，今天还适用吗？
本文将探讨：
- Web服务器和WAS的传统职责划分
- 前端/后端是WAS的子分类吗？
- 在现代架构中，前端为何也拥有了WAS
- 减少术语混淆的思维框架
为什么这个话题会让人困惑？
有些问题，即使是新手开发者，甚至是有经验的开发者，也会犹豫不决。
Next.js服务器是Web服务器还是WAS？
React应用是前端，所以它不是WAS，对吗？
SSR和WAS有什么区别？
问题在于我们学习的教科书是基于2000年代初期Java Web架构编写的。当时，前端和后端几乎都在同一个WAS中运行。但现在，世界已经完全不同了。
传统观点 — Web服务器 vs WAS
首先，让我们明确整理一下原始定义。
Web服务器的作用
它是响应静态内容的服务器。它直接提供HTML、CSS、JavaScript文件、图片、字体等，这些文件在请求时内容不会改变。
代表产品有Nginx、Apache HTTPD，其特点如下：
- 速度快（从磁盘读取文件并立即响应）
- 并发连接数多
- 不执行业务逻辑
WAS的作用
它是生成动态内容的服务器。它根据用户请求查询数据库，运行条件语句，并组合结果来创建响应。
代表产品有Tomcat、JBoss/WildFly、WebLogic，其特点如下：
- 执行业务逻辑（服务层）
- 管理数据库连接池、事务
- 处理会话、认证、权限
这便是“原始定义”。在那个时期，前端/后端是WAS内部的层次划分。如果使用JSP或Servlet生成HTML，那就是前端；如果使用Service/DAO处理数据库数据，那就是后端。两者都在同一个Tomcat中运行。
那么，WAS是否分为前端和后端？
这是核心问题。结论是——“以前是WAS内部的层次划分，但现在WAS本身已经分化为两种类型” 是最准确的答案。
为什么会发生分化？
从2010年代中期开始，两件事情同时发生。
第一是SPA（单页应用）的兴起。随着React、Vue、Angular的出现，前端开始在浏览器中独立运行。服务器不再生成HTML，只提供JSON API，浏览器自行绘制屏幕。
第二是SSR（服务器端渲染）的重新出现。为了解决SPA的SEO和初始加载问题，基于Node.js的Next.js、Nuxt.js等框架再次在服务器端生成HTML。
在第二个节点上，“前端专用WAS”的概念应运而生。
现代三层划分
| 类别 | 职责 | 代表技术 |
| Web服务器 | 提供静态资源 | Nginx, Apache, CDN |
| 前端WAS | 通过SSR动态生成HTML | Next.js, Nuxt.js, Remix |
| 后端WAS | 业务逻辑 + 数据库 | Spring Boot, Django, Rails |
换句话说，您提出的“WAS是否可以分为前端和后端”这个问题，在现代意义上，最准确的理解是“WAS范畴内出现了两种类型的服务器”。并非WAS的内部一分为二，而是可以被称为WAS的服务器种类增加到了两种。
简单比喻 — 餐厅
将这三种服务器比作餐厅，更容易理解。
- Web服务器 = 门口的菜单板。快速展示不变的信息。
- 前端WAS(SSR) = 服务员。接收顾客的请求，传达给厨房，并整理好订单返回。（负责UI组装）
- 后端WAS(API) = 厨房。进行实际的烹饪（业务逻辑）并取出食材（数据库）。
在传统架构中，服务员和厨房紧密相连。现在，两者分离并独立工作。甚至有很多没有服务员的餐厅（SPA + 纯API结构）。
实际配置示例
在现代云架构中，一个服务的配置通常是这样描绘的。
[Browser]
↓ HTTPS
[CloudFront / Nginx] ← Web Server (정적 자원)
↓
[Next.js on Node.js] ← Frontend WAS (SSR)
↓ REST / GraphQL
[Spring Boot on Tomcat] ← Backend WAS (API)
↓ JDBC
[PostgreSQL / MySQL] ← Database这里值得注意的是，每个层都运行在不同的实例或容器中。即使前端WAS宕机，后端WAS仍然存活，反之亦然。这就是MSA（微服务架构）时代的灵活性。
⚠️ 三个常见误解
第一，“React应用本身就是WAS” — 不对。React应用是在浏览器中执行的JavaScript捆绑包。通过Webpack、Vite构建的静态资源通常由Nginx提供服务。在这种情况下，前端仅仅是Web服务器后面的静态文件，而不是WAS。
第二，“Next.js是Web服务器” — 不对。当Next.js以SSR模式运行时，它会为每个请求动态生成HTML，因此它明确是WAS。但是，如果以Static Export模式构建，它只会生成静态文件，那么这些产物可以部署在Web服务器上。
第三，“Nginx也处理API逻辑” — 误解。Nginx作为反向代理，仅仅是将请求转发给WAS，它本身不执行业务逻辑。逻辑由其背后的WAS处理。
✅ 总结
- 原则依然有效：Web服务器 = 静态，WAS = 动态的基本公式没有改变。
- WAS的外延扩大了：在现代，WAS可以分为前端（SSR）层和后端（API）层两种。
- 判断标准：以“每次请求时服务器端是否执行代码”为标准进行判断，会非常清晰。
- 实务观点：在绘制自己的服务架构时，可以将每个组件代入Web服务器 / 前端WAS / 后端WAS / 数据库这四个类别中的一个。
最终，术语会随着时代而扩展其外延。与其固守教科书的定义，不如拥有一个区分各层是静态还是动态、是客户端代码还是服务器代码的思维框架，这样会实用得多。
发表回复