边缘作为核心的悖论

边缘在技术架构中非常重要。大型技术项目有很多叙述。大多数叙述都是从供应商的角度出发，以自我为中心的。这是有道理的，不同的公司对他们想要推出的产品有不同的观点和不同的议程。

由于我们在技术栈中的位置，我们对边缘主题进行了很多讨论，其中一个核心发现非常简单。使用云操作系统模型构建您的边缘架构，但要针对带宽进行优化。换句话说，边缘应该看起来像您的云架构的计算/存储/网络优化版本。乍一看可能听起来很激进，但从运营、技术和经济角度来看，这是完全合理的。

据估计，全球边缘物联网连接的数据量将在 2019 年的 13.6 ZB 上升到 2025 年的 79.4 ZB，因为能量效率高、外形尺寸紧凑的边缘硬件将部署到蜂窝基站、零售店、汽车或工厂等位置。

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

• 低延迟数据处理： 在更靠近网络边缘的地方处理数据，可以缩短数据从设备到云端再返回的往返时间。这将导致延迟降低和应用程序响应能力提高。
  
  
• 物联网和边缘设备管理： 随着万物互联，边缘云可用于管理和控制大量物联网设备，例如传感器、摄像头和其他设备，这些设备可能分散在世界各地。
  
  
• 内容交付： 边缘云可用于分发大型文件内容，例如视频、音频或软件更新。智能缓存通过提高传输速度和效率来改善用户体验，对于物理上更靠近边缘云位置的用户来说尤其如此。
  
  
• 离线数据处理： 边缘云可用于在与中心云断开连接时处理数据，这对于自动驾驶汽车、无人机和机器人等需要在偏远或离线环境中运行的应用程序非常有用。因此，边缘服务必须设计为在连接和断开连接的情况下都能运行。
  

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

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

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

容器，物理和其他

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

Kubernetes 在边缘可以发挥关键作用。使用 Kubernetes，开发人员知道他们可以本地编写代码并部署到数据中心、公有/私有云和边缘，而不会出现任何问题。通过 Kubernetes，数据可以作为 API 服务以一致的方式跨多云公开，并具有细粒度的访问控制。Kubernetes 和 S3 API 还通过自动化的故障转移机制来确保业务连续性。

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

使用软件定义的 MinIO，DevOps 团队可以声明配置并使用自动化将这些配置应用于各个位置。结果是，边缘不再是特殊情况（双关语），它只是另一种云原生部署。

批量处理

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

目标是在数据创建的边缘进行处理和分析，过滤掉无关和重复的部分，并将见解和相关数据传输到中心数据湖。边缘的计算和存储资源应该小而高效，足以处理和存储数据，以便将其发送到数据湖。ETL/ELT、处理和早期分析在边缘进行，并通过经典的集线器和辐条模型移动数据，以供数据湖使用。

MinIO 的批量功能相对较新，但在我们看到的边缘拓扑结构中特别相关。使用用于数据复制的批量框架或移动，可以为应用程序开发人员和基础设施运营商提供对其整个数据足迹的精细控制。

此外，批量复制允许在任何所需时间将数据从任何源移动到任何目标。在这种情况下，批量复制或其他一体化数据移动方法成本过高，这种方法是首选的。

希腊怪兽

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

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

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

组合拳

MinIO 客户使用批量复制和 Lambda 通知相结合的方式来为边缘数据管道提供动力。这种架构可以快速处理数据，并消除了用户干预的需求。批量处理和 Lambda 通知相结合可以用于操作数据文件、在格式之间转换文件、组合来自多个来源的数据等等。

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

现实世界的例子

Chick-fil-A 是一家著名的快餐连锁店，它依赖于开源 Kubernetes 和 GitOps来使用云原生 DevOps 方法管理边缘部署。该公司拥有 2000 家餐厅，以及数十万个网络连接的“事物”，例如油炸机、烤架、冰箱和食品托盘。当这些设备互相发送信息时，需要对其数据进行分析并对其进行本地控制。

每家 Chick-fil-A 餐厅都运行一个小型 Kubernetes 集群，从而构建了一个完整的云原生边缘环境。立即运营所需的数据保留在本地，而更高级别的业务和运营信息则发送到中心数据湖。Chick-fil-A 在云中维护一个 Git 版本控制库。边缘集群下载规范文件并将其应用，无需人工干预。

虽然 Chick-fil-A 没有运行 MinIO，但他们的架构正是我们建议的。创建一个云原生实例（实际上是 2000 个），它看起来和感觉就像您在数据中心中运行的实例一样。它易于管理、易于操作和易于故障排除（运送一个新的迷你集群，将其插入并开始使用）。

边缘已死，万岁边缘

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

您可以在 这里 找到我们关于边缘计算的更多想法。反之，您可以 下载 我们小于 100MB 的二进制文件，看看它如何适应类似 树莓派 的东西。有问题？如果您是商业性质的问题，请通过 咨询专家 渠道联系我们；如果是技术性质的问题，请通过 通用 Slack 联系我们。