随着企业急于获得边缘可以提供的低延迟、灵活性、成本和性能优势，对边缘计算的需求正在急剧扩大。IDC估计，到2022年，全球在边缘硬件、软件和服务上的支出将达到1760亿美元，比上一年增长14.8%，并在2025年达到2740亿美元。因此，您的开发人员很可能正在构建边缘应用程序，或者将在不远的将来。但是，在您开始之前，有几件事需要考虑。作为企业架构师，我有与开发组织合作的经验，让我告诉您一些创建边缘应用程序时的经验教训。牢记这些教训可以帮助您避免走弯路，并确保您充分利用边缘所提供的优势。第1课：挑战您的思维方式开发人员经常创建边缘应用程序，就好像它们在数据中心或云中一样。但边缘是一种不同的范例，需要不同的编码方法和深思熟虑的方法来选择适合边缘的应用程序。大多数开发者习惯于集中式的计算环境，大量的计算资源集中在少量的服务器上。然而，边缘计算颠覆了这种情况，将相对适度的资源分布在不同位置的许多服务器上。这可能会影响任何一个边缘工作负载的可扩展性。例如，使用大量内存的应用程序可能无法在数百或数千个边缘实例之间很好地扩展。出于这个原因，大多数边缘应用程序将专门为边缘构建，而不是从现有数据中心或云部署中“提升和迁移”。您需要认真考虑边缘架构如何影响您的应用程序，以及哪些应用程序将从这种分布式方法中受益。将逻辑放在数据所在的位置通常更容易。因此，如果数据更加区域化，或者需要访问大型集中式数据存储，则基于云的方法可能是合理的。但是，当应用程序使用边缘生成的数据时——例如来自在线用户的请求/响应、cookie和标头——这就是边缘计算真正发挥作用的地方。第2课：不要忽视基础知识虽然将代码分发到边缘可以改善延迟和可扩展性，但它不会神奇地运行得更快。低效代码在边缘同样低效。如前所述，边缘的每个存在点都比典型的集中式计算环境更受资源限制，尤其是在无服务器边缘环境中。在为边缘编写代码时，优化效率对于充分利用此架构至关重要。虽然将功能推到边缘相对快速和容易，但您仍然需要像对待任何其他代码一样应用同样勤奋的管理流程。这包括良好的变更管理流程、在源代码控制中存储代码以及使用代码审查来评估代码质量。第3课：重新思考可扩展性在边缘，您是在“扩展”而不是“增加”。因此，您需要开发代码以适应每个请求的约束，而不是每个服务器的约束。这包括对内存使用、CPU周期和每个请求的时间的限制。约束会根据您使用的边缘平台而有所不同，因此了解它们并相应地设计您的代码非常重要。通常，您希望使用每个操作所需的最小数据集进行操作。例如，如果您在边缘进行A/B测试，您只想存储您正在操作的特定请求或页面所需的数据子集，而不是整个规则集。对于基于位置的体验，您只需在一个轻量级查询中保存该边缘实例所服务的特定州或地区的数据，而不是所有地区的数据。第4课：可靠性编码确保边缘应用程序的可靠性对于提供积极的用户体验绝对必要。确保在您的QA计划中包含测试边缘代码。添加适当的错误处理以确保您的代码妥善处理错误也很重要，包括在事件发生时规划和测试回退行为。例如，如果您的代码超出了平台的限制，请创建一些默认内容的回退，这样用户就不会收到影响他们体验的错误消息。进行分布式负载测试是确认应用程序可扩展性的好做法。部署代码后，继续监控平台以确保未超过CPU和内存限制，并追踪任何错误。第5课：优化性能边缘计算的主要好处是通过将数据和计算资源移动到更靠近用户的位置来显着减少延迟。当您跨数百或数千个接入点(PoP)进行扩展时，创建轻量级、高效的代码对于实现这一优势至关重要。完成功能所需的数据也应该在边缘。开发需要从集中式数据存储中获取数据的代码会消除边缘提供的延迟优势。对高效执行的强调同样适用于边缘应用程序利用的任何第三方代码。一些现有的代码库效率低下，会损害性能或超出边缘平台的CPU和内存限制。因此，在将任何代码合并到边缘部署之前，请仔细评估它。第6课：不要重新发明轮子仅仅因为Edge是一种新范例并不意味着您必须从头开始编写所有代码。大多数边缘平台都集成了各种内容分发网络(CDN)功能，允许您创建自定义逻辑来生成输出信号，以提示现有的CDN功能，例如缓存。将代码设计为可重用也是一个好主意，这样它就可以在边缘和集中式计算环境中执行。将核心功能抽象到不依赖于浏览器、Node.JS或特定平台功能的库中，可以使代码“同构”并能够在客户端、服务器和边缘上运行。使用现有的开源库是避免重写通用功能的另一种方法。但要注意需要Node.JS或浏览器功能的库。并考虑与与您正在使用的边缘平台集成的第三方开发人员合作，这样可以节省时间和精力，同时提供成熟互操作性的好处。将这些经验付诸实践为了说明这些最佳实践的影响，请考虑一个真实案例：一个组织难以在边缘实施地理围栏应用程序。他们遇到了由于超出平台的CPU和内存限制而导致的高错误率。看看他们如何构建他们的应用程序，他们有所有地理围栏区域的数据，900KB的JSON，存储在每个边缘PoP中。使用CPU密集型算法检查每个地理围栏的POI，在检查前几个区域后未找到POI时触发CPU超时。为了解决这个问题，每个地理围栏区域的数据被移动到一个键值存储（KVS）中，每个区域存储在一个单独的条目中。添加了轻量级检查以确定兴趣点的可能“候选区域”（通常为1到3个候选区域）。仅对候选区域进行全数据和CPU密集型检查，大大降低CPU工作量。这些更改将错误率降低到可以忽略不计的水平，同时缩短了初始化时间并减少了内存使用量，如下图所示。图1：成功率和错误率的前后比较（请注意，成功和错误指标的比例不同，因此无法直接比较）。图2：初始化时间前后对比图3：内存使用前后对比（图片来源：Akamai）个性化用户体验快速高效的优势。成功的关键是确保应用程序是边缘平台的良好候选者，然后优化您的代码以充分利用边缘平台的功能，同时在其约束范围内工作。请注意我在与组织合作时学到的经验教训，您可以更快地到达边缘，而不会头疼。
