边缘计算第三章，开始谈谈边缘计算的需求描述。任何新生事物，都是从需求收集阶段开始的。我们做软件工程，第一步涉及的也必然是需求分析。

什么是需求？需求的提供方和需求的接收方，本身就是矛盾的，也是辩证统一的。长命百岁算不算是对医学的需求？现代医学如果高度发达，这个目标就是合理需求，如果放在古代那就是痴人说梦，但我们不得不承认，用户需求是技术发展的动力。

在边缘计算项目里，用户需求常常会变，有时候甚至是很极端的。因用户最终需求还有待商榷，举这个例子也许不太恰当：笔者曾经遇到过国内某电梯厂商，项目要求电梯里安装传感器控制器。在一个中等小区里，所有设备加起来可能有2万个之多，他们希望边缘计算解决小区集中管理设备的问题。一般来说，我们可以希望几十个设备或者几百个设备就需要有一个控制节点，但是用户是站在成本的角度考虑问题的，他们认为2万个端设备，应该只需要一个控制节点就好了，这样不仅简化了管理，而且节省了开支。作为开发者，2万个设备能不能用一个控制节点远程管理，看到这还是有点懵圈。啥，就买一台服务器？作为英特尔员工的笔者，已经哭晕在厕所。

所以在边缘计算里，用户与开发者之间也是公说公有理，婆说婆有理。往往更多的时候，要进行协商，要相互妥协，要相互教育，而且随着项目的进展、技术的变化，原始需求也会呈迭代变化的。

我们知道，2010年OpenStack诞生以来，OpenStack一直模仿的对象是以AWS为代表的公有云，自2015年之后有段时间OpenStack更多的是解决企业私有云问题，也就是我们常说的企业就绪（Enterprise Readiness），模仿的对象是以VMware为代表的私有云产品。这还算不错的，因为都是有章可循，有对象可以参考。但是边缘计算的诞生，属于一个新鲜事物，基本上没有其它软件项目或成熟产品可以借鉴的，用户需求就只能通过调查研究，开会讨论以及头脑风暴靠想来形成，并且在实践中不断修正，其中也不乏一些在现阶段无法实现的美好愿望。

今天，我们就来讨论并总结归纳一下，到目前为止，笔者所看到的边缘计算需求。有了需求，开发者就知道该怎么努力该怎么修改代码，以满足这些需求。由于见识有限，本文可能概括不了所有需求，也必然有遗漏或错误的地方。欢迎各位看官，在留言本里踊跃留言，留下你觉得应该加的新需求。

让我们先回顾一下边缘计算里的概念。边缘计算的边缘指的是位于管理域的边缘，它们尽可能地靠近数据源或用户，这个概念适用于运营商网络、也适用于有众多分支机构的大企业，比如零售、智能工厂或者是与IoT相关的其它应用。到目前为止，大部分边缘计算的事都几乎跟运营商有关，移动、电信、联通或是美国的AT&T，因为他们是最有实力最有条件首先部署大规模边缘计算结点的金主。

当我们提到边缘计算概念的时候，不能不先提另两个词：雾计算和MEC。2011年美国哥伦比亚大学斯特尔佛教授首先提出雾计算这个词，2012年思科正式提出雾计算概念，指出它是一种系统级水平架构，分配从云计算到物联网这一连续区域内任何地方的计算、存储、网络和控制的资源和服务。后来2015年，思科、ARM、戴尔、英特尔、微软和普林斯顿大学等公司和机构联合发起成立开放雾计算联盟OpenFog，旨在驱动工业和学术界联合研究，通过互操作和兼容性研究实现云计算和边缘计算架构的无缝协作，应用端到端的IoT场景。

MEC顾名思义多接入边缘计算，指在网络边缘为应用开发商和内容提供商提供云计算能力和IT服务环境。应用可以充分利用边缘计算环境带来的低延迟、高带宽、实时访问无线网络信息的能力。2014年，欧洲电信标准协会ETSI成立了移动边缘计算（Mobile Edge Computing）规范工作组，推动相关标准化工作，在2016年，ETSI把MEC扩展为多接入边缘计算（Multi-Access Edge Computing），将边缘计算能力从电信蜂窝网络进一点延伸到其它接入网络，并提出了MEC参考架构，如下图所示。

因此，MEC就是运营商搞的边缘计算，通常认为三者之间的关系是这样的。

了解了它们之间的关系，了解了运营商是现阶段边缘计算的大户，对我们了解边缘计算的用户需求是十分有益的，那接下来我们就专注于MEC领域。我们以云计算为参照物，阐述边缘计算需要明确的基本设计规则包括以下几个方面，但不仅限于以下几个方面。之所以这么说，是因为由于时代和技术的发展，可能将来会出现新情况新问题新需求新设计规则。

提供一个跨多种基础设施的一致性操作模式

这点要求边缘计算对所管理的下面基础设施是没有具体限制的，是可以异构混杂的。它要求所支持的基础设施不论是规模大小还是种类都可以有巨大差异性的，可以是Intel芯片，也可以是ARM芯片；可以是几十个结点和设备，也可以是上万结点和设备，甚至可以是单个设备。现在云计算技术都很好的支持并具备相应功能，因此边缘计算如果能继承云计算基础架构，问题都不会太大。

能够支持大规模分布式环境，能够为全球分布的客户交付网络服务，能够实现区域隔离以保护本地数据的隐私

该点要求边缘计算能够扩展到非常多的站点，各站点又分别分布在不同的地理位置，一个靠近在用户端运行的应用程序运行时，需要处于并分配到正确的边缘部分，该边缘部分通过它的访问认证连接与更上一级的基础设施进行安全交互。多站点的所有资源池呈动态，虽然站点们处于不同地点它们之间被物理隔离了，但是站点之间可以进行相互连接，并通过广域网与核心联接。边缘计算与核心云计算数据中心也是隔离的，并且要求云计算不能影响边缘计算的相关服务。

从这点上看，边缘计算站点之间是需要分层分级管理的，连接认证要尽可能本地化。某运营商曾经做过一个比喻，如果网络功能虚拟化（NFV）可以比作是核心网的虚拟化，那么边缘计算就戏称接入网的虚拟化，运营商的接入就是分区县市省的。

能够满足应用集成、编排和服务交付需求

边缘计算还有一个重要特性就是无人值守，所以在服务部署和编排，后续应用集成上更强调少人工手动参与。在开源边缘计算项目Akraino里，就提出一个零接触业务配置和维护（Zero Touch Provisioning and Operations，ZTP）的概念，即要求相关技术支持多应用和服务的集成、编排和交付，背后它是利用ONAP来实现完成的。有了它，管理维护边缘计算成本将大大降低。

能够满足硬件资源的限制和成本的限制

边缘站点资源往往是受限的，由于空间或电源的限制导致不能随意往站点里面添加资源。例如：在有些场景里，摄像头传感器等资源可能会布在偏远地区，而且部署量也十分庞大，将来也必然会缺乏日常维护和升级，一个需求就是，用户可能会要求电池电量供应要能持续数年之久。对于边缘站点的其它资源，也会有硬件资源和成本限制的要求。在这点上，要求几乎达到了我国航空航天领域里的玉兔月球车和天宫空间站的水平了。

能够支持远程控制和管理，且能够运行在局限及不稳定的网络上

这就是我们通常所谓的“拉远管理”。边缘站点一般处于远端、数量大且太分散，用户也不太可能经常性派驻人员参与维护，那些边缘站点很可能无法被人现场操纵，因此边缘站点必须能够被远程管理，管理工具还要能支持在不可靠网络情况下，对边缘站点进行有效控制和管理。这点需求与集中在数据中心的云计算完全不同。读者可以看到，在下图中Akraino拉远了控制结点，使得控制结点（Regional Controller）与计算结点和存储结点不在同一个地方。

能够满足应用对超低延迟的需求

理想情况下，未来借助5G或更先进的网络技术，边缘计算应用能够带给用户低延迟和高带宽的高速服务体验。而且，边缘节点都会尽可能地靠近最终用户和数据源，能够提供数据和计算的本地化处理，即便是在高延时和不可靠连接网络情况下，边缘计算也能够利用策略管理和异步服务，提供无差别用户体验。

某运营商曾经对在边缘云里部署的CDN、SAE-GW、enterprise vCPE、5G-UP、MEC、CRAN、5G-CU和sCPE服务作过一个测量和调查统计。

调查因子包括延时、带宽、存储量级、虚拟化技术、计算结点规模和存储结点规模等，列出了各场景边缘云对这些因子的大致需求情况如下：

通常来说，低延迟和高带宽并不是边缘计算的必要条件，针对不同应用场景可能需求不尽相同，比如在增强现实、虚拟现实、无人驾驶和语音识别里对服务延迟要求比较高，有时还需要用到特殊硬件加速提高计算速度。然而，有些边缘计算应用却也可以在低速或不稳定网络下工作，比如“抄水表”“查电费”等，低延迟和高带宽的需求需要具体问题具体分析。

最后，简单地概括一下，针对各种需求，未来边缘计算将会

• 继承云计算的衣钵是肯定的，所以会继续使用OpenStack进行基础设施架构管理，因为不需要管理集中式的大规模数据中心结点群，OpenStack会被轻量化和简单化，API的互操作性也会进一步加强和统一，Keystone配合边缘多层结构的多级联合认证也会完善。除此之外，Nova、Cinder、Neutron和Glance等OpenStack Core都会相应被修改，新建的Kingbird项目为多地区OpenStack部署中跨多个OpenStack实例提供资源操作和管理服务。

• ONAP作为可选提供边缘计算应用服务部署编排以及生存周期管理的工具。

• 分布式存储仍然当道，Ceph仍然是首选。

• 应用场景增多，应用案例的多元化，边缘计算的可扩展性和适应性会加强，既要涵盖运营商、公有云厂商，也会涵盖IoT领域。

• 快是硬道理，任何情况下快总不会错。所以，硬件加速技术如SR-IOV、SmartNIC、FPGA以及GPU，还有其它加速技术比如DPDK将会被运用得淋漓尽致，OpenStack Cyborg众望所归。

• 不排除底层采用容器化，但是笔者认为轻量化OpenStack的重要性无法替代，有时候甚至仍需要裸机。OpenStack和Kubernetes的混合管理模式也许会持续一段相当长的时间。

• 零接触配置和维护（ZTP）目标长期有效，因为边缘计算需要拉远管理，需要远程打补丁和升级，需要无人值守。

• 边缘计算将是一个包容和开放的项目集合和集成，OpenStack和ONAP不可能完成所有任务，也不可能是唯一选择。各开源项目之间是协作的关系，比如英特尔网络边缘虚拟化（NEV）SDK包含独立的Intel边缘计算参考软件库，就可以加入社区，用来简化边缘计算开发。

主要参考文献：

[1]. OpenStack边缘计算白皮书，https://www.openstack.org/edge

[2]. OPNFV edge cloud项目，https://wiki.opnfv.org/display/PROJ/Edge+cloud

[3]. Akraino Project Overview at ONS LA 2018, http://sched.co/Dm4U

[4]. Edge Computing Meetup at Shanghai 2018, https://www.meetup.com/Shanghai-OpenStack-Meetup/events/249560291/

[5]. OpenStack edge discussions at Dublin PTG, https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG

[6]. OpenStack 2017 edge computing working sessions, https://etherpad.openstack.org/p/2017_edge_computing_working_sessions

[7]. Orchestration for Edge-Computing - ONAP Wiki, https://wiki.onap.org/download/attachments/28379482/Edge_ONAP_WG_v3.pdf?api=v2

[8]. Intel Network Edge Virtualization, https://networkbuilders.intel.com/network-technologies/nev

扩展阅读：

王庆的边缘计算（第一章）

王庆的边缘计算（第二章）

＞＞  关于作者：王庆，英特尔开源技术中心研发经理。在2004年复旦大学计算机软件与理论专业获得博士学位后加入英特尔公司，做过基于迅驰平台的移动软件开发工具集开发，2007年加入开源技术中心从事开源技术领域的工作至今，涉及过基于硬件虚拟化技术（VT）的虚拟化软件Xen的底层开发，开发与维护开源的可信启动解决方案tboot，以及领导研发团队开发嵌入式解决方案Yocto等，2012年起从事云计算OpenStack的开发，专注网络和存储但不仅限于OpenStack Neutron、OpenStack Cinder、Ceph、Open DayLight、ONAP、OPNFV等，2018年起拓展到边缘计算领域。2018年1月12日，OpenStack基金会个人独立董事选举结果揭晓，英特尔开源技术中心研发经理王庆博士（Shane Wang）连续第四年当选个人独立董事。

＞ ＞  关于『 Linux宝库 』：欢迎关注『Linux宝库』微信公众号，这里每天发布最新的开源人物和开源事件。谨以此号记录Linux和开源业界的点点滴滴，为开源爱好者和从业者点亮人生。

- To be continued -

责任编辑：RAY MAN

『 Linux宝库 』 为开源爱好者和从业者点亮人生！

长按二维码关注我们