介绍
边缘的定义始终与数据中心架构的演进交织在一起。 过去十年见证了企业基础设施架构的快速转型，从本地数据中心扩展到当今的分布式云架构。 我们认识到 Edge 2.0 是一项技术转变，它将使应用能够利用分布式云架构。
每个人、组织或实体对边缘都有不同的解读。 有些人可能认为边缘是手机信号塔，其他人可能说他们的移动设备就是边缘。 对于云服务提供商 (CSP) 来说，边缘是一个托管的基础设施覆盖范围，可无缝集成到其后端。 对于军事应用来说，边缘就是战场——无论是陆地、海上还是空中。 每次我们读到有关边缘的内容时，解释通常被概括为基础设施和/或其位置的计算、网络和存储能力。
但我们也将 Edge 2.0 视为向生态系统中所有利益相关者提供的体验，而不仅仅是基础设施资产或其位置。
本文档描述了 Edge 2.0 的功能，独立于其物理或虚拟基础设施，或其位置或实例化位置。 目的不是解释如何构建更好的分布式应用，而是阐明 Edge 2.0 中必须具备的功能，以支持创建适合特定要求的最优分布式应用。
什么是 Edge 2.0？
从驻留在分布式云上的实体的角度来看，边缘就是实体当前所在的位置。 因此，我们提出了以体验为中心的 Edge 2.0 的定义，而不仅仅与基础设施的位置、基础设施类型或控制实体相关。
Edge 2.0 的重点是增强以应用程序为中心、以运营为中心和以开发人员为中心的体验。 Edge 2.0 必须通过适应应用不断变化的需求来解决应用的元属性（如 SLA 和 SLO）。 Edge 2.0 必须易于操作，并减轻运营团队为每个分布式应用创建新的自动化的负担。 Edge 2.0 必须通过无缝支持安全性、治理和服务级别目标来减少开发人员在大规模开发和部署分布式应用时面临的摩擦。
让我们以一个银行应用为例。 Edge 2.0的目标不是改进交易的业务逻辑。 它是关于使其更安全、更快、更私密、可在所有地区使用（根据需要），并可根据需要向上或向下扩展以支持业务目标。
概念和断言
以下是本文的关键概念和断言：
- 以体验为中心的优势： 围绕 Edge 2.0 所提供的体验（而不是资产或其位置）建立基础。
- 设计考虑： 指定成功实施 Edge 2.0 架构的关键设计考虑因素。
- 异构基础设施： 强调分布式云的设计意味着考虑基础设施的分散控制。
- 遥测作为基础： 强调遥测是必须在基础设施的所有层面上得到支持的基本构建模块。 如果没有遥测，数据优先战略就会被削弱。
- 集群间挑战： 强调 Edge2.0 面临的基本挑战是集群间而非集群内。
- 自适应接口： 介绍自适应接口，并与声明式接口和命令式接口进行明显的比较。
- Edge 2.0应用平台 (EAP)： 引入EAP作为框架，使Edge 2.0能够适应应用的需求。
未解决的主题
本文中我们还没有讨论几个主题：
- 应用数据分布： 这里有许多子主题，如内容分发网络（CDN）、存储分布、数据分布、缓存等。 还有一些新兴技术，例如无冲突复制数据类型（CRDT）。 Edge 2.0框架应该在其范围内包括对应用数据分发的支持。
- 功能分布： 边缘计算的进步可以被认为是核心云功能和逻辑，更接近事件生成或数据所在的位置。 由于边缘处有大量计算可用，如果我们希望利用这种计算，我们现在应该解决与传统云架构中通常解决的问题类似的问题。 例如，覆盖网络、中间件工作负载和其他类型的工作负载相互交织，并且比我们在早期边缘看到的简单用例更为复杂 - 例如 storlet，它们是在数据旁边运行的无状态简单流。
- 可能还有其他领域尚未讨论。 该框架的目标是可扩展，以便可以根据需要添加职责。
边缘演进
图 1 最好地描述了 Edge 和数据中心架构的共同演进。Edge 1.0 和 1.5 基于原点的概念，将数据和服务从原点移动到消费者。 Edge 1.0 是互联网基础设施的部署，主要侧重于通过分布式内容缓存（又称内容分发网络）优化带宽使用。 CDN 是一种基本的设计模式，因为要传输的总内容总是会超过可用带宽。
随着 CPU 和内存成本的下降，计算农场与 CDN 节点一起出现。 applications通过面向服务的架构 (SOA) 作为服务被使用。 因此，Edge 1.5 被称为服务分发网络。
Edge 1.0 和 Edge 1.5 的一个共同特点是源站的概念。 在移动设备发展之前，人们、设备和事物主要都是下载内容或作为服务的消费者。 提供服务的站点与消费者的站点仍然不同。
边缘后果： 复杂性增加
计算和存储的丰富性和超分布性为企业快速实现数字化转型创造了机会。 但这种快速的演变也有其后果。
大多数企业通常由异构基础设施组成，环境不统一。 有效地扩展这样的环境需要部署系统进行复杂的编排和自动化。 应用程序需求的快速变化（例如 CPU 和带宽要求的变化）增加了分布式云中操作的复杂性。 这给运营团队增加了压力，因为他们可能没有足够的能力有效响应应用或最终客户不断变化的需求。
这些问题的后果是运营的复杂性，从而抵消了企业进行数字化转型所带来的任何潜在收益。
接下来重点介绍由于复杂性而产生的一些相互交织的问题和产物。
混合云会导致受多种攻击媒介影响的表面面积增加。 不同的用例会带来多重安全挑战，并且随着基础设施的发展，我们也在不断追逐这一挑战。 因此，我们预计的问题是：只有技术建议会经常改变，还是实现安全性的设计模式也会改变？
现有方法存在以下一些问题：
- 软件定义边界 (SDP) 不易扩展，因为流行的解决方案是基于代理的，这不利于简单的操作部署。
- 实施零信任网络访问 (ZTNA) 通常不切实际，因为 ZTNA 解决方案需要部署一系列生产服务，例如流量检查、集中日志管理、全局 PKI 和身份管理等。
- 安全访问服务边缘 (SASE) 结合了网络即服务和安全即服务，这是几种难以实现的技术的首字母缩写。 此外，SASE 的重点往往以软件定义的广域网 (SD-WAN) 为中心，解决一小部分企业网络边缘用例。
- 不同公共云提供商的基础设施和已经很复杂的安全模型（例如身份和访问权限管理(IAM)）之间的差异，常常导致团队对提供商进行拼凑式强化和繁琐的多云配置。
边缘低功耗、低成本计算的超分布所面临的主要挑战之一是以统一的方式协调和调度基础设施的能力。 运营团队在扩展和支持利用分布式云的应用方面遇到困难——因为这些应用通常包含具有不同管理要求的异构技术。
虽然 Terraform 等自动化平台提供了定制自动化的复杂方法，但运营团队仍然需要维护多种排列的脚本：例如，五种不同的计算风格、四种不同类型的防火墙和三种类型的负载均衡器。 管理和维护自动化脚本的人力成本无法扩大。
这导致基础设施客户继续通过票证驱动系统与运营团队进行互动，这对现有工作流程的自动化造成了障碍。 服务台收到的票据过多，需要优先考虑安全性和稳定性，而不是灵活性。
随着多云的演进，微服务架构已经成为构建新应用的实际方法。 API 被发布并且可以在需要的任何时间和地点被实例化，从而导致 API 蔓延。 以自主的方式发现、连接和管理这些 API 成为一个巨大的挑战。
解决 API 蔓延问题需要模式转变。 我们的内部模型表明，即使对参数进行适度假设，例如全球 API 开发人员的数量、每个开发人员每年开发的 API 数量以及 API 保质期，到 2030 年也将有数亿（甚至数十亿）个 API 同时活跃（图 2）。 2021 年 API Sprawl 报告对这一新兴主题提供了全面的介绍。
复杂性的增加要求企业实现端到端系统的细粒度且有意义的端到端可视性。 在分布式云环境中，应用超越由独立实体管理的多个异构基础设施堆栈。
此外，目前没有任何运营商愿意向企业客户公开其基础设施的本地遥测数据。 企业在分布式云中部署应用时本质上是盲目运行，需要借助多种可观察性工具。 为了填补这些可见性空白，工具通常来自不同的供应商公司，在基础设施或应用堆栈的不同点工作。
非标准的基础设施指标增加了企业内部的困境。 通常，由于运营孤岛以及不同基础设施环境中的基础设施不统一等因素，指标并不统一。 例如，不同公共云提供商的指标不同，并且内部数据中心技术也不遵循任何标准指标。
业务成果： 体验减弱
创收工作负载和关键任务系统通常会利用企业的大部分运营资源和预算。 与此同时，规模较小的项目，虽然复杂度较低，但往往构成企业应用的总量。 图 3 将此描绘为企业可能拥有的项目数量与其运营复杂性之间的长尾分布。
虽然较小的应用的操作复杂性可能较低，但操作流程和工作流程在许多情况下仍然是手动的，服务票可能需要数周时间才能成功传递到多个运营团队。 例如，部署需要具有细粒度安全策略的专用网络资源的应用可能首先需要全球安全团队制定安全策略批准。 然后，服务票可能会发送给网络团队，以规划需要进行的子网和路由配置。 最后，可能需要另一个负责防火墙管理的运营团队来验证防火墙规则。
现在让我们想象一下，对于部署在分布式云上的每个应用，都需要解决上述复杂性，而企业不拥有任何底层基础设施。 需要加入和支持的小型项目或应用数量庞大，使得运营团队无法支持每个项目，从而产生了优先级问题和自助服务机会。
这个优先级问题尤其引人注目，因为基础设施团队的投资集中在支持关键和创收系统上，而几乎没有时间或预算用于涉及生产前开发、测试和准备生命周期的净新项目。 这导致功能速度、定制化和支持新产品的创新方面的能力和投资减少，最终导致业务及其产品的停滞。
边缘解决方案空间
边缘生态系统的演变通过提供利用应用平台应对这些挑战的机会，极大地扩展了解决方案空间。
图 4 展示了 Edge 2.0 解决方案空间。 这里我们声明，分布式云架构下的所有内容都是解决方案空间的全部。
因此，在解决方案空间的背景下，Edge 2.0 必须提供以下所有内容所需的体验：
- 解决方案范围内的所有实体 - 充当消费者的应用程序、人员和设备，或构成服务的 Web 后端和无头应用。
- 这些应用程序的 SRE 团队和应用所有者，同时保留基础设施所期望的安全和监管护栏。
Edge 2.0 将在操作上简单、安全、合规，并为参与其中的所有生态系统实体提供高质量的体验。
Edge 2.0 设计注意事项
默认安全
随着端点数量呈指数级增长，分布式云会放大这种大规模安全问题。 由于规模如此庞大，实施解决方案的复杂性也会随之增加。 安全态势应该是，应用假定其当前部署的环境已经受到了损害。 同样，基础设施不应信任在其中运行的任何应用。
这些想法的基础体现在零信任思维的概念中，而 BeyondCorp1 示例针对应用访问的用例展示了这些概念。 展望未来，Edge 2.0 将基于以下五个核心原则扩展此模型：
- 身份是基础： 在 Edge 2.0 中，身份根深蒂固，每个实体实例都有自己的全局唯一身份，而且也有其在组织层次结构中的位置及其特权级别。 身份不仅应该是南北交通的一个关键考虑因素，而且也是内部东西向访问的一个关键考虑因素。
- 最小权限： 参与者允许的行为应该仅限于参与者在系统中履行其角色所需的行为。 一个例子是，根据设计规范限制允许与数据库服务器通信的工作负载子集。
- 持续身份验证： 系统参与者做出的任何证明都必须有验证手段，并且每次发生此类证明时都应明确进行验证。 身份验证不应仅通过共享秘密或信任链来明确，还应考虑隐含的行为模式和上下文元数据。
- 持续监测和评估： 必须监控系统中所有参与者的行为，从而强化数据收集和仓储技术在 Edge 2.0 架构中的关键作用。 此外，必须不断评估这些活动，以发现并减轻执行禁止或危险行为的企图。 评估必须接近实时、大规模，这意味着需要大量使用自动化和机器学习技术。
- 假设违反： 考虑到当今狡猾对手所掌握的资源，我们必须承认任何系统都已经以某种方式受到了损害。 因此，完全基于工作量和用户身份的确定性策略（强制执行由 a 和 b 表示的基于特权的访问）通常不足以防止所有攻击。 因此，完全成熟的Edge 2.0系统还必须能够基于持续的监控和评估做出实时的风险/回报评估。
提供原生可观察性
Edge 2.0 必须将遥测作为一等公民融入基础设施堆栈深处，提供一种简单且可扩展的方法来收集基础设施内的跨层遥测，并将其呈现到一个通用平台上。 这有助于可观察性团队根据需要询问“基础设施状态”。 这使得应用团队可以专注于业务逻辑，而无需明确地检测他们的应用堆栈。
当前的可观察性技术基本上是供应商特定的和专有的。 这导致许多特定于供应商的代理收集类似的信号，争夺昂贵的内存和 CPU。
下一个合乎逻辑的步骤是使用与供应商无关的遥测收集器，以便将基础设施和流量数据传输到集中式数据平台。
许多产品团队努力证明对仪器仪表的投资是合理的，因为这种努力需要与创收机会相对应。 基础设施应该像任何其他业务功能或流程一样进行检测，因为团队需要了解其行为以便针对业务目标进行优化。 因此，辩论应该更多地集中在应优先考虑什么工具，而不是其必要性。
为了实现对应用行为的更细致和更准确的测量，我们预计仪器将通过在代码执行时调用它来“左移” - 图 5。
支持自适应接口
为了与分布式云保持一致，在其范围内（本地或全局）的每个云下剥离几层，都有自己的管理器、管理员、编排器等。 每个实体都独立运作，做出自己的决定，但会根据需要为其他实体提供接口。
因此，分布式云的概念本质上是分散的管理和控制。 我们无法逃避这个事实，认识到这一点对于我们更好地理解自适应与声明性和命令性接口的细微差别非常重要。
为了有效利用 Edge 2.0 基础设施，命令式和声明式接口是不够的，因为它们仍然依赖于手工制作的工件，而这些工件本质上是静态构造，不能足够快地适应快速变化的条件。
我们需要以结果为导向，并且系统需要足够智能，能够调整整个基础设施（端到端）的策略以满足这些结果。 我们称之为自适应接口。
需要明确的是，命令式、声明式和自适应接口并不互相排斥：
至关重要的： 变得非常规范，并详细定义了一系列操作以达到所需状态。 例如，路由器的配置是一项必要的操作。 在上述场景中，规定的行动将是精确的——哪个数据中心、多少 CPU/内存、所需带宽、具体路线等等。 数据模型的输入质量非常高，因此需要对基础设施有更深入的了解和专业知识。 人们期望了解基础设施的模型和结构。
声明式： 声明的细微差别在于它侧重于描述期望状态，而不是实现期望状态的操作。 尽管它仍然要求应用至少了解底层基础设施的结构，但输入的质量较低。
自适应： 与命令式或声明式不同。 自适应界面关注的是期望的目的或目标，而不是状态。 自适应界面的目标是捕捉想要部署应用的利益相关者的目标，而不是关注底层系统的预先知识。 自适应则有所不同，因为它不知道底层基础设施的功能是什么。 对于如何“完成工作”没有任何限制，因此，它是独立的。
自适应时，输入的质量较低，接近自然语言。 application所有者可以发送请求来告诉基础设施控制器他们期望的结果，而不需要声明所需的功能或专门配置资源。
解决集群间问题
根据定义，分布式云可容纳所有类型的应用架构：单片架构、微服务架构或无服务器架构。 无论架构如何，应用都使用 API 来提供服务。
API 发现、连接性和网络安全问题主要通过使用服务网格来解决，但服务网格仅在集群内部（集群内）解决这些问题。
另一方面，Edge 2.0应用利用超分布式云基础设施（本质上是多集群环境）中的 API。 新应用使用跨越组织和地理界限的 API 编写。 某些 API 可能是私有的，或者是位于多层防火墙后面的合作伙伴 API，它们之间没有明确的路由，即使它们是可发现的。 这个异构集群（集群间）问题目前还没有一个优雅、轻量、可扩展、安全的实用解决方案。
| 场景/属性 | 至关重要的 | 声明式 | 自适应 |
|---|---|---|---|
| 定义 | 命令式接口根据底层资源的具体能力来定义详细的控制流。 |
声明式接口定义逻辑但不定义控制流。 从程序化的说法来看，它是伪代码。 |
自适应接口将期望状态表达为一种需求，而不对底层资源的能力做出任何假设。 自适应接口由基础设施拥有，使基础设施能够动态地响应应用不断变化的需求。 |
场景 1： 包裹需要从旧金山国际机场寄往纽约 |
Jane 告诉 Mark：(a) 打印发货标签，(b) 前往 UPS 商店，(c) 选择 72 小时送货，(d) 付款并发货 标记： 必须遵循一套非常具体的步骤 |
简要求马克：（a）请将此包裹快递到此地址，（b）包裹必须在 72 小时内到达。 标记： 可以选择任何快递公司（UPS、FedEx、DHL等）。 |
Jane 向 Mark 表示：(a) 这个包裹必须在星期六之前到达纽约。 标记： 可以做任何他喜欢的事。 甚至可能亲自拿着包裹，飞到纽约，然后亲手递送。 |
场景 2： 负载均衡器示例 |
负载均衡器已存在。 任务：需要配置此策略。 这里的任务特定于负载均衡器的品牌、型号、版本等。 |
负载均衡器不存在。 任务：使用给定的开放策略对应用进行负载平衡。 任务假设一个业务流程 |
不对底层基础设施做任何假设。 请确保应用程序根据需要扩展，最大延迟为 10 毫秒。 |
所有权 |
共同所有权：应用和基础设施 |
共同所有权：应用和基础设施 |
只有基础设施 |
输入质量 |
非常高。 需要对底层范围有深入的了解。 例如，需要知道哪个 F5 负载均衡器、哪个软件版本等。 CLI 或 NMS 是命令式接口的一个例子。 |
高的： 需要了解基础设施的功能。 例如，在上面的例子中，需要预先了解支持负载均衡器的基础设施。 |
低的： 不需要了解基础设施的功能。 输入质量接近自然语言等效。 |
技能等级（角色） |
特定功能技能。 例如，网络管理员、计算管理员、存储管理员。基础设施的每个方面都要求用户是该领域的专家。 |
应用部署技能。 用户知道部署应用所需的功能类型。 与上述情况一样，应用管理器知道需要一个负载均衡器，并且必须配置 LB 以支持自动扩展的高级策略。 |
应用工程师。 可以向基础设施发出信号，告知应用的非功能性需求是什么。 在这种情况下，应用应该多快响应客户请求。 可以根据需要添加其他因素，如地理位置、成本等。 |
范围 |
命令式接口有 |
申明范围较大。 通常，与编排引擎相关联，该编排引擎与多个命令式接口对话以实现所需的结果。 |
范围非常大，因为 |
例子 |
- 名称：更新 Web 服务器 主机：Web 服务器 远程用户：root 任务： - 名称：确保 apache 为 最新版本 yum： 名称：httpd 状态：最新 - 名称：编写 apache 配置文件 模板： 源：/srv/httpd.j2 目标：/etc/httpd.conf |
apache-server: 版本：“最新” |
应用程序延迟： - lt： 10ms 基础设施成本： - lt：200 美元 - 计费：每月 |
我们在 2021 年 API Sprawl 报告 2 中广泛介绍了 API，并解决了其中可能出现的许多问题。 图6展示了簇间和簇内的差异。
集群内： 在单片架构中，可能只有很少的 API 通过其他进程间通信方法在模块之间进行内部通信来暴露。 而微服务架构则分解为数十个甚至数百个 API。
无论如何，每个应用集群都是以自己的方式开发和管理的。 例如，在微服务架构的情况下，团队可能会使用任何类型的服务网格 - Istio，Linkerd，Aspen Mesh 或其他。 每种方法都有自己的方法来管理和控制其集群内（换句话说，集群内）的 API。
这里有很多解决方案，而 Edge 2.0 的目标不是重新发明或强迫组织或开发团队采用另一项新技术。
集群间： 随着通过 API 交付的服务数量的增加，新的应用可以使用企业内不同应用团队已经开发或采用的服务来构建，因为无需重新发明轮子。
新的应用也正在通过公共和私有 API 的不同组合来构建。 从架构的角度来看，现代应用利用其他集群提供的服务。 在分布式云中，这些集群是全球部署的，因此可以位于任何可以托管应用或成为应用集群一部分的空间上。
需要重申的是，应用集群的范围并不仅限于组织内部。 集群可以跨越任意两个网络、应用、组织孤岛，甚至两个企业之间。
范围涵盖了所有排列组合的全部范围，从而成倍增加了操作的复杂性。 图7显示了应用部署范围内的流量排列。
实现自主权
云计算的一个被低估的价值是它为“云消费者”提供的自主性。 企业和企业家可以按需实例化自己的基础设施，同时体验完全控制的感觉。
Edge 2.0 平台必须遵循的基本设计原则是实施正确的保护措施，同时为云客户提供自主体验。 由于实体可以出现在任何基础设施（受信任或不受信任）中，因此必须以适当的方式实施防护栏，以免给负责构建应用的 BU 或 DevOps 团队带来负担。
Edge 2.0 面临的新挑战是各种服务之间的发现、身份、信任和可观察性。
即使是中型企业，每年生产的 API 数量也会很大。 团队如何在企业内发现这些服务？ 或者就此而言，他们如何知道这些服务是否仍然有效以及谁拥有它？ 他们能否确定这是一项经过验证且值得信赖的服务？ 当团队想要使用企业边界之外的集群创建的服务时，问题就会变得更加复杂，例如，SaaS 提供商或在边缘设备上运行的应用程序完全不受企业基础设施团队的管理控制。
Edge 2.0application平台
考虑到前面章节提出的挑战，我们需要将整个分布式云视为一个平台。 在最高层面上，我们阐明了解决方案的目标：在分散的基础设施中自主发现（无需人工干预）、扩展和保护分布式应用。
本质上，我们可以这样描述 Edge 2.0application平台 (EAP) 的职责：
- API 发现、身份和信任
- 基础设施调度和编排
- 安全的应用连接
EAP 范围
基础设施是解决方案空间的总和，其中基础设施元素可以不断出现和消失。 基础设施及其资源的所有权与这些资源的管理和控制是两个独立的结构。 基础设施所有者可以将特定的基础设施或其实例分配给管理和配置它的不同组织，或者基础设施所有者可以根据需要收回控制权。 管理和配置元素的组织可以进一步将其分配给单个项目或应用。 这个概念并不新鲜；例如，云服务提供商提供分层管理控制，企业的 IT 团队可以使用它进一步向内部业务部门、团队等提供基础设施即服务 (IaaS)。 Edge 2.0 主要关注点是如何在超分布式云中广泛实现这一点，这是边缘基础设施的当前和未来状态。
这就是 EAP 的范围。 下图 8 显示了不同类型接口环境中 EAP 的范围。 每个 EAP 使用声明性和命令性接口与其本地范围进行协调。 在此例中：
- 声明式/命令式将是 AWS API、Azure API 等。
- 自适应接口是全新的，必须根据具体情况进行定义。
为了利用分布式云，EAP 应该能够利用分布式云中可用的所有节点和实体。 我们的愿景是让单个 EAP 等同于 IP 网络中的自治系统3概念，但适用于应用层。
把它们放在一起（如下图 9），我们现在可以构建一个高级视图，了解如何在分散的云基础设施上部署多个 EAP，并以自主的方式相互交互。
自适应接口还使 CI/CD 和其他应用生命周期应用程序可以轻松地与分布式云集成。 CI/CD 平台可以直接与 EAP 交互，使用简单的自适应接口仅说明期望的结果。
值得注意的是，EAP 间通信也可以通过自适应接口实现。
EAP 框架
EAP 框架如图 10 所示，根据每个 EAP 实例的功能来组织职责。 EAP 的作用是与底层基础设施控制器（基础设施即服务 (IaaS)、平台即服务 (PaaS)、软件即服务 (SaaS)）进行交互，并根据需要协调和安排适当的资源。
统一 API 控制和管理
未来将是一个由 API 驱动的经济，其中 API 不仅仅是一种通过服务网格简化的软件架构方法。 API 将成为参与分布式云的任何实体提供服务的主要手段。
根据既定数据，十年内全球可用的公共和私有 API 数量将达到数亿甚至数十亿。 API 将重塑我们的经济，因此我们要求更仔细地研究 EAP 必须实施哪些措施来支持我们的经济。
日益严重的 API 蔓延要求每个 API 都必须可以在 EAP 内部和外部被发现。 通过分布式云，API 可以位于多个集群的任何地方。
潜在的假设是 API 发现问题确实是一个集群间问题。 EAP 的范围可能跨越许多使用不同软件方法（微服务到单片）的应用集群，每个集群都实现自己的 API 网关策略。 EAP 为所有在其范围内注册和发现的 API 提供了一个通用存储库，而不仅仅是在集群内。 这种区别是推导现有 API 网关策略（例如服务网格）的局限性的关键。
EAP 面临的挑战是能够发现 API、提供有关其使用的正确文档，并管理 API 的生命周期以确保一致性、准确性和版本控制。 EAP 实现了一种方法，用于通知使用其 API 的实体正在使用的特定 API 的当前状态。 这可以简单地通过设置到期日期或通过某些消息系统明确通知来实现。
所采用的安全态势是应用假定其当前部署的基础设施已经受到损害。
实现这一安全态势的关键支柱是身份驱动。 每个 API 端点必须具有全局唯一的标识。 安全策略和控制在中央存储库中单独维护。
API 必须标记为公共或私有，从而触发底层基础设施安全组件为特定 API 自动配置。
所有应用程序与应用程序之间的对话均以拒绝所有策略开始。 仅仅因为 API 可见并不意味着另一个应用可以调用它。 这必须在应用的安全策略中明确配置。
EAP 必须确保其范围内的所有 API 都是可信的，同时其范围内的服务所使用的所有外部 API 也是可信的。
“你无法证明信任，这就是‘信任’的由来”——来自 Netflix 的《叛徒》
信任本质上是“随着时间的推移的声誉”，您必须不断地重新验证这种信任以确保它没有跌破可接受的水平。 这越来越成为在系统中建模和实现信任的常用方法，要求持续评估信任，而不是在初始执行时静态地断言。
随着时间的推移，信任的流动性可能会对一些没有时间在自己和第三方系统之间建立相互声誉的企业构成挑战。 如果不密切关注声誉，基础设施和 API 都可能造成严重破坏。
假设 EAP 范围内的服务访问外部 API，平台必须实现一种机制，以便调用服务能够确保从外部 API 收到的响应的准确性。仅仅因为 API 响应看起来有效，并不意味着它是可信的。 要么是由于质量问题导致响应不准确，要么是明确插入不准确信息以降低业务竞争力。 具有为每个 API（内部或外部）分配信任因素的能力是 EAP 构造所独有的。
实现信任的一个策略是取最近“时间段”的平均值，而不是服务的完整历史记录。 这就像查看亚马逊上某个产品的“热门评论”与“最新评论”一样。 该产品可能有四颗星，但如果大多数负面评价都出现在过去六个月，这表明最近信任度已经下降，而过去六个月大量涌入正面评论则表明信任度得到修复或重建。
信任因素不仅仅取决于 API 是否是已知的虚假或误导数据来源。 EAP 的声誉还取决于它如何管理和更新其范围内的 API。 另外，“信任”也是相对的。 服务 A 可以信任服务 C，但服务 B 可能与服务 C 有不同的体验。
边缘基础设施经理
由于分布式云是 Edge 2.0 基础设施的基础，因此必须易于发现、保护和检测 EAP 范围内的资源。 以下内容可以理解为边缘基础设施管理员能力所需的一组建议。
在 EAP 中，资源可以根据需要进行安排。 由于移动性，新资源可能会动态地到达或离开。 EAP 还可以发送或接收来自其他 EAP 的请求，以代表其根据需要发现和安排资源。
重申安全态势：部署应用的基础设施已经受到了损害。 因此，EAP 必须确保其范围内部署的应用的安全性。
无论行政级别如何，EAP 框架都必须考虑安全的多个方面，例如（但不限于）：
外部威胁： 例如分布式拒绝服务 (DDoS) 攻击和高级持续性威胁 (APT)。 可以使用现有的安全最佳实践（如 DDoS 预防、防火墙等）来缓解这些问题。 建议所有流量都需要它。
中间人： 所有流量都必须加密，并且不能假设应用层会做正确的事情。 这可确保基本数据不受任何流量监视设备的影响，并保护数据完整性在传输过程中不被操纵。
内部威胁： 基础设施层的范围必须受到限制并且主要用于保护自身。 建议是为了防止基础设施内的资源对基础设施管理器发起内部攻击。
如果 Edge 2.0 关注的是它所提供的体验而不是资产或其位置，那么遥测自然也必须以体验为中心。
问题是，我们指的是谁的经验？ 这种体验指的是任何驻留在基础设施中或使用基础设施来生产或消费服务的实体：应用程序、设备、人员、后端应用、数据库等。 因此，经验的观点是实体的观点。 实体生产或消费的服务与分配给它的计算、存储和网络资源直接相关。
但我们不能仅仅停留在衡量经验上；还必须有一种补救方法。
任何消费或提供服务的实体都可以确定它是否获得了其所要求的体验。 然而，在分布式云环境中，几乎不可能解释基础设施层发生了什么，导致了糟糕的体验。
CPU 利用率、内存、带宽和延迟测量等高级指标不足以确定应用未获得所请求的3体验的原因。 指标需要具有时间粒度，并在应用堆栈深处收集，并在基础设施堆栈的不同层随时可用。
强大、可扩展且能延伸的遥测和数据策略对于 EAP 至关重要。 然后可以利用机器学习 (ML) 和人工智能(AI) 策略来做出保留新资源或优化现有资源使用的最佳决策。
软件定义application连接
尽管连接性和可达性被认为是已经解决的问题，但许多网络团队仍然在努力根据应用层的动态需求合理化其网络结构。 平台也必须应对这些挑战。
现有方法的问题在于我们将应用连接需求转化为企业 WAN 连接，尤其是在分布式云中。 解决分布式云网络的方法可以使用不同的 SDN 策略或纯基于路由的方法。 但这些解决方案严重依赖基础设施的同质性，因此无法提供一致的行为。
为应用实现全球可扩展、安全和稳定的网络的唯一方法是将应用连接平面与底层网络分离，如下所述。
在向分布式云架构演进的过程中，新兴的 SDN 模式将联合协调底层网络和覆盖网络，并实现应用路径的端到端可编程性。
自适应界面模型
EAP 的关键原则是它独立、自主，并管理整体解决方案空间的子集。 但是 EAP 需要一种沟通方式来提供他们的资源或者向其他 EAP 请求资源。 这种方法有几个优点。
基于结果的接口使得 EAP 不再需要了解其他基础设施的详细信息。 假设有两个 EAP： A 和 B。每个 EAP 都有其基础设施的本地范围来调度和预留资源。 EAP-A不需要知道EAP-B提供的资源。 例如，如果 EAP-A 不能满足应用的需求，并且需要 EAP-B 范围内的基础设施资源，那么它可以简单地向 EAP-B 表达其期望目标。 然后，EAP-B 负责调用声明性或命令性接口来从其空闲资源池中进行保留、分配和配置。 EAP-B 还负责确保满足其基础设施内该服务的 SLO。
虽然通用语法有助于引导初始的自适应 API 集，但随着时间的推移，通过使用自然语言处理和人工智能来降低所需的输入质量，实现会变得更加复杂和成熟。
EAP 功能
- 多租户： 虽然图 9 中显示的 EAP 网格适用于单一部署，但每个云可以有多个 EAP。 另一个应用可以与不同的 EAP 或 EAP 网格对话。
- 设计规模： 每个网格都是一个对等 (P2P) 网格，并且可以水平扩展。 对等 EAP 可以独立跟踪哪些 EAP 具有哪些资源类型以及如何连接到资源。 AI/ML 将进一步增强每个 EAP 在其自身范围内安排资源或根据需要联系其他 EAP 的方式。
- 内置网络： 为了使应用能够跨分布式云进行连接，EAP 必须支持与底层基础设施无关的内置网络。
整合起来
图 12 直观地展示了在分布式云上部署应用时不同层的作用。
此次表彰的亮点如下：
- 每个 EAP 阶段都有一个本地化范围，图 10 并未标明其所有功能。 EAP必须支持资源发现和调度功能。 EAP 通过自适应 API 与适当的基础设施控制器交互来调度资源。
- 应用连接不同于网络连接——与服务网格边车模型一样，跨多云连接应用的资源必须是应用基础设施的一部分。 有人可能会说基础设施平面也提供应用网络连接，因此应该位于网络层之下。 从技术上来说这也是正确的，但是我们选择将其纳入“应用连接”平面，因为它们主要是网络功能。
- 基础设施层面必须被视为与应用层面分离。
- 网络连接不同于传输，因为我们本质上谈论的是与应用连接分开的特定可路由网络。
- 传输平面可以被视为可配置的聚合骨干网络，只要电信提供商启用流程和 API 来连接上方的网络层。
概括
本白皮书试图对原始 Edge 2.0 宣言进行更深入的阐释。 我们引入了一些新的主题，目的是向组织内部和行业外部的不同利益相关者提供信息。
Edge 2.0 建立在分布式云的概念之上，其中每个实体都可以作为服务的源以及目的地参与。 主要主题是 Edge 2.0 将关注体验而不是资产或位置。
边缘应用平台 (EAP) 作为功能堆栈引入，使 Edge 2.0 能够在分布式云上实现。
我们故意跳过了实施细节以呈现与供应商无关的观点。
资源
2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf
3 维基百科- 自治系统 (AS) 是一组连接的互联网协议 (IP) 路由前缀，由一个或多个网络运营商代表单个管理实体或域进行控制，为互联网提供通用的、明确定义的路由策略。