到目前为止，使用Wrangler CLI，您现在可以直接将整个网站部署到Cloudflare Workers和Workers KV。如果你可以静态地为你的站点生成资产，比如createreact app，Jekyll，甚至WP2Static插件，你就可以把它部署到我们的整个全球网络中，这个网络覆盖了90多个城市的194个城市国家。而以前你可以直接将整个站点部署到工人那里，这不是最简单的过程。因此，Workers开发人员体验团队提出了一个解决方案，使部署静态资产成为一种明显更好的体验。使用Workers命令行工具Wrangler，我们可以通过三个简单的步骤将任何静态站点部署到worker：运行Wrangler init--site，配置新创建的牧马人.toml将您的帐户和项目详细信息归档，然后使用wrangler publish将其发布到Cloudflare的edge。如果您想了解这是如何工作的，请查看我们的createreact app的新Workers站点教程，其中我们介绍了这个新功能如何允许您在不需要编写任何额外代码的情况下进行部署！虽然事后看来，我们走到这一步的道路似乎不是最直接的，但它确实突出了整个Workers平台的灵活性，可以轻松地支持我们最初设想不到的用例。考虑到这一点，我将引导您完成整个实现过程，并认为我们已经做到了这一点。我还将谈一谈Workers平台的灵活性如何让我们兴奋，无论是它所代表的风气，还是它的未来使能。所以"建筑工人的工地都是什么？"文件系统？！我们要去的地方，不需要文件系统！"Workers平台构建在v8隔离之上，虽然很不错，但是缺少文件系统。如果您曾经通过FTP部署过静态站点，将其上载到对象存储，或者使用过计算机，那么您可能会同意文件系统很重要。对于许多用例，比如构建API或路由，您不需要文件系统，但是随着对工人的愿景的增长和我们的受众的增长，我们清楚地认识到这是我们需要解决的一个新的限制特色。欢迎对于没有文件系统的模拟，我们决定在Workers KV上模拟一个！Workers KV提供了对一个安全的密钥值存储的访问，该存储在Cloudflare的边缘工人们。什么时候运行wrangler preview或wrangler publish，我们会检查牧马人.toml对于站点密钥。站点关键点指向一个bucket，它代表我们将用来表示静态资产的KV名称空间。然后我们上传每个资产，其中相对于入口目录的路径是键，文件的blob是值。什么时候来自用户的请求进入，工作进程读取请求的URI并查找与请求的段匹配的资产。例如，如果用户获取"我的-site.com/关于.html"，工作人员查找关于.html输入KV并返回blob。在幕后，我们还将检测所请求资产的mime类型，并返回带有正确内容类型头的响应。对于那些习惯于构建静态站点或使用静态资产服务组件的站点的人来说，这可能会让人觉得过于工程化。其他人可能会争辩说，事实上，这就是文件系统的构建方式！对我们来说有趣的是，我们必须建造一个，而不是只有一个在等待我们。它很高兴我们能把它和Workers KV放在一起，但是我们仍然有一个问题……缓存规则meWorkers KV周围的一切都是一个数据库，所以它是为读和写操作而设置的。然而，它主要针对那些通常生命周期不长的条目进行了大量的读取工作。这对于频繁访问和经常更新数据的应用程序非常有效。但是，对于静态网站，资产通常只写一次，然后再也不会（或很少）再写。静态站点内容应该缓存很长时间，如果不是永远缓存（长寿命空间堵塞）。这意味着我们需要缓存比使用KV更长的数据到。到解决这个问题，在发布或预览时，Wrangler会遍历您在牧马人.toml并创建一个资产清单：文件名到其内容哈希的映射。我们使用这个资产清单来映射特定文件名的请求，例如索引.html，到最近上载的静态的内容哈希资产。你通过使用createreact app等工具可能熟悉资产清单的概念。资产清单有助于维护资产指纹，以便在浏览器中进行缓存。我们采用了这个想法并在Workers站点上实现了它，这样我们就可以利用边缘缓存了！现在，我们可以在每个位置进行第一次读取之后，将静态资产缓存在Cloudflare缓存中，这样资产就可以无限期地存储在边缘上。这将对KV的读取减少到几乎为零；我们希望使用KV来实现持久性，但我们希望使用更长的缓存策略来提高性能。让我们深入了解一下这到底是什么样子比如：怎么了工作创建新资产时，Wrangler publish将把新资产推到KV，并将资产清单推到您的旁边工人。什么时候有人首先访问您的页面，离他们最近的Cloudflare位置将运行您的Worker。Worker脚本将通过在资产清单中查找资产来确定他们所请求的资产的内容哈希。它将使用文件名和内容哈希作为键从KV获取资产的内容。此时，它还会将资产的内容插入Cloudflare的边缘缓存中，同样由文件名和内容哈希键控。然后它将用资产。开在随后的请求中，Worker脚本将在资产清单中查找内容哈希，并检查缓存以查看资产是否存在。由于这是一个后续请求，它将在边缘的缓存中找到您的资产，并返回包含资产的响应，而不必从中获取资产内容千伏。所以当你更新你的索引.html或者你的任何静态资产？这个过程与上传新资产时发生的过程非常相似。您将在本地计算机上使用新资产运行wrangler publish。Wrangler会浏览你的资产目录，并上传到KV。同时，它将创建一个新的资产清单，其中包含文件名和表示资产新内容的内容哈希。当一个请求进入您的Worker时，您的Worker将查看资产清单并检索该资产的新内容哈希。工作线程现在将在缓存中查找新哈希！然后，它将从KV获取新资产，填充缓存，并将新文件返回到您的终端用户.边缘缓存在全球194个城市的每个位置进行，确保页面上最频繁访问的内容缓存在最接近请求内容的位置，从而减少延迟。所有这些都是在浏览器缓存之外发生的，这意味着您的资产几乎总是离最终用户非常近！由于处于边缘，工人处于一个独特的位置，不仅能够缓存JS、CSS和图像之类的静态资产，还可以缓存HTML资产！传统的静态站点解决方案利用站点的HTML作为静态站点生成器资产清单的入口点。使用这种缓存HTML的方法，不可能破坏缓存，因为除了HTML本身，没有其他入口点来管理资产的指纹。但是，在Worker中，入口点是您的*Worker*！然后，我们可以利用wrangler资产清单来查找和获取准确和可缓存的HTML，同时缓存内容哈希。制作"我们所拥有的是一场想象的危机"。阿尔伯特·爱因斯坦说过，你不能用创造问题的思维定势来解决问题。"—彼得·巴菲特在构建一个全新的开发平台时，往往会有大量可能的应用程序。然而，可能性之多往往使每一种可能性都难以想象。这就是为什么我们认为任何平台最重要的部分是它能够灵活地适应以前无法想象的用例。而且，我们不仅仅是为了我们自己。每个人都有能力根据新的和有趣的用例定制平台，这一点很重要！从表面上看，我们为实现这个特性所做的工作看起来像是以前解决的问题的另一种解决方案。然而，这是一个很好的例子，说明了一群专注的开发人员可以如何改善其他人。我们希望通过将静态资产包括在工人中，开发人员可以利用额外的认知空间来构思更多的新方法来使用可能很难想象的工人以前。工人们站点不是最终目标，而是继续批判性地思考构建Web应用程序意味着什么的垫脚石。我们很高兴能给开发人员一个空间来探索简单的静态应用程序如何在与edge的动态功能相结合的情况下成长和发展计算。开始去建造一些很棒的东西！你和工人们一起做了些有趣的事吗？告诉我们@CloudflareDev！