application边缘集成： 进化研究

航班： 实践中的趋同进化

我们大多数人都梦想着能够飞翔；事实证明，进化也是如此。 飞行能力——无论是为了躲避捕食者、更有效地寻找食物还是长距离迁徙——已被反复证明对多种动物都具有巨大的实用性。 事实上，这种现象出现得如此频繁，以至于进化最终还是会找到某种途径来实现飞行的目标。 今天，我们看到三组不同的动物已经独立发展了飞行能力：昆虫、鸟类和哺乳动物（蝙蝠）。 这三个群体各自遵循了不同的飞行进化路径，当前的飞行形式反映了他们祖先的飞行前形式。 以昆虫为例：祖先昆虫有外部外骨骼，其特性是密度低和层压，导致不同维度上的抗拉强度不同。 因此，昆虫在飞行方面的进化利用了可变形的翅膀——这种方法利用了现有的低密度、可变抗拉强度的构件。 另一方面，鸟类则将羽毛的进化视为其飞翔之旅的关键“技术”；在这种情况下，羽毛的出现是一个幸福的巧合，是由一组温血恐龙的需求驱动的，这些恐龙需要一种类似毛皮的材料来保暖。 后来，羽毛才被证明是实现飞行的偶然“技术”。 最后，蝙蝠是最新进化出飞行能力的群体，其进化方式是基于滑翔哺乳动物的渐进进化，但尚未享受漫长进化适应带来的好处。

对这个故事的一个有趣和值得注意的补充是，当人类最终使用机器实现实用飞行时，它采用了一套完全不同的方法 - 要么比空气升力更轻，要么由汽油发动机推动的快速移动翼型。

这很有趣，但这与边缘有什么关系？

从进化思维的角度来看，过去 20 年来应用交付所走的路径也是一个趋同进化的故事。 更具体地说，这些年来我们已经看到了多种交付技术的发展，回想起来，这些技术都是朝着应用优势迈出的最初的、新生的进化步骤。 

许多这些祖传技术的前身是内容分发网络 (CDN)。 这项技术的动机——可以说是它的“进化利基”——是需要向庞大的消费者客户群体提供大量相当静态的数据，通常是大图像和流音频/视频。 解决方案是将大型数据文件的缓存副本放置在多个地理位置分散、更靠近客户端设备的位置。 这种方法允许将交付工作负载（就计算和带宽而言）分散到单个中央数据中心之外，同时提供更低、更可预测的延迟。

如今，随着应用s的不断进步并紧密融入我们的日常生活，改善客户应用体验的需求不断推动着减少延迟和提供额外带宽的需求。 然而，基本规则已经发生改变和发展。 正如气候和地理不断推动自然的适应一样，应用交付要求的变化也推动着所需解决方案的变化。 更加现代的应用交付需求已经远远超出了基本的 CDN 场景。 当今更为复杂的用例不仅仅需要提供简单的静态内容；它们在计算和交互方面也有要求。 具有更高级需求的应用s示例是视频会议和电子交易。 更广泛地说，单页应用（SPA）范式的总体趋势是，应用由多个不同的 Web 服务的聚合组成，需要一组比单纯的静态存储更强大的分布式资源，以保持丰富的用户体验。 随着环境朝着这些新用例“发展”，我们看到多个现有的市场解决方案相应地融合，以更好地适应这个新的、利润丰厚的“进化领域”——“趋同进化”概念的技术类似物。

这些预先存在的解决方案中，第一个就是前面提到的 CDN。 他们的进化在职“优势”是他们现有的大量 CDN 节点基础设施；他们的“进化”路径是增强现有节点，从单纯关注类似缓存的存储转向提供多种存储技术（文件、数据库、对象存储）的更均衡组合，并与可以在该存储上运行的计算资源相结合。

现有市场解决方案的第二种是公共云提供商。 他们的“优势”领域是计算、存储和带宽资源的强大生态系统，以及这些资源相应的灵活消费模式。 例如，AWS 提供多种形式的数据库技术，使用基于服务器或无服务器模型提供计算，拥有一套丰富的处理身份和身份验证的技术，并提供多种辅助服务，如日志记录/报告、可视化、数据建模等。 然而，他们的“进化差距”在于他们没有像现任 CDN 供应商那样多的接入点，因此他们无法享受相同的分布广度。

接入点规模的另一端是移动服务提供商 (MSP)，尤其是在他们推出 5G 基础设施时。 大型 MSP 计划拥有数万个移动接入点，每个接入点都是核心网络的入口点。 除了分布和规模的“优势”之外，它们在这些接入点还具有计算能力和一些有限的存储能力；然而，直到最近，计算和存储的范围还仅限于 MSP 自身的基础设施需求。 因此，他们需要解决的“差距”是迁移到一种计算范式，将计算基础设施暴露给外部applications，并通过额外的存储功能进行增强。

重返飞行——以及人类为何采用不同的方法

旅程只是将地图勾勒出一个自然渐进的进化过程。 然而，有时会出现进化的“游戏规则改变者^[1]” ——一些会扰乱进化并导致对线性进程的重新评估的事物。 对于人类飞行技术的研发来说，能够快速输出大量动力的系统（例如汽油发动机）与能够制造坚固轻质合金的材料和工程技术相结合，使我们人类能够重新想象如何应对飞行的挑战，并“改变游戏规则”，以适应大自然如何发展飞行。 

将这个故事与边缘概念联系起来，到目前为止，应用交付叙述一直集中在卸载“服务器”端的工作 - 即交付链中从接收请求的服务器开始的部分。 具体而言，由于预先存在的解决方案的“进化倾向”（其价值在于减轻应用服务器的负担），重点一直隐性地集中在响应“客户端”客户请求的计算和内容交付的卸载和分配上。 

然而，现在考虑一下，当我们将这些地理上分散的接入点不仅视为用于减轻服务器负担的计算节点和缓存（“应用代理”），而且还视为同等关注传入客户端请求的控制点时，会发生什么情况，将这些请求映射到适合应用程序要求的基础设施和计算/缓存节点上。 例如，对延迟有容忍度但带宽较高的应用（如云文件备份）的路由方式可能与对低带宽、延迟敏感的应用（如在线游戏）的路由方式不同。 需要中央数据交换所的银行应用s可能会被引导至中央数据中心。 在我看来，这个概念就是“应用编排器”，一旦你认为边缘不仅仅是卸载服务器的东西，而是一个作为通用服务器/访问节点环境入口的元素，这个概念就会自然而然地出现。

让我们制造一架飞机，而不是扑翼机

正如人类最终实现了实用飞行，不是通过使用机械化的类似鸟类的方法（达芬奇著名的“扑翼机”），而是通过思考如何更好地利用手头最合适的技术——与汽油发动机相结合的机翼——我们应该思考如何随着无处不在、分布式、服务丰富的边缘的出现而重新构想应用基础设施。 随着这种新兴功能的威力变得越来越明显和越来越容易使用，应用所有者和运营商将开始应用演进之旅的下一步。 由此产生的“改变游戏规则”的事件 - 边缘的颠覆性演变，从仅仅是应用服务器的代理或类固醇的应用缓存，到成熟的应用编排器 - 将为应用生态系统带来新可能性的爆发，这将是未来文章的主题。 

展望未来的道路，我打算分享一个愿景，即如何利用边缘作为应用编排器的角色，实现对每个应用程序预期行为的声明性、意图驱动的规范，推动应用程序基础设施和应用客户体验的优化。 例如，一个应用（可能是一个强调增强现实技术的应用程序）可能会指定优先考虑延迟和带宽的策略，而一个金融应用可能优先考虑可靠性或集中化，而其他一些消费者物联网应用可能专注于运营支出管理。 更广泛地说，采用扩展边缘作用的思维方式，并将其用作应用编排器，也将边缘定位为实施安全策略和可见性的逻辑位置，实现许多应用所有者的另一个梦想 - 与基础设施无关的应用程序控制的目标。
 

^[1] 基于氧的代谢的发展就是一个很好的例子，但我必须把这个故事留到下次再讲。