Rails滚动部署中结合CDN使用哈希化资源的技术问题咨询

针对你们的架构，滚动部署过程中最容易碰到以下几个资源相关的问题，我逐个分析并给出解决思路：

1. 旧服务器下线后，缓存的旧资源触发404 #

问题原因 #

滚动部署时，旧服务器终止后，CloudFront可能还缓存着带有旧哈希的资源。当用户请求这些旧资源时，CloudFront回源到新服务器，但新服务器的public/assets目录只有新编译的、带新哈希的资源，找不到旧资源就会返回404。

解决方案 #

• 将资产存储与服务器解耦：把预编译后的资产上传到AWS S3，而非存在服务器本地。然后配置CloudFront的源指向S3，同时在Rails中设置config.public_file_server.enabled = false和config.assets.compile = false。这样所有历史版本的资产都持久化在S3，不管服务器怎么上下线，都能被正常访问。
• 部署前同步旧资产到新服务器：如果暂时不想用S3，可以在部署新服务器时，把旧服务器的public/assets目录同步过去，确保新服务器包含所有历史资产（但这种方式长期维护起来比较麻烦，不如S3方案省心）。

2. 新旧服务器共存期间，用户混合加载不同版本的资源导致样式/JS冲突 #

问题原因 #

滚动部署过程中，新旧服务器会同时在线一段时间，用户的请求可能被负载均衡路由到不同服务器，拿到旧版本或新版本的资源。比如用户先加载了旧版本的页面，后续请求JS时拿到了新版本的，就可能出现兼容性问题（比如样式错乱、JS报错）。

解决方案 #

• 给资产URL添加版本前缀：在Rails配置里设置config.assets.prefix = "/assets/v#{APP_VERSION}"，每次部署时更新APP_VERSION的值（比如用Git commit hash）。这样新旧版本的资产路径完全分离，CloudFront的缓存也不会混，用户只会加载同一版本的资源。
• 优化滚动部署流程：等所有新服务器完成资产预编译、通过健康检查后，再一次性把流量切换到新服务器，然后立刻终止旧服务器。尽量缩短新旧服务器共存的时间，降低混合加载的概率。
• 确保新服务器预编译完成再上线：在部署脚本中加入检查，确认新服务器的public/assets目录已经生成好所有新资产，再将其加入负载均衡的可用服务器列表。

3. CloudFront缓存未及时更新，用户看不到新内容 #

问题原因 #

虽然Asset Pipeline的哈希机制已经能保证新资源的URL是唯一的，但如果有部分非哈希的资源（比如favicon.ico、robots.txt），或者CloudFront的缓存策略设置了过长的TTL，可能会导致用户无法及时看到更新。

解决方案 #

• 依赖哈希特性自动更新缓存：对于带哈希的资产，因为URL是全新的，CloudFront会自动去源站拉取新资源，不需要手动刷新缓存。这也是Rails Asset Pipeline设计的核心优势之一，一定要确保config.assets.digest = true处于启用状态。
• 针对性失效非哈希资源：对于没有哈希的静态资源，可以在部署脚本中调用CloudFront的Invalidation API，自动失效这些资源的缓存。比如失效/favicon.ico、/robots.txt这类路径。
• 合理设置CloudFront TTL：给带哈希的资产设置较长的TTL（比如365天），因为它们的URL唯一，不会有缓存过期问题；给非哈希资源设置较短的TTL（比如1小时），减少缓存 stale 的概率。

4. 多台新服务器预编译资产时，生成的哈希不一致 #

问题原因 #

如果让每台新服务器各自预编译资产，可能因为环境变量、gem版本、Rails版本的细微差异，导致同一代码生成的资产哈希不同。这样用户请求同一资源时，可能从不同服务器拿到不同的版本，引发问题。

解决方案 #

• 统一预编译资产：在CI/CD流程中完成资产预编译，然后把编译好的public/assets目录打包同步到所有新服务器。这样所有服务器的资产哈希完全一致，避免不一致问题。
• 标准化服务器环境：确保所有新服务器的Ruby版本、Rails版本、gem依赖、环境变量完全一致。可以用Docker镜像来标准化环境，从根源上消除哈希不一致的可能。

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