域名频道资讯站随着物联网和5G网络的发展， “边缘计算”逐渐成为许多大佬的关注点。边缘计算作为新的计算范式，在靠近设备端的运算上，展现出了实时处理与高效节能的优势。那么，业界如何定义边缘计算呢?它目前的市场状况与未来的发展前景又如何呢?
2018 年 5 月 18-19 日，由 51CTO 主办的全球软件与运维技术峰会在北京召开。在“IOT开发技术解析”分论坛上，来自华为、及边缘计算产业联盟的技术架构主席史扬，给大家带来了《边缘计算参考架构2.0实践与思考》。
本文将按照如下三个部分展开：
为什么需要边缘计算(WHY) 华为如何在边缘计算领域持续发力(HOW) 边缘计算参考架构2.0实践与思考
为什么需要边缘计算
行业数字化的转型是当下比较时髦的概念。其本质是：以数字化产生数据，网络化实现价值的流动，通过智能化来创造经济和社会价值。
行业数字化的迭代发展是从互联网公司开始，逐步进入互联网金融公司(FinTech)，而近两年则进入了实体行业的智能制造等场景中。
纵观任何一个企业，其运营无非涉及到：人、财、物，应用和环境，而说到底都是源于数据。我们通过对数据的感知、到对数据含义的认知、从而达到对数据进行预测。
例如：我们通过关联分析，来对互联网用户做“画像”，进而预测他的购物习惯。凭借着越来越廉价的云计算服务、ERP和CRM等软件的协助，我们能够从历史看未来，不断优化用户体验，进而做出各种决策。
如今，传统行业需要通过物联网，来获知其核心资产(如发电机)的运行状况和资产利用率，进而打通从云端到边缘计算。
因此，数字化转型的核心问题是：缔造“数据+模型=服务”的模式，实现如下四个转变：
物理世界与数字世界从割裂转变为协作融合。 运营决策从模糊的经验化转变为基于数字化、模型化的科学化。 流程从割裂转变为基于数据的全流程协同。 行业单边创新转变为基于产业生态的多边创新。
如今我们的数字化转型技术正变得越来越成熟，门槛也越来越低。例如：在汉诺威工业展上受到追捧的数字孪生，就是通过模型化的方式，使用ICT的技术，在数字世界里构建一个虚拟世界。可见，数字技术其实是可以将物理世界的潜能释放出来的。
当然，物理世界与云数字世界的联接也存在各种问题，包括：十毫秒的时延约束，无人驾驶场景中的数据猛增和带宽消耗，人员与企业的数据安全与隐私，以及边缘侧物理设备与云端的联接的不可靠性等。
因此，我们需要通过智能分布化，来实现物的自主化，从而进一步实现：物与物之间的协助、物与本地系统的协作、物与人的协作(即人机交互)、以及物和云的交互协作。那么在整个过程中，我们都需要通过一种数据和支持的共享，来实现全面的协作化。
不过，我们所用到的边缘计算、云服务、乃至Docker和K8等技术，其实归根到底都属于分布式系统。
而对于分布式系统架构来说，除了我们所熟悉的，具有可扩展性和性能优势之外，也带来了如上图所示的各种挑战。
其中包括：部署、学习曲线陡峭、理解整体架构逻辑、以及各种开发成本、维护成本和运营成本等方面。
同时，那些在工业上被广泛使用到的各种传统软件，如ERP、MES、CAD等，由于具有较强的行业定制化的特点(MES尤为典型)，导致了它们既不赚钱，又难以适应灵活的需求变化。
因此，我们需要将原有的工业服务平台从层次化变为扁平化，把它们的业务逻辑打碎成多个模块。我们通过内部封装，以一种组态编排的方式来解决工业现场的多样化问题。
在业界上，我们通过K8之类的技术来构建出一种“高内聚、松耦合”的分布式服务架构，并且使用微服务来为架构提供包括：服务发现、控制总线、业务编排、架构运维在内的一系列基础服务。
伴随着微服务化，工业界本身的控制架构也产生了分布式化。例如：在工业现场的PLC控制装备上，实现了可交互的分布式控制逻辑。
一般而言，企业每更换一种手机型号，其生产线上所有的工艺都要做出相应的调整。因此，各个企业在生产线水平上的竞争，就主要体现在换装能力和新产品的上线能力等方面。同时，企业需要通过快速地加载和迭代系统工艺，实现灵活的编排和工序控制。
总结起来，如今行业数字化转型面临着如下的挑战：
OT(Operation Technology)和ICT(Informationand Communications Technology)跨界协作挑战 知识模型化仍是巨大挑战 数据信息难以有效流动与集成 产业链变长，增加了端到端协作集成挑战
我们需要通过AI、大数据、机器学习等技术，将传统的机理模型与数据计算模型相结合，让企业转向运营服务转型和协作型，从而带来整个产业链在生态架构上的变化。
下面，我们来看看边缘计算的基本概念。简言之，它是一个开放分布式平台，能够解决实时性、数据优化和安全等一系列问题。
从软件技术的发展历程来看，早年各大软件公司各自为政，都推出过自己的操作系统，后来则由能够跑在X86芯片上的Linux操作系统成为了主流。
近几年，由亚马逊推出的云计算服务封装了底层的操作系统和硬件，用户只需像使用水电煤那样去应用这些云服务便可。
而在工业上，其价值链的最上端是工艺，接着是核心装备，再往下是PLC，以及一些核心的工业软件，而我们常见的IT则处于基础的末端。因此整个价值链的核心是：系统集成商负责把软硬整体打包提供服务。
另外，对于某些通用的软件而言，其实它们并不可能去单独招标。例如：网络软件，一般是被绑定在整个项目中进行招标的。可见，工业上的整体商业模式是不太一样的。
作为类比，边缘计算和云计算的本质都集中在两个方面：
水平解耦，通用化所有组件。例如：我们可以把在边缘侧要用到的所有数据流程分解，做成一个通用工具。 新的商业模式，边缘计算和云计算都屏蔽掉了大部分底层的基础部件，以运营服务的方式来盈利。原来只需提供设备的厂商，如今要提供各种服务，包括：预测性维护、精益类服务等。因此这会是一个技术到商业模式的全栈方案。
基于上述理论，我们提出了如图所示的模型驱动架构，旨在让物理世界和数字世界协作起来，达到在物理世界里建立各种认知。
如今，工业界很多厂商都强调自己是MBE(基于模型的企业)，就是突出了它们的模型化和协作能力。
由于工业界存在着硬件和操作系统等多方面的异构现象，因此它们希望通过模型封装，将各种KnowHow进行软件化。正如云计算领域经常通过DevOps，来对从开发到部署的整个生命周期进行有效地支撑那样，边缘计算的运营能力也需要有一套工具链和服务，来实现业务编排。
当然我们在技术上应该采取的是一种演进性的，而非推倒重来的模式。各种适合于信息系统的服务器硬件配置(如内存大小)和AI的云端模型(如GPU的功耗)，它们对于工业环境(如只有几百M的存储空间和内存大小)，以及边缘计算的低功耗芯片来说，是无法迅速被移植过去的。我们需要有更多独特的创新机会。
华为如何在边缘计算领域持续发力?
下面我们来看华为是如何在边缘计算领域持续发力的。如上图所示，这是一个边缘云的协同。在数字世界里，最上方是一个集中式的云服务，它包括公有云和私有云，一般被建立在某个IDC中。
在云服务的PaaS和IaaS之上，可以提供边缘通用的AI、大数据服务，以及上方的Enterprise Intelligence服务。
在边缘侧，我们配有嵌入式LiteOS(轻量级系统)、物联网关、服务器、以及第三方的节点。在此基础上，我们提供了一个基于K8的、优化了的边缘云。
由于在工业上的诸多场景中，资源都是极其有限的。因此，我们不能直接照搬K8，而需要做适当的优化。
再往上面就是一些诸如：流式数据分析和数据管理等基础服务。同时用户也可以把自己的应用和训练的模型，推送到微服务的架构之中。
另外，该架构除了能实现完全的分布式，还能提供一致性的服务接口。因此，该边缘侧既满足了即时的业务需求，又在云端满足了长周期的分布式架构。
上图是华为EI大数据的网页。除了提供一些缺省的服务之外，我们还提供一些面向行业解决方案，包括：水务、制造、交通、金融和零售等相关解决方案。
该架构具体包括：深度学习、预置模型、云端训练、边缘集成、边缘部署。同时，它也面向一些典型的应用场景(如视频应用)提供各种工具链，以更好地支持应用开发。
针对机器学习，我们的平台提供了一整套的工具链，来实现核心构建、建模、以及模型库的发布。
前面提到过，工业项目一般周期都特别长。我们当年做过的一个空气压缩机的降能耗项目，就持续了半年多。
其中涉及到了如下关键因素：
IT人员跨界到工业领域，需要很长的时间去熟悉各种环境。因此，工业项目往往需要外部和内部专家的合作，充分发挥IT人员擅长做数据，和OT人员提供支持的优势，并能持续交互与合作。 我们需要花大量的时间，对工业现场所产生的数据进行清洗和打标签。由于过程比较复杂，因此往往需要半年才能做出像样的模型和框架。当然，后期的迭代数据会比较快。可见，IT技术在工业领域不但需要有较长的沉淀周期，而且也顶多也只是一个赋能的工具。
由于在许多场景中资源是有限的，因此我们需要在边缘侧有一个轻量化的架构。如上图所示，我们在边缘侧提供了EdgeCore，这一无服务器架构。
我们将网关等组件统一抽象为边缘计算节点，通过协议来形成本地的逻辑组，从而实现设备的统一、交互、协助、以及去中心化。
在边缘侧，其实每个行业的场景都是不一样的。例如：水库机组的不同水泵之间，就需要有一些内在逻辑，以实现在云端连接出现故障时，不同主机仍可进行交互。
如上图，SmartMesh提供一个服务总线，我们通过抽象每个节点，并在此基础上去定义逻辑。而在其他场景下，我们只需修改上面的逻辑，并保持下方不变，便可很容易地实现适配。
当然，在物联网边缘应用的场景开发中，我们碰到过许多问题。例如：华为在交付它所提供的网关时，从网络接口的配置，到场景的切换与测试，都不但耗时，而且可能发生各种特殊环境的问题。
如今，我们实现了在云端提供一个集成式的开发环境，从而仿真出网关类的硬件，以及不同的设备库、各种OS库，甚至是网关的内存资源都能被仿真出来。如此，用户只需简单拖拽，便可构建、加载出一个运营环境。
过去，我们往往需要人工巡检包括胸牌、警示牌的安全相关状况。如今有了机器学习、大数据、深度学习等方式，我们就可以构建出模型库与合规库。通过现场的照片采集和云端的数据分析，我们就能很方便地得到相应的安全报告了。
另外，过去人工检测芯片电路板，一般每块板需要大约5分钟。如今摄像头通过机器学习和机器识别的方式，大幅提高了准确度和效率。
同理，我们基于机器学习，对空压机的各种多功率参数进行了控制与优化，使之能耗减少了2%—4%。
在3C领域，通过取代人工识别，我们也能将人员的工作量降低48%。
面向未来，我们需要把来自垂直方向的需求进行水平化，通过统一术语和架构，最终促进产业的协作与发展。
边缘计算参考架构2.0实践与思考
上图是我们提出的边缘计算参考架构。最上面是智能服务，它处于云端和边缘层，其本质上是为开发和部署提供全流程的服务。
而它的最底端是一些边缘传感、边缘网关和边缘服务器等物理设备，它们负责将采集到的信息数字化。
可见，负责架构上方的IT人员和负责下方OT人员需要通过交互，来实现业务，并一层层地映射到具体的行业之中。因此，大家需要使用统一的语言模块化描述具体的需求。
与此同时，上面的数字世界跟下面的物理世界在交互时，需要有一个中间层，以负责定义各种业务规则，实现上下映射，并层层进行屏蔽。也就是说：对于业务层来说，它不必了解过多操作和物理层面的资源信息。
因此，我们把边缘侧整体抽象成了一个边缘云，然后通过接口跟上方进行交互，进而层层解耦，直至下方那些纯工业人员所关注的物理层。
过去因为考虑到切换的成本太高，大家都害怕被某个“阵营”所绑架，因此在合作时都很谨慎。
而如今，通过该框架，大家能够实现协作与融合。不同的用户能够通过生态的协作方式，能够打通每个层次，最终提供出覆盖数据全生命周期、全流程服务的解决方案。
下面我们来看看架构中的几个关键点：
从概念视图来讲，我们将网关和系统通过数字化、网络化、智能化，定义成不同的逻辑节点，然后向下提供实时计算、轻量计算、智能网关和智能分布式等OS。
从功能视图来讲，我们可以通过虚拟化，来实现软件定义的功能，而且还能细分为缺省功能、数据分析、实时数据以及行业定制化等方面。
从功能视图来讲，我们基于该模型框架实现了开发接口的标准化和操作运行的自动化，从而让IT人员和OT人员能够建立协作关系。
由于边缘云是一个分布式的调度系统，因此它能够通过业务策略来予以定义。
对于整个应用而言，该框架提供了从开发层到部署层的支撑，并且通过业务编排来实现业务的快速部署。
因此，我们所提供的框架，能够定义出数据处理的核心服务和整体调度。而用户只需在其中进行业务逻辑的实现便可，从而实现了平台与用户的分工合作。
从部署视图来讲，既有分散式的，如摩拜单车，它们每辆车上都被嵌入一个小模块，其基站起到了网关的作用;又有集中式的，如在分布式电网里，有着大量的计算节点，并在边缘侧形成边缘云。
而且它们的流量模型也略有不同：分散式主要采取的是南北向的流量模型，所有数据直接与云进行交互。
而在集中式的场景下，由于本地侧装备希望有更多的自主化，因此大量的流量是东西向交互的，只有少量的流量经过长周期地清洗、聚合后再被上传。
本文素材来自互联网
