当你的第一个项目让你把你的爱好带到办公室时，你知道你的工作很酷。就在几周前，当我加入Cloudflare时，我就是这样。我们的任务是：创建数据中心地图的一个浅色版本——我们讨论的是与每个Cloudflare数据中心的部署状态相关的100多个LED。这张地图将是我们展位的一部分，因此它必须能够旅行；这意味着我们必须考虑实际运输以及地图不在办公室时更新数据的能力。有趣的是，我们将在2月下旬的SF开发者周上发布它（我甚至可以做一个关于它的演讲！）这给了我一个星期的软件时间在旧金山的办公室里，而在奥斯汀的办公室里花了两个半多一点材料。什么最后的发光二极管看起来像是世界。所以这跟无服务器有什么关系？好吧，让我们想想这张地图需要在哪里和如何操作：这张地图将要去世博会和会议，我们希望它能够更新，以显示我们最新的数据中心状态，至少在那次活动中，如果不是每天更新一次。但是，我们不需要在会议或世博会期间一直与信息存储保持联系，我们也不应该期望如此WiFi.数据存储在数据中心关于每个数据中心存储的数据有两个不同的类别：与数据中心本身相关的数据，以及关于如何在地图上显示该数据中心的数据。然而，这些都是相对简单的数据结构：对于数据中心，我们需要存储数据中心所在的城市、纬度和经度以及状态。我们任意地为每个数据中心分配一个ID整数，我们将使用它来匹配这个数据与另一个存储中的数据。我们不打算挑选我们想要的数据中心，只要把它们全部拉下来，让微控制器来决定如何显示他们。说话这是与显示相关的数据存储的位置。LED位于编号为0-7的线股上，并由编号为0-63的LED表示。我们需要在strand。两者都有这些数据集可以存储在一个键值存储区，ID号作为键，JSON对象表示数据中心或其在地图上的代表性LED作为值。正因为如此，再加上我们不需要搜索或索引这些数据，我们决定使用Workers KV数据存储来保存这些数据信息。那个数据中心和数据中心地图APIWe需要两个API围绕着数据中心，而且我们需要它们很快—这两个API都是在只有几周时间完成项目的情况下，从某种意义上说，我们需要在非理想的互联网环境下相对快速地下载数据。我们也知道这张地图将在世界各地传播——我们需要API来工作，并且不管地图的地理位置如何，至少要有一个相当好的延迟。这就是数百个LED的用武之地——每一个都代表一个数据中心，我们可以在其中部署无服务器工作人员。我们可以在离开舒适的办公室之前将API部署到数据中心，当我们到达会议室时，它就已经为我们准备好了。毫不奇怪，Workers与Workers KV数据存储的配合非常好；这使我们能够快速开发API数据。我们的软件架构图在最后，我们得到了这个架构图；2个Workers KV数据存储，2个serverless Worker；所有这些都可以部署到世界各地，以确保每次我们去一个新的显示。在本系列的下一篇文章，我们将研究标牌：我们我们还将看看我们构建的系统，它使用了本文中列出的体系结构，该体系结构使用这些数据并将其转换为LED地图，因此下个月请密切关注它！有兴趣在不在Cloudflare上设置域的情况下部署Cloudflare Worker吗？我们正在使使用自定义子域来构建无服务器应用程序变得更加容易工人.dev。如果您已经是Cloudflare客户，可以在此处向现有网站添加员工。保留a工人.dev子域