首席技术官办公室报告

边缘 2.0 核心原则

  • Share to Facebook
  • Share to Twitter
  • Share to Linkedin
  • Share to email
  • Share via AddThis
作者:Rajesh Narayanan、Michael Wiley

前言

边缘的定义始终与数据中心架构的演变交织在一起。过去十年,我们看到了企业基础设施架构的快速转型,从本地数据中心扩展到目前的分布式云架构。我们认识到边缘 2.0 是一种技术转变,将使应用能够充分利用分布式云架构。

每个人、每个组织或每个实体都对边缘有着不同的理解。有些人可能认为边缘是信号塔,有些人可能认为移动设备就是边缘。对于云服务提供商 (CSP) 而言,边缘是可无缝集成至其后端的托管基础设施足迹。对军事应用来说,边缘就是战场(包含海陆空)。每次我们读到关于边缘的阐释时,一般都概括为基础设施和/或其位置的计算、交互和存储能力。

但我们也认为边缘 2.0 是其为生态系统中所有利益相关者提供的体验,不仅仅是基础设施资产或其位置。

本文描述了边缘 2.0 的功能,与其物理或虚拟基础设施,或其位置或实例化无关。其目的不是解释如何建立更好的分布式应用,而是阐明边缘 2.0 必须具备的能力,以支持创建适合特定要求的最优化分布式应用。

什么是边缘 2.0?

从位于此分布式云中的实体角度来看,边缘是实体目前所处的任何位置。因此,我们提出的边缘 2.0 定义是以体验为中心,不仅仅只是与基础设施的位置、基础设施的类型或控制实体相关联。

边缘 2.0 重点是加强以应用为中心、以操作为中心和以开发人员为中心的体验。边缘 2.0 必须适应不断变化的应用需求,从而解决应用的元属性(如 SLA 和 SLO)。边缘 2.0 必须操作简单,使运营团队无需为每个分布式应用创建新的自动化。边缘 2.0 必须无缝支持安全、管理和服务级目标,减少开发人员在大规模开发和部署分布式应用时所面临的阻碍。

例如,以银行应用为例,边缘 2.0 的目标不是改善交易的业务逻辑,而是让其更安全、更快速、更私密、可在所有地区使用(根据需要),并可根据需要上下扩展,以支持实现业务目标。

概念与断言

以下是本文的关键概念与断言。

  • 以体验为中心的边缘:围绕其所提供的体验,而非资产或其位置,为边缘 2.0 构建基础。
  • 设计考量因素:明确成功实施边缘 2.0 架构的关键设计考量因素。
  • 异构基础设施:强调为分布式云设计意味着要考虑对基础设施的分散控制。
  • 遥测即基础:强调遥测是基本构件,必须在基础设施的所有层面得到支持。没有遥测,数据为先的战略就会被淡化。
  • 集群间挑战:强调边缘 2.0 的一项基本挑战是集群间挑战而非集群内挑战。
  • 自适应接口:介绍自适应接口,与声明和命令接口进行了鲜明对比。
  • 边缘 2.0 应用平台 (EAP):介绍 EAP 作为框架,使边缘 2.0 能够适应应用的需求。
  •  

未涉及的主题

本文有几个主题我们尚未涉及:

  • 应用数据分布:这里包含许多副主题,如内容交付网络 (CDN)、存储分布、数据分布、缓存等。还有一些新兴技术,如无冲突复制数据类型 (CRDT)。边缘 2.0 框架应在其范围内包括对应用数据分布的支持。
  • 功能分布:边缘计算的发展可被认为是核心云功能和逻辑,转移至更接近事件产生或数据所处的位置。由于大量计算在边缘变得可用,如果我们希望充分利用这些计算,现在应解决类似于传统云架构中通常解决的问题。例如,叠加网络、中间件工作负载和其他类型的工作负载,它们相互交织,比我们在早期边缘看到的简单用例更为复杂,例如 Storlet,这是一种无状态的简单流,在数据周围运行。
  • 可能还有其他领域没有讨论。该框架的目标可扩展,如此便可以根据需要增加责任。

边缘的演进

图 1 良好地描述了边缘和数据中心架构的共同演进。边缘 1.0 和边缘 1.5 基于原点的概念,将数据和服务从原点转移到消费者。边缘 1.0 是部署互联网基础设施,主要侧重于通过分布式内容缓存(又称内容分发网络)优化带宽使用。CDN 是一种基本的设计模式,因为要传输的内容总量总是超过可用带宽。

随着 CPU 和内存成本的急剧下降,计算节点与 CDN 节点一同出现。应用通过以服务为导向的架构 (SOA) 作为服务被消费。因此,边缘 1.5 被称为服务分配网络。

边缘 1.0 和边缘 1.5 的共同特点即原点概念。在移动发展之前,人类、设备和事物主要是下载内容或作为服务的消费者。发起服务的站点仍与消费者的站点不同。

图 1:边缘和基础设施的共同演进

但在边缘 2.0 中,任何实体都可以作为原点或消费者。流量已发生改变。人类、手机和设备在上传内容或产生周期性数据时,正积极地生产数据。应用正成为消费者,因为它们依赖于其他应用。所有实体都可以作为服务的生产者或消费者 - API、人类、物联网设备或 Web、后端和无序应用。从其自身角度来看,基础设施上的每个实体都认为自己处于边缘。

分布式云是数据中心发展演进的最新阶段。计算已变得真正无处不在,从移动设备到融入至与网络关联的日常事物中。与其共同发展的是软件架构,以实现分布式和可扩展应用。

边缘带来的后果:复杂性增加

计算和存储的丰富性与超分散性无处不在,为企业的快速数字化转型创造机遇。但这种快速演进也会带来相应的后果。

大多数企业通常由异构的基础设施组成,具有不统一的环境。有效扩展此类环境需要部署系统的复杂协调和自动化。应用需求的快速变化(如 CPU 和带宽需求的变化)增加了整个分布式云的操作复杂性。这为运营团队带来了巨大压力,他们可能没有足够的能力来有效应对应用或最终客户不断变化的需求。

这些问题带来的后果就是运营的复杂性,使得正在经历数字化转型的企业的任何潜在收益中和。

接下来将关注因复杂性导致的交织问题和工件。

安全模型需要持续更新

混合云导致攻击面增加,这可能因各种攻击载体而受到损害。不同的用例会带来多种安全挑战,随着基础设施的发展,我们也在不断地突破。因此,我们想到的问题是:只有技术建议会经常改变,还是实现安全的设计模式也会改变?

以下是现有方法存在的一些问题:

  • 软件定义边界 (SDP) 不容易扩展,因为受欢迎的解决方案基于代理,这并不适合简单的操作部署。
  • 实施零信任网络访问 (ZTNA) 往往不切实际,因为 ZTNA 解决方案需要一系列部署的生产服务,如流量检查、集中式日志管理、全球 PKI 和身份管理等。
  • 安全访问服务边缘 (SASE) 将网络即服务和安全即服务结合,是由多种实施起来并不简单的技术组成的缩略语。此外,SASE 重点关注的往往是以软件定义的广域网 (SD-WAN) 为中心,解决企业网络边缘用例的一小部分。
  • 不同公有云供应商的基础设施和已经十分复杂的安全模型间的差异,例如身份和访问管理 (IAM),往往导致团队对供应商拼凑式加固,以及繁琐的多云配置。
自动化挑战

边缘可用的低功耗和低成本计算的超分散性的主要挑战之一是以统一方式协调和安排基础设施的能力。运营团队在扩展和支持利用分布式云的应用方面遇到重重困难,因为这些应用通常包括具有不同管理要求的异构技术。

虽然 Terraform 等自动化平台提供了复杂的方式来定制自动化,但运营团队仍需要为多种排列组合维护脚本:例如,五种不同的计算方式,四种不同类型的防火墙,以及三种类型的负载均衡器。管理和维护自动化脚本的人力成本并不高。

这导致基础设施客户继续通过票证驱动系统与运营团队互动,这会阻碍实现现有工作流程的自动化。服务台因票证而不堪重负,需要优先考虑安全性和稳定性而不是灵活性。

API 无序扩展

随着向多云演进发展,微服务架构已成为构建新应用的既实方法。发布并随时随地实例化 API,导致了 API 的无序扩展。以自主方式发现、连接和管理这些 API 成为一项巨大的挑战。

在解决 API 无序扩展这一问题上,需要进行范式转变。内部模式表明,即使是适度假定参数,如全球 API 开发人员的数量、每个开发人员每年开发的 API 数量以及 API 的生命周期,也会导致到 2030 年有数亿(即使没有数十亿)的 API 同时活跃(图 2)。2021 年 API 无序扩展报告对这一新兴话题进行了全面阐述。

端到端系统可视性糟糕

复杂性增加要求企业对端到端系统实现细化和具有意义的端到端可视性。在分布式云环境中,应用跨越了由不同实体管理的多个异构基础设施堆栈。

图 2:10 年预估 API 增长情况

此外,目前没有一家运营商有动力向企业客户公开其基础设施的原始遥测数据。企业在分布式云中部署应用时基本上都盲目执行,并且需要借助多种可视性工具。为了填补这些可视性差距,这些工具通常来自不同的供应商公司,在基础设施或应用堆栈的不同点发挥作用。

非标准的基础设施指标使企业内的困境更加严重。通常情况下,由于运营壁垒和其他因素(如不同基础设施环境中的非统一基础设施),指标并不统一。例如,公有云供应商的指标大相径庭,而本地数据中心技术也不遵循任何标准指标。

业务成果:经验减少

创造营收的工作负载和关键任务系统通常使用企业的大部分运营资源和预算。同时,较小的项目虽然复杂程度较低,但往往累积了企业的应用数量。图 3 描述了企业可能拥有的项目数量与运营复杂性间的长尾分布。

虽然较少的应用在操作上的复杂性可能较低,但在许多情况下,操作过程和工作流程仍为手动,服务票证可能需要几周的时间才能成功传送至多个操作团队。例如,部署需要专用网络资源和细化安全策略的应用,可能首先需要全球安全团队解决安全策略批准。然后,服务票证可能会转至网络团队,以规划需要进行的子网和路由配置。最后,可能需要另一个负责防火墙管理的运营团队对防火墙规则进行验证。

现在设想一下,需要为部署在分布式云(企业未拥有底层基础设施的任何部分)上的每个应用解决上述的复杂性。需要载入和支持的小项目或应用数量之多,使得运营团队为每个项目提供支持不现实,这也带来了优先级问题和自助服务机会。

图 3:项目规模与其部署复杂性的分布情况

这一优先级问题特别明显,因为基础设施团队的投入都集中在支持关键和创收系统方面,很少有时间或预算投入新项目,而这些项目在生产前都有各自的开发、测试和暂存生命周期。这就导致了对功能速率、定制化和支持新产品的创新能力与投资减少,最终导致业务和产品服务停滞。

边缘解决方案空间

边缘生态系统的演进通过提供借助应用平台解决这些挑战的机会,显著扩展了解决方案空间。

图 4 显示了边缘 2.0 解决方案空间。在此我们声明属于分布式云架构的一切为解决方案空间的全部。

因此,在解决方案空间范围内,边缘 2.0 必须提供以下所有方面所期望的体验:

  • 处于该解决方案范围内的所有实体 - 作为消费者的应用、人类以及设备,或构成服务的 Web 后端和无序应用。
  • 这些应用的 SRE 团队和应用所有者,同时保留基础设施预期的安全性和监管防护。
图 4:边缘 2.0 解决方案空间

边缘 2.0 在操作方面将十分简单、安全且合规的,并为参与其中的所有生态系统实体提供高品质体验。

边缘 2.0 的设计考量因素

缺省安全

由于端点数量呈指数级增长,因此分布式云将此规模安全问题进一步放大。在如此大规模的情况下,实施解决方案的复杂性也在不断增加。安全态势应为应用假定其目前部署的环境已遭到破坏。同样地,基础设施也不应相信在其中运行的任何应用。

这些想法的依据均体现在“零信任”思维概念中,BeyondCorp1 典型示例为应用访问用例展示了相关概念。展望未来,边缘 2.0 在以下五个核心原则的基础上,将此模式进一步扩展。

  1. 身份即基础:在边缘 2.0 中,身份根深蒂固,每个实体实例不仅有各自的全球唯一身份,其在组织层次结构中的位置与其权限级别也具唯一性。无论是对南北流量还是内部的东西访问,身份都应为一项关键的考量因素。
  2. 最低权限:行为者所允许的行动应被限制在行为者为履行其在系统中的角色而需实施的行动。例如,根据设计规范限制允许与数据库服务器通信的工作负载的子集。
  3. 持续验证:系统行为者所做的任何证明都必须具有验证方法,并且每当此类证明发生时,都应进行明确验证。身份验证不应该仅通过共享秘密或信任链明确,还应该考虑到隐含的行为模式和环境元数据。
  4. 持续监控和评估:系统中所有行为者的行动都必须予以监控,从而加强数据收集和仓储技术在边缘 2.0 架构中发挥的关键作用。此外,必须持续评估这些活动,以检测和减少执行被禁或危险行动的企图。评估必须近乎实时且大规模进行,这也意味着对自动化和机器学习技术的随意使用。
  5. 假定存在漏洞:考虑到当今老练的对手所拥有的资源,我们必须假定任何系统都已通过某种方式遭到破坏。因此,植根于工作负载和用户身份的完全决定性策略(执行由 a 和 b 代表的基于特权的访问),往往不足以防止所有攻击。因此,完全成熟的边缘 2.0 系统还必须能够在持续监控和评估的基础上进行实时风险/回报评估。

提供本地可视化

边缘 2.0 必须将遥测作为一等阶级集成至基础设施堆栈的深处,提供简单且可扩展的方式来收集基础设施内的跨层遥测,并将其呈现在共用平台上。这有助于可视性团队根据需要对 “基础设施状态” 进行表面询问,让应用团队专注于业务逻辑,而不必明确对其应用堆栈进行检测。

图 5:遥测收集器的演进

目前的可视性技术在很大程度上针对供应商且具专有性。这就导致了许多供应商特有的代理收集类似的信号,争夺昂贵的内存和 CPU。

下一步合乎逻辑的措施即使用与供应商无关的遥测收集器,使基础设施和流量数据能够流向集中式数据平台。

许多产品团队正努力证明投资检测十分合理,因为所有的付出都需要转变为营收机遇。基础设施应像其他业务职能或流程一样被检测,因为团队需要了解其行为,以优化其业务目标。因此,我们应更多地探讨哪些方面应优先检测,而不是其需求是什么。

为了实现对应用行为的细化和更精确衡量,我们预计检测将通过在编码时进行调用以进行“左移”- 图 5。

支持自适应接口

为了与分布式云保持一致,继续深入几层,在其范围内(本地或全球)的每个云都有各自的管理器、管理员、协调器等,彼此独立运行,各自决策,但在需要时会提供接口供其他实体使用。

因此,分布式云的概念在本质上是分散化管理和控制。这一事实不可否认,我们必须认识到这一点,以便更好地实现自适应与声明和命令接口的细微差别。

为了有效利用边缘 2.0 基础设施,仅依靠命令和声明式接口远不够,因为它们仍依赖于手工制作的工件,这些工件基本上是静态结构,无法快速适应迅速变化的条件。

结果决定了我们的后续行动,而系统需要足够智能以调整整个基础设施(端到端)的策略从而满足这些结果。我们称此为自适应接口。

显然,命令接口、声明接口和自适应接口并不相互排斥。

命令接口:具有很强的规范性,详细定义了一系列行动,以达到预期的状态。例如,路由器的配置即命令性行动。在上述场景中,命令性行动将十分精确,精确到哪个数据中心、多少 CPU/内存、所需带宽、特定路由等。数据模型的输入品质非常高,因此需要对基础设施有更深入的了解和专业知识。人们也期望对基础设施的模型和结构都有所了解。

声明接口:声明接口的细微差别在于,其侧重于描述期望的状态,而非实现期望状态的行动。输入的品质较低,尽管其仍然要求应用至少了解底层基础设施的结构。

自适应接口:与命令或声明接口区分开来。自适应接口关注的是预期的目标或目的,而非状态。自适应接口旨在获取想要部署应用的利益相关者的目标,而非关注对底层系统的预先了解。自适应接口不同,因为其对底层基础设施的能力缺乏概念。对于如何“完成工作”没有任何限制,因此其十分独立。

自适应下,输入的品质比较低,接近自然语言。应用所有者可以发送请求,告知基础设施控制器他们期望的结果,而非需要声明所需的能力或具体配置资源。

解决集群间问题

根据定义,分布式云可以容纳所有类型的应用架构:单体、微服务或无服务器。无论哪种架构,应用均使用 API 来提供服务。

在很大程度上,API 发现、连接和网络安全问题可通过使用服务网格加以解决,但服务网格只在集群内解决此问题。

另一方面,边缘 2.0 应用在超分布式云基础设施(本质上是多集群环境)上利用 API。新应用是通过跨组织和地理边界的 API 编写而成。有些 API 可能是私有或合作伙伴 API,隐藏在多层防火墙之后,彼此之间没有明确的路径,即使它们很容易被发现。此异构集群(集群间)的问题在于没有精简、轻量级、可扩展、安全且实用的解决方案。

表 1:命令和声明接口与自适应接口的对比
情景/属性 命令接口 声明接口 自适应接口
定义

命令接口根据底层资源的具体能力定义详细的控制流程。

声明接口定义逻辑,但没有定义控制流程。从程序化角度来看,其为伪代码。

自适应接口将期望状态表达为一种需求,而不对底层资源的能力做任何假定。

自适应接口由基础设施所有,可使基础设施动态地响应应用不断变化的需求。

情景 1:包裹需要从旧金山到达纽约市

Jane 告诉 Mark:(a) 打印运送标签;(b)前往 UPS 商城;(c) 选择 72 小时内到达;(d) 付款并运送

Mark:必须遵循一套非常具体的流程

Jane 告诉 Mark:(a) 请将这个包裹快递到这个地址;(b) 包裹必须在 72 小时内到达。

Mark:可以选择任何快递公司(UPS、FedEx、DHL 等)。

Jane 告诉 Mark:(a) 这个包裹必须在星期六之前到达纽约市。

Mark:可以随心所欲做任何事,甚至有可能自己拿着包裹,飞到纽约市,亲手将它送达。

情景 2:负载均衡器示例

负载均衡器已经存在。任务:需要通过此策略进行配置。此处的任务特定于负载均衡器的品牌、型号、版本等。

负载均衡器并不存在。任务:通过给定的开放策略对应用进行负载均衡。任务假定存在协调
或管理层,并明确需要做些什么。行动:最终任务被转换为命令接口,以配置特定的负载均衡器。

对底层基础设施不做任何假定。请确保应用根据需要进行扩展,最大延迟为 10ms。

所有权

共同所有权:应用和基础设施

共同所有权:应用和基础设施

仅基础设施

输入的品质

极高:需要对底层范围有深入了解。例如,需要了解哪个 F5 负载均衡器,哪个软件版本等。CLI 或 NMS 将是命令接口的其中一个示例。

高:需要对基础设施的能力有所了解。例如在上述示例中,对支持负载均衡器的基础设施有预先了解。

低:不需要对基础设施的能力有所了解。输入的品质接近于自然语言。

技能水平(角色)

特定功能的技能。例如网络管理,计算管理,存储管理。基础设施的每个方面都需要用户成为该领域的专家。

应用部署技能。用户了解部署应用所需的功能类型。如上述情况,应用管理器知道需要负载均衡器,以及必须在其中配置 LB 以支持自动扩展的高级策略。

应用工程师。只能向基础设施发出信号,告知应用的非功能要求。在此示例中,应用应多快地响应客户的请求。其他因素如地理位置、成本等,可根据需要添加。

范围

命令接口具有
高度本地化的范围。例如基础设施、网络、数据中心、机架级等。

声明接口的范围更大。通常与协调引擎相关,该引擎可与多个命令接口通讯以实现所需的结果。

范围非常大,因为
接口结果可以调用多个声明或命令接口。执行起来比较复杂,需要对命令和声明接口进行复杂的实施。

示例

- name: update web servers
hosts: webservers
remote_user: root
tasks:
- name: ensure apache is at
the latest version
yum:
name: httpd
state: latest
- name: write the apache
config file
template:
src: /srv/httpd.j2
dest: /etc/httpd.conf
apache-server:
version: “latest”
application-latency:
- lt: 10ms
infrastructure-cost:
- lt: $200
- billing: monthly

2021 年 API 无序扩展报告2中有广泛涉及 API,并在其中解决了许多可能出现的问题。图 6 显示了集群间和集群内的区别。

图 6:集群内与集群间的对比

集群内:在单体架构中,模块之间通过其他进程间通讯方法进行内部通讯,因此可能会有很少的 API 暴露。而微服务架构则被分解成几十个甚至几百个 API。

无论哪种情况,每个应用集群均以某种有主见的方式进行开发和管理。例如,在微服务架构的情况下,团队可能会使用任何服务网格 - Istio、Linkerd、Aspen Mesh 等。每种方法都有其各自的方式来管理和控制其集群内部(换言之,即集群内)的 API。

这里有诸多解决方案,边缘 2.0 的目标不是重新发明或强迫组织或开发团队采用另一种新技术。

集群间:随着通过 API 交付的服务数量不断增加,新应用则利用企业内不同应用团队已经开发或采用的服务来构建,因为没有必要重新研发。

新应用也正通过公有和私密 API 的不同组合来构建。从架构的角度来看,现代应用充分利用了其他集群提供的服务。在分布式云中,这些集群在全球范围内部署,因此,可以位于任何可托管应用的实体上,或成为应用集群的一部分。

应用集群的范围

重申一下,应用集群的范围并不仅仅局限于组织内部。集群可以跨任何两个网络、应用、组织孤岛,甚至是两个企业之间。

此范围涵盖所有的排列组合,因此成倍增加了操作的复杂性。图 7 显示了应用部署范围内的流量变化。

图 7:现代企业中的流量排列组合

一般的企业会有不同的应用架构。可能有不同风格的服务网格,或基于以服务为导向的架构的 Web 2.0 应用,或是单体软件部署,这取决于哪个团队在开发和部署。因此,API 分散在整个企业中,无论是私密 API 还是使用公有 API。这一问题尚未得到解决。多个地点之间的 API 通讯至关重要,在任何规模的企业中都是一个难以解决的问题。

有多种解决方案可以管理集群内的 API(例如入口控制器、API 网关等),而集群间的 API 通讯还没有以实用、可扩展且安全的方式解决。因此,我们将统一的 API 控制和管理范围集中在只解决集群间的问题。

提供自主性

云被低估的一项价值即其提供给“云消费者”的自主性。企业和企业家可按需建立自己的基础设施,同时享受完全控制的体验。

边缘 2.0 平台必须遵循的基本设计原则是向云客户提供自主体验,同时实施正确的防护措施。由于实体可以出现在任何基础设施(受信任或不受信任)中,因此必须以此类方式实施防护措施,避免给负责构建应用的 BU 或 DevOps 团队带来负担。

总结原则

边缘 2.0 带来的新挑战将是各种服务之间的发现、身份、信任和可视化。

即使在中等规模的企业,每年产生的 API 数量也十分庞大。团队如何在企业内发现这些服务?或者说,如何知晓这些服务是否仍然有效,以及谁拥有这些服务?他们能否确定这是经过验证且具有既定信任的服务?当团队想要消费由位于企业边界之外的集群创建的服务时,问题就会更复杂,例如,SaaS 供应商或在企业基础设施团队管理控制之外的边缘设备上运行的应用。

边缘 2.0 应用平台

考虑到前面章节提出的挑战,我们需要将整个分布式云视为一个平台。在超级别层面上,我们阐述解决方案的目标:在分散的基础设施上自主发现(没有人为干预)、扩展和保护分布式应用。

从本质上讲,我们可以将边缘 2.0 应用平台 (EAP) 的责任描述如下:

  • API 发现、身份和信任
  • 基础设施安排和协调
  • 保护应用连接

EAP 范围

基础设施是解决方案空间的整体,其中基础设施要素可以不断出现和消失。基础设施及其资源的所有权与这些资源的管理和控制是两个独立的结构。基础设施所有者可以将特定的基础设施或其实例分配给进行管理和配置的不同组织,或者基础设施所有者可以根据需要收回控制权。管理和配置要素的组织可以进一步将其分配给各个项目或应用。这个概念并不新奇;例如,云服务提供商提供分层管理控制,企业 IT 团队可以加以利用以进一步向内部业务部门、团队等提供基础设施即服务 (IaaS)。边缘 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:边缘 2.0 应用平台 (EAP) 框架

统一的 API 控制与管理

未来经济将由 API 驱动,API 不仅仅是通过服务网格简化的软件架构方法,它还将成为参与分布式云的任何实体提供其服务的主要方式。

在十年内,全球可用的公有和私密 API 数量将达到数亿甚至数十亿,这是不争的事实。API 将重塑我们的经济,因此我们需要仔细研究 EAP 必须如何实施以支持实现此经济。

API 发现

阻止 API 无序扩展要求每个 API 必须在 EAP 内部和外部都能被发现。通过分布式云,API 可位于多个集群的任何地方。

基本假定为 API 发现问题确实是集群间的问题。EAP 的范围可能跨越众多使用不同软件方法(从微服务到单体)的应用集群,每个集群都实施各自的 API 网关策略。EAP 为在其范围内(不仅仅是集群内)注册和发现的所有 API 都提供共同的存储库。这种区别是产生现有 API 网关策略限制的关键,例如像在服务网格中一样。

EAP 所面临的挑战是如何实现 API 发现,提供正确的使用文档,并管理 API 生命周期,以实现一致性、准确性和版本化。EAP 通过实施一种方法来通知使用其 API 的实体目前所使用之特定 API 的当前状况。这可以通过简单设置到期日期或通过某些消息传递系统明确通知加以实现。

身份驱动安全

所采用的安全态势是应用假定其目前部署的基础设施已遭受损害。

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

API 必须被标记为公有或私密,触发底层基础设施的安全组件,以为特定的 API 自动配置。

所有应用与应用间的通讯都始于拒绝所有策略。仅因为 API 可见,但这并不意味着另一个应用可以进行调用。这必须在应用安全策略中明确配置。

信任:随时间推移而变化的信誉

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

“你无法证明信任,这就是其 “受信” 所在” - 摘自 Netflix 的 Traitors

信任在本质上是 “随时间推移而变化的信誉” ,您必须不断地重新验证信任,以确保其没有下降到可接受水平以下。这已逐渐成为在系统中建模和实施信任的一种常见方法,我们要不断评估信任,而不是在最初执行时断言。

信任随时间推移而变化可能对某些企业来说是一项挑战,这些企业没有充足的时间在其与第三方系统之间建立相互信誉。如果不密切关注信誉,基础设施和 API 都会造成破坏。

假定 EAP 范围内的服务访问外部 API,平台必须实施一种机制,通过这种机制,调用服务可以保证从外部 API 所获得的响应的准确性。仅因为 API 响应看起来有效,并不意味着其可以被信任。响应可能因质量问题而不准确,也可能是明确插入了不准确的内容,使企业的竞争力有所下降。具备这种为每个 API(内部或外部)分配信任因素的能力,是 EAP 结构所独有的。

实施信任的一项策略是在近期 “时间段”(而非整个服务历史时段)内进行平均。这就像在 Amazon 浏览某个产品的 “热门评论” 与 “近期评论” 。该产品很可能有四颗星,但如果大多数负面评价是在过去六个月内提供,这表明近期信任度有所下降,但在过去六个月内撰写正面评论将表明信任得以修复或重建。

信任因素不仅是特定于 API 是否是错误或误导性数据的已知来源。EAP 的信誉也将取决于其对范围内的 API 的管理和更新程度如何。此外,“信任” 也是相对的。服务 A 可以信任服务 C,但服务 B 可能对服务 C 有不同的感触。

边缘基础设施管理器

随着分布式云成为边缘 2.0 基础设施的基础,EAP 范围内的资源必须易于发现、保障和检测。以下内容可以理解为边缘基础设施管理器能力所需的一系列建议。

发现与安排

在 EAP 内,可以根据需要安排资源。但因移动性,新资源可能动态到达或离开。EAP 也可以发送或接收其他 EAP 的请求,以代表其发现并安排所需的资源。

安全性

重申一下安全态势:在其中部署应用的基础设施已遭受损害。因此,EAP 必须确保部署在其范围内的应用的安全。

无论管理级别如何,EAP 框架必须考虑到安全的多个方面,例如(但不限于):

外部威胁:例如,分布式拒绝服务 (DDoS) 攻击和高级持续性威胁 (APT)。这些威胁都可以利用现有的安全最佳实践来加以缓解,如 DDoS 防护、防火墙等。建议是所有流量都需要。

中间人:所有流量都必须加密,不能假定应用层会采取适当措施。这可确保基本的数据保密性,而不受任何流量窥探设备的影响并保护数据的完整性,使其在传输过程中不被篡改。

内部威胁:基础设施层的范围必须受到限制,主要针对自我保护。建议是防止基础设施内的资源对基础设施管理器发起内部攻击。

以体验为中心的遥测

如果边缘 2.0 关于其所提供的体验,而非资产或其位置,那么遥测自然而然地也必须以体验为中心。

问题是,我们所指的体验对象为何?它是指位于或使用基础设施来生产或消费服务的任何实体:应用、设备、人类、后端应用、数据库等。因此,体验的观点即实体的观点。实体生产或消费的服务与分配给其的计算、存储和网络资源直接相关。

但我们不能仅停留在衡量体验方面;还必须制定补救措施。

任何消费或提供服务的实体都可以确定其是否获得了所期的体验。然而,在分布式云环境中,可能几乎不可能阐释在基础设施层发生了什么导致体验不佳。

像 CPU 利用率、内存、带宽和延迟测量这样的高级指标不足以确定为何应用没有获得所期的3体验。指标需为多粒度时间,并在应用堆栈的深处收集,只要是基础设施堆栈的不同层都可以收集。

强大、可扩展的遥测和数据策略对 EAP 而言至关重要。可以利用机器学习 (ML) 和人工智能 (AI) 战略,对预留新资源或优化使用现有资源做出最佳决策。

软件定义的应用连接

虽然连接和可达性被认为是已解决的问题,但许多网络团队仍在努力使其网络结构与应用层的动态需求合理化。平台也必须解决这些挑战。

分隔应用连接面板的案例

现有方法的问题是我们将应用连接需求转化为企业 WAN 连接,特别是在分布式云中。解决分布式云网络的方法可以使用不同的 SDN 策略或纯粹基于路由的方法。但这些解决方案严重依赖基础设施的同质性,因此在提供一致行为方面有所欠缺。

我们能够为应用实现全球可扩展、安全和稳定网络的唯一方法是将应用连接面板与底层网络分隔开,接下来我们会对此进行讨论。

拟议的连接堆栈

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

图 11:认识到应用连接面板与底层网络(企业和骨干网)不同

有了边缘 2.0,即使是连接企业网络,我们也需要这种表面上的稳定性。我们建议,应用连接面板必须与企业网络连接分开。应用连接模式可能遵循也可能不遵循与数据中心叠加(例如 VXLAN、NVGRE 等)或基于 BGP 之 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,但随着时间的推移,使用自然语言处理和人工智能来降低所需的输入品质,实施起来会更加先进和成熟。

简化操作

不同的操作模式也变得十分简单,只需指定所需的状态即可。例如,弹性模式可以仅基于预期的 SLO。提供服务的 EAP 有责任确保分配其范围内的资源以满足服务级目标。调用 EAP 无需在意,但可能需要监控服务指标以了解其是否得以满足。

EAP 功能

  • 多租户:虽然图 9 显示的 EAP 网格针对单一部署,但每个云有可能有多个 EAP。其他应用可以与不同的 EAP 或 EAP 网格通讯。
  • 按比扩展:每个网格都是点对点 (P2P) 网格,可以水平扩展。对等 EAP 可以独立跟踪哪些 EAP 拥有哪些资源类型以及如何连接资源。AI/ML 将进一步加强每个 EAP 如何在各自范围内安排资源或根据需要联系其他 EAP。
  • 内建网络:为使应用能够在分布式云中连接,EAP 必须支持与底层基础设施无关的内建网络。

整合在一起

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

重点在于:

  • 每个 EAP 的范围都很局限,图 10 没有指出其所有的能力。EAP 必须支持资源发现和功能安排。EAP 通过适应性 API 与适当的基础设施控制器交互,从而安排资源。
图 12:显示不同实体与层所发挥作用的参考。
  • 应用连接与网络连接不同,就像服务网格 sidecar 模型一样,跨多云连接应用的资源必须是应用基础设施的一部分。有人会说,基础设施面板也提供应用网络连接,因此应处于网络层之下。这在技术层面上来说正确无误,但我们选择将其归入“应用连接”面板,因为这些主要是网络功能。
  • 基础设施面板必须与应用面板分隔开。
  • 网络连接与传输不同,因为我们基本上是在讨论特定的可路由网络,其与应用连接分隔开来。
  • 传输面板可被视为可被配置的聚合骨干网,前提是电信运营商启用流程和 API 来连接上述网络层。

总结

本白皮书试图在最初版边缘 2.0 宣言的基础上再深入一些,引入了一些新主题,旨在为内部组织和外部行业的不同利益相关者提供相关信息。

边缘 2.0 建立在分布式云概念之上,其中每个实体都可以作为服务来源及目的地。主要的主题为边缘 2.0 是关乎于体验,而非资产或其位置。

边缘应用平台 (EAP) 可视为能力堆栈,促进在分布式云上实现边缘 2.0。

实施细节被刻意跳过,以呈现出与供应商无关的观点。

下载报告


资源

1 beyondcorp.com

2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf

3 Wikipedia - 自治系统 (AS) 是互联网际协议 (IP) 路由前缀的集合,由一个或多个网络运营商代表单一管理实体或域控制,向互联网提出共同且定义明确的路由策略。