我们都经历过这样的烦恼，网站加载缓慢，或者应用在需要调用 API 以更新数据的时候似乎卡住了。只要稍微慢一点，您的注意力就会转移到别处去……
提高速度的一个方法是使资源尽可能靠近用户——这就是 Cloudflare 通过在距离世界上大多数人口仅数毫秒的地方运行计算所要做的。但是，尽管看起来可能有悖常理，但有时让计算更接近用户实际上会减慢应用的速度。如果您的应用需要连接到离最终用户较远的 API、数据库或其他资源，那么应用在资源而不是用户附近运行性能可能更高。
因此，今天我们隆重宣布适用于 Workers 和 Pages Functions 的 Smart Placement，使每次交互都尽可能快。通过 Smart Placement， Cloudflare 把计算资源转移到最佳位置来将无服务器计算提升到 Supercloud，以加快应用的速度。最棒的地方是，它是完全自动的，无需任何额外输入（例如令人头疼的“地区”）。
Smart Placement 现已推出公测，向所有Workers 和 Pages 客户开放。
欢迎观看演示，了解 Smart Placement 如何工作。
无服务器计算的变化
Cloudflare 的 Anycast 网络用于在接近用户的地方迅速处理请求。我们的无服务器计算产品 Cloudflare Workers 对开发人员具有如此吸引力，这就是原因所在。竞争对手受到“地区”的限制，而 Workers 在任何地方运行——因此我们只有一个地区：地球。完全由 Workers 处理的请求可就地立即处理，无需访问源服务器。
虽然无服务器的概念最初被认为针对轻量级任务，但无服务器计算近年来发生了一个变化。它正被用来取代依赖源服务器和自我管理基础设施的传统架构，而不仅仅是对其进行增强。我们看到越来越多 Workers 和 Pages 用户采用这些用例。
无服务器需要状态
随着计算转向无服务器并在 Workers 上构建整个应用，对数据存储的需求也出现了。通过存储之前操作或事件的信息，您能够构建个性化、交互式的应用。假设您需要创建用户配置文件，记录用户停留的页面，用户的购物车中有哪些单品，所有这些都映射到用于维护状态的数据点。关系数据库、键值存储、Blob 存储和 API 等后端服务都支持您构建有状态应用。
Cloudflare 计算 + 存储：强大的组合
我们有自己不断发展壮大的存储产品套件： Workers KV， Durable Objects， D1， R2 。随着我们的数据产品成熟，我们深入思考它们与 Workers 的交互，以便您无需这样做。例如，在某些情况下，另一种提高性能的方法是将存储——而不是计算——移动到离用户更近的地方。如果您使用 Durable Objects 来创建实时游戏，我们可以移动 Durable Objects 以最大程度减少所有用户的延迟。
我们针对未来状态的目标是，只要您设置 mode = "smart"，我们就会评估您所有资源的最佳位置，无需额外配置。
Cloudflare 计算 + $ {backendService}
如今，Smart Placement 的主要用例是您在应用中使用非 Cloudflare 服务，例如外部数据库或第三方 API。
许多后端服务，无论是自托管服务还是托管服务，都是集中式的，这意味着数据是在单一位置存储和管理的。您的用户分布在全球各地， Workers 也在全球范围运行，但您的后端是集中式的。
如果您的代码向后端服务发出多个请求，这些请求可能会横跨全球多次，对性能造成严重影响。一些服务提供数据复制和缓存，这有助于提高性能，但也带来了数据一致性和成本增加等权衡，这些都需要根据您的用例来考虑。
Cloudflare 网络与 95% 的世界互联网用户距离约 50 毫秒。反过来说，我们也非常接近您的后端服务。
应用性能就是用户体验
让我们通过一个例子来了解将计算移近您的后端服务如何减少应用的延迟：
假设来自澳大利亚悉尼的用户正在访问一个在 Workers 上运行的应用。应用对位于德国法兰克福的数据库进行了 3 次往返，以服务用户的请求。
凭直觉，您可以猜到瓶颈在于 Worker 与数据库之间进行多次往返所需的时间。如果不是在用户附近调用 Worker，而是在最靠近数据库的数据中心调用呢？
我们来测试一下。
我们对一个未启用 Smart Placement 的 Worker 测量请求持续时间，并将其与启用 Smart Placement 的 Worker 进行比较。两项测试中，我们都是从悉尼向一个 Worker 发送 3500 个请求，后者与位于 eu-central-1（法兰克福）的Upstash实例（免费层）进行 3 次往返。
结果一目了然！本例中，将 Worker 移近后端使应用性能提高了 4-8 倍 。
网络决策不应该由人来做
作为开发人员，您应该专注于您最擅长的事情——构建应用，而不需要费心考虑将使您的应用更快的网络决策。
Cloudflare 具有独特的优势：我们的网络收集关于用户、Cloudflare 数据中心和后端服务器之间最佳路径的情报——在这方面我们通过 Argo 智能路由具有丰富经验。Smart Placement 会考虑这些因素，自动将您的 Worker 放置在最佳位置，以缩短总体请求持续时间。
那么，Smart Placement 是如何工作的呢？
可以在“设置”选项卡下或在您的 wrangler.toml 文件中为每个 Worker 启用 Smart Placement ：
[placement]
mode = "smart"在 Worker 或 Pages Function 上启用 Smart Placement 后，Smart Placement 算法会实时分析 Worker 发出的 fetch 请求（也称为子请求）。然后，将其与我们网络汇总的延迟数据进行比较。如果我们检测到，如果我们检测到，您的 Worker 平均向后端资源发出不止一个子请求，那么您的 Worker 将自动从最优的数据中心调用！
有一些后端服务出于充分原因没有被 Smart Placement 算法考虑：
全球分布式服务：如果您的 Worker 与之通信的服务分布在多个地区，那么 Smart Placement 并不适用。我们会自动将这些 Worker 排除在 Smart Placement 优化之外。
分析或日志服务： 对分析或日志服务的请求不需要位于应用的关键路径中。应当使用
waitUntil()，以便在监控代码时不会阻塞返回用户的响应。由于从用户的角度来看，waitUntil()不会影响请求持续时间，因此我们会自动将分析/日志记录服务排除在 Smart Placement 优化之外。
请参阅我们的文档，获取 Smart Placement 算法未考虑的服务列表。
一旦 Smart Placement 生效，您将会在 Worker 上看到一个新的“请求持续时间”选项卡。我们在未启用 Smart Placement 的情况下路由 1% 的请求，以便您可以看到其对请求持续时间的影响。
没错，就是这么简单！
欢迎观看我们的演示，以试用 Smart Placement（非常有意思的哦！）。要了解更多信息，请访问我们的开发人员文档。
Smart Placement 的下一步是什么？
我们才刚刚开始！关于改进 Smart Placement，我们有很多想法：
支持在应用使用多个后端时计算最佳位置
微调位置（例如，如果您的 Worker 根据路径使用多个后端。我们会计算每个路径的最佳放置位置，而不是每个 Worker 的最佳放置位置）
支持基于 TCP 的连接
我们期待听到您的声音！如果您有任何反馈或功能请求，请通过 Cloudflare Developer Discord 联系我们。