企业官网建设流程全解析

建立一个购物网站需要多少钱,网站升级停止访问如何做,下载百度到桌面上,网站聚合页面模板Cloudflare Workers 性能#xff1a;与 Astro 和全球延迟的实验 为何使用 Cloudflare Workers#xff1f; Cloudflare Workers 允许托管页面和运行代码#xff0c;而无需管理服务器。与传统服务器放置在单个或少数几个位置不同#xff0c;部署的静态资产和代码在全球数据…Cloudflare Workers 性能与 Astro 和全球延迟的实验为何使用 Cloudflare WorkersCloudflare Workers 允许托管页面和运行代码而无需管理服务器。与传统服务器放置在单个或少数几个位置不同部署的静态资产和代码在全球数据中心如下方蓝点所示镜像。这自然提供了更好的延迟、可扩展性和鲁棒性。其开发者平台还超越了“Workers”计算部分包括存储、数据库、队列、AI 和许多其他开发者工具。所有这些都提供一个慷慨的免费层和超出部分的合理定价。撰写本文的原因发现它相当不错有良好的使用体验因此在此介绍。本文并非赞助。开发者有责任交流他们使用的工具以保持其生态系统活跃。曾见过太多好东西因为缺乏“热度”而被抛弃。使用 Cloudflare Workers 的好处是全球范围内出色的延迟无限的可扩展性无需维护服务器数据、文件、AI 等的进一步工具GitHub 拉取请求预览 URL免费层对大多数业余项目足够好何时不使用它与所有工具一样它有它擅长的用例也有不适合的用例。理解底层技术非常重要。基本上它会将整个应用打包为脚本并在运行时动态评估。如果您的 API 和使用的框架是轻量级和极简主义的它会很快并且效果很好。然而在以下用例中不建议使用大型复杂应用评估您的 API/SSR 脚本的成本会随着应用的增大而增加。它变得越大整个调用就越低效。还有一些限制是关于“脚本”可以有多大。尽管过去已经多次提高此限制但它效率极低的事实将始终存在。因此在选择依赖项/框架时要小心因为它们可能迅速使您的代码库膨胀。资源消耗大由于其性质它不适合需要大量 CPU/内存/时间的计算如统计模型或科学计算。大型缓存也有问题。等待长时间运行的异步服务器端请求是可以的执行在中间暂停不计入执行时间。长连接这也是有问题的。应该使用轮询而不是保持连接开放。换句话说“越轻量越好”很难说什么足够小什么时候变得太大。这更适合于适度大小的小型自包含微服务。即使使用断点调试也可能变得具有挑战性。对于此类大型应用程序传统的服务器部署会更合适。我们将构建什么一个“每日名言”Web 应用程序。目的不是构建一个大型的东西而是一个简单的概念验证。名言将存储在 KV 存储中并在客户端获取。这样我们可以测量整个工作的速度以及它是否符合期望。https://quoted.day 的默认版本有两种风格https://quoted.day/spa一个静态页面异步获取名言文本/作者https://quoted.day/ssr服务器端渲染在服务器上渲染带有名言的页面为了进行实验会不时交换哪个是默认版本。性能延迟可能因您所在的位置以及您获取的内容是“热”还是“冷”而异。在深入研究如何构建此类应用之前让我们先看看可以预期的性能。全球延迟基准测试与在某中心内部测量的、因此相当乐观的内部 Cloudflare 延迟测量不同我们将使用出色的工具 https://www.openstatus.dev/play/checker 来查看“真实的”外部延迟。借助此工具我们可以很好地了解全球各地可观察到的总体延迟。但请注意澳大利亚、亚洲和非洲的延迟可能有时相当不稳定会出现“跳跃”。我们还将分别对多个事物进行基准测试静态资产无状态函数热 KV 读取冷 KV 读取KV 写入此外每种情况都会进行“两次传递”以希望在此过程中填充缓存并仅记录第二次结果。静态资产通过获取主页面 https://quoted.day/spa 获得。区域延迟 德国法兰克福30ms 德国法兰克福 (koyeb)31ms 法国巴黎33ms 荷兰阿姆斯特丹 (railway)33ms 英国伦敦31ms 瑞典斯德哥尔摩32ms 法国巴黎 (koyeb)31ms 荷兰阿姆斯特丹54ms 美国新泽西州西考克斯32ms 美国弗吉尼亚州阿什本36ms 美国华盛顿 (koyeb)35ms 加拿大多伦多50ms 美国伊利诺伊州芝加哥36ms 美国加利福尼亚州洛杉矶28ms 美国加利福尼亚州圣何塞26ms 美国弗吉尼亚州 (railway)41ms 美国加利福尼亚州 (railway)49ms 美国旧金山 (koyeb)29ms 新加坡 (railway)53ms 印度孟买95ms 美国德克萨斯州达拉斯30ms 日本东京28ms 澳大利亚悉尼31ms 新加坡294ms 新加坡 (koyeb)436ms 巴西圣保罗252ms 南非约翰内斯堡559ms 日本东京 (koyeb)28ms无状态函数通过获取端点 https://quoted.day/api/time 获得该端点仅返回当前时间。区域延迟 英国伦敦38ms 德国法兰克福 (koyeb)32ms 荷兰阿姆斯特丹 (railway)36ms 法国巴黎75ms 荷兰阿姆斯特丹76ms 德国法兰克福88ms 法国巴黎 (koyeb)73ms 瑞典斯德哥尔摩97ms 美国弗吉尼亚州 (railway)36ms 美国华盛顿 (koyeb)62ms 美国新泽西州西考克斯95ms 美国加利福尼亚州洛杉矶39ms 美国加利福尼亚州圣何塞25ms 美国弗吉尼亚州阿什本92ms 美国德克萨斯州达拉斯90ms 加拿大多伦多22ms 美国伊利诺伊州芝加哥108ms 印度孟买99ms 新加坡 (railway)45ms 日本东京27ms 美国加利福尼亚州 (railway)99ms 巴西圣保罗89ms 澳大利亚悉尼26ms 新加坡220ms 美国旧金山 (koyeb)26ms 南非约翰内斯堡540ms 新加坡 (koyeb)354ms 日本东京 (koyeb)71ms热 KV 读取通过使用端点 https://quoted.day/api/quote/123 从 KV 存储中获取固定名言获得。区域延迟 英国伦敦34ms 法国巴黎39ms 荷兰阿姆斯特丹 (railway)35ms 法国巴黎 (koyeb)37ms 瑞典斯德哥尔摩34ms 荷兰阿姆斯特丹77ms 德国法兰克福 (koyeb)103ms 加拿大多伦多25ms 美国德克萨斯州达拉斯33ms 美国华盛顿 (koyeb)55ms 德国法兰克福168ms 美国弗吉尼亚州阿什本106ms 美国加利福尼亚州 (railway)52ms 美国新泽西州西考克斯122ms 美国旧金山 (koyeb)33ms 美国弗吉尼亚州 (railway)123ms 南非约翰内斯堡43ms 印度孟买99ms 新加坡 (railway)88ms 美国伊利诺伊州芝加哥69ms 巴西圣保罗99ms 美国加利福尼亚州圣何塞40ms 澳大利亚悉尼64ms 美国加利福尼亚州洛杉矶91ms 新加坡345ms 日本东京126ms 日本东京 (koyeb)65ms 新加坡 (koyeb)856ms冷 KV 读取通过使用端点 https://quoted.day/api/quote 从 KV 存储中获取随机名言获得。请注意每次调用将在边缘位置缓存结果一天随着流量的增加可能会将冷读取变为热读取。区域延迟 德国法兰克福131ms 德国法兰克福 (koyeb)105ms 英国伦敦110ms 荷兰阿姆斯特丹130ms 法国巴黎145ms 瑞典斯德哥尔摩134ms 法国巴黎 (koyeb)127ms 荷兰阿姆斯特丹 (railway)133ms 美国新泽西州西考克斯197ms 美国伊利诺伊州芝加哥201ms 美国弗吉尼亚州阿什本220ms 加拿大多伦多243ms 美国华盛顿 (koyeb)229ms 美国德克萨斯州达拉斯287ms 美国弗吉尼亚州 (railway)270ms 新加坡288ms 美国加利福尼亚州圣何塞245ms 印度孟买502ms 南非约翰内斯堡322ms 新加坡 (railway)323ms 美国加利福尼亚州洛杉矶247ms 美国旧金山 (koyeb)217ms 美国加利福尼亚州 (railway)300ms 巴西圣保罗601ms 日本东京822ms 新加坡 (koyeb)574ms 日本东京 (koyeb)335ms 澳大利亚悉尼964msKV 写入通过调用 quoted.day/api/bump-counter 获得它创建一个具有 10 分钟过期时间的临时 KV 对。这有点模拟了启动“会话”的概念。区域延迟 法国巴黎128ms 德国法兰克福 (koyeb)151ms 德国法兰克福147ms 法国巴黎 (koyeb)194ms 荷兰阿姆斯特丹145ms 瑞典斯德哥尔摩240ms 英国伦敦176ms 美国德克萨斯州达拉斯212ms 美国加利福尼亚州 (railway)238ms 美国华盛顿 (koyeb)305ms 美国弗吉尼亚州 (railway)295ms 美国新泽西州西考克斯408ms 美国弗吉尼亚州阿什本423ms 加拿大多伦多337ms 美国伊利诺伊州芝加哥359ms 新加坡 (koyeb)409ms 美国加利福尼亚州洛杉矶335ms 印度孟买347ms 美国加利福尼亚州圣何塞438ms 美国旧金山 (koyeb)247ms 新加坡508ms 日本东京684ms 澳大利亚悉尼713ms 日本东京 (koyeb)734ms 荷兰阿姆斯特丹 (railway)1,259ms 新加坡 (railway)1,139ms 南非约翰内斯堡2,266ms具有 KV 冷读取的 SSR 页面最后在这个测试中结合读取随机名言通常会导致冷 KV 读取并在页面中服务器端渲染它。区域延迟 法国巴黎 (koyeb)111ms 英国伦敦108ms 荷兰阿姆斯特丹 (railway)125ms 法国巴黎133ms 德国法兰克福 (koyeb)139ms 德国法兰克福146ms 瑞典斯德哥尔摩142ms 荷兰阿姆斯特丹70ms 美国弗吉尼亚州 (railway)151ms 美国华盛顿 (koyeb)159ms 美国新泽西州西考克斯201ms 美国弗吉尼亚州阿什本209ms 美国伊利诺伊州芝加哥217ms 美国德克萨斯州达拉斯220ms 美国加利福尼亚州圣何塞191ms 美国加利福尼亚州 (railway)201ms 加拿大多伦多255ms 美国加利福尼亚州洛杉矶257ms 美国旧金山 (koyeb)268ms 印度孟买422ms 日本东京332ms 新加坡284ms 巴西圣保罗327ms 新加坡 (railway)632ms 新加坡 (koyeb)677ms 南非约翰内斯堡673ms 澳大利亚悉尼385ms 日本东京 (koyeb)350ms观察结果通过观察数字来推断 KV 的工作方式很有趣。似乎 KV 存储不是主动复制的而是 KV 对在远程位置“按需”复制。当被缓存时默认 1 分钟后续读取很快。此类“热”KV 对的延迟总体上相当不错。这里没有问题。该对在缓存中保留多长时间也可以在 KV get 请求期间使用cacheTtl参数进行配置。然而增加该值的缺点是在此期间此缓存副本不反映其他位置触发的变化/更新。不出所料冷读取的延迟更差。从数字中可以推断出的另一件事是似乎存在一个“源位置”冷读取的延迟根据到该位置的距离成比例地增加。因此请注意“在哪里”创建 KV 存储因为它会影响全球所有未来的延迟。请注意Workers KV 将来可能会改变这仅仅是其当前状态的观察。虽然读操作还可以但写操作目前相当令人失望。原本期望它也有很好的延迟写入“边缘”并让传播异步进行但情况恰恰相反。写入似乎与“源”存储通信。设置一个值所需的时间取决于您距离创建 KV 存储的位置有多远。这有点糟糕因为设置/更新值是一个非常常见的操作例如对用户进行身份验证。亲爱的某中心团队希望将来改进这一部分。注意事项如果您开发 Web 应用、发布它并查看它您可能甚至不会注意到糟糕的延迟。您将面临最佳的延迟源 KV 存储就在您附近。然而在地球另一端的人将会有更差的体验。如果那个人有一些缓存未命中或写入响应时间可能会迅速攀升到几秒钟然后响应才到达。这不是期望的“分布式”KV 存储的行为方式。让我们明确一点目前它的行为更像是具有边缘按需缓存副本的集中式 KV 存储。相当讽刺的是目前它基本上感觉更像传统的单位置数据库缓存。虽然单个缓存未命中或单个写入的延迟并不严重但随着多次调用它可能会迅速累积尤其是写入量大的 Web 应用可能会根据其位置面临增加的“迟缓”现象。同样在使用 Workers 构思 Web 应用时应牢记在 KV 调用方面保持“极简主义”。最后Worker 中还有一个可用的设置“默认放置”与“智能放置”。两者都尝试过但在延迟方面没有看到明显变化。我认为这是由于只有单个 KV 存储调用并且需要时间和流量来收集遥测数据并调整 Workers 的放置。这可能很棒但对于这个实验它根本没有效果。单页应用程序与服务器端渲染同样没有一个普遍比另一个更好或更差答案取决于具体情况。除了框架和整体架构的强烈差异外对于最终用户来说它也有实际的根本差异。看到历史重演也很有趣互联网最初从服务器渲染页面开始然后单页应用程序数据获取占据了主导地位而 SSR 再次兴起就像过去一样只是有了新的技术栈。SSR 实际上是最容易解释的在服务器端获取所有所需数据将所有内容放入模板并将结果页面返回给最终用户。它在服务器端花费一些时间和处理能力不可缓存但客户端获得一个“已完成”的页面。SPA 则相反。虽然 HTML/CSS/JS 是静态的并且被缓存因此获取很快但由于需要所有客户端 JavaScript 库资源通常要大得多。然后开始繁重的工作获取数据并渲染页面通常显示一个加载指示器。因此渲染页面的总时间更长。然而之后与 SPA 的交互通常更流畅因为交互只是与服务器交换数据并对页面进行本地更改。相比之下SSR 意味着导航和加载新页面。因此选择 SPA 还是 SSR 更适合取决于页面/应用应该有多“交互”。作为经验法则如果它更像静态“网页”选择 SSR如果它更像交互式“Web 应用”选择 SPA。最后选择 Astro 作为示例的好处在于整个频谱都是可能的静态页面、SPA 和 SSR。来源此实验的源代码位于https://github.com/dagnelies/quoted-day如果您有 Github 和 Cloudflare 帐户也可以通过单击此处进行 fork 和部署https://deploy.workers.cloudflare.com/?urlhttps://github.com/dagnelies/quoted-day它将 fork GitHub 存储库并将其部署在内部 URL 上以便您可以预览。之后您可以编辑代码它将自动部署等等。请注意示例引用了一个 KV 存储该存储是我的。因此您必须创建自己的名为 QUOTES 的 KV 存储并用您的 KV id 替换wrangler.json文件中的 QUOTES KV id。如果希望重现该示例还必须最初用名言填充它。幸运的是package.json中有脚本来做到这一点。此后的所有内容都值得单独写一个教程。这仅仅是一个实验的结果延迟如何维持以及对该平台的一些见解。享受吧FINISHED更多精彩内容 请关注我的个人公众号 公众号办公AI智能小助手或者 我的个人博客 https://blog.qife122.com/对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号网络安全技术点滴分享