大厂生产环境：云设施与生产链路
本文整合《大厂生产环境网络与服务架构》《云厂商、VPC 与生产环境基础设施规划》《生产环境上线部署流程》《LB、Nginx 的联系与区别》。
全文分成两条主线：
- 云设施：回答资源放在哪里、如何划分网络边界、如何隔离访问。
- 生产链路：回答请求如何进入系统、如何找到服务和数据、如何完成上线与回滚。
第一部分：云设施——资源放在哪里，如何隔离
PNG 备用文件：01_云设施全景.png
1. 云厂商、账号/组织、VPC、子网、资源的关系
生产环境通常尽量把同一个业务的核心服务和基础设施放在同一云厂商的网络体系中。最基础的层级关系是：
云厂商
↓
账号 / 组织
↓
VPC
↓
子网
↓
ECS（Elastic Compute Service 弹性计算服务 即云服务器） / LB / MySQL / Redis / MQ 等资源
各层职责：
| 层级 | 回答的问题 | 典型含义 |
|---|---|---|
| 云厂商 | 在哪个云平台建设？ | 阿里云、腾讯云、华为云、AWS 等 |
| 账号 / 组织 | 由谁管理、如何计费和隔离权限？ | 企业账号、资源目录、组织单元 |
| VPC | 私有网络边界在哪里？ | 云上独立私有网络 |
| 子网 | VPC 如何继续分区？ | 公网、应用、数据等网段 |
| 资源 | 具体运行什么？ | ECS、数据库、缓存、消息队列等 |
需要特别区分三个概念：
同一个云厂商 ≠ 同一个 VPC
一个 VPC ≠ 只能服务一个项目
一个项目 ≠ 必须固定对应一个子网
云厂商可以提供多个 VPC；一个 VPC 也可以承载多个业务项目、公共基础设施或环境资源。划分 VPC 和子网时，主要依据网络安全边界、环境隔离、组织结构和合规要求，而不是机械地按照项目名称划分。
2. VPC 与 CIDR：云上私有网络边界
VPC 全称是 Virtual Private Cloud，即虚拟私有云。可以把它理解成云厂商内部的一块大型私有局域网。
例如：
VPC：10.0.0.0/16
VPC 内的资源可以使用私网 IP 通信。与公网通信时，还要结合公网 IP、NAT 网关、公网负载均衡、路由和安全组等能力。
CIDR 全称是 Classless Inter-Domain Routing，即无类别域间路由，写法是：
IP / 前缀长度
常见规划示例：
VPC：10.0.0.0/16
子网：
10.0.1.0/24
10.0.2.0/24
10.0.3.0/24
10.0.3.0/32
| CIDR | 网络位 | 常见用途 | 地址规模 |
|---|---|---|---|
10.0.0.0/16 |
前 16 位 | 较大的 VPC 网段 | 约 65,536 个地址 |
10.0.1.0/24 |
前 24 位 | 较小的一组子网 | 约 256 个地址 |
/16 和 /24 是常见规划，不是固定规定。云厂商还会保留部分地址，因此实际可分配数量通常少于理论值。
记住两者的区别：
VPC
= 私有网络边界
CIDR
= 描述这个网络及其子网范围的方法
子网
= VPC 内部的网络分区
3. 子网与可用区 AZ：网络分区和高可用
一个 VPC 可以划分多个子网。子网可以按照网络功能、安全边界、资源类型和可用区进行规划。
可用区 AZ 是同一地域内相对独立的物理区域。生产环境通常不会把所有实例和数据库都放在一个可用区，而是做多可用区部署：
VPC
├── 可用区 A
│ ├── App-1
│ └── Data-1
├── 可用区 B
│ ├── App-2
│ └── Data-2
└── 可用区 C
├── App-3
└── Data-3
当 AZ-A 发生故障时，AZ-B 和 AZ-C 仍然可以提供服务。多实例解决单机故障，多可用区进一步降低单个可用区故障造成整体不可用的风险。
生产环境常用子网分层：
公网 / 接入子网
↓
应用子网
↓
数据子网
- 公网 / 接入子网承载 LB、NAT、WAF（Web Application Firewall Web 应用防火墙） 等入口资源；
- 应用子网承载 Nginx、Java、Python 和其他业务服务；
- 数据子网承载 MySQL、Redis、MQ、Milvus、TOS、OBS 等核心数据资源。
4. 公网子网与私网子网：哪些资源能接公网
公网子网和私网子网都属于 VPC。区别不在于“是不是 VPC 内部”，而在于路由、网关和公网访问能力。
公网子网通常关联公网网关或等价能力，允许其中的资源与 Internet 建立连接，常见资源包括：
负载均衡
NAT 网关
公网入口
必要的 Web 层资源
私网子网通常不配置直接访问公网的默认路由，常见资源包括：
Java / Python 服务
MySQL
Redis
Milvus
MQ
典型流量路径：
Internet
↓
公网入口 / 公网子网
↓
应用子网
↓
数据子网
核心原则是：能不直接暴露公网的服务，就不要暴露公网。 数据库、缓存和消息队列通常只允许应用层通过 VPC 私网访问。
5. 路由、安全组与网络 ACL：网络可达 ≠ 访问允许
云网络里至少有三个不同层次的控制：
路由
→ 数据包应该往哪里走？
安全组 / 网络 ACL
→ 这条访问是否被允许？
端口
→ 最终访问的是哪一个服务？
VPC 路由属于网络层，解决数据包从源地址到目标地址的可达性。例如：
10.0.1.10
↓
VPC 路由
↓
10.0.2.20
Nginx 路由属于应用层，解决 HTTP 请求应该交给哪个服务。例如：
GET /api/user
↓
Nginx
↓
Java 用户服务
两者不能混为一谈：
| 对比项 | VPC 路由 | Nginx 路由 |
|---|---|---|
| 所在层 | 网络层 | 应用层 |
| 处理对象 | IP 数据包 | HTTP / HTTPS 请求 |
| 核心问题 | 数据包往哪里走 | 请求交给哪个应用或服务 |
| 典型依据 | 目标网段、路由表 | Host、Path、Header、Cookie |
即使两个资源位于同一个 VPC，也不代表所有访问都会自动获得业务许可。例如应用需要访问 MySQL 3306 端口，通常是：
应用安全组
↓
MySQL 安全组
↓
允许 3306
而不是：
0.0.0.0/0
↓
允许访问 3306
安全组通常作用于实例或资源，网络 ACL 更偏向子网级别的补充控制。生产环境应遵循最小权限原则。
6. 一个 VPC 是否只服务一个项目
不一定。
一个公司可能拥有多个 VPC：
云账号 / 组织
├── VPC-A：生产环境
├── VPC-B：测试环境
├── VPC-C：数据平台
└── VPC-D：其他业务
一个 VPC 也可能同时服务多个项目：
VPC
├── 项目 A
├── 项目 B
└── 公共基础设施
是否拆分 VPC，通常取决于：
- 安全边界和爆炸半径；
- 生产和测试环境是否隔离；
- 业务之间是否需要强网络隔离；
- 组织结构、权限和合规要求；
- 网络地址是否冲突；
- 运维和成本能否接受。
因此：
项目只是业务概念
VPC 是网络概念
子网是网络分区概念
它们相关，但不是一一对应的固定关系。
7. 多云与第三方 SaaS 的正确理解
大型企业可能同时使用多个云厂商，但通常是基于整体规划，而不是把同一个业务的核心 MySQL、Redis、MQ 随意分散在不同云上。
常见多云原因：
- 不同地域覆盖；
- 合规和数据驻留要求；
- 不同云厂商的 AI、GPU、数据库、CDN、音视频等能力差异；
- 避免单一厂商依赖；
- 收购、合并和系统迁移形成的历史架构。
更典型的多云结构是：
阿里云
└── 国内核心业务
AWS
└── 海外业务
华为云
└── 特定业务或合规场景
对于 Java 服务高频访问的 MySQL、Redis、MQ 等核心基础设施，通常尽量放在同一个云网络体系中。跨云访问要额外考虑 VPN、专线、VPC Peering、PrivateLink、路由、安全策略、延迟、故障和流量费用。
第三方 SaaS 是特殊情况。Zilliz、第三方 AI API、企业级向量服务等不一定要部署在自己的 VPC 中，可以通过 HTTPS API、PrivateLink、VPC Peering、VPN 或专线连接。
正确原则是：
高频、核心、强依赖的内部基础设施尽量处于同一云网络体系；外部 SaaS 或专业服务可以通过受控网络或 API 与业务系统连接。
8. Java + AI 项目的典型云资源布局
一个 Java + AI 项目可以采用如下结构：
云厂商
└── VPC：10.0.0.0/16
├── 公网 / 接入子网
│ └── ALB / SLB / NAT slb是阿里云的总负载均衡产品，alb是其中一种
│
├── 应用子网
│ ├── ECS-1：Nginx + Java + Python
│ ├── ECS-2：Nginx + Java + Python
│ └── ECS-3：Nginx + Java + Python
│
└── 数据子网
├── MySQL
├── Redis
├── MQ
└── Milvus
运行时访问路径：
用户
↓
DNS
↓
LB
↓
ECS / Nginx
↓
Java / Python
↓
MySQL / Redis / MQ / Milvus
其中：
- LB 接收并分发入口流量；
- 应用服务通过 VPC 私网访问数据层；
- 数据层不直接暴露公网；
- 安全组进一步限制“谁可以访问谁”；
- 多可用区和多实例共同提供高可用能力。
9. 第一部分总结：VPC 是网络边界，项目只是业务概念
云厂商
↓
账号 / 组织
↓
VPC
↓
子网
↓
资源
最关键的三句话：
- 同一个云厂商可以有多个 VPC，同一个 VPC 也可以服务多个项目。
- VPC 路由决定网络能否到达，安全组和网络 ACL 决定访问是否允许，端口决定访问哪个服务。
- 高频、核心、强依赖的基础设施尽量放在同一个云网络体系中，但不能把“必须全部在同一 VPC”绝对化。
第二部分：生产链路——请求如何进来，服务如何发布
PNG 备用文件：02_生产全链路.png
1. 全链路总览：DNS → LB → Nginx/Gateway → Service → Data
典型生产环境不是：
用户 → ECS → MySQL
而是会把网络入口、节点负载、应用路由、服务路由和数据访问拆成不同层次：
用户
↓
DNS
↓
Internet
↓
CDN（缓存加速） / WAF（web攻击防护-SQL注入，XSS） / DDoS（抗流量攻击）
↓
LB：SLB / ALB / NLB
↓
Nginx / Gateway / Ingress
↓
Java / Python 等服务
↓
MySQL / Redis / Milvus / MQ
外围还包括：
安全体系
监控、日志、链路追踪与告警
CI/CD
Docker / Kubernetes
备份与容灾
可以用四个问题理解整条链路：
| 层 | 核心问题 | 典型组件 |
|---|---|---|
| DNS | 入口在哪里？ | DNS |
| LB | 去哪一个节点？ | SLB、ALB、NLB |
| 代理 / 网关 | 去哪一个应用或服务？ | Nginx、Gateway、Ingress |
| 业务与数据 | 如何执行业务、读写数据？ | Java、Python、MySQL、Redis 等 |
2. DNS：只负责把域名解析到入口
DNS 全称是 Domain Name System，核心作用是把域名转换成 IP 地址或其他解析结果：
api.example.com
↓
DNS
↓
1.2.3.4
这个地址可能对应：
- ALB；
- SLB；
- Nginx；
- CDN；
- API Gateway。
DNS 的核心是：
域名 → 流量入口
它通常不负责：
/api/user → 用户服务
/api/order → 订单服务
因此，DNS 解决“入口在哪里”，不解决“业务请求交给哪个服务”。
3. CDN、WAF、DDoS：可选的公网加速与安全层
CDN 主要用于加速和分发静态内容：
- JS、CSS、图片和视频；
- 内容就近访问；
- 降低源站压力；
- 降低公网带宽压力；
- 部分 DDoS 防护。
典型过程是：
用户
↓
CDN
↓
缓存命中：直接返回
缓存未命中：回源
WAF 更关注 HTTP / HTTPS 应用层攻击防护，DDoS 防护更关注大流量攻击。它们不是所有系统的必备组件，但大厂公网业务通常会按风险和流量规模配置。
CDN、WAF、DDoS 防护与 DNS、LB 一样，都属于公网入口体系的一部分，但职责不同：
DNS → 找到入口
CDN → 加速内容、减少回源
WAF → 过滤恶意应用层请求
DDoS → 吸收或清洗异常大流量
LB → 把合法流量分发到多个节点
4. LB：节点级负载均衡，L4 与 L7 ALB 的区别
LB 全称是 Load Balancer，核心是回答：
这次请求应该进入哪一个节点？
例如：
LB
/ \
↓ ↓
Server A Server B
主要能力包括：
- 负载均衡；
- 健康检查；
- 故障节点摘除；
- 水平扩容入口；
- 提高服务可用性。
健康检查发现 Server B 异常后：
LB
↓
Server A
LB 不再向 B 发送新请求，从而把多个相同实例组织成一个高可用服务入口。
云厂商产品名称可能不同：
SLB → Server Load Balancer
ALB → Application Load Balancer
NLB → Network Load Balancer
画通用架构图时，可以统一写 Load Balancer 或 LB。
LB 也分不同层次：
| 类型 | 主要依据 | 典型能力 |
|---|---|---|
| L4 LB / NLB | TCP、UDP、IP、Port | 高性能四层转发，偏节点级分发 |
| L7 ALB | HTTP、HTTPS、Host、Path、Header、Cookie | 七层路由、灰度、会话和内容分发 |
传统四层 LB 更偏向“去哪台机器”，但现代 ALB 可以进行七层路由：
api.example.com → Java 集群
ai.example.com → AI 集群
/api/user → User Service
/api/order → Order Service
因此不能机械记成“LB 不负责路由”。更准确的表述是：
传统 LB 主要负责节点级负载，现代 ALB 具备 HTTP 七层路由能力，可以接管部分 Nginx 或 Gateway 的路由职责。
5. Nginx：反向代理、域名路由、路径路由与多层代理
Nginx 同时可以承担：
Web Server
+ Reverse Proxy
+ Load Balancer
+ HTTP 流量处理
常见职责包括：
- 静态资源服务；
- 反向代理；
- 域名路由；
- 路径路由；
- HTTPS 终止；
- 负载均衡；
- 请求头处理、重写、限流等。
例如：
浏览器
↓
Nginx
├── / → 前端 dist
├── /api/ → Java
└── /ai/ → Python
为什么叫反向代理
区别不是“方向反了”，而是代理站在谁的一侧、代表谁访问目标。
正向代理：
客户端 → 正向代理 → 目标服务器
代理客户端
反向代理：
客户端 → Nginx → 后端服务
代理服务器
正向代理通常代理客户端去访问互联网；反向代理站在服务端前面，替后端服务接收请求。
第一层 Nginx：域名路由
www.example.com → 官网
admin.example.com → 管理后台
student.example.com → 学生端
核心是：
Host → 应用
第二层 Nginx：路径路由
/api/user → User Service
/api/order → Order Service
/api/ai → AI Service
核心是：
Path → 后端服务
Nginx 可以只有一层，也可以根据域名、应用、服务和团队边界拆成多层。不是层级越多越成熟，而是职责越清晰越容易治理。
LB 与 Nginx 的关系
经典分工可以记成：
LB
= 节点级流量分发
= 去哪个 ECS / Server？
Nginx
= 应用层请求处理与路由
= 去这个节点中的哪个应用或服务？
但它们不是必须同时存在：
- 小型系统可以让 Nginx 同时完成反向代理、路由和负载均衡；
- 使用 LB 后，也可以让 LB 直接转发到业务服务；
- 使用 ALB 时，部分域名和路径路由可能已经在 LB 完成。
LB 与 Nginx 不天然重复，关键是看“节点选择”和“应用路由”被放在哪个组件中。
6. LB、Nginx、Gateway、Ingress 的职责划分与历史演变
不同阶段的生产架构可以这样理解：
| 阶段 | 典型链路 | 主要变化 |
|---|---|---|
| 单体 | 用户 → Tomcat → MySQL | 一台应用直接对外 |
| Nginx | 用户 → Nginx → Tomcat | 反向代理、HTTPS、静态资源 |
| 多实例 | 用户 → Nginx → 多台 Tomcat | Nginx 开始承担负载均衡 |
| 云计算 | 用户 → SLB / ALB → Nginx → Tomcat | 基础设施 LB 与应用代理分层 |
| 微服务 | 用户 → LB → Gateway → 微服务 | 出现专业 API Gateway |
| 云原生 | 用户 → Cloud LB → Ingress → Service → Pod | Ingress Controller 接管入口路由 |
现代生产架构没有唯一答案，常见有四种方案组合：
方案一：Internet → Nginx → Services
方案二：Internet → SLB / ALB → Nginx → Services
方案三：Internet → ALB → API Gateway → Microservices
方案四：Internet → Cloud LB → Ingress → Service → Pod
选择的依据是流量规模、技术栈、发布方式、团队职责和运维边界，而不是死记某一个组件组合。
一个统一的理解模型是：
DNS
找入口
LB
找节点
Nginx / Gateway / Ingress
找应用和服务
Service
执行业务
Data
保存和读取数据
同时必须保留两个例外：
- Nginx 本身也可以负载均衡；
- ALB 作为七层负载均衡，也可以做域名和路径路由。
7. 应用层与数据层：多实例、MySQL、Redis、Milvus、MQ、OSS/NAS
进入私网后，应用服务通常会有多个实例：
LB
├── Java-1 / Python-1
├── Java-2 / Python-2
└── Java-3 / Python-3
多实例用于：
- 水平扩容；
- 高可用；
- 故障转移；
- 流量分摊；
- 滚动发布。
应用层与数据层通常进一步隔离：
应用层
├── Java
├── Python
└── 其他服务
↓
数据层
├── MySQL
├── Redis
├── Milvus
├── MQ
└── OSS / NAS
| 组件 | 主要用途 | 生产关注点 |
|---|---|---|
| MySQL | 用户、订单、课程、权限、配置等结构化数据 | 主从、读写分离、备份、故障切换 |
| Redis | 缓存、Session、分布式锁、计数器、热点数据 | 主从、哨兵（Sentinel）、集群、高可用 |
| Milvus | RAG、知识库、语义搜索、向量检索 | 索引、容量、查询性能、数据一致性 |
| MQ | 异步解耦、削峰、消息驱动、最终一致性 | 顺序、积压、重试、死信、幂等 |
| OSS | 图片、视频、文件、上传资源和备份 | 权限、生命周期、跨地域复制 |
| NAS | 多服务共享文件系统 | 挂载、权限、性能和容量 |
应用访问数据层时，通常使用 VPC 私网地址，并通过安全组限制来源。
8. 监控、日志、链路追踪与告警
服务部署完成不代表生产环境已经可用。还需要回答：
系统现在是否正常？哪里慢？哪里报错？异常时谁先知道？
完整观测体系通常包括：
监控
日志
链路追踪
告警
监控
常见指标包括：
CPU、内存、磁盘、网络
QPS、响应时间、错误率
连接池、线程池、队列积压
日志
集中收集：
Nginx 日志
Java 日志
Python 日志
数据库和中间件日志
常见体系有 ELK、Loki 等。
链路追踪
一次请求可能经过：
用户
↓
Nginx
↓
Java
↓
Redis
↓
MySQL
链路追踪用于定位具体是哪一步慢、哪一步报错，常见方案有 SkyWalking、Zipkin 等。
告警
例如：
CPU > 80%
错误率 > 5%
接口 P99 > 1s
MySQL 连接池耗尽
Redis 不可用
告警可以通过短信、邮件、企业微信、飞书等渠道发送。指标、日志和链路需要相互关联，才能从“发现问题”走到“快速定位问题”。
9. CI/CD：Git → 构建 → 镜像 → 镜像仓库 → 部署
生产环境不应采用：
本地改代码
↓
SSH 登录服务器
↓
手工复制文件
更常见的自动化流程是：
Git
↓
CI：持续集成
↓
构建与测试
↓
Docker Image
↓
镜像仓库：ACR / Harbor
↓
CD：持续部署
↓
ECS / Kubernetes
CI 关注代码提交后的自动检查和构建，CD 关注把通过验证的产物安全地发布到目标环境。
Docker 负责应用容器化：
Docker
├── Java 容器
├── Python 容器
└── Nginx 容器
当 ECS 和容器规模变大后，可以使用 Kubernetes 进行：
- 容器编排；
- 服务发现；
- 自动扩缩容；
- 故障恢复；
- 滚动发布；
- 调度；
- 服务负载均衡。
Kubernetes 不是所有项目的必选项。规模、发布频率和团队运维能力决定是否引入。
10. 生产环境上线部署八步流程
| 步骤 | 工作内容 | 关键产物或检查项 |
|---|---|---|
| 1. 云资源准备 | 创建 VPC、子网、ECS/容器节点、MySQL、Redis、Milvus 等资源 | 网络规划、资源清单、容量 |
| 2. 网络与安全配置 | 配置公网入口、SLB/ALB/Nginx、安全组和私网访问 | 数据库不直接暴露公网，最小权限 |
| 3. 服务器环境准备 | 安装 Docker、Jenkins、Nginx，创建统一部署目录 | 权限、日志、磁盘和基础依赖 |
| 4. 项目 Docker 化 | 编写 Dockerfile、docker-compose.yml 和 .env |
可重复构建、环境配置外置 |
| 5. CI 持续集成 | Checkout、构建、测试并生成 Docker Image | 代码检查、测试结果、镜像 Tag |
| 6. CD 持续部署 | 推送和拉取镜像，执行部署并做健康检查 | ACR/Harbor、部署脚本、健康状态 |
| 7. 上线验证 | 检查容器、健康接口、业务接口、前端、日志和数据连通性 | 功能、性能、日志、MySQL/Redis/Milvus |
| 8. 回滚 | 保留历史 Image Tag，异常时切回上一版本 | 镜像版本、数据库回滚或数据恢复方案 |
CI/CD 的最小链路可以概括为：
Git
↓
Jenkins / CI
↓
Docker Build
↓
ACR / Harbor
↓
生产服务器
↓
docker pull
↓
docker compose up -d
↓
Health Check
使用 Kubernetes 时，最后几步可能变成 Deployment、Service、Ingress 和 Rollout，但“构建产物可追踪、部署可重复、异常可回退”的原则不变。
11. 上线验证与回滚
上线验证不只检查进程是否启动，还要检查完整业务链路：
容器状态
↓
健康检查
↓
核心接口
↓
前端访问
↓
日志检查
↓
数据库 / Redis / Milvus 连通性
生产发布还要保证：
- 历史镜像 Tag 被保留；
- 发布版本可识别、可追踪；
- 出现异常时可以快速切回上一版本；
- 数据库变更要评估兼容性、回滚方式和数据恢复能力；
- 回滚后重新检查健康状态和核心业务链路。
版本回滚不是简单地把代码换回去。数据库结构或数据已经发生变化时，必须事先设计兼容和数据恢复策略。
12. 第二部分总结：成熟架构的关键是职责分层与边界清晰
DNS
负责找入口
LB
负责找节点
Nginx / Gateway / Ingress
负责找应用和服务
Java / Python
负责执行业务
MySQL / Redis / Milvus / MQ
负责保存和交换数据
监控 / 日志 / 链路 / 告警
负责观察和定位
CI/CD
负责构建、发布和回滚
真正成熟的理解不是死记：
LB = 负载均衡
Nginx = 路由
而是理解：
企业会根据流量规模、网络层次和运维边界，把节点级负载、应用级路由、发布控制和运行观测拆到不同组件中；组件名称可以变化，但职责和边界必须清晰。