Edge 2.0核心原则

作者：Rajesh Narayanan、Michael Wiley

简介

边缘的定义始终与数据中心架构的演进密不可分。过去十年间，企业基础设施架构迅速转型，从本地数据中心扩展到如今的分布式云架构。我们认为，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必须适应应用不断变化的需求，以满足应用的元属性要求（如服务级别协议和服务级别目标）。Edge 2.0必须易于运维，让运维团队无需为每个分布式应用创建新的自动化流程。Edge 2.0必须无缝支持安全、治理和服务级别目标，减少开发者大规模开发和部署分布式应用时遇到的阻碍。

以银行应用为例。Edge 2.0的目标并非改进交易的业务逻辑，而是提高其安全性、速度和隐私保护能力，使其可按需在各个地区使用，并可根据需要扩缩容，从而支持业务目标。

概念与断言

以下是本文的关键概念和论点：

• 以体验为中心的边缘：以其交付的体验为核心，为Edge 2.0奠定基础，而非以资产或资产所在位置为核心。
• 设计注意事项：明确成功实施Edge 2.0架构时需要考虑的关键设计因素。
• 异构基础设施：强调在设计分布式云时，需要考虑对基础设施进行分散控制。
• 以遥测为基础：强调遥测是一项基础构建要素，必须在基础设施的所有层面得到支持。缺少遥测，以数据为先的战略将难以充分发挥作用。
• 集群间挑战：强调Edge2.0面临的一项根本挑战，即它涉及集群间通信，而非集群内通信。
• 自适应接口：介绍自适应接口，并将其与声明式接口和命令式接口进行明确对比。
• Edge 2.0 Application Platform (EAP)：介绍EAP如何作为一个框架，使Edge 2.0能够适应应用需求。

未涉及的主题

本文尚未讨论以下几个主题：

• 应用数据分发：这一主题涵盖许多子主题，例如内容分发网络（CDN）、存储分发、数据分发和缓存等。此外，还有无冲突复制数据类型（CRDT）等新兴技术。Edge 2.0框架的范围应包括对应用数据分发的支持。
• 功能分布：边缘计算的发展可以理解为将核心云功能和逻辑迁移到更靠近事件发生位置或数据所在位置的地方。要充分利用边缘侧日益丰富的计算资源，就需要解决通常由传统云架构处理的类似问题。例如，覆盖网络、中间件工作负载及其他类型的工作负载相互交织，其复杂程度高于早期边缘计算中的简单用例，例如storlet，即在数据附近运行的无状态简单流程。
• 可能还有其他未讨论的领域。该框架旨在具备可扩展性，以便根据需要添加相应职责。

边缘演进

图1清晰展示了边缘架构与数据中心架构的协同演进。Edge 1.0和1.5以源站为基础，将数据和服务从源站移至消费者附近。Edge 1.0主要部署互联网基础设施，通过分布式内容缓存（即内容分发网络）优化带宽使用。由于需要传输的内容总量始终会超过可用带宽，CDN已成为一种基础设计模式。

随着CPU和内存成本迅速下降，计算集群与CDN节点应运而生。应用通过面向服务的架构（SOA）以服务形式提供。因此，Edge 1.5也称为服务分发网络。

Edge 1.0和Edge 1.5的一个共同特征是都采用源站这一概念。在移动技术兴起之前，人员、设备和物体主要下载内容或使用服务。提供服务的源站与使用服务的一端仍然彼此分离。

图1：边缘与基础设施的协同演进

然而，在Edge 2.0中，任何实体都可以充当源站或消费者。流量模式已经发生变化。人、手机和设备在上传内容或定期生成数据时，都会主动产生数据。应用依赖其他应用，因此也逐渐成为消费者。所有实体都可以充当服务的生产者或消费者，包括API、人、IoT设备，以及Web应用、后端应用和无头应用。从各自的视角来看，基础设施上的每个实体都认为自己位于边缘。

分布式云是数据中心演进的最新阶段。计算已真正无处不在，从移动设备延伸到接入网络的各种日常物品。软件架构也随之演进，为分布式、可扩展的应用提供支持。

边缘计算的影响：复杂性增加

无处不在且高度分布的计算和存储资源，为企业快速推进数字化转型创造了机遇。但这种快速演进也带来了相应影响。

大多数企业通常采用异构基础设施，环境并不统一。要有效扩展此类环境，已部署的系统需要具备复杂的编排和自动化能力。应用需求的快速变化（例如CPU和带宽要求的变化）会增加分布式云中的运维复杂性。这给运维团队带来了压力，而他们可能尚不具备高效响应应用或最终客户需求变化的充分能力。

这些问题会导致运营复杂性增加，抵消企业在数字化转型过程中可能获得的任何收益。

下面重点介绍复杂性所导致的一些相互关联的问题和产物。

安全模型需要持续跟上变化

混合云扩大了可能遭受攻击的范围，多种攻击途径都可能导致其被攻破。不同的用例会带来多重安全挑战；随着基础设施不断演进，我们也必须持续跟进。因此，我们预见的问题是：频繁变化的只是技术建议，还是用于实施安全措施的设计模式也会随之变化？

现有方法存在以下一些问题：

• 软件定义边界（SDP）难以轻松扩展，因为常见解决方案基于代理，不利于简化运维部署。
• 实施零信任网络访问（ZTNA）通常并不切实际，因为ZTNA解决方案需要部署一系列生产服务，例如流量检查、集中式日志管理、全局公钥基础设施（PKI）和身份管理等。
• 安全访问服务边缘（SASE）融合了网络即服务和安全即服务等多项技术，涉及多个缩略语，实施起来并不简单。此外，SASE通常以软件定义广域网（SD-WAN）为核心，仅能满足企业网络边缘的一小部分用例。
• 不同公有云提供商的基础设施存在差异，加之身份和访问管理（IAM）等安全模型本就复杂，往往导致团队只能零散地加固各提供商的环境，并采用繁琐的多云配置。

自动化挑战

边缘侧可用的低功耗、低成本计算资源高度分散，主要挑战之一是如何以统一方式编排和调度基础设施。利用分布式云的应用通常包含管理要求各异的异构技术，因此运维团队难以扩展和支持此类应用。

尽管Terraform等自动化平台提供了成熟的自动化定制方式，运维团队仍需维护适用于多种组合的脚本，例如5种不同的计算环境、4种不同类型的防火墙和3种负载均衡器。管理和维护这些自动化脚本所需的人力成本难以随规模扩展。

这导致基础设施客户仍需通过工单系统与运维团队持续沟通，阻碍了现有工作流的自动化。服务台因工单过多而不堪重负，不得不优先保障安全性和稳定性，而非敏捷性。

API泛滥

随着多云架构不断发展，微服务架构已成为构建新应用的主流方式。API发布后可随时随地按需实例化，导致API蔓延。如何以自主方式发现、连接和管理这些API，已成为一项重大挑战。

要解决API蔓延问题，需要转变思路。我们的内部模型表明，即使对全球API开发人员数量、每位开发人员每年开发的API数量以及API生命周期等参数作出适度假设，到2030年，同时处于活跃状态的API也将达到数亿个，甚至数十亿个（图2）。《2021年API蔓延报告》全面介绍了这一新兴主题。

端到端系统可见性不足

随着复杂性增加，企业需要实现对整个系统精细且有意义的端到端可见性。在分布式云环境中，应用跨越由不同实体分别管理的多个异构基础设施堆栈。

图2：未来10年API增长预估

此外，目前没有任何运营商有动力向企业客户开放其基础设施的原生遥测数据。企业在分布式云中部署应用时，基本上无法掌握运行状况，只能借助多种可观测性工具来弥补这些可见性缺口。这些工具通常来自不同的供应商，分别作用于基础设施或应用堆栈的不同环节。

非标准化的基础设施指标进一步加剧了企业面临的难题。由于运营孤岛，以及不同基础设施环境中的基础设施不统一等因素，这些指标通常无法统一。例如，各公有云提供商采用的指标各不相同，本地数据中心技术也不遵循任何统一的指标标准。

业务结果：体验下降

创收型工作负载和任务关键型系统通常会占用企业的大部分可用运维资源和预算。与此同时，规模较小的项目虽然复杂度较低，但往往在企业应用中占据多数。图3以长尾分布展示了企业可能拥有的项目数量与其运维复杂度之间的关系。

虽然较小型应用的运维复杂性可能较低，但其投产流程和工作流在许多情况下仍依赖人工处理，服务工单可能需要数周才能顺利流转至多个运维团队。例如，部署需要专用网络资源和精细安全策略的应用时，可能首先需要由全球安全团队完成安全策略审批。随后，服务工单可能会转交网络团队，由其规划所需的子网和路由配置。最后，可能还需要由负责防火墙管理的另一个运维团队验证防火墙规则。

现在设想一下：对于部署在分布式云上的每个应用，都需要应对上述复杂性，而企业并不拥有任何底层基础设施。需要接入和支持的小型项目或应用数量庞大，运营团队难以为每个项目提供支持，因此既需要确定优先级，也为自助服务创造了机会。

图3：项目规模与部署复杂度的分布

这一优先级问题尤为突出：基础设施团队将投入集中在支持关键系统和创收系统上，几乎没有时间或预算用于全新项目，而这些项目在投入生产前还需经历开发、测试和预发布等完整生命周期。因此，团队在加快功能交付、自定义以及支持新产品的创新方面能力和投入不足，最终导致业务及其产品与服务停滞不前。

边缘解决方案领域

边缘生态系统的演进为利用应用平台应对这些挑战创造了机会，从而大幅拓展了解决方案空间。

图4展示了Edge 2.0解决方案空间。这里所说的解决方案空间，是指分布式云架构涵盖的全部内容。

因此，在这一解决方案空间中，Edge 2.0必须为以下各方提供符合其期望的体验：

• 解决方案范围内的所有实体，包括作为使用方的应用、人员和设备，以及构成服务的Web后端和无头应用。
• 这些应用的SRE团队和应用所有者，同时保留基础设施应具备的安全与监管防护机制。

图4：Edge 2.0解决方案空间

Edge 2.0将易于运维、安全且合规，并为参与其中的所有生态系统实体提供高质量体验。

Edge 2.0设计注意事项

默认安全

随着端点数量呈指数级增长，分布式云会加剧大规模安全问题。在如此庞大的规模下，解决方案的实施复杂性也会随之增加。应采取这样的安全策略：应用假定其当前部署环境已遭入侵。同样，基础设施不得信任其中运行的任何应用。

这些理念以零信任思维为基础，BeyondCorp1范例展示了如何将其应用于应用访问用例。展望未来，Edge 2.0将基于以下五项核心原则扩展这一模型：

1. 身份是基础：在Edge 2.0中，身份贯穿各个层面。每个实体实例不仅拥有自己的全局唯一身份，还在组织层级中具有相应位置和权限级别。身份不仅应是南北向流量的关键考量因素，也应是内部东西向访问的关键考量因素。
2. 最小权限：应将主体可执行的操作限制为其在系统中履行自身角色所必需的操作。例如，根据设计规范，仅允许部分工作负载与数据库服务器通信。
3. 持续身份验证：系统参与者作出的任何声明都必须有相应的验证方式，并且每次作出此类声明时都应进行明确验证。身份验证不应仅通过共享密钥或信任链进行显式验证，还应考虑隐含的行为模式和上下文元数据。
4. 持续监控与评估：必须监控系统中所有参与者的行为，这进一步凸显了数据收集和数据仓库技术在Edge 2.0架构中的关键作用。此外，还必须持续评估这些活动，以检测并缓解执行禁止或危险操作的企图。评估必须以近实时方式大规模开展，因此需要广泛运用自动化和机器学习技术。
5. 假定已遭入侵：鉴于当今复杂攻击者所掌握的资源，必须假定任何系统都已在某种程度上遭到入侵。因此，完全基于工作负载和用户身份的确定性策略，以及由a和b表示的基于权限的访问控制，往往不足以阻止所有攻击。为此，完全成熟的Edge 2.0系统还必须能够基于持续监控和评估，实时权衡风险与收益。

提供原生可观测性

Edge 2.0必须将遥测作为核心能力深度集成到基础设施堆栈中，提供简单且可扩展的方式来收集基础设施内的跨层遥测数据，并将其呈现在统一平台上。这有助于可观测性团队按需查询“基础设施状态”，同时让应用团队无需对应用堆栈进行显式插桩，便可专注于业务逻辑。

图5：遥测收集器的演进

目前的可观测性技术大多由特定供应商提供，并采用专有技术。因此，许多供应商专用代理会收集类似的信号，争用成本高昂的内存和CPU资源。

下一步自然是使用与供应商无关的遥测收集器，将基础设施和流量数据以流式方式传输到集中式数据平台。

许多产品团队难以证明在可观测性数据采集方面投入的合理性，因为这项工作需要与创收机会相对应。基础设施应像其他业务职能或流程一样进行数据采集，因为团队需要了解其运行状况，才能根据业务目标加以优化。因此，讨论的重点不应是是否需要采集数据，而应是优先采集哪些数据。

为了更精细、更准确地衡量应用行为，我们预计可观测性埋点将“左移”，在编码阶段启用，如图5所示。

支持自适应接口

与分布式云的理念一致，深入到更底层后可以看到，其范围内的每个云（无论本地还是全球）都有自己的管理器、管理员、编排器等。每个云都独立运行并自主决策，同时提供接口，供其他实体按需使用。

因此，分布式云的本质是分散式管理和控制。这一事实无法回避。认识到这一点，有助于更深入地理解自适应接口与声明式接口和命令式接口之间的细微差别。

要有效利用Edge 2.0基础设施，仅靠命令式和声明式接口还不够，因为它们仍依赖手工创建的构件。这些构件本质上是静态结构，无法足够迅速地适应快速变化的条件。

我们需要转向以结果为导向的模式，系统也需要足够智能，能够在整个基础设施中进行端到端的策略调整，以实现这些结果。我们将此类接口称为自适应接口。

需要明确的是，命令式、声明式和自适应接口并不相互排斥：

命令式：规定非常具体，会详细定义为达到所需状态而执行的一系列操作。例如，配置路由器就是一种命令式操作。在上述场景中，规定的操作会非常明确，包括使用哪个数据中心、需要多少CPU和内存、所需带宽、具体路由等。数据模型对输入质量的要求很高，因此需要深入了解基础设施并具备相关专业知识，同时还应熟悉基础设施的模型和结构。

声明式：声明式方法的特点是侧重描述期望状态，而不是实现该状态所需的操作。其输入质量要求较低，但仍要求应用至少了解底层基础设施的结构。

自适应式： 独立于命令式和声明式。自适应接口关注的是预期目标，而非状态。其目的是捕捉希望部署应用的利益相关者的目标，而不是侧重于预先了解底层系统。自适应式的不同之处在于，它不需要了解底层基础设施具备哪些能力。对于如何“完成任务”没有任何限制，因此自成一类。

采用自适应方式时，输入要求较低，表达形式接近自然语言。应用所有者可以发送请求，告知基础设施控制器期望的结果，而无需声明所需的能力或专门配置资源。

解决集群间问题

顾名思义，分布式云可支持各种应用架构，包括单体架构、微服务架构和无服务器架构。无论采用哪种架构，应用都通过API提供服务。

使用服务网格可以在很大程度上解决API发现、连接和网络安全问题，但服务网格只能解决集群内部（集群内）的问题。

相比之下，Edge 2.0应用利用跨高度分布式云基础设施的API，本质上是在多集群环境中运行。新应用采用跨组织和地域边界的API构建。部分API可能是位于多层防火墙之后的私有API或合作伙伴API，即使可以被发现，彼此之间也可能没有明确的路由。目前，这种异构集群（集群间）问题仍缺少一种简洁、轻量、可扩展、安全且切实可行的解决方案。

我们在《2021 年 API 蔓延报告》2中对API进行了深入探讨，并解答了许多可能出现的问题。图6展示了集群间与集群内的区别。

图6：集群内与集群间

集群内：在单体架构中，对外公开的API可能很少，模块之间通过其他进程间通信方式进行内部通信。而微服务架构则会拆分为数十个甚至数百个API。

无论采用哪种架构，每个应用集群都会按照特定的方式进行开发和管理。例如，在微服务架构中，团队可能会使用任意一种服务网格，如Istio、Linkerd、Aspen Mesh或其他服务网格。每种方法都有各自的方式来管理和控制集群内（即集群内部）的API。

这方面已有许多解决方案，而Edge 2.0的目标并非另起炉灶，也不是强迫组织或开发团队再采用一种新技术。

集群间：随着通过API交付的服务不断增多，企业内不同应用团队可以利用其他团队已开发或采用的服务来构建新应用，无需重复开发。

新应用也通过公共API和私有API的不同组合来构建。从架构角度看，现代应用会利用其他集群提供的服务。在分布式云中，这些集群部署在全球各地，因此可以位于任何能够托管应用或作为应用集群一部分的场所。

应用集群的范围

再次强调，应用集群的范围并不局限于单个组织内部。集群可以跨越任意两个网络、应用或组织孤岛，甚至可以跨越两个企业。

该范围涵盖所有可能的排列组合，导致运维复杂性呈指数级增长。图7展示了应用部署范围内的流量排列组合。

图7：现代企业中的流量流向组合

典型企业通常采用多种应用架构。根据负责开发和部署的团队不同，可能会采用不同类型的服务网格、基于面向服务架构的Web 2.0应用，也可能采用单体软件部署。因此，无论是私有API还是公有API，API都分散在整个企业中。这一问题尚未解决。多个位置之间的API通信至关重要，但对于任何规模的企业而言，这都是一个难以彻底解决的问题。

集群内API管理已有多种解决方案（例如入口控制器、API网关等），但目前仍缺乏实用、可扩展且安全的集群间API通信解决方案。因此，我们将统一API控制和管理的范围限定为仅解决集群间问题。

实现自主控制

云的一项常被低估的价值，是它赋予“云消费者”的自主性。企业和创业者可以按需创建自己的基础设施，同时获得近乎完全掌控的体验。

Edge 2.0平台必须遵循的基本设计原则是：在实施适当防护措施的同时，为云客户提供自主体验。由于这些实体可能出现在任何基础设施中（无论可信与否），实施防护措施时不得给负责构建应用的业务部门（BU）或DevOps团队增加负担。

原则总结

Edge 2.0将面临的新挑战，是如何实现各种服务之间的发现、身份识别、信任和可观测性。

即使在中型企业中，每年生成的API数量也会非常庞大。团队如何在企业内部发现这些服务？又如何知道这些服务是否仍然有效，以及由谁负责？他们能否确定这些服务已经过验证并建立了信任关系？当团队希望使用由企业边界之外的集群创建的服务时，问题会更加复杂，例如SaaS提供商提供的服务，或在边缘设备上运行且完全不受企业基础设施团队管理控制的应用。

Edge 2.0应用平台

鉴于前文所述的挑战，我们需要将整个分布式云视为一个平台。从宏观层面来看，该解决方案旨在跨去中心化基础设施自主发现（无需人工干预）、扩展和保护分布式应用。

从本质上讲，Edge 2.0 Application Platform（EAP）的职责可概括如下：

• API发现、身份和信任
• 基础设施调度与编排
• 安全的应用连接

EAP范围

基础设施涵盖整个解决方案空间，其中的基础设施元素可以不断出现和消失。基础设施及其资源的所有权，与这些资源的管理权和控制权是两个相互独立的概念。基础设施所有者可以将特定基础设施或其实例分配给其他组织，由其进行管理和配置；也可以根据需要收回控制权。负责管理和配置这些元素的组织还可以进一步将其分配给各个项目或应用。这一概念并不新鲜。例如，云服务提供商提供分层管理控制机制，企业IT团队可以利用该机制，进一步向内部业务部门、团队等提供基础设施即服务（IaaS）。Edge 2.0主要关注的是，如何在高度分布式云中广泛实现这一模式，而高度分布式云正是边缘基础设施当前及未来的发展形态。

由此可以看出EAP的作用范围。下图8展示了不同类型接口环境下EAP的作用范围。每个EAP都使用声明式接口和命令式接口，在其本地范围内进行编排。在此示例中：

• 声明式和命令式接口包括AWS API、Azure API等。
• 自适应接口将是全新接口，必须根据具体情况逐一定义。

图8：EAP范围与接口类型的对应关系

为充分利用分布式云，EAP应能够利用分布式云中的所有可用节点和实体。其愿景是让单个EAP在应用层发挥与IP网络中的自治系统3概念相当的作用。

综合以上内容（见下方图9），现在可以从宏观层面展示如何在去中心化云基础设施中部署多个EAP，并使其自主交互。

自适应接口还可帮助CI/CD及其他应用生命周期应用轻松与分布式云集成。CI/CD平台可通过简洁的自适应接口直接与EAP交互，只需指定预期结果。

需要注意的是，EAP之间也可以通过自适应接口实现通信。

图9：具有本地作用域的EAP高层拓扑

EAP框架

如图10所示，EAP框架根据各EAP实例的能力划分职责。EAP负责与底层基础设施控制器对接，包括基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS），并根据需要编排和调度适当的资源。

图10：Edge 2.0应用平台（EAP）框架

统一的API控制与管理

未来将进入API驱动的经济时代，API将不再只是通过服务网格简化的软件架构方法。对于参与分布式云的任何实体而言，API将成为其提供服务的主要方式。

如前所述，未来十年内，全球可用的公共和私有API数量将达到数亿，甚至可能达到数十亿。API将重塑我们的经济，因此需要进一步审视EAP必须实现哪些功能，才能为这种经济模式提供支持。

API发现

日益加剧的API蔓延要求每个API在EAP内外均可被发现。在分布式云环境中，API可能分布在多个集群中的任意位置。

其基本假设是，API发现问题实际上是一个跨集群问题。EAP的范围可能涵盖多个采用不同软件架构（从微服务到单体架构）的应用集群，每个集群都实施自己的API网关策略。EAP提供一个通用存储库，用于注册其范围内的所有API并支持发现，而不局限于集群内部。这一区别是分析现有API网关策略局限性的关键，例如服务网格中的API网关策略。

EAP面临的挑战是支持API发现，提供正确的API使用文档，并管理API生命周期，以确保一致性、准确性和版本控制。EAP通过相应机制，向API使用方告知其所用特定API的当前状态。具体方式可以是简单地设置到期日期，也可以通过某种消息传递系统明确通知。

身份驱动的安全

所采用的安全策略是：应用假定其当前部署的基础设施已遭入侵。

实施这种安全态势的关键支柱是以身份为驱动。每个API端点都必须具有全局唯一身份。安全策略和控制措施单独维护在中央存储库中。

必须将API标记为公有或私有，以触发底层基础设施安全组件针对特定API进行自动配置。

所有应用间通信最初均采用全部拒绝策略。API可见并不意味着其他应用可以调用该API。必须在应用的安全策略中对此进行显式配置。

信任：经时间积累的声誉

EAP必须确保其范围内的所有API均可信，同时还必须确保其范围内的服务所使用的所有外部API也可信。

“信任无法证明，正因如此才称为‘信任’。”——摘自Netflix的《Traitors》

信任本质上是“长期积累的信誉”，必须持续重新验证，以确保其未降至可接受水平以下。在系统中对信任进行建模和实施时，这种方法日益普遍：信任需要持续评估，而不是仅在初始执行时进行静态断言。

信任会随时间动态变化，这可能会给一些企业带来挑战，因为它们没有充足的时间在自有系统与第三方系统之间建立相互信任。如果不密切监控信誉状况，基础设施和API都可能造成严重破坏。

假设EAP范围内的某项服务访问外部API，平台必须实施一种机制，使调用服务能够确认从外部API收到的响应是否准确。API响应看似有效，并不意味着它值得信任。响应可能因质量问题而不准确，也可能被人为植入不准确信息，以削弱企业的竞争力。EAP架构的独特之处在于，能够为每个内部或外部API分配信任因子。

一种实现信任度评估的策略是，计算最近一个“时间段”内的平均信任度，而不是基于服务的全部历史记录。这类似于在Amazon上查看产品的“热门评论”和“最新评论”。产品的总体评分可能达到四星，但如果大多数负面评分都出现在过去6个月，则表明近期信任度有所下降；而如果过去6个月涌现大量正面评论，则表明问题已得到修复，或信任正在重建。

信任因素并不只取决于某个API是否已知会提供虚假或误导性数据。EAP的声誉还取决于其管理和更新范围内API的成效。此外，“信任”也是相对的。服务A可能信任服务C，但服务B与服务C交互时的体验可能有所不同。

边缘基础设施管理器

分布式云是Edge 2.0基础设施的基础，因此，EAP范围内的资源必须易于发现、受到保护并具备可观测性。以下内容可视为对边缘基础设施管理器所需能力的一组建议。

发现与调度

在EAP内，可根据需要调度资源。由于移动性，新资源可能会动态加入或离开。EAP还可以向其他EAP发送请求或接收其请求，以便根据需要代表对方发现和调度资源。

安全性

再次说明安全态势：部署应用的基础设施已遭入侵。因此，EAP必须确保其范围内部署的应用安全。

无论处于哪个管理层级，EAP框架都必须考虑安全性的多个方面，包括但不限于：

外部威胁： 例如，分布式拒绝服务（DDoS）攻击和高级持续性威胁（APT）。可采用现有安全最佳实践来缓解这些威胁，例如DDoS防护、防火墙等。建议对所有流量强制采取这些措施。

中间人攻击：所有流量都必须加密，不能假定应用层会采取正确的安全措施。这样可以确保基本的数据机密性，防止任何流量嗅探设备窃取数据，并保护数据完整性，避免数据在传输过程中遭到篡改。

内部威胁：基础设施层的范围必须受到限制，并主要用于保护自身。建议防止基础设施内的资源对基础设施管理器发起内部攻击。

以体验为中心的遥测

如果说Edge 2.0关注的是所交付的体验，而非资产本身或其位置，那么遥测也必然要以体验为中心。

问题在于，我们所说的是谁的体验？这里的体验是指任何驻留在基础设施中，或使用基础设施来提供或使用服务的实体所获得的体验，包括应用、设备、人员、后端应用、数据库等。因此，体验应从实体的视角来衡量。实体提供或使用的服务与分配给该实体的计算、存储和网络资源直接相关。

但不能止步于衡量体验，还必须有相应的改进手段。

任何使用或提供服务的实体都可以判断是否获得了所要求的体验。然而，在分布式云环境中，可能几乎无法解释基础设施层发生了什么，进而导致体验不佳。

CPU利用率、内存、带宽和延迟测量值等高层指标不足以确定应用为何未能获得所请求的体验。指标需要具备精细的时间粒度，并从应用堆栈深层采集；在条件允许时，还应从基础设施堆栈的不同层采集。

稳健、可扩展且易于拓展的遥测和数据策略对EAP至关重要。在此基础上，可以利用机器学习（ML）和人工智能（AI）策略，更合理地决定是预留新资源，还是优化现有资源的使用。

软件定义的应用连接

尽管连接和可达性被认为已不再是难题，但许多网络团队仍难以让网络架构适应应用层的动态需求。平台也必须应对这些挑战。

应用连接平面分离的必要性

现有方法的问题在于，我们将应用连接需求转化为企业WAN连接需求，在分布式云环境中尤其如此。构建分布式云网络时，可以采用不同的SDN策略或纯路由方法。但这些解决方案高度依赖基础设施的同构性，因此难以提供一致的行为。

要为应用构建可在全球范围内扩展、安全且稳定的网络，唯一的方法是将应用连接平面与底层网络分离，具体将在下文讨论。

建议的连接技术栈

在向分布式云架构演进的过程中，新兴的SDN模式是对底层网络和叠加网络进行联合编排，并实现应用路径的端到端可编程性。

图11：应用连接平面不同于底层网络（企业网络和骨干网络）

借助Edge 2.0，即使在连接企业网络时，我们也需要实现这种相对稳定的状态。我们建议，应用连接平面必须与企业网络连接分离。应用连接模式可能采用数据中心覆盖网络中常见的SDN连接方式（例如VXLAN、NVGRE或其他方式）或基于BGP的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。随着自然语言处理和AI的应用，该实现将日益完善和成熟，并降低对输入质量的要求。

EAP功能

• 多租户：虽然图9所示的EAP网格用于单个部署，但每个云中可以部署多个EAP。其他应用可以与不同的EAP或EAP网格通信。
• 专为扩展而设计：每个网格均为点对点（P2P）网格，可横向扩展。对等EAP可独立跟踪各EAP拥有的资源类型以及如何连接到相应资源。AI/ML将进一步增强每个EAP在自身范围内调度资源或按需联系其他EAP的能力。
• 内置网络：要让应用跨分布式云连接，EAP必须支持不依赖底层基础设施的内置网络。

整合应用

图12直观展示了在分布式云上部署应用时不同层所发挥的作用。

此表示形式的要点如下：

• 每个EAP的作用域均为本地化范围，图10并未展示其全部功能。EAP必须支持资源发现和调度器功能。EAP通过自适应API与相应的基础设施控制器交互，以调度资源。

图12：展示不同实体和层级所承担角色的参考图。

• 应用连接不同于网络连接。与服务网格边车模型类似，用于跨多云连接应用的资源必须属于应用基础设施。也可以认为，基础设施平面同样提供应用网络连接，因此应位于网络层之下。从技术角度看，这种说法也正确，但由于这些功能主要属于网络功能，我们选择将其纳入“应用连接”平面。
• 必须将基础设施平面与应用平面视为彼此独立的平面。
• 网络连接不同于传输，因为这里实质上指的是特定的可路由网络，这些网络与应用连接相互独立。
• 传输平面可视为可配置的聚合骨干网络，前提是电信提供商启用相应流程和API，以连接其上层的网络层。

总结

本白皮书旨在对原版Edge 2.0宣言进行更深入的探讨。我们引入了一些新主题，旨在为组织内部的不同利益相关方以及外部行业人士提供参考。

Edge 2.0基于分布式云理念构建，其中每个实体既可以作为服务的来源，也可以作为服务的目的地。其核心理念是，Edge 2.0关注的是体验，而非资产或位置。

边缘应用平台（EAP）是一套能力栈，旨在通过分布式云实现Edge 2.0。

为呈现不依赖特定供应商的视角，本文特意省略了实施细节。