服务端渲染（SSR）会让服务器先把页面拼成完整 HTML 再返回，浏览器拿到就能直接看到内容，首屏更快，搜索引擎也更容易抓到正文。代价是要多维护一个 Node.js 渲染服务，部署和运维都比纯静态站麻烦。搜 ssr阿里云 的人，多半卡在这一步。阿里云上能跑的地方不少，选哪个，直接决定后面省不省心。这篇我把函数计算和 SAE 各走了一遍，把踩过的地方说清楚。
SSR 到底在做什么
普通单页应用的流程是：浏览器先下载一个空壳 HTML 和一堆 JS，再由 JS 去拉数据、画页面。SSR 把这一步挪到了服务端。请求进来后，服务端执行 React 或 Vue 的渲染函数，取到数据，输出完整 HTML。
服务端要为此付出计算。流量一上来，渲染服务的 CPU 和内存会先顶满。所以部署方案能不能弹性伸缩，基本决定了你半夜会不会被告警叫醒。
方案一：函数计算 FC
函数计算适合流量忽高忽低、平时访问不多的站点。它按调用次数和执行时长计费，没有请求时实例会缩到零，闲时几乎不花钱。
具体步骤大致是这样：
- 先把 Next.js 或 Nuxt 项目打成生产包，在本地跑通 npm run build。构建都过不了，上线只会更乱。
- 在函数计算控制台创建 Web 函数，运行时选 Node.js，启动命令指向框架自带的 start 脚本。
- 配置 HTTP 触发器并开启公网访问，再绑定自定义域名。
- JS、CSS、图片这些静态资源放到 OSS，前面挂 CDN。渲染服务只接页面请求，别让它替你送静态文件。
我们用这套方式跑过一个资讯站。日常 PV 不高，但午间和晚间各有一波明显高峰。上线后平时的月成本降了不少，高峰时也没有出现扩容跟不上的情况。
冷启动要提前想好。长时间没人访问后，第一次请求会多等几百毫秒到一两秒。如果首屏速度很敏感，可以开预留实例，或者用定时任务每隔几分钟请求一下首页，让实例保持温热。后者省钱，前者更稳，取舍看你的预算。
方案二：SAE 或 ACK 容器部署
渲染服务如果需要长连接，要在内存里常驻缓存，或者团队已经有容器化规范，那就更适合 Serverless 应用引擎 SAE，或者容器服务 Kubernetes 版 ACK。
SAE 不用管集群。镜像或代码包直接上传，配好实例规格和弹性策略就能跑，上手快。ACK 灵活得多，同一个集群里放好几个服务都没问题，但要有人熟悉 Kubernetes，日常维护也重。团队里没有这样的人，硬上 ACK 往往会拖慢整个项目。
用 SAE 或 ACK 时，有几件小事值得提前做：
- 镜像只保留运行时和构建产物。镜像越小，实例拉起越快，扩容时的等待越短。
- 健康检查接口单独写一个轻量路由，别直接探测首页。首页要真的渲染，探测请求本身就会加重负载，还可能因为渲染慢被误判成故障。
- 弹性策略同时看 CPU 和请求数。只看 CPU 的话，请求堆积时 CPU 可能还没涨，扩容就滞后了。
一个迁移案例
某内容团队原先把 SSR 服务部署在一台 ECS 上，用 PM2 守护进程。典型的问题出现了：一次大促推广后，单机 CPU 打满，页面开始超时。他们只能手动加机器，而新机器的环境配置经常对不上，又多出一批排查工作。
迁移分三步走。第一，渲染服务容器化，镜像统一构建，环境不再漂移。第二，部署到 SAE，最小实例数设为 2 保证可用，最大实例数根据压测结果定。第三，页面缓存交给 CDN，对不含个性化内容的页面设置较短的边缘缓存时间，减少回源渲染的次数。
迁移后，他们用压测工具模拟了三倍日常流量，服务没有出现超时。具体的响应时间、实例数变化和成本对比，请补充真实数据：【待补充：迁移前后 P95 响应时间、高峰实例数、月成本对比】。
几个容易踩的坑
- 个性化页面被缓存。用户登录后的页面如果进了 CDN 缓存，别人可能看到你的信息。缓存规则要按路径和 Cookie 区分，登录态相关的页面直接不缓存。
- Node 版本不一致。本地用 Node 20，线上却是 16，构建产物可能直接报错。把版本号锁死，写进部署配置里。
- 日志散落各处。渲染服务的错误日志接入日志服务 SLS，再用 ARMS 做链路追踪。否则线上出问题，你得在好几个地方翻才能找到原因。
- 超时设得随意。网关超时要比渲染最长耗时略长，但不能太长。设短了，正常的慢请求会被掐断；设长了，故障时连接会一直堆着，把服务拖垮。
怎么选
流量波动大、人手又少，先从函数计算开始。业务稳定、需要常驻进程，或者公司已经有容器体系，就选 SAE 或 ACK。
不管选哪个，先把渲染服务的压测数据跑出来，再决定最小实例数和扩容阈值。没有数据，配置只能靠猜，猜错了就得半夜调参数。
