我有一个安装在页面上的脚本，它将从S3存储桶中加载更多的JS和CSS。
我有版本，所以当我在Github上发布1.1.9版本时，它会在S3上部署到/my-bucket/1.1.9/。
问题，如果我想要一个符号链接/my-bucket/v1 - ＆gt; /my-bucket/1.1.9，我如何通过AWS或CloudFlare实现这一目标？
我的想法是，我希望通过将它部署到我的存储桶或任何CDN来发布新版本，而且当我准备好时，我想将v1切换到最新发布的1.x.y版本。我希望所有网站都指向/v1，并在有新版本时获取最新信息。
是否有CDN或AWS服务或配置允许我创建类似Linux的符号链接？
答案 0 :(得分：1)
使用CloudFront的简单解决方案需要稍微改变路径设计：
铲斗：
/1.1.9/v1/foo
浏览器：
/v1/foo
CloudFront Origin Path（在Origin选项卡上）
/1.1.9
无论您配置什么，原始路径都会添加到浏览器请求的开头，然后再将请求发送到Origin服务器。
请注意，更改此值意味着您还需要执行缓存失效，因为响应是根据请求的内容缓存的，而不是基于所获取的内容。
这里有一个潜在的竞争条件，在您更改配置和无效之间 - 配置更改和无效请求之间的操作顺序没有相关性 - 配置更改后跟失效可能在完成之后，¹因此可能需要使无效，更新配置，无效，验证分发已经进展稳定状态，然后再次失效。您无需单独使对象无效，只需/*或/v1*。如果只有直接请求的资源受重写影响最好，而不是它的依赖性。还要记住，浏览器缓存是一个很大的成本节省，如果你使用相同的请求URI来表示不同的对象，你就无法充分利用它。
CloudFront中更复杂的路径重写需要Lambda @ Edge Origin Request触发器（或者您可以使用Viewer Request，但这些更频繁地运行，因此成本更高，并增加了整体延迟）。
¹失效请求 - 虽然没有记录并且严格轶事 - 似乎涉及一些时间旅行。失效是带时间戳的，看起来它们使在时间戳之前缓存的任何内容无效，而不是在它们传播到边缘位置之前。在架构上，如果设计CloudFront使得失效不主动清除内容，但仅作为缓存的指令，将任何缓存的对象视为过时，如果它在失效请求之前的时间戳上预先设定，则允许实际清除在后台进行。对于任何其他解释，失效似乎完成得太快。这意味着在分发返回到稳定Deployed状态之后创建失效请求将确保旧的所有内容真正被清除，并且最初提交更改时的另一个失效请求将捕获可能从中提供的大多数落后者在传播更改之前缓存。根据观察到的完成时间，变化和失效似乎确实通过独立的管道传播到边缘。