代码之家 › 专栏 › 技术社区 › Assaf Moldavsky

CloudFlare或AWS CDN链接

cloudflare cdn routing amazon-s3 amazon-web-services

Assaf Moldavsky · 技术社区 · 7 年前

我在页面上安装了一个脚本,它将从S3 bucket加载更多的JS和CSS。

我有版本,所以当我在Github上发布1.1.9版本时,它将部署到 /my-bucket/1.1.9/ 在S3上。

问题,如果我想有一个象符号链接这样的东西 /my-bucket/v1 -&燃气轮机; /my-bucket/1.1.9 ,如何使用AWS或CloudFlare实现这一点?

我的想法是,我想通过将其部署到我的bucket或任何CDN上来发布一个新版本,然后在我准备好的时候,我想切换 v1 至最新1。x、 y版本已发布。我希望所有网站都指向 /v1 并在有新版本时获取最新信息。

是否有CDN或AWS服务或配置允许我创建类似linux的符号链接?

1 回复 | 直到 7 年前

Michael - sqlbot 7 年前

使用CloudFront的简单解决方案需要对路径设计稍作更改:

铲斗:

/1.1.9/v1/foo

浏览器:

/v1/foo

CloudFront原点路径(在“原点”选项卡上)

/1.1.9

将配置为原点路径的任何内容添加到开始在将请求发送到源服务器之前,浏览器请求的内容。

请注意,更改这一点意味着您还需要执行缓存失效,因为响应是基于请求的内容而不是提取的内容进行缓存的。

这里有一个潜在的竞争条件,在您更改配置和无效化之间——配置更改和无效化请求之间的操作顺序没有相关性——配置更改然后失效可能会在之后完成,¹因此可能需要失效、更新配置、失效、验证分发已进入稳定状态,然后再次失效。您不需要单独使对象无效,只需 /* 或 /v1* . 最好只重写直接请求的资源,而不重写其依赖项。此外,请记住,浏览器缓存是一个巨大的成本节约,如果您使用相同的请求URI来表示不同的对象,则无法充分利用它。

在CloudFront中更复杂的路径重写需要Lambda@Edge原始请求触发器(或者您可以使用查看器请求,但这些请求运行得更频繁,因此成本更高,并增加了总体延迟)。

无效化请求——虽然这没有文档记录,而且严格来说是轶事——似乎涉及一些时间旅行。失效是有时间戳的,它们似乎会使时间戳之前缓存的任何内容失效,而不是在传播到边缘位置之前。从架构上讲,如果CloudFront的设计使失效不会主动清除内容,而只是作为缓存的指令,如果缓存对象早于失效请求上的时间戳,允许在后台进行实际清除,则可以将其视为过时对象。对于任何其他解释来说,失效似乎完成得太快了。这意味着在发行版返回稳定版本后创建一个失效请求 Deployed 状态将确保所有旧的内容都被真正清除,并且在最初提交更改时,另一个无效化请求将捕获在传播更改之前可能从缓存中提供的大多数散乱者。根据观察到的完成时间,更改和失效似乎通过独立管道传播到边缘。