下载掌阅APP，畅读海量书库
立即打开
本章将从网络的角度介绍多接入边缘计算（MEC），从云计算的历史背景开始，然后考虑驱动向边缘发展的新趋势（包括开放创新、网络软件化以及电信和信息技术（IT）的融合）。
什么是MEC？
为了正确理解这一点，我们实际上需要从结尾开始，字母“C”表示“计算”。本书主要是关于计算的，而且当下更多指的是“云计算”（不管这意味着什么，我们稍后再进行讨论）。然后，这里有一个“E”表示“边缘”，你很可能认为你知道什么是“边缘计算”，但我们敢说你的定义太窄了。我们希望这本书至少有助于拓宽你的“边缘视野”。最后，“M”代表“多接入”（Multi-access）。这里，“接入”（access）很重要——表示以某种方式“连接”到了“接入”的“边缘计算”（不管它代表什么）——也就是说，用户和其他客户端设备（例如构建物联网（IoT）的数十亿件事物）用来“接入”互联网的网络。“Multi”是首字母缩略词中最不重要的部分，它表示MEC技术可用于各种网络（移动、Wi-Fi、固定接入等）以支持各种应用。
因此，MEC似乎是一种奇美拉（chimera）技术——一种远离云的云技术，与网络有着重要的关系。而且我们可以看到，它来自几个不同的已经存在了一段时间的趋势的融合。但这并不意味着MEC作为一个领域是不协调的、脱节的和不起作用的——不像神话中的奇美拉那样。
从理论上说，MEC代表了计算、通信和控制（根据它对实现工业物联网的重要性）的实用融合，这是现代信息科学的圣杯。与集中式“优化”方法相比，它也生动地展示了分散决策的效率和稳健性。
一个合适的起点似乎是回答“为什么通常需要边缘计算，尤其是MEC”的问题。关于该主题的文章很多，它们可以总结如下：有些应用程序无法使用传统的基于云的应用程序托管环境。发生这种情况可能有多种原因，其中一些较为常见的是：
边缘计算的一个重要驱动力是物联网，其中边缘计算通常称为雾计算（fog computing）。美国国家标准与技术研究院（NIST）在其“Fog Computing: Conceptual Model”报告 [8] 中声明：
管理物联网传感器和执行器生成的数据是部署物联网系统时面临的最大挑战之一。传统的基于云的物联网系统面临着一些云生态系统中存在的大规模、异构和高延迟问题的挑战。一种解决方案是使用分布式和联合计算模型，将应用程序、管理和数据分析分散到网络本身。
此外，物联网正迅速发展成为边缘计算收益的重要驱动，微软的边缘云解决方案“Azure IoT Edge”就是证明。
然而，物联网只是需要边缘计算的几种类型的应用之一。在一份对定义“5G”具有广泛影响的白皮书中，下一代移动网络（NGMN）联盟列出了定义5G用户体验和驱动5G移动网络需求的8类5G应用 [9] ，包括：
对这些类别进行粗略的顶层分析，我们可以得出这样的结论：大多数类别要么需要边缘计算，要么能从中显著受益。事实上，我们可以做出以下陈述：
显然，边缘计算是5G的关键使能技术，这一点早在NGMN的论文中就得到了认可，该论文将“智能边缘节点”列为“技术构建块”，并列出了它在靠近用户的情况下运行核心网络服务的用途，以及它在边缘缓存等应用服务方面的潜在用途。
然而，NGMN的论文虽然专注于移动网络，但却遗漏了一点，因为NGMN的“智能边缘节点”是应用的着陆区，所以它确实需要成为一种“云节点”。欧洲电信标准化协会（ETSI）在白皮书《移动边缘计算：一项通向5G的关键技术》以及专注于所谓移动边缘计算（Mobile Edge Computing，MEC）的行业规范组（ISG） [10] 的创建中，都提出了这一主题。几年后，因为认识到其工作适用于所有类型的接入网（移动（3GPP定义）以及Wi-Fi、固定接入等），该工作组更名为多接入边缘计算（Multi-access Edge Computing，保留MEC缩写）。这里引用其释义：
MEC代表了一项关键技术和架构概念，因为它有助于推进移动宽带网络向可编程世界的转型，并有助于满足5G在预期吞吐量、延迟、可扩展性和自动化等方面的苛刻要求，使其能够向5G演进。
所有这些工作都忽略了，或者说没有突出强调的一点是，边缘计算（尤其是MEC）不仅仅是一种“5G技术”。事实上，MEC是一种关键工具，它使运营商能够在其现有的4G网络上启动5G应用。这可能会对MEC的商业方面产生重大影响——参考文献[11]和我们在第3章中关于MEC的经济和商业方面的讨论将对此进行详细介绍。
在这一简短的介绍性讨论的末尾，让我们总结一下主题：边缘存在是构建5G工作网络的必备条件。这包括物联网，物联网是许多初始部署的重点，但涵盖了更广泛的应用、用例和市场。MEC通过在接入网中创建一个类似云的应用着陆区来实现这种边缘存在，也就是说，尽可能靠近客户端设备。因此，它是5G、IoT、AR / VR等新兴计算领域的关键推动力。本书对这些主题进行了扩展，详细分析了它们的含义、各种生态系统参与者、挑战和机遇，并概述了所涉及的关键技术。然而，我们必须首先实际解释什么是MEC，或者什么不是MEC，这就是我们接下来要讨论的问题。
回想一下，前面我们注意到“MEC”中的主要字母是最后一个——“C”表示“计算”（Computing），但实际上表示“云计算”（Cloud Computing）。因此，我们先从MEC的云计算方面开始。维基百科中对“云计算”的定义如下。
云计算是一种IT范式，它支持对可配置系统资源和可以最小的管理工作量快速调配的更高级别服务的共享池的无处不在的访问，这些访问通常通过互联网进行。云计算依赖资源共享以实现一致性和规模经济，类似于公用设施。
正如维基百科指出的，这个词虽然在2005年左右曾被Amazon Web Services（AWS）普及，但至少可以再往前追溯10年。因此，边缘计算的云计算方面似乎已是众所周知的事情。事实上，边缘计算的主要目标之一是“支持对可配置系统资源和可快速调配的更高级别服务的共享池的无处不在的访问”。注重细节的读者可能会想知道为什么只引用到了这里，事实上这是有意的。
让我们考虑一下上面没有引用的内容，特别是“资源共享以实现一致性和规模经济”。事实上，要实现这两个术语所描述的内容，需要取得重大进展，而这需要几十年才能实现，直到云计算成为经济上可行的业务：
上述发展和由此产生的技术使得企业和云提供商能够将向应用提供计算资源的系统组合在一起，作为一个统一抽象资源（vCPU、虚拟RAM、虚拟磁盘存储等）的同质池，这些资源可以在不考虑其物理来源的情况下使用。为了强调这项任务的实际困难，我们注意到，即使在现在，x86 CPU架构仍然是最流行的虚拟化架构。虽然基于ARM的处理器在许多行业（包括电信行业）都很普遍，但对于ARM虚拟化来说，情况并非如此，ARM虚拟化的使用率明显低于基于x86的虚拟化。此外，如果你有一个需要访问GPU的高性能计算应用程序，那么你就不走运了。尽管GPU广泛应用于各种应用程序，但GPU虚拟化支持现在才由OpenStack开发出来。这种不被采用的情况并不是因为任何深层次的技术挑战。以ARM为例，虚拟化技术已经出现了一段时间。这是因为云系统需要规模经济才能有意义，而实现这样的规模需要很多因素的及时融合，包括应用和工具组成的广泛生态系统的存在，这些应用和工具可以“在适当的时候”聚集在一起，使云发挥作用。
那么，MEC是一种云技术吗？当然是。它完全是关于计算（和存储）资源的抽象，其方式与传统云技术完全相同。与传统的云技术一样，MEC利用了现代资源访问模式（特别是基于Web的资源访问）和管理框架。例如，所有ETSI MEC API都被定义为RESTful并使用HTTP作为默认传输协议。然而，它与传统云在一个关键方面有所不同：规模。我们并不是暗示MEC（更广泛地说是边缘计算）缺乏与传统云计算相同的规模。相反，规模的性质以及由此带来的挑战具有不同的本质。为了正确理解这一点，我们需要研究MEC的第二个组成部分——表示“边缘”（Edge）的字母“E”。
边缘计算之所以现在成为云计算和电信领域的热门话题，不是因为它是一项热门的新技术，而是有很多重要的原因。边缘计算的起源至少可以追溯到2000～2005年开发的边缘内容分发网络（CDN）。可以从CloudFlare网站（ www.cloudflare.com/learning/cdn/glossary/edge-server/ ）上找到一个很好的简短摘要：
边缘服务器是一种提供网络入口点的边缘设备。其他边缘设备包括路由器和路由式交换机。边缘设备通常放置在互联网交换点（IxP）内，以允许不同的网络来连接和共享传输。
CloudFlare网站上还有一个很好的图示，如图1.1所示。
图1.1 边缘CDN图示（来自CloudFlare）
这里我们要做一个重要的观察。CloudFlare定义的边缘CDN服务器实际上位于用户与通信服务提供商（CSP）网络（互联网服务提供商（ISP）是CSP的一种特殊情况）的最远点。在某种程度上，这是由一个简单的必然情况决定的——边缘CDN提供商（如CloudFlare和Akamai）根本无法将它们的设备离用户更近，因为这意味着要离开互联网，将它们的设备放在CSP的专有网络中。
这导致了一个自然的下一步，即开发尽可能靠近用户的CSP所有的“边缘CDN”。
在移动网络的情况下，这意味着将其定位在无线接入网（RAN）上，或者更确切地说，将RAN连接到核心网络的“S1”接口上。不幸的是，这样做需要截获正常的流量，在5G之前的移动核心网络中，这些流量是在RAN（例如基站）和分组网关（PGW）之间进行隧道传输的。PGW位于移动网络最远的边缘，即“正常”边缘CDN所在的位置
。图1.2显示了这种情况，即4G核心网络（称为“演进的分组核心”（ePC））的高度简化图。ePC接口有标签，但其中的S1接口（注意：有两个！）和SGi接口将非常重要，它们将多次出现在本书的多个讨论点上，如关于“S1上的MEC”和“SGi上的MEC”实现选项部分。S1-U接口（用于S1用户面）将RAN连接到服务网关（SGW）并承载用户流量，而S1-MME接口将RAN连接到移动性管理实体（MME）并承载控制最终用户设备访问RAN的各个方面的流量。S1接口应该被视为“控制面”。SGi接口是3GPP给予进出ePC的“普通IP流量”接口的“架构参考”。虽然边缘CDN可以放置在ePC中的其他逻辑位置（例如：S5上，SGW中），但一般来说，假设你要进入移动网络，会希望其位于RAN中，也就是在S1接口上。
图1.2 高度简化的4G核心网络显示了边缘CDN的位置
在S1上有一个“边缘CDN”节点以及提供其他服务的可能性的需求，导致了标准定义架构（LIPA）和“透明的”本地突破方法的开发，S1上的通道被打破。在2005年左右，这两种方法都是被积极开发和产品化的主题，并且预计MEC将被用于比“边缘数据缓存”更广泛的应用中。有关与边缘缓存完全不同的示例，以及如何在“S1上”定位处理的较完善讨论，请参见参考文献[3]。这里需要注意的是，在目前由3GPP定义的5G架构中，通过一个正确定位的用户面功能（UPF），在RAN旁边的应用程序功能的放置将以本地方式支持。我们将在后面更详细地讨论这个问题。
然而，回到传统的边缘CDN，我们注意到它在CSP网络的远端位置是由另一个附加因素决定的——这些实体的工作方式。至少在一定程度上，它们使用复杂的算法来分析用户数量统计和内容请求统计，并试图预测哪些内容可能会被哪些用户群请求。只有当用户和内容总体统计数据足够大，并且“边缘”站点的存储也足以容纳大量内容时，这才有效。将边缘CDN移近用户还会减少在任意给定时间服务的用户群体的数量大小（也就是统计样本），以及通过缓存点的内容量（同样是统计样本）。这可以通过增加缓存的大小来抵消。不幸的是，转向边缘的经济性决定了恰恰相反的情况——必须减少存储量。因此，传统的边缘缓存方法不会比CSP网络的边缘更有效。
解决这一问题的方法是充分利用处于最边缘的丰富环境。例如：为咖啡店提供服务的一个非常小的小区是高度情景化的，它的用户群很可能喜欢咖啡，并且有一个与该咖啡店相关联的特定配置文件。如果该内容可以公开给应用，应用就会知道如何去处理它。如果它随后在小区中为其内容提供一个着陆区（landing zone），那么它很可能会非常明确该如何处理这些存储。这个想法得到了小蜂窝（Small Cells）社区的认可，小蜂窝论坛（Small Cells Forum）在这个领域的工作记录可参见参考文献[4-7]。然而，它的实现还需要等待边缘计算的实现。毕竟，一旦为应用提供了内容的着陆区，下一步自然就是为应用的计算建立一个着陆区，至少对于一些可能在边缘运行的组件来说是这样。
显然，在边缘做点什么的想法既不新鲜，也没有某些技术的支持，但这仍然留下了一些开放性的问题：什么是边缘？边缘在哪里？边缘和传统云的边界在哪里？现在让我们发表以下大胆的声明。读者可能会被问到一个更难回答的问题：在“边缘计算”的背景下，什么是“边缘”呢？举一些好例子很容易。此外，如果你深深地沉浸在你自己的领域，你可能会认为你的例子才是实际上的边缘。但是，当你和一个在相关领域工作的熟人交谈时，你会惊讶地发现，他们的“边缘”与你的不同，事实上很难界定“深层”云的终点和“边缘”的起点。然而，这正是我们需要做的事情——否则，本书的其余部分就没有意义了。除非我们与读者对本书的内容有一些共同的理解，否则我们不可能写出一本对广大读者有用的书（或是一篇文章）。
正如我们认识到的那样，我们需要从良好的例子开始。亚马逊似乎对“什么是边缘”有一个清晰的定义——看看它的Greengrass软件。微软或多或少同意亚马逊的观点，比如Azure IoT Edge或Azure Stack。这就引出了以下定义：边缘是公共云对本地部署的扩展。其目的是为企业客户提供一种跨“深层”公共云和本地部署的边缘云的统一管理体验，其中还包括无缝的自动化工作负载迁移（当然，取决于规模和其他限制因素）
。事实上，在当今的企业计算领域，这是一个非常好的定义，因此对我们来说是一个好的起点。
少了什么东西呢？边缘计算的一个例子就是用户处所设备（CPE），其存在于大多数企业中，且不完全符合这一定义。CPE是广域网（WAN）基础设施的一个组成部分，由CSP提供给它的（一般）企业用户。它驻留在客户的站点上，并终止与该站点的WAN链路。其目的是在特定站点提供WAN通信能力和局域网（LAN）之间的安全可靠访问。因此，CPE通常包括用于在WAN和LAN之间移动流量的交换和智能路由功能，并且当存在多个这样的链路时，也用于跨WAN链路之间的负载平衡（在通常情况下）。此外，CPE还提供了防火墙，为进出企业的流量提供行业标准的安全服务。交换/路由和防火墙功能通常都是策略可配置的，并支持QoS差异化、与企业策略系统的集成等。在某些情况下，附加功能（如CSP所需的对计费、合规性或Wi-Fi AP（接入点）以及LTE eNB等的支持）也可能是CPE的一部分。
传统的CPE由所有这些组件的离散垂直（硬件+软件）实现组成。通常，这些都被打包到一个“盒子”中（但并不总是这样），这样CPE对用户来说就成了一个单独的设备。然而，CPE的内部仍然基于硬件，这使得升级、维护和修复变得不灵活且成本高昂。
最近，业界一直在向灵活、可配置且通常是虚拟化的广域网方法（通常称为软件定义广域网（SD-WAN））迈进。作为这一趋势的一部分，越来越多的人开始用灵活的“通用”CPE（uCPE）取代传统的CPE，其中所有的CPE应用都被虚拟化并在通用计算平台上运行。图1.3显示了一个典型的uCPE示例，其中除了标准的uCPE应用外，还有一个WLAN控制器应用。
图1.3 uCPE的一个例子
与其他应用一样，虚拟化带来了显著的优势：能够远程监控、维护和升级各种uCPE应用，以及频繁、廉价地进行这些操作（以前是硬件更改，现在变成了软件升级）；能够在通用的平台上发布不同的CPE应用（如不同的最大吞吐量、最大连接数、用户数、广域网链路等）——事实上，这是一种将一种CPE转变为另一种CPE的能力（因此有“通用”的绰号）。例如，图1.3中的uCPE设备可能在没有WLAN控制器应用的情况下被运送到客户站点。在某些情况下，当设备到达现场时，客户会要求添加WLAN控制器功能。将适用的应用远程推送到设备并激活，而客户只需打开并连接WLAN AP即可。如果uCPE中的计算平台有足够的能力运行这个附加的应用，那么所有这些操作都是远程完成的，而不需要停止WAN功能（因为不需要关闭其他应用），并且与客户的交互最少。
此时，uCPE实际上是另一个运行在通用计算（generic compute）之上的虚拟化应用（或者更确切地说是一组这样的应用），因此uCPE应该可以在企业运行其他应用的同一个本地部署边缘云（例如，AWS或Azure的边缘解决方案）上运行。但是，uCPE上运行的应用在几个关键方面与标准云应用有所不同。
对实时数据流的操作是这些应用的一个关键方面，因此，它们与物理基础设施的“联网”组件进行了大量交互。一种常见的方法是通过数据平面虚拟化来实现，即以太网交换机在x86计算机上虚拟化（Open vSwitch就是一个例子），“联网”只是物理层功能。然后，更高层的应用（PBR、路由器等）与这个虚拟化交换机交互。第二种常见方法是使用SDN，在这种情况下，“联网”组件是可编程交换机（例如OpenFlow交换机），由虚拟化基础设施内的SDN控制，上层应用与SDN控制器交互。
无论采用何种联网方法，需要对实时数据进行操作的结果是，uCPE应用的操作要求与传统的由企业操作并虚拟化的“IT”应用有很大不同。应用停机（即使持续非常短的时间）也可能导致严重的服务中断和数据丢失。通过应用实例的冗余实现负载平衡和恢复是很困难的——当然，你可以在多个计算节点上运行多个PBR实例，但你不可能在任何给定的时间复制一个实例正在处理的数据。
uCPE应用的一个相关方面与其用于满足CSP任务的需求有关。其中包括合同服务水平协议（SLA）——本质上是与CSP向企业提供的连接服务相关联的性能保证。更重要的是，这些通信链路往往是关键基础设施的一部分，即停机可能对业务性能产生重大甚至灾难性影响的基础设施，而如果涉及公共基础设施，则可能会对人们的生活产生重大影响。最后，就公共基础设施而言，uCPE的性能受到各种监管——从其作为关键基础设施的潜在作用到合法拦截等。所有这些都无法承受故障带来的后果，而对于“IT”应用来说，这些故障却可以通过冗余和负载平衡的现行标准方法轻松解决。
这些截然不同的需求导致了一种认识的形成，即这些需求代表了一种不同类型的虚拟应用，实现这些功能的基础设施也必须有所不同。这种不同的虚拟化方法现在被称为网络功能虚拟化（NFV），它所需要的虚拟化和管理基础设施与“IT”和“Web”应用的传统虚拟化领域是不同的，这一点已被广泛接受。
ETSI的NFV ISG已经为这种基础设施的管理框架开发了一个关键样板，本书将更深入地研究这个框架。然而，正如我们区分“边缘计算”“MEC”和“ETSI MEC”三者那样，我们提醒读者不要将NFV的一般概念与ETSI NFV的特定管理框架混淆——后者既是前者的子集（侧重于管理方面），也是通用概念的具体示例。
所以现在，我们可以回到我们以前问过的问题——为什么不能在企业运行其他应用的同一个本地部署边缘云上运行uCPE应用？答案很简单，因为企业边缘云就是这样，它不是NFV云。它们通常不能运行NFV基础设施——这对于当前实现的亚马逊边缘环境和微软边缘环境来说，确实是这样。因此，大多数NFV部署都使用OpenStack。此外，典型的企业应用程序不会公开NFV的网络方面需求。计算集群（和底层网络）是为企业和NFV的不同需求而构建的，因此，它们应该产生不同的架构。NFV应用程序被“打包”为虚拟网络功能（VNF），所需的管理通常比标准虚拟化堆栈（如OpenStack或VMware）所能提供的要多，因此需要VNF管理器和NFV编排器等软件。服务编排是使用比Ansible或Puppet更为复杂的工具来完成的，并不是因为这些工具不好，恰恰相反，它们在企业领域的成功已经说明了它们的出色，只是因为它们不适用于NFV领域。
显然，uCPE与典型的企业应用程序不同，但它是否只是一个个例，一个不必泛化的特例？答案是否定的，尽管uCPE可能是企业内部运行的“多接入”边缘计算的唯一例子。以下是CSP网络中可能部署边缘云的部分位置：用户驻地（仅针对企业讨论，不针对住宅）、天线塔、光纤汇聚点、中心局（CO）、移动电话交换局（MTSO）。可能在这些位置运行的应用程序包括：云无线接入网（CRAN）的分布单元（DU）和集中单元（CU）、包保护（ePC）、边界网关、移动网络视频优化、深度包检查等。所有这些都是VNF，因此其行为和要求与uCPE相似，而与传统的“IT”应用程序不同，就像uCPE不同于传统uCPE应用程序一样。
这确实引出了一个问题，为什么有那么多位置运行着这么多“奇怪的应用程序”？毕竟像亚马逊和微软提供的企业和网络服务，似乎只需要两个位置——云和驻地。为什么电信如此不同？很大程度上是因为在传统的IT/Web服务领域中只有两个实体：云和企业驻地。剩下的只是一根管道。自从互联网出现以来，在这个“顶层”（Over-The-Top，OTT）领域的参与者从来不需要担心管道是如何工作的。这曾经是而且现在仍然是互联网的“魔力”所在。
然而，这个“管道”实际上是一个高度复杂的全球工程系统（也许是人类创造的最复杂的系统），其中使用了多个高度复杂的组件来确保关键通信和YouTube视频请求都能获得预期的QoS。一旦我们开始讨论组成这个基础设施的组件的虚拟化，我们就不能再忽视它的复杂性了——它暴露在我们面前，我们就必须应对它。
此外，这一精心设计的全球系统依赖于大规模分布式基础设施——也许是世界上唯一一个具有如此规模的分布式基础设施。因此，它是“边缘原生的”（edge native）——可能多达90%的电信系统都是边缘。当这些组件被虚拟化并迁移到通用计算平台时，每个组件都成为一个云计算存在点。所以，我们还是有很多选择的。
这引发了另一个问题：CSP真的需要所有这些选项吗？对于任何一个CSP来说，答案都是否定的。每个提供商可能会选择少量边缘云“地点”——有可能只有一个，这取决于每个CSP的具体情况：其网络的架构——无线接入网（RAN）、接入等；它们所服务的人口统计类型；所需启用的用例以及与这些CSP相关的业务案例。所有这些在不同的运营商之间都会有很大不同，因此它们对“边缘”的定义也会有很大不同。此外，它们也会随着时间的推移而变化，因此每个运营商的边缘架构都需要具有架构可塑性。鉴于电信行业中CSP的所有这些可变性，确实需要启用所有这些不同的选项。这意味着我们需要开发基础设施、标准、管理框架等，以一种简单、统一和高度可扩展的方式处理所有这些选项。
在这里，有必要撇开主题讨论一下标准化的作用。如果你是一个“电信人”，你的反应可能是：“为什么？我们当然需要标准！”然而，如果你是一个“云人”，你的反应可能是：“为什么？到目前为止，我还没有必要为标准操心。”因此，当谈到MEC时，我们再一次对一个可能至关重要的话题持有不同的观点，这就是为什么我们需要偏离主题。
为了理解造成这种差异的根本原因，我们需要再次考虑传统的“IT”和“Web”应用程序是如何开发的。开发团队做出了许多关键决策：架构方法（例如微服务）、开发和运营理念（例如DevOps）、计算平台（如果你计划虚拟化，很可能是x86）等，其中包括云提供商/堆栈。一些常见的选择可能是AWS、Azure、Kubernetes、Mesophere、OpenStack等
，其中每一个都有自己的管理服务的方法，也就是说，有自己的API。配置、管理以及保证脚本和服务必须使用这些API。然而，这并不是问题。毕竟，开发团队只会选择一个，也许两个。团队很有可能已经熟悉了环境，但是即使是全新的环境，经过一段时间的学习之后，你也可以开始正常工作了。此外，如果你使用一个被广泛应用的平台，那么无论是在开源领域还是在商业软件领域，都有很多好的工具可以提供帮助。
让我们把这个经验转化到MEC，记住MEC是关于CSP提供商的边缘云，也就是说，CSP变成了云提供商。为了简单起见，我们把注意力集中在美国。在撰写本书时，美国有四大移动运营商：Verizon、AT&T、Sprint和T-Mobile。也有几个主要的独立宽带/有线电视提供商：Comcast、Spectrum、Time Warner和CenturyLink。有了MEC，它们中的每一个都将成为边缘云提供商，这似乎与前面列出的AWS、Azure、Kubernetes、OpenStack等生态系统类似，但除了一个关键点，那就是： 你不能只选择一个或两个。作为应用程序开发者，你必须能够处理以上所有这些。
考虑一下你的用户，原因就显而易见了：他们必须能够访问你的云实例。然而，尽管你期望大多数用户大部分时间都能够访问AWS，并且能够一直访问运行OpenStack的私有云，但是期望运营商1（Op1）的用户能够访问运营商2（Op2）的边缘云是不合理的。即使能够访问，Op2的边缘云也不是Op1用户的边缘云。为了达到这个目的，他们的通信必须“离开”Op1的网络，穿过互联网，然后进入Op2的云。这样任何边缘优势（邻近性、低延迟、最小化网络带宽等）都将丢失——事实上，Op1用户最好网外访问公共云托管的实例。我们在图1.4中对此进行了说明。
图1.4 到公共云和另一个运营商边缘云路径的说明
这就要求应用程序开发者能够与任何地理位置上的大多数CSP一起工作，而应用程序需要能够出现在这些地理位置的边缘。然而，对于大多数应用程序开发者来说，这样的扩展根本不可行，而且即使在可行的地方，所涉及的经济投入也是难以想象的。这是一个我们将在本书中多次提到的问题，因此给它一个简短的名称是很有用的，我们称之为应用程序开发者的扩展性问题（Application Developers' Scaling Problem，ADSP）。ADSP有许多方面需要注意——如何建立适当的业务关系、指定在何处部署应用程序、如何管理应用程序实例等。这里尤其关注的是技术问题——应用程序开发者如何编写一次软件，并确保它能在每个边缘云上正常工作。
幸运的是，这个问题只是通信行业中一个众所周知的问题的一个特例，即多设备供应商的互操作性问题。例如：想想不同制造商生产的各种类型的Wi-Fi设备，它们以不同的形状和尺寸与Wi-Fi接入点配合使用，而这些Wi-Fi接入点设备同样也是由不同制造商制造的，形状和尺寸也完全不同（从家用Wi-Fi路由器到企业WLAN，再到打印机中越来越多的软AP等）。而标准则是通信行业用来解决这一问题的手段。当成功时（如许多技术一样，许多标准都不成功），标准可以促进新生态系统的巨大增长，推动全新的应用程序和业务。我们见证了IEEE 802.11标准的成功，该标准是Wi-Fi的基础。还有3GPP标准集，它是GSM时代以来全球移动通信产业的基础。
因此，解决ADSP的技术问题需要一个标准，更准确地说，是应用程序和MEC云之间的标准化接口。正如我们将在ETSI的MEC中进一步看到的那样，标准就定义了这样一个接口。此外，ADSP并不是MEC中涉及多设备供应商互操作性的唯一方面，我们将在后面的一些章节中看到。
在我们的社区中有一种感觉，虽然行业标准接口定义很重要，但这些定义不必来自传统的“标准”，相反，它们可以来自开发社区，例如：来自开源项目。此外，从开源项目中获取会更好，因为结果不仅仅是一个文档，还包括运行的代码。
让我们在这里达成共识：开源已经并正在产生巨大的影响。开源极大地降低了进入市场的门槛，从而使小型、灵活和高度创新的公司能够在更平等的基础上与大型老牌企业竞争。它是通过提供一个基础来建立的，允许一个小团队（或者一个大团队）只关注那些可以提供增值的领域。一个引人注目的例子是：TensorFlow允许开发者使用大约20行相当简单的Python代码来部署机器学习算法。这意味着数据公司不再需要花费时间和资源来开发神经网络处理机制。相反，他们可以专注于其增值的地方——数据科学。
然而，这并不意味着开源可以扮演标准所扮演的角色。实际上并非如此！为了说明这一点，让我们选择OpenStack。不是因为它不好，恰恰相反，因为它是一个非常好的开源项目，而且非常成功，所以它是一个表达观点的好地方。任何使用过OpenStack的人都知道，我们对API进行开发，而不是开发API本身。
是的，它们几乎是一样的，但又不完全一样。对于一家小公司，拥有100个呈现相同接口的边缘云仍然会让你面临扩展的挑战，以便与100个略微不同（但仍然不同）的实现进行集成。换言之，你仍然缺少标准。
这里的一个简单事实是，标准不能取代开源——因为标准不会告诉你如何构建任何东西，而开源也不能取代标准。在理想的情况下，开源项目将在需要使用标准化接口的领域中使用标准化接口，也就是说，在需要大规模供应商互操作的领域中使用标准化接口。这样对业界来说是两全其美的。
在这个介绍性章节中，我们尝试了很多事情：让读者了解为什么边缘很重要，定义什么是边缘，以及讨论各种生态系统参与者的角色，包括标准和开源。这是一个高层次的概述，本书的其余部分对这些主题进行了更深入的探讨——试图在前言中写下整本书是不可能的，也是愚蠢的。
我们还希望能够提供足够的历史视角，让你感觉到边缘计算，特别是MEC，并不是一个突然出现的激进的新想法。相反，它是几个现有的和长期发展的链条的综合，这些链条聚在一起解决一个新的需求。它们的同时出现并不是偶然的，而是由非常相似的时间线驱动，也就是说，技术的成熟使边缘计算在经济上可行，并结合了潜在市场需求的出现。
话虽如此，如果你读完前言，以为围绕边缘计算的主要问题已经解决了，那就错了——事实远远不是这样。正如我们将在接下来的章节中看到的，已经基本解决的是如何建立一个单一MEC站点的技术问题，即接入网上的一个单一边缘云，接入网流量有某种形式的中断，上面运行有一些简单的应用程序。换句话说，我们（广泛的电信和云计算社区）知道如何构建概念验证和现场试验。
一旦投入生产，我们将不得不管理成千上万个小云。没有人真的知道应该怎么做。谷歌管理着世界各地的几十个大型云，而不是成千上万个小型云。在许多情况下，这些云将运行来自彼此不信任的实体的工作负载（按照“信任”的正式定义方式），其中一些实体运行构成关键的、实时监管的基础设施的软件应用程序，而其他实体则运行游戏等内容。它们是如何工作的？有一些潜在的答案，但没有“最佳实践”——因为还没有大规模的“实践”来支持从中选择出一些“最佳”的实践。
当这些云确实构成了关键基础设施的组成部分，或者仅仅是“重要”基础设施，它们会如何失败呢？我们需要做些什么来定位故障？回想一下，物联网是边缘计算的一个主要用例，这意味着边缘计算将在我们的生活中普及。正如许多最近的例子所表明的那样，复杂系统以我们无法理解的复杂方式失败，而且发生这种失败的灾难性后果比我们想象的要频繁得多（参见Nicholas Taleb在《反脆弱》一书中的讨论，参考文献[13]）。大规模分布式计算使这些系统更加复杂。如果你们中的任何人，正在寻找一个具有挑战性和影响力的博士学位研究课题，那选它就对了。
除了失败之外，我们还需要关注安全，但不仅仅是传统的云安全。对于网络意义上的“云”中数据的访问，我们担心的是有人通过盗用用户凭证、获得管理员对管理系统的访问权限等获得对这些数据的访问。但对于使用边缘计算，我们还需要担心物理访问——确切地说，是对众多云站点之一的未经授权接入。预防虽然至关重要，但由于规模如此之大，而且大多数站点的位置在本质上不如云提供商的数据中心那样安全，其作用十分有限（只能走到这一步）。如何检测入侵？如何保护敏感数据？恢复机制是什么？
同时，边缘计算在安全系统中可能是一项巨大的资产。例如，众所周知任播（Anycast IP）路由是一种有效的抵御拒绝服务（Denial-of-Service，DoS）攻击的缓解策略，特别是分布式DoS攻击。然而，基于任播的DDoS缓解的有效性取决于是否有一个高度分布式的基础设施，不仅是在端点（假设云提供商可以在数据中心的许多计算节点上提供多个端点），而且包括到端点的路径。由于物理原因，这很难实现——最终，流量必须集中在云所在的一个或几个物理站点上。边缘计算并非如此——大型MEC网络固有的规模和物理分布自然适合基于任播的DDoS防御。
然后，还有一个挑战是如何编写利用边缘这一优势的应用程序。我们知道它们可能应该依赖RESTful微服务，但实际上不是非常依赖。从非常实用的方法（参见参考文献[12]）到分布式计算潜在能力的基本问题 [14] （即，它是否能够以及如何完全实现图灵机所能实现的一切），分布式云计算的挑战仍没有得到广泛的研究，尽管关于分布式计算的大量现有工作必然是相关的，而且也许边缘才是诸如ICN之类的网络/计算范式找到其真正应用的地方。亚马逊将它的无服务器计算命名为“Lambda函数”，而AWS Greengrass目前在边缘支持的正是“Lambda函数”，这并非偶然。
边缘的社会影响也不为人知。从商业案例和策略这样的普通话题（我们将更详细地讨论这些话题）到更深入的问题，即无处不在的边缘云如何影响社会，人们对此的研究和了解都很少。然而，很明显，通过将灵活的通用计算放在边缘，并实现适当的通信和管理，MEC可以产生重大影响。从将云技术带到全球服务不足的地区，到诸如Sigfox的“Seconds to Save Lives”中的倡议，MEC（通常与物联网结合）能够以我们当前无法想象的方式重塑我们的生活。
这就把我们带到了讨论的最后一点——虽然MEC的一些用途将要出现，因为社会需要它们，但大多数需要坚实的商业考虑来驱动。简言之，各方都需要了解如何盈利。这一点尤其困难，因为MEC需要庞大的规模才能兑现其承诺。在一个城市的市中心有十几个MEC站点只是一个试点部署，而不是一个商业上可行的事业。这样的规模需要巨额的投资，而如果不了解如何从这些投资中获得回报，那么巨额投资是不可能发生的。虽然MEC的这些业务方面目前已经得到了很好的理解，我们将在本书中更深入地探讨某些部分。