译者 | 布加迪

审校 | 孙淑娟

鉴于许多组织纷纷获得边缘计算在延迟、灵活性、成本和性能等方面带来的好处，边缘计算正在迅猛发展。IDC估计，2022年全球在边缘硬件、软件和服务上的支出将超过1760亿美元，比上一年猛增14.8%，到2025年将达到2740亿美元。因此，您的开发人员很可能现正在开发边缘应用程序，或者在不远的将来会开发。

在积极试水之前，有几个方面需要考虑。我是一名企业架构师，与多家开发组织有过合作，在创建边缘应用程序方面可以给出几个重要的经验。牢记这些经验可以帮助您避免令人沮丧的结果，并确保您充分发挥边缘计算的优势。

经验一：质疑自己的想法

开发人员常常将创建边缘应用程序视为它们就像是面向数据中心或云的应用程序。但是边缘是一种不同的范式，需要不同的方法来编写代码，还需要深思熟虑地选择哪些应用程序适合边缘。

大多数开发人员习惯于少量服务器拥有大量计算资源的集中式计算环境。但边缘计算颠覆了这种情形，将数量适中的资源分布在不同位置的多台服务器上。这会影响任何一种边缘工作负载的可扩展性。比如说，使用大量内存的应用程序面对成百上千个边缘实例时可能无法很好地扩展。出于这个原因，大多数边缘应用程序将是专门为边缘构建的，而不是从现有数据中心或云部署环境“平移”。

您需要批判性地思考边缘架构如何影响自己的应用程序、哪些应用程序将受益于这种分布式方法。将逻辑引入到数据所在的位置通常比较容易。因此，如果数据比较分散，或需要访问大型集中式数据存储，基于云的方法可能很明智。但当应用程序使用边缘处生成的数据时，比如来自在线用户的请求/响应、Cookie和标头，这时候边缘计算就能真正大放异彩。

经验二：不要忽视基本面

虽然将代码分发到边缘可以改善延迟和可扩展性，但不会一下子运行得更快。低效的代码在边缘同样很低效。如前所述，边缘的每个接入点都将比典型的集中式计算环境更受资源的限制，尤其是在无服务器边缘环境下。在为边缘编写代码时，优化效率对于充分利用这种架构至关重要。

当将功能推送到边缘相对快速和容易时，您仍然需要运用通常用于任何代码的同样的妥善管理流程。这包括良好的变更管理流程、将代码存储在源代码控制系统中，以及使用代码审查来评估代码质量。

经验三：重新考虑可扩展性

如果使用边缘，您是“横向扩展”而不是“纵向扩展”。因此，您需要开发代码以适应每个请求的约束，而不是从每个服务器的约束方面来考虑。这包括内存使用、CPU 周期和每个请求的时间等方面的约束。约束会因您使用的边缘平台而异，因此了解这些约束并相应地设计代码很重要。

通常，您需要使用每个操作所需的最小数据集进行操作。比如说，如果您在边缘进行 A/B测试，您可能只想存储您在处理的特定请求或页面所需的那部分数据，而不是整个规则集。如果是基于位置的体验，您只需要轻量级查询中该边缘实例为特定的州或地区所提供的数据，而不是所有地区的数据。

经验四：为确保可靠性编写代码

确保边缘应用程序的可靠性对于提供积极的用户体验而言至关重要。确保您的质量保证（QA）计划包含测试边缘代码。添加适当的错误处理对于确保代码能够从容地处理错误也很重要，包括规划和测试出现问题时的回退行为。比如说，如果您的代码超出了平台施加的限制，您希望创建回退机制，以便退回到一些默认内容，这样用户不会收到影响体验的出错消息。

执行分布式负载测试是证实应用程序具有可扩展性的好方法。一旦您部署了代码，继续监控平台，以确保不会超出CPU和内存方面的限制，并跟踪任何错误。

经验五：优化性能

边缘计算的主要好处是将数据和计算资源移到靠近用户的位置，从而大幅缩短延迟。当您在成百上千个接入点（PoP）进行扩展时，创建轻量级高效代码对于获得这个优点至关重要。完成一项功能所需的数据也应该在边缘处。开发需要从集中式数据存储获取数据的代码将使边缘带来的延迟优点荡然无存。

对于您可能希望用于边缘应用程序的任何第三方代码，同样需要强调高效执行。一些现有的代码库很低效，损害性能及/或超出边缘平台在CPU和内存方面的限制。因此在将任何代码合并到部署的边缘环境之前，先仔细评估一番。

经验六：不重新发明轮子

虽然边缘是一种新范式，但这并不意味着必须从头开始编写所有代码。大多数边缘平台与各种内容交付网络（CDN）功能相集成，允许您创建自定义逻辑，以生成表示现有CDN功能（如缓存）的输出。

构建代码确保可重用也是一个好主意，以便代码在边缘和集中式计算环境中都可以执行。将核心功能抽取到不依赖浏览器、Node.JS或特定平台功能的库中，让代码可以“同构”，能够在客户端、服务器和边缘处运行。

使用现有的开源库是另一种避免重写通用功能的方法。但要注意需要Node.JS或浏览器功能的库。一些第三方开发人员开发与您使用的边缘平台集成的产品，还要考虑与他们合作，这可以节省时间和精力，同时获得互操作性经过验证的优点。

将经验付诸实践

为了说明这些最佳实践带来的影响，不妨考虑一个真实案例：一家组织在边缘实施地理围栏应用程序时遇到了困难。由于超出了平台在CPU和内存方面的限制，该组织面临高错误率。

看看该组织如何构建应用程序，他们拥有所有地理围栏区域的数据，即900KB的JSON，存储在每个边缘PoP处。使用CPU密集型算法针对每个地理围栏检查兴趣点，在接受检查的前几个区域中未找到兴趣点时，就触发CPU超时。

为了纠正这个问题，每个地理围栏区域的数据都被移到了键值存储（KVS）系统，每个区域存储在一个单独的条目中。并添加了轻量级检查，以确定某个兴趣点可能存在的“候选区域”（通常是1到3个候选区域）。仅针对候选区域执行完整的数据和CPU密集型检查，这大大减少了CPU工作量。这些变化将错误率降到了可忽略不计的水平，同时缩短了初始化时间，并减少了内存使用量，如下图所示。

图1：成功率和错误率的前后对比（请注意，成功和错误度量指标在不同的尺度上，因此无法直接比较）

图2：初始化时间前后对比

图 3：内存使用量前后对比。（图片来源：Akamai）

充分发挥边缘的优势

边缘计算为受益于贴近用户的应用程序提供了巨大的优势，不仅带来了速度和效率，还带来了个性化用户体验。成功的关键是确保您的应用程序很适合边缘，然后优化代码以充分利用边缘平台功能，又不超出约束范围。

如果注意我在与多家组织合作中获得的经验，您可以更快速地充分发挥边缘的好处，又没有棘手的问题。

原文标题：​​Coding for the Edge: Six Lessons for Success​​​，作者：Josh Johnson​