n 层是什么
n 层指物理部署分层：Web 层、应用层、数据层各自独立部署，通过网络通信。它与逻辑分层是两个不同维度：逻辑分层关注代码职责怎么组织，物理分层关注进程与主机怎么分布，两者经常被混为一谈，导致扩容方案设计错位。
收益与代价
物理分层的收益是隔离与独立扩容：Web 层扛并发连接、应用层扛计算、数据层扛存储，任一层可以单独加机器。代价是每个跨层调用都变成网络调用，延迟与失败概率上升，因此层与层之间必须配超时、重试与降级，否则一次数据库抖动会顺着层间调用放大成整站故障。
逻辑分层与物理分层
| 维度 | 逻辑分层 | 物理分层 |
|---|---|---|
| 关注点 | 代码职责组织 | 部署与网络拓扑 |
| 典型形态 | 表现层、业务层、持久化包结构 | Web 服务器、应用服务器、数据库服务器 |
| 扩容方式 | 不直接对应 | 按层独立扩容 |
| 故障隔离 | 编译期依赖约束 | 进程与主机级隔离 |
基本信息
| 典型形态 | Web 层、应用层、数据层三层 |
|---|---|
| 常见变体 | 四层，额外拆出缓存层或消息层 |
| 部署要求 | 层间网络放行、健康检查与超时配置 |
| 层数决定因素 | 部署边界与安全边界，而非凑数 |
典型使用场景
- 传统企业应用部署：Web 容器集群加数据库主从
- 按层扩容：并发升高时只增加 Web 层实例
- 安全分区：数据库层放内网，只允许应用层访问
- 灰度发布：按层滚动升级，先升应用层再升 Web 层
- 故障隔离：单层异常时不至于整站不可用
容易踩的两个误解
第一个误解是认为分层越多越规范，于是把缓存、消息、搜索各切一层，最后一次业务请求要跨四五个进程，排障时要在多台机器上拼日志。第二个误解是认为物理分层会自动带来解耦，但如果上层直接用 SQL 访问下层数据库，边界只是名义存在。判断是否需要新增一层，看它是否带来独立的扩容需求或独立的安全边界。
三层是最常见的形态，但层数应当由部署与安全边界决定；为了凑层数而拆出的中间层，只会增加调用链长度与运维成本。