AWS多实例运行自定义Next.js应用：共享缓存与无影响部署方案

可行性结论 #

完全可行。核心思路是将Next.js的缓存文件（如.next/cache）和增量生成的静态页面（如.next/static或out目录）从EC2实例本地存储迁移到AWS EFS（弹性文件系统）——这是一种支持多EC2实例同时挂载的NFS协议共享存储，完美适配Auto Scaling Group的动态实例场景。

基础实现步骤 #

• 创建EFS文件系统，配置挂载目标到ASG所在VPC的子网中，确保实例能通过内网访问EFS。
• 通过EC2 Launch Template的User Data，在实例启动时自动挂载EFS到指定路径（比如/mnt/nextjs-shared），并配置持久化挂载（写入/etc/fstab）。
• 修改Next.js配置：在next.config.js中指定缓存和静态文件的存储路径为EFS挂载目录下的对应子目录，或者将本地的.next/cache、.next/static软链接到EFS的对应路径。
• 为EC2实例的IAM角色添加EFS访问权限（比如AmazonElasticFileSystemClientFullAccess权限策略，或自定义最小权限策略）。

新版本部署时的共享文件冲突解决 #

由于采用CodeDeployDefault.OneAtATime部署策略，新旧版本实例会短暂共存，直接共享同一目录会导致版本冲突（比如旧版本读取新版本的静态文件，或部署过程中文件被覆盖）。需通过版本隔离+原子切换的方式处理：

1. 按版本划分共享目录 #

每次CodeBuild构建时，生成唯一的版本标识（如Git Commit Hash、CodeBuild构建ID），在EFS上为该版本创建独立目录（比如/mnt/nextjs-shared/v-<commit-hash>）。

• CodeBuild阶段：将构建完成的Next.js产物（包括静态文件、缓存模板）上传到EFS的对应版本目录。
• 借助SSM Parameter Store存储当前活跃的版本号，方便新扩容实例获取正确的目录路径。

2. 部署时的原子软链接切换 #

在CodeDeploy的生命周期钩子脚本中，执行以下操作：

• 先验证EFS上的目标版本目录存在且完整。
• 创建临时软链接指向新版本目录，再通过mv命令原子替换实例上的正式软链接（比如ln -s /mnt/nextjs-shared/v-xxx /tmp/new-link && mv -T /tmp/new-link /var/www/nextjs/current）——mv -T保证原子替换，避免中间状态的访问错误。
• 重启Next.js服务，让实例加载新版本的共享文件。

3. 缓存分层优化 #

将缓存分为两类处理：

• 公共缓存（如第三方依赖缓存、静态资源缓存）：放到EFS的公共共享目录，所有版本实例共享，避免重复生成。
• 版本专属缓存（如页面增量生成的动态缓存）：放到对应版本的隔离目录，避免新旧版本互相干扰。

4. 旧版本清理策略 #

待所有实例完成部署并验证正常后，通过自动化脚本（比如Lambda触发）清理EFS上的旧版本目录，节省存储资源。

额外注意事项 #

• EFS性能配置：根据并发访问量选择合适的性能模式（通用模式适合大多数场景，最大IO模式适合高并发读写）。
• 权限控制：通过EFS访问点为不同版本目录配置独立权限，避免实例误修改其他版本的文件。
• Auto Scaling扩容适配：在Launch Template的User Data中，从SSM Parameter Store拉取当前活跃版本号，自动挂载对应版本的EFS目录，确保新实例直接加入正常服务。

内容的提问来源于stack exchange，提问作者Costas