在阿里云上部署nodejs服务，很多人都有过这样的体验：本地跑得好好的接口，一上线就出问题。端口没开，进程莫名挂掉，没人知道该由谁拉起；流量一上来，机器扛不住；出了错，日志又找不到。这篇文章不谈概念，只从几个常见场景出发，说说ECS和函数计算各自适合什么，怎么配，哪些地方容易踩坑。
先看服务的形态，再决定部署方式
选之前，可以先问自己三件事：流量稳不稳定，团队有没有精力维护服务器，服务是不是需要一直常驻。三个问题的答案大体就能定下方向。
- 流量比较稳定，又希望完全掌控运行环境：用云服务器ECS，装好nodejs，再用PM2或systemd守护进程。
- 流量忽高忽低，请求多由事件触发：可以考虑函数计算FC，按调用次数和执行时长计费，没有请求时基本不产生费用。
- 服务数量多，需要统一调度：可以把nodejs应用打成镜像，交给容器服务ACK，由Kubernetes管理扩缩容。
场景一：内部管理后台，最怕挂了没人知道
有个十来人的电商团队，用Express写了一个内部后台，给客服和运营日常使用。访问量不大，但白天晚上都得能打开。他们最初把代码直接放到一台ECS上，用node命令启动。有一次服务器重启，服务就没了，第二天上班才发现后台打不开。
之后的调整并不复杂。在ECS上安装nodejs LTS版本，用PM2启动应用，执行pm2 startup和pm2 save，让服务随系统开机自启。前面加一层Nginx做反向代理，把80端口转到应用的3000端口，再配置HTTPS证书。日志交给PM2按天切割，同时通过阿里云日志服务SLS采集，出问题时直接在控制台搜索，不用登录服务器翻文件。
方案本身谈不上高级，但对小团队够用。它真正解决的是“进程挂了没人知道”这件事。
场景二：活动当天，接口调用量一下子涨上来
做营销活动的团队碰到的是另一种情况。nodejs接口平时每天只有几百次调用，活动开始后瞬间涨到几万次。如果按ECS的思路，就得提前扩容机器，还要预估峰值。估多了是浪费，估少了活动页面直接卡住。
他们后来把核心接口迁到了函数计算FC。代码需要按照FC的入口函数格式改写，通过API网关触发，平台根据请求量自动伸缩。活动结束后，资源随之回收，费用只算实际调用的部分。迁移时有两点要特别留意。第一，函数是无状态的，会话或临时数据不能放在本地文件或内存里，应该落到Redis或数据库中。第二，冷启动会让首次请求变慢。如果接口对延迟敏感，可以配置预留实例，代价是多付一部分固定费用。
上线前后，这几个问题最常出现
不管选哪种方式，下面几类问题都值得提前检查：
- 安全组没放行端口：服务在服务器本机能访问，外网却打不开。先去ECS安全组看看规则里有没有放行对应端口，这通常是第一个该排查的地方。
- 密钥写死在代码里：数据库密码、AK/SK直接写进源码，代码仓库一旦泄露，损失会很大。改用环境变量，敏感信息更适合交给KMS等密钥服务管理。
- 内存慢慢涨，没人察觉：长时间运行的nodejs进程，如果有没释放的闭包或全局缓存，内存会一点点往上走。建议接入云监控设置内存告警，同时用PM2的max_memory_restart做兜底，超过阈值自动重启。
- 本地和服务器版本不一致：两边的nodejs版本不同，带原生模块的依赖很容易编译失败。在package.json里固定engines字段，并提交package-lock.json，让依赖在两边保持一致。
数据和文件不要放在服务器上
nodejs服务本身最好保持无状态，需要保存的东西交给专门的服务。关系型数据放云数据库RDS，缓存放Redis，用户上传的图片和文件放对象存储OSS。这样服务随时可以重启、扩容或迁移，哪台机器出问题，数据也不会跟着丢。
OSS还支持生成带时效的临时访问链接，前端上传文件时可以直接传到OSS，不必经过自己的服务器中转。带宽压力小了，服务端的代码也少写一层。
最后说一句
在阿里云上跑nodejs，没有唯一标准答案。小项目可以先用ECS把流程跑通，流量上来以后再考虑容器化；如果波峰波谷非常明显，再认真评估函数计算。与其一开始就追求完美的架构，不如先让服务稳定上线，再根据监控数据一步步调整。
