边缘计算的弹性挑战之探讨

边缘计算将计算资源放置在互联网边缘，接近设备与信息源头。类似CPU中的缓存，边缘计算能够为应用提高带宽、减少延迟，但潜在的代价是可靠性和容量。这是因为边缘设备通常不如集中式服务器和云计算资源，在维护性、可靠性、功能和稳定性方面仍面临挑战。

就边缘设备的地理分布而言，本文对边缘的定义包含临近部署的少量边缘设备、城市内蜂窝基站的设备，及全市范围的部署。当本地处理不充分、成本高昂或者计算依赖于非本地信息时，本地设备计算将卸载到附近的边缘计算设备（雾、云等）上。例如，手机中过长的语音片段可以卸载到电池塔上处理，而不是在本地设备（移动边缘计算）上处理，这既可节省电池，又可减少处理速度差异导致的端到端延迟。

与传统高度集中的云计算相比，边缘计算设备充当了分布式计算的基础结构，提供更高的带宽和更低的延迟，但与中央云相比，却存在资源有限的短板。

边缘范式支持大规模的物联网（IoT）设备，物联网设备与本地环境的交互生成实时数据，从而分担云上繁重的处理和分析任务。此结构是增强现实（AR）和家庭自动化等应用的主干，它们通过复杂的信息处理来分析本地环境以支持决策。在物联网领域，功能输入和输出与地理分布的传感器和执行器是物理绑定的。如果这些数据集中在中心位置处理，则“最后一英里”网络将面临巨大压力，云基的物联网部署方案将变得不切实际。

如果没有大幅度的网络提升（这在中短期似乎不太可能实现），那么边缘计算将会成为物联网的基石。由于两个方面的原因，本地计算和边缘计算的范围发生了变化：一是更多苛刻应用的出现（从声音处理到视频处理再到增强现实）；二是本地可用资源的增加，包括处理、存储、网络等。前者将一些处理推向边缘，并进一步推向云，而后者则驱使处理更靠近本地。

受益于边缘计算的应用通常具有低延迟的需求并且会产生高带宽的数据流。物联网设备和增强现实应用是两个典型例子。本文将以此为例，考察边缘计算应用带来的弹性挑战。

当前，边缘计算应用还处于起步阶段，许多设计决策在小规模场景下似乎是合理的。但是，随着边缘应用程序规模的扩大，无论是在客户端设备的数量还是在生成的数据量方面，都会出现许多实际挑战。在低成本无线电子产品和易于集成的特点的推动下，物联网正在快速地增加可寻址计算机的数量以及对应的需要传输的环境数据量。共享计算工具（尤其是网络资源）会因数据密集型应用的横向扩展而迅速饱和，当端点数量的算法复杂度呈现超线性增长时，协议可能无法及时返回结果。

网络影响：随着新设备的投入使用，云基的计算可通过向计算环境中逐渐增加资源来支持拓展性。实际上，集中式数据中心较容易实现这样的拓展，例如只要安置新服务器并将其连接到现有基础架构中即可。但是随着物联网规模的不断扩大，如果网络运营商仍然依靠平均容量做部署规划，而网络技术无法跟上数据的持续增长，那么将所有数据处理转移到数据中心显然是不可行。如果固定视频传感器全天候生成6Mbps的视频，每月就会产生近2TB的数据，从消费者连接的商业管理来讲，这将是无法维持的。如果使用广泛部署的有线互联网技术DOCSIS3.0，当今美国的大多数有线系统在500个家庭中最多总共支持81Mbps，平均每个家庭仅支持0.16Mbps。如果12个用户在该地区进行AR交互，网络就将饱和。而如果使用边缘计算，500个家庭可以同时处于活跃状态，但需要些弹性成本：如果每个家庭有4个活跃的AR用户，那么由于最后一英里网络的限制，500台边缘计算机中仅仅容许有3台可以同时出现故障并返回到云中处理。

缺少故障转移：第一个弹性挑战是如何在发生故障时进行故障转移。在云计算中，同一本地网络存在热备份，因此每个独立资源的可用性并不是很重要。在边缘环境中，热备份就显得不切实际。常见的部署方案非常精简，只使用一个边缘设备，如一个WiFi路由器即提供了一个家庭中所有的边缘服务。对此的替代解决方案是协商基于对等点的故障转移或资源的社区聚合（类似于微电网）在这种情况下，社区带宽仍将限制故障转移的能力。如果没有额外的网络基础架构支持，即使在同一本地社区内进行对等点的故障转移，500个家庭也只能支持12个未在本地处理数据的AR用户。除非增加带宽，额外的冗余边缘计算才能变得可行，但这需要既昂贵又部署缓慢的最后一英里网络的支持。

边缘计算的低延迟特性吸引了具有软实时要求应用的部署。例如，AR应用需要保持低于16毫秒的端到端延迟，以保持60帧/秒的无缝交互。这种延迟在本地设备上很容易实现，但让所有客户端设备都具备AR应用必要的计算能力却是不可行的。边缘计算提供了一个经济可行的办法，尤其是当边缘设备大部分时间处于空闲状态时（如商店收银机中的“计算机”）。这促使实时应用选择在边缘计算机上运行而非在客户端设备上。在边缘计算设备内部，存在少量的CPU、RAM、GPU/APU和网络支持。每个实时应用都需要一部分资源的支持以便在规定的时间内执行任务。受限环境中的实时调度（通常采用截止时间优先）可能会因以下因素而复杂化：不同应用程序的延迟容忍级别，不可预测的用户交互、边缘设备和客户端设备之间不可预测的网络行为以及同一普通边缘设备服务的多客户端设备的时钟漂移。在边缘计算网络具备足够的所需能力之前，设备可能会一直等待。例如，边缘设备正在分析来自AR设备的视频流，而此时恒温器却急需视频流的分析结果来识别屋内人数，进而设定温度。如果边缘设备无法同时支持这两项任务的执行，那么就需要调度算法来安排它们的执行顺序。如果边缘计算范式得到普及，边缘设备上的竞争将不可避免，并且当今许多应用对资源及时可用的需求将导致许多实时服务无法得到及时响应。针对此类问题的一种解决方案是使用云作为故障备份，用来延迟容错应用。此外，如果应用是有状态的，但是鉴于某些边缘设备的无常性。这些状态也需要存储在客户端、云上或兼而有之。