**摘要：**在很多 AI 运维场景中，真正决定系统能否稳定运行的，并不是模型本身，而是支撑模型的基础设施布局与服务治理方式。本文围绕一个完整的云上部署实践，对 "三台 ECS + OSS 对象存储 + Nginx 网关" 的组合进行系统拆解，从概念解释到具体配置，力图形成一套可以直接复用的认知框架。用户从浏览器或小程序发起请求，经由 Nginx 进入后端，再访问 MySQL 与 Redis，期间涉及的每一个名词都给出清晰的定义与工程含义。
本文图片来自于课程：01-IT运维基本概念_哔哩哔哩_bilibili
一、整体架构：从小程序到后端服务的访问链路
如图所示，项目整体架构可以分为两部分。一部分是小程序端的发布流程，包括代码上传到微信公众平台、提交审核、测试以及发布上线。另一部分是后端服务访问链路，小程序在上线后会通过网络访问后端接口，这一访问路径与浏览器访问保持一致。
在服务端侧，可以将系统抽象为若干逻辑节点。前端服务节点承担入口角色，内部部署 Nginx，负责接收来自浏览器和小程序 WebView 的 HTTP 请求。后端服务节点通过运行打包好的 Jar 包提供业务接口，通常是 Spring Boot 或类似框架的可执行 Jar。数据层由 MySQL 数据库和 Redis 缓存构成，MySQL 负责结构化数据的持久化，Redis 负责高频访问数据的内存缓存与部分分布式协调任务。
这条链路可以理解为：用户 → 浏览器/小程序 → Nginx → Jar 包服务 → MySQL/Redis。
二、ECS 与网络环境：三节点架构背后的设计
在物理或虚拟资源层，本项目采用三台阿里云 ECS（Elastic Compute Service）实例构建基础环境。ECS 可以看成云端的虚拟服务器，每一台都有独立的 CPU、内存、磁盘和网络配置，运维人员可以像管理传统物理服务器一样登录、安装软件和部署服务。
三台服务器的典型分工可以设置为：（1）node1 部署 MySQL 和 Redis，作为数据节点；（2）node2 部署后端 Jar 包，作为业务节点；（3）node3 部署 Nginx 与前端静态资源，作为入口节点。这样的划分使每一台机器只关注一个主要职责，易于扩展和替换。
在申请 ECS 时，最关键的参数在于网络属性 。阿里云会要求选择地域、可用区以及专有网络 VPC。地域决定数据中心所在的大区位置，例如"华南 2"；可用区是地域内部的物理机房划分；VPC（Virtual Private Cloud）则定义了一组相互隔离的私有网络空间。三台服务器必须处于相同地域、相同可用区、相同 VPC 内，这样它们才会在同一网段中，通过内网地址直接通信。
如图所示，在 ECS 购买页面中可以看到地域和可用区的下拉选项。实践中有一个较为稳妥的做法：当三台服务器配置相近时，可以一次性批量创建多个实例，这样地域和可用区天然保持一致。
在权限层面，还需要在数据库所在节点上为后端服务准备专用账号。**通常会在 MySQL 中创建一个对应****后端服务器（的ip）**user 的账户，并授予该账户远程连接和访问业务库的权限。这样 node2 上的 Jar 服务才能以该身份连接 node1 的 MySQL。很多"数据库连不上"的问题，最终都源自远程访问权限配置不完整。
三、OSS 对象存储：从"云硬盘"到可编程存储服务
对于图片、附件、视频等非结构化文件，如果全部保存在后端服务器本地磁盘中，随着访问量提升，磁盘空间和带宽压力会越来越大。对象存储服务的作用就在于为这些文件提供一个专门的存放与访问空间。
阿里云 OSS（Object Storage Service）是一个面向对象的云存储服务 ，可以理解为部署在云端的"可编程网盘"。与传统文件系统中的"目录 + 文件"模式不同，OSS 使用**"Bucket + Object"**的结构。Bucket 可以理解为逻辑存储空间，每个 Bucket 下可以保存大量对象；Object 是具体的文件，每个对象通过一个 Key 进行索引。应用程序在访问 OSS 时，会向指定的 endpoint 发起 HTTP 请求，附带 AccessKeyId 与 AccessKeySecret 进行身份鉴权。
如图所示，云平台文档中通常会从三个角度描述 OSS 的特点：(1) 相当于位于云端的硬盘，可以保存数量巨大的文件；(2) 通过 HTTP 协议进行访问，只要网络可达就能上传、下载和管理文件；(3) 适合处理海量数据，例如网站图片、视频文件和备份数据等。对运维人员而言，更需要关注访问控制、费用模型以及与现有系统的集成方式。
在具体接入时，项目采取了修改生产环境配置文件的方式。首先，打开后端服务的 Jar 包，可以使用任意解压工具，进入 BOOT-INF/classes 目录，找到生产环境配置文件 application-prod.yml，如图所示。
接着，将该配置文件拖到桌面进行修改，在其中新增或调整 oss: 配置段，填写以下四个关键字段：endpoint、accessKeyId、accessKeySecret 和 bucketName（在阿里云OSS控制台都有） 。endpoint 指向对应地域的 OSS 访问域名；accessKeyId 和 accessKeySecret 构成访问凭证；bucketName 是在 OSS 控制台中创建的桶名称。修改完成后，再将 application-prod.yml 拖回原来的 Jar 包位置，覆盖旧文件。
通过这一方式，后端服务在启动时即可读取 OSS 配置信息，通过 SDK 或封装好的工具类完成文件上传和下载。整个过程主要发生在配置层，业务代码基本保持稳定，从运维视角看具有较高的可维护性。
四、Nginx：Web 服务器、反向代理与网关的统一实现
在整体架构中，Nginx 位于服务入口位置，承载 Web 服务器与反向代理双重角色。Nginx 使用事件驱动模型处理连接，对单机多并发场景有良好的适应能力，在高访问量网站和微服务网关领域应用广泛。
从功能定义角度，可以将 Nginx 理解为三种能力的叠加。第一，Web 服务器能力，负责接收浏览器发来的 HTTP 请求，返回 HTML 页面、CSS 样式和 JavaScript 脚本等静态资源。第二，反向代理能力，负责接收客户端请求后，根据配置转发给后端服务，此时客户端只看到 Nginx 的地址，看不到后端实例的真实 IP 与端口。第三，负载均衡能力，当存在多台后端实例时，Nginx 可以按照轮询、权重或最少连接等策略，将请求均匀分配到各个后端节点，减轻单节点压力。
部署 Nginx 的实际步骤并不复杂：(1) 在前端节点上通过包管理器或二进制安装 Nginx ；(2) 启动 Nginx 服务进程；(3) 在云平台安全组中开放 80 端口 ，如需要 HTTPS 再开放 443 端口。安全组是云平台提供的虚拟防火墙机制，用于控制入站和出站流量。只有安全组放通了 HTTP/HTTPS 对应端口，外部请求才会真正到达服务器上的 Nginx 进程。
五、Nginx 目录结构与文件组织
为了能够稳定修改和排障，需要对 Nginx 的目录结构形成清晰认识。常见 Linux 发行版下，Nginx 的核心目录集中在
/etc/nginx与/var/www两个路径。
/etc/nginx 用于存放配置文件 。nginx.conf 是主配置文件，负责定义 worker 进程数量、日志路径、HTTP 块结构等全局参数。conf.d 目录通常用于放置各站点或服务的独立配置文件，例如可以为每一个域名或每一个项目建立一个 .conf 文件，便于分开管理和按需启用。mime.types 文件中定义了文件扩展名与 MIME 类型的映射规则，例如 .html 对应 text/html，.js 对应 application/javascript，Nginx 会在响应头中使用这些类型信息。
/var/www 目录则承载静态资源。许多默认配置中，/var/www/html 被用作网站根目录，前端构建产物可以放置在此目录下 。如果前端项目构建生成的是 dist 目录，则可以将 dist 作为根目录，例如 /var/www/dist 。在 Nginx 配置中，通过 root 指令指向这一目录，通过 index 指令指定默认首页文件。
如图所示，对目录结构进行可视化展示之后，整个配置与文件组织关系会较为直观。一旦访问出现 404、静态资源加载异常或 MIME 类型错误，就可以从这两个目录入手排查问题。
六、Nginx 配置解析：静态资源与接口转发的协同
在完成目录和文件准备之后，需要在 Nginx 中写入具体的 server 配置。下图给出了一段典型的配置片段，涵盖静态资源访问和后端接口转发两类需求。
在 location / 段落中，root /var/www/dist; 指定了静态资源根目录，index index.html index.htm; 声明了默认首页文件。当用户访问根路径 / 时，Nginx 会先在 /var/www/dist 下寻找 index.html 或 index.htm。try_files $uri $uri/ /index.html; 是前端单页应用常用写法 ，当请求路径对应的实际文件不存在时，Nginx 会回退到 index.html，将路由控制权交给前端框架，避免刷新页面时出现 404。
在 location /prod-api/ 段落中，proxy_pass http://192.168.88.102:8080/zzyl-admin/;指明了后端服务的真实地址。这里使用的是内网 IP 与端口**（后端节点所在 ECS 服务器在 VPC 里的内网 IP）** ，路径 /zzyl-admin/ 对应后端 Jar 服务的上下文路径。proxy_set_header Upgrade $http_upgrade; 与 proxy_set_header Connection upgrade; 的作用是在需要 WebSocket 等长连接场景下，正确传递 HTTP 头部信息，保证连接升级过程顺利完成。
通过这样的配置划分，浏览器和小程序只需要面向一个统一入口域名，静态页面和接口请求由 Nginx 根据 URL 自动区分和转发。前后端部署位置可以独立调整，对外暴露方式保持稳定，整体运维难度明显降低。
七、从组件到体系：云上基础部署的运维视角
回到 AI 运维的视角，ECS、OSS 与 Nginx 是支撑整套系统的基础设施组合。ECS 提供计算与网络环境，为服务运行提供容器；OSS 提供面向对象的存储空间，用于承载大量非结构化文件；Nginx 提供访问入口与流量治理机制，将用户请求有序分发到各个后端节点。
如果从流程角度再整理一次，可以得到这样一条实践路线：（1）根据业务需求设计三节点架构，明确前端、后端和数据节点的职责；（2）在同一地域、同一可用区和同一 VPC 内申请三台 ECS，建立可互通的内网环境；（3）在 node1 上部署 MySQL 与 Redis，创建后端访问账户并配置远程连接权限；（4）在 node2 上部署后端 Jar 包，并在
application-prod.yml中接入 OSS 配置；（5）在 node3 上安装 Nginx，将前端构建产物放入/var/www/dist或类似目录，并编写静态资源与反向代理相关配置；（6）在云平台安全组中开放 80（以及需要时的 443）端口，确保用户访问能够穿透到 Nginx；（7）通过小程序审核发布流程，将前端入口与这一套后端服务打通。
在后续的章节中，可以在这一基础之上继续扩展 HTTPS 证书部署、日志采集、灰度发布与监控告警等内容。只要始终围绕"组件职责、访问链路与配置含义"三个维度理解云上部署，就能在更复杂的 AI 运维场景中保持清晰的工程判断。