以边缘为核心的悖论

技术架构的优势很大。大科技事物有很多故事。从供应商的角度来看，大多数叙述都是自私的。这是有道理的，不同的公司对他们希望推出的产品有不同的观点和不同的议程。

由于我们在技术堆栈中所处的位置，我们就边缘主题进行了很多对话，这些讨论的核心发现之一非常简单。使用云操作模型构建您的边缘架构，但优化带宽。换句话说——边缘应该看起来像云架构的计算/存储/网络优化版本。起初听起来可能很激进，但在操作、技术和经济方面都是完全有道理的。

据估计，到 2025年，边缘物联网连接的全球数据量将从 2019 年的 13.6 ZB 增加到 79.4 ZB，因为高能效、高密度的边缘硬件被部署到手机信号塔、零售店、汽车或工厂等位置。

这种边缘数据爆炸有很多驱动因素：

• 低延迟数据处理：在靠近网络边缘处理数据可以减少数据从设备到云端再返回的往返时间。这会减少延迟并提高应用程序的响应速度。
  
  

• 物联网和边缘设备管理：随着万物互联，边缘云可用于管理和控制大量物联网设备，例如传感器、摄像头和其他设备，这些设备可能在地理上分布在世界各地。
  
  

• 内容分发：边缘云可用于分发大文件内容，例如视频、音频或软件更新。智能缓存通过提高向物理上更靠近边缘云位置的用户的传输速度和效率来改善用户体验。
  
  

• 离线数据处理：即使与中央云的连接丢失，边缘云也可用于处理数据，这对于需要在远程或离线环境中运行的自动驾驶汽车、无人机和机器人等应用非常有用。因此，边缘服务必须设计为在连接时和未连接时都运行。
  

在这篇文章中，我们将重点关注存储组件。这些是我们与电信、国防、制造、媒体、游戏、零售和汽车客户一起吸取的一些经验教训。

如前所述，第一个原则是边缘存储必须遵循与云原生生态系统的其余部分相同的操作结构和架构框架。要释放边缘的价值，只需将边缘架构视为使用云原生原则、Kubernetes、自动化和软件定义对象存储的当前数据管理框架的扩展——但针对带宽进行了优化。

这通常意味着需要在边缘进行一定数量的计算，以便减少处理并传送到中央位置的数据有效负载。这里的目标是最大限度地减少与传输相关的数据停机时间或与遍历系统相关的 ETL 任务。

容器，物理的和其他的

具有讽刺意味的是，许多边缘部署实际上是集装箱大小的数据中心，配有电源和冷却装置。这些容器包含计算、存储和网络，这些又使用 Kubernetes 进行编排。

Kubernetes 可以在边缘发挥关键作用。借助 Kubernetes，开发人员知道他们可以在本地编写代码并毫无障碍地部署到数据中心、公共/私有云和边缘。通过 Kubernetes，数据可以作为具有精细访问控制的 API 服务在多云中一致公开。Kubernetes 和 S3 API 还通过自动故障转移机制确保业务连续性。

MinIO 被设计和构建为一个多租户和多用户系统，可以从 GB 无缝扩展到 EB。自然地，Kubernetes 在 MinIO 的多云和边缘功能中扮演着关键角色。正如 DevOps 团队所青睐的那样，Kubernetes 原生设计需要运营商服务来配置和管理多租户对象存储即服务基础设施。这些租户中的每一个都在自己隔离的命名空间中运行，同时共享底层硬件资源。

借助软件定义的 MinIO，DevOps 团队受益于声明配置和使用自动化跨位置应用它们的能力。结果是边缘不再是一个特殊的边缘案例（双关语意），它只是另一种云原生部署。

批处理

批量数据集成操作经常用于构建 ETL/ELT 流程。它们可以在连接和/或带宽非常宝贵的边缘发挥重要作用。

目标是在创建数据的边缘进行处理和分析，过滤掉无关和重复的位，并将洞察力和相关数据传输到集中式数据湖。边缘的计算和存储资源应该小而高效，足以处理和存储数据到数据湖的途中。ETL/ELT、处理和早期分析发生在边缘，并通过经典的中心辐射模型移动数据以提供数据湖。

MinIO 的批处理能力相对较新，但与我们在该领域看到的边缘拓扑特别相关。使用批处理框架进行数据复制或移动可为应用程序开发人员和基础架构操作员提供对其整个数据足迹的细粒度控制。

此外，批量复制允许在任何需要的时间将数据从任何源移动到任何目的地。在批量复制或其他一体式数据移动方法成本过高的边缘用例中，首选这种方法。

希腊怪胎

Lambda 事件通知是松散耦合架构的重要组成部分，微服务在该架构中交互并共同处理数据。微服务不是直接通信，而是使用事件通知进行通信。

例如，一个微服务可能会验证数据，一旦它完成了一个对象，就会通知下一个微服务开始预处理。通过这种方式，微服务彼此隔离，更改一项服务不需要更改其他服务，因为它们通过通知进行通信，而不是通过来回直接调用。这种方法在计算或存储受限环境中非常有效，在这些环境中可以依靠容量利用率来克服突发性。

MinIO 为所有 HTTP 请求（GET、PUT等）生成事件通知，这些通知通常用于触发应用程序、脚本和 Lambda 函数。最常见的用途是在将对象写入存储桶后触发对对象的数据处理。

1-2 重拳

MinIO 客户结合使用批量复制和 Lambda 通知来支持边缘数据管道。该架构可快速处理数据并消除用户干预的要求。批处理和 Lambda 通知的结合可以用于处理数据文件、在格式之间转换文件、组合来自多个来源的数据等等。

这些技术通常结合起来形成边缘和核心数据湖之间的数据管道。一旦数据进入数据湖，就可以利用更多计算（和弹性计算）进行分析、AI/ML 和报告框架。数据湖的输入速度越快，就可以更快地收获洞察力，从而更快地做出决策。

一个真实世界的例子

Chick-fil-A 是一家知名的快餐连锁店，它依靠开源 Kubernetes 和 GitOps使用云原生 DevOps 方法来管理边缘部署。该公司拥有 2,000 家餐厅和数十万个联网的“东西”，例如油炸锅、烤架、冰箱和食品托盘。由于这些设备来回发送信息，因此需要分析它们的数据并在本地进行控制。

每个 Chick-fil-A 餐厅都运行一个小型 Kubernetes 集群，从而实现完整的云原生边缘环境。即时操作所需的数据保留在本地，而更高级别的业务和操作信息被发送到中央数据湖。Chick-fil-A 在云中维护一个 Git 版本控制存储库。边缘集群拉取规范文件并在无需人工干预的情况下应用它们。

虽然 Chick-fil-A 不运行 MinIO，但他们的架构正是我们所建议的。创建一个云原生实例（实际上有 2,000 个），其外观和感觉就像您在数据中心运行的实例。它易于管理、操作和故障排除（运送一个新的迷你集群，插上电源，然后关闭）。

边缘已死，边缘万岁

是时候改变我们对边缘和边缘架构的思考了——并将重点从“边缘计算和存储”转移到“边缘是我的云原生足迹的一部分”。毕竟，我们生活在一个云原生世界中，边缘架构必须与云架构保持一致，并且无论数据位于何处，都可以通过相同的 API 调用来检索数据。更重要的是，随着边缘用例开始成熟，重点正在从在边缘硬件上运行的专用存储转向构建多云平台，使您的组织能够跨云、边缘和内部部署相同的存储——以及那就是 Kubernetes 原生的、软件定义的对象存储。

您可以在这篇文章中找到我们更多关于边缘的思考。相反，您可以在此处下载我们的<100MB 二进制文件，看看它如何适合Raspberry Pi之类的东西。问题？如果他们是商业性质的，请在咨询专家频道上联系我们；如果他们是技术性质的，请在General Slack上联系我们。