边缘计算的数据模式，与现有系统的整合和共存

今天的企业正在竞相将关系到用户体验的数据置于更接近终端用户的位置，同时各类区域性数据隐私法规也纷纷出台；在这样的背景下，我们有必要审视数据中心的“同步数据检索”“后续数据检索”和“预取数据检索”等企业数据模式。我们还应了解如何在将数据移植到边缘的同时避免像数据中心那样复杂地克隆整个架构，且能有效掌控控制平面、避免边缘盲点。

企业的用户体验数据

上图是现有的企业级数据图景概况：其中服务 A 是多个服务的抽象表示，服务 B 表示访问数据中心本地数据的服务层，访问来自外部第三方供应商的数据的所有服务都抽象为服务 C。跨越这些服务的数据检索操作又可以进一步分为以下类别：

• 同步数据检索。这种模式中，用户的所有数据都在一个单一或父级请求中检索，这个请求可能是初始 html 负载调用或来自原生移动应用程序的服务调用。这种模式的一个例子是任意交易体验或个性化用户体验：一个同步数据检索的增强版本中，数据是逐步分块或分页提供给最终用户的。

• 后续数据检索。在这种模式中，系统首先检索初始关键数据，后续数据则通过异步调用检索。该模式的一个例子是非初始页面内容推荐（其中所需的内容是在最终用户滚动页面后才出现的），广告或游戏瓦片也适用于这种检索模式。

• 预取数据检索。第三种模式利用了用户参与时间，基于预测性统计数据/排名/工作流程来预取或加载数据，这里的数据可能是媒体资源/模板/个性化数据。

首先简单介绍一下边缘计算：如果 SDN 更接近最终用户，且你或你的组织为边缘计算做好了准备，那么任何位于你的数据中心之外的位置都可以被看作是网络边缘。例如，如果计算是在数据中心和边缘组件之间的互动，而不像本地计算那样基本在集群的边缘节点完成，这样的计算就可以被看作是边缘计算。

在我们深入研究边缘和边缘计算的数据模式之前，首先要看到行业范式一直在向用户设备或浏览器的静态数据集转移，从而导致用户资源和带宽的开销增加，同时也让企业失去了对某个时间点上提供的数据的控制机制。

这篇文章试图解释的是，我们如何在边缘计算模式中将传统的控制旋钮或语义保留给数据中心工程师与边缘工程师，同时不让用户为你的优化付出代价。简而言之，我们的目标是将数据范围从 D 空间扩展到 E 空间，如图 1 所示。这需要克服与以下方面有关的障碍：

• 有限的基础设施 Capex

• 流量路由和升温（Ramp Up）

• 遗留技术支持

这篇文章旨在介绍各种数据模式、解决相关的问题集合，并给出一些见解，告诉读者可以利用哪些技术来扩展企业数据集。

边缘数据模式

我们先来讨论一下面向边缘计算和用户体验优化的三种主要数据模式。

同步数据检索

互联网领域的大多数数据都属于这个范畴。企业数据集包含许多相互依赖的服务，这些服务以分层的方式提取所需的数据集，这些数据集可以是个性化的，也可以是通用格式。传统上，企业只能将静态资源、标头数据集或媒体文件迁移到边缘或 CDN，同时基础数据集基本上是从源 DC 或云提供商那里检索的。

谈到用户体验，这方面的优化工作主要涉及关键渲染路径和基于 web 体验的导航时间线的相关改进，还关系到设备体验中有多少视图模型被卸载到应用二进制文件上。在混合体验中，状态模型会通过服务器推送或轮询定期更新。本文讨论的用例是我们如何从边缘为个性化的数据集实现数据检索。

用户体验数据被划分为非用户上下文（NC）和用户上下文信息（UC），其中非用户上下文数据指的是跨用户或体验的通用信息，而用户上下文数据是特定于设备或用户的信息。非用户上下文数据会被存储、失效、即时清除，而相关的用户上下文信息则在父请求生命周期内缝合或定制。这里的设计原则是，引入边缘不应削弱网络和领域团队实现各自的控制和优化旋钮的能力。

我们先讨论一下数据中心的各种组件，因为许多团队已经有了数据中心的各种服务，所以这是一个很好的出发点。

数据中心组件

一般情况下这会是企业内部的前端层，它需要做一些变更来支持上述模式。首先，这一层需要将边缘侧流量标识符头传播到底层服务、处理 cookie 管理事宜、确定并设置必要的缓存控制值（如缓存或不缓存）、如果缓存还要设置缓存时长，这里一般利用标准的 Cache-Control指令。这一层也负责删除任何动态的全局头或通用模块，并重新插入相同的内容作为用户上下文响应负载的一部分。就边缘生态系统而言，前端层预计将主要处理以下四个数据流：

• 常规流量（非 POP）

• 常规的实验控制流量

• 缓存创建/写入调用，这里就是非用户上下文的请求

• 用户上下文请求

这一层负责根据用户和非用户上下文信息来分割数据，通过一个模块提供者组（如 CACHEABLE）让业务团队控制哪些数据段需要被缓存，哪些不需要，并由 ValidationViewModel 作为先导，对不需要被缓存的受限数据集施加规则和限制。实验和跟踪都是在这一层处理的，用于业务影响分析需求。这一层基于边缘流标识符头来处理所需的数据响应、为分析提供相关的跟踪，并用所需的缓存 ttl 值和修订 ID 对数据响应进行着色，以便于数据清除和拉取，从而让业务团队在移动到 POP 生态系统的边缘时仍然可以管理数据。

正如你在上面所观察到的，数据中心的入口点要根据从边缘传播的不同标头而表现出不同的行为，并根据路由而有不同的行动。同时我们要确保边缘数据存储与基于浏览器的缓存指令相兼容。为了在边缘或 POP 上适应这一点，我们需要有一个可扩展的软件负载均衡器，Envoy就是一个选项。它有强大的跨主集群发现服务、路由、监听器、密钥管理和添加自定义过滤器的能力。就边缘数据存储集群而言，考虑到数据存储理解浏览器缓存衍生物时要注意的事项，对我们来说ATS是一个有利的、可扩展的选择。

如下图所示，软件负载均衡器负责以下操作步骤：

• 处理传入的用户请求

• 在业务特定的服务 E 上询问可能的高速缓存密钥

• 如果缓存被命中，检索非用户上下文数据给终端用户

• 如果缓存未命中，将基于哈希的数据写入边缘数据存储中，以便将来调用

• 在父请求生命周期中缝合用户上下文

• 在更新或修订 ID 变化时令缓存失效

这项服务在边缘是必不可少的，它允许业务或领域团队输入与数据集相关的必要知识工程。如果你的数据或经验是国际性的，那么服务 E 就会负责处理不同的地域、识别实验组的用户部分、基于查询参数自定义逻辑、检测设备以允许或不允许缓存模式、生成用户请求的缓存密钥。

边缘数据存储

边缘数据存储集群主要需要处理基于 TTL 值设置的缓存清除机制，并对数据中心进行必要的调用以检索新的数据集（而不是缓存数据集），即使在设置了相应的缓存控制值并做出了缓存调用尝试的情况下也是如此。

在我们的用例中，鉴于 ATS 会为每个单独的请求调用源数据，ATS 数据存储被植入了一个自定义插件，只在请求有 cache-key 头值时才进行调用，从而允许 SLB 控制缓存数据集的条件与时机。

上述方法可以在边缘缓存非个性化（非用户上下文）数据，并在请求生命周期中检索用户上下文数据，从而让终端用户看到相同的非 POP 体验。给终端用户提前检索非用户上下文数据可以让浏览器构建 DOM，从而提高关键渲染路径的性能，并允许未来的用户数据渗入到浏览器渲染层，以获得更好的用户感知。在我们的高流量页面中，我们能够将延迟从>1500ms 降至<700ms。上述方法的额外优势包括处理机器人流量，并能集中观察全球流量，在流量与业务之间建立有效关联。

后续数据检索

与同步数据检索不同，这种检索模式中缓存的力量更集中在重复调用数据内容以获得更高的缓存命中率上。如果你有一个长尾访问模式，并且检索的数据在本质上是独特的，这种模式可能就不合适了。大多数此类场景可以通过更早发送关键内容来优化，后续数据集可以根据需要从边缘检索。这种模式有一个额外的优势——即使数据是唯一的且只访问一次（例如广告），也能实现边缘数据的检索。我们可以通过验证用户体验的内容检索的常规时间线来判断在这种模式中能否看到延迟预算的改善。在下图中，正如你所看到的，当浏览器发出请求时（1-2），初始页面内容被检索出来，并为将来的数据内容调用提供相关的标识符（5）（主要在页面 onload事件后触发）。浏览器端用于构建 DOM 和网络延迟的时间被认为是从服务 B 层检索数据集的并行调用的一个额外优势。

如上图所示，迁移到边缘可以让内容在边缘可用，并让不同的标识符以较低的 ttl（短时交易数据集）来支持最终用户体验，如果可行的话，将服务 B 迁移到离第三方供应商更近的地方可以在服务 B 层更快提供数据。

具体来说，来自服务 B 的数据中心数据在可用时被推送到各自的边缘集群，以便快速检索；如果出现任何失败就返回到传统的由数据中心调用的模式。所有的读和写操作都通过相同的软件负载均衡器转移，以实现一致的哈希和单点可观察性。

我们来看看实现上述模式的数据中心组件和边缘组件。

数据中心组件

该服务嵌入到现有的架构模式中，以支持创建动态标识符，用于放置或分页对终端用户的最终响应上的模块。在一些用例中，这一层可以容纳用户信息，以定制与终端用户相关的页面模块响应。同时该层管理边缘流标识符头到下游的传播。

服务 B 的抽象适用于来自第三方系统或竞标引擎的数据检索。这里要有并行的、支持 FIFO 的数据检索。

服务 C 容纳从数据中心写入和读取的数据内容。

服务 E 将边缘洞察力嵌入业务团队，使数据在终端用户本地可用。该层提供了基于父级原始请求的复制和数据可用性。

在这种模式下，软件负载均衡器负责

• 针对响应 HTTP 204 处理无内容场景

• 处理预检请求和响应头，以尽早确定允许的域

• 传播上游服务的 POP 集群信息，以确定未来调用的会话亲和性

• 边缘数据存储（ATS）的 POST 到 PUSH 转换

• 处理缓存命中、缓存丢失、写入、读取路径、数据大小的可观察性

例如，在下面的场景中，每段内容都是唯一的，边缘的命中率大于 82%，写操作被路由到父请求 POP，没有复制到该区域的其他 POP。

然而，当业务团队减少对边缘数据的推送时，同样的情况在边缘侧响应代码中很明显，这样异常检测系统就很容易发现它。

边缘数据存储

在这种场景中，我们要利用 ATS 的 PUSH 模式来存储相关的 TTL 值的数据内容，关键点是通过数据中心的 POST 或 PUT 进行写入操作。同样的操作被转换为 ATS，以支持 PUSH 方法在插入时 drop HTTP 201、在复制时 drop HTTP 200、在内容丢失场景 drop HTTP 204。

上述方法可以支持将数据转移到边缘的目的，即使数据集只被访问或使用一次（短时交易记录），或者在用户无法确定（如访客或系统新用户）的情况下也是可行的。

预取数据检索

在预取的场景中，重点是可以提供下一个确定的数据集。考虑下图中的服务 Z，它是由服务 A、B 或 C 驱动的页面请求的前置服务。在基于下一步内容的漏斗或工作流中，相关的（预测的或排名的）数据集被预取并在边缘提供。一般来说，这适用于加载游戏瓦片、推荐、顶级搜索结果和加载媒体文件等场景。

这种模式的效率取决于相关数据集是如何被缓存或存储在边缘的，被提供的数据应利用同步数据检索、后续数据检索或离线数据模式提供。

我们正进入一个数据爆炸的时代，在未来几年内边缘平台将承载大部分新增数据。只有适应边缘计算的组织才能转变为围绕边缘智能的持续创新体系。正如你在上面的边缘数据模式中所看到的，现在任何组织都可以改造他们现有的传统系统来利用边缘计算的优势。由于我们正在处理的是底层数据，就可以适应不断变化的技术栈。另外这些数据模式可以让数据本地化，以应对数据隐私法案的要求。

作者介绍：

Anoop Koloth 是一名架构师，拥有从用户感知到数据库调整的技术和问题集的经验。他的专长是建立可扩展和有弹性的系统，能够处理 PB 级的数据和数十亿的请求。Anoop 认同解决方案工程，并强调人们应该更多使用技术来为当前和未来的问题找到更好的解决方案。他也是 Dottedyellow 的创始人，这家公司的目标是用最好的技术来简化司机教学过程。

原文链接：

Data Patterns on Edge