初探阿里云 Serverless 架构

作为前端 er，有时候会好奇一个公司的运维工作到底是如何开展的，前端、后端的项目会选择如何部署？我们公司大多的服务都是购买自阿里云，其提供的产品、服务琳琅满目，看到它的菜单栏简直头大，很多不了解的产品名，因此激发了我想一探究竟的兴趣，这篇文章是我与 AI 聊天过程中得到的一些认识，很好的帮助了我了解基本的运维，希望也对你有帮助。

在初创阶段，尤其是基于 React 前端和 Node.js 后端的分离架构，直接购买 ECS 并自行维护 Linux 系统并非最优解。更合理的策略是采用全托管的 Serverless 架构，以降低运维成本并提高稳定性。

整体架构被拆解为三部分：前端、后端与数据。前端的 React 静态资源不应存放在服务器硬盘，而应托管在 OSS（对象存储）中，并配合 CDN（内容分发网络）进行加速。OSS 负责存储，CDN 负责分发，这种组合不仅提升了加载速度，还能节省 ECS 的公网带宽成本。后端 Node.js 应用推荐使用 SAE（Serverless 应用引擎）替代传统 ECS。SAE 免去了配置 Nginx、安装环境和服务器安全加固的繁琐过程，支持通过镜像或代码包直接部署，并且能根据流量自动扩缩容。数据库则选用 RDS MySQL，利用其自动备份和恢复功能保障数据安全，避免自建数据库在容灾上的短板。

网络规划是基础设施的核心。需要创建一个 VPC（专有网络），建议网段为 192.168.0.0/16，并在其下划分不同的交换机（vSwitch）以隔离资源。例如，使用 192.168.1.0/24 作为公网/网关子网，放置 NAT 网关；使用 192.168.2.0/24 作为私网/应用子网，放置 SAE 和 RDS。这种划分不仅逻辑清晰，还能通过安全组和网络 ACL 增强隔离性。需要特别注意的是，SAE 和 ECS 默认无法访问公网，为了支持 npm install 或调用第三方接口，必须配置“公网 NAT 网关”，绑定 EIP 并设置 SNAT 条目，涵盖所有需要上网的交换机网段。

流量入口层引入 ALB（应用型负载均衡）接管公网请求。配置 ALB 时有一个硬性约束：必须在至少两个不同的可用区创建交换机。HTTPS 证书应配置在 ALB 监听上，而非后端的 Node.js 服务或域名本身。这实现了 SSL 卸载，即 ALB 负责处理加密握手，解密后的请求通过内网转发给后端，减轻了后端计算压力。域名解析只需 CNAME 指向 ALB 的 DNS 名称即可。

在多环境管理上，采用“逻辑隔离”而非“物理堆砌”的策略能有效控制成本。生产环境（Prod）应独享一个 VPC 和高可用 RDS 实例，SAE 实例配置高规格并保持常驻。开发（Dev）、测试（Fat）和预发（UAT）环境可以共用一个非生产 VPC，通过 SAE 的“命名空间”进行隔离。非生产环境的数据库可在同一个 RDS 实例中创建不同的库（如 db_dev, db_test）来区分。为了省钱，非生产环境的 SAE 实例可以配置定时启停，仅在工作时间运行，甚至使用竞价实例。

服务间的调用（如订单服务调用用户服务）走内网通信。利用 SAE 的内网 SLB 功能为服务分配固定内网 IP，并通过环境变量将地址注入调用方。这种方式完全在 VPC 内部流转，速度快且无流量费。对于日志和监控，由于容器是动态销毁的，不能依赖本地文件，需开启阿里云 SLS（日志服务）收集标准输出，并利用 ARMS 监控应用性能和慢 SQL。

部署流程必须自动化。使用阿里云云效（Flow）搭建流水线，前端代码构建后自动上传 OSS 并刷新 CDN 缓存，后端代码构建后自动触发 SAE 的灰度发布。关于前端缓存策略，推荐在 CDN 控制台统一配置：index.html 设置为不缓存（no-cache），而带 Hash 的静态资源文件（js/css/img）设置长缓存。这样既能保证用户即时获取新版本，又能利用缓存提升性能。