云原生边缘计算与嵌入式计算之间的关系分析详解

嵌入式计算已经笑傲江湖多年，然而，最近它的地位似乎正在受到某种撼动。全球最大的开源基金会——Apache软件基金会的董事Roman Shaposhnik甚至认为，云原生边缘计算意味着嵌入式计算的“终结”（The End）。尽管“终结”这个词有些虚张声势的噱头之势，但若沿着这条线索顺藤寻瓜，探究云原生边缘计算的价值以及未来，或对趋势有更准确的研判。

嵌入式计算我们都不会陌生，它可以说是物联网人的必修课。“嵌入式”的英文是“Embedded”，意思是“植入的、深入的、内含的”。这个词用来描述的是系统中软件和硬件之间的关系，所以嵌入式系统是指软硬件关系非常紧密的一类“计算机”系统。

紧密到什么程度呢？家里的洗衣机、空调，银行的ATM设备，路边的自动售货机，工厂内部的PLC控制器、通讯网关，都是借助嵌入式系统而变身智能的。这些看起来不怎么像计算机的“计算机”，都有自己的控制程序，这些软件程序都是针对这个硬件平台编写的，耦合性极强，几乎是不可替换的。

也就是说，对于硬件来说，如果软件出现任何问题，除了调试纠错或者完全重写一个，没有什么替换方案；对于软件来说，除了给这个硬件使用，这个软件基本没有其它用武之地，复制性极差。

所以，对于嵌入式计算而言，程序实现的功能相对简单，但必须要有对应的硬件编程知识，出厂之后程序较难更改或者升级，可选的额外应用软件几乎没有。

随着云原生逐步向边缘渗透，云原生边缘计算出现了，这一趋势在我之前的文章中已探讨多次。这次我们不妨更加透彻的谈谈，云原生边缘计算和嵌入式计算，将如何融合、相互借势。由于临近2018年末，为了陪伴你度过一个惬意的圣诞以及新年，我剔除了所有烧脑的专业术语，一起来听故事、看漫画吧～

1． 什么是云原生边缘计算？

2． 云原生边缘计算有什么价值？

3． 云原生边缘计算是否会终结嵌入式计算？

什么是云原生边缘计算？

先说说什么是云原生？云原生并不是一种单一技术，而是一种理念。云原生应用，即指专门为在云平台部署和运行而设计的应用。

提到云原生，与之成对出现的一个词则是“容器”。简单的说，容器就是一个存放东西的地方，就像书包可以装各种文具、衣柜可以放各种衣服一样，容器可以放各种程序、应用或者系统软件。而且省去了对资源或环境的配置，因为容器都已经打包好了。启动也快捷，容器可以实现毫秒级的开启和关闭。

至于边缘计算，大家都已经熟知，它是指在靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端的服务。上海繁易公司的工程师曾经开玩笑道——边缘计算就是云计算（服务器）说：边缘你就这么点儿数据，不如你在采集的时候，顺便自己算完得了，什么都丢到服务器来算很累的，况且我又算不快，这点事儿自己都办不好么？

云原生和边缘计算相遇，会擦出什么样激烈的“火花”？现在大多数的边缘设备都与云端配合使用，比如工程师们可以在云中训练机器学习模型，训练好之后应用于边缘节点。云原生边缘计算有利于让边缘也具备像云一样的“d性”，让应用可以“顺滑”的部署到边缘，保持应用在边缘与云端的一致性。

如果你需要管理由成千上万台边缘设备构成的集群，云原生边缘计算的功劳就更大了。它可以同时管理多个边缘节点，工程师们不用再把精力浪费在考虑哪个边缘设备实际运行哪个应用程序，部署和维护都更加简便。

这样工程们就可以从底层技术设施的管理中解放出来，将注意力集中到更高抽象层次的应用开发之中。云、边、端就像一个完美的整体，最终用户也根本感觉不到各种计算设备的复杂分布，后期的方案迭代也更加容易和透明。

举个例子，快到圣诞节了，如果共享单车的运营公司希望给用户们创造惊喜，开锁的瞬间不仅听到“咔嚓”声，还要播放一段“铃儿响叮当”的音乐，那该怎么办呢？我们假设车锁硬件已经支持这种新的业务需求，所以最具创新价值的工作就是教会车锁“演唱”新曲。

如果使用嵌入式的传统方案，需要工程师现场或者远程通过物理访问硬件完成部署，不仅费力费时，这个过程还有可能被黑客盯上而将硬件“劫持”。如果使用云原生边缘计算，几乎可以实现业务需求的一键变更，将新功能迅速传达给所有的单车宝宝们。

综合对比，嵌入式计算和云原生边缘计算的差异如下表所示。

云原生边缘计算有什么价值？

云原生边缘计算带来的价值，可以简单总结为两点、三个字：快、可靠。

天下武功唯快不破，除了刚才共享单车的例子中提到的业务需求变得更快，还包括新业务上线更快。过去，一台物理设备从安装配置到正常使用，前前后后免不了调测少则一天多则一周的时间；现在，通过虚拟化技术，一台设备几个小时可以搞定；未来，利用在云原生边缘运行的容器，几秒钟就可以让设备开始工作。

云原生边缘还有丰富的中间件可以选择，业务上线周期大大提速。从一个故事讲起。估计你也看到了无人酒店的新闻，一个服务员都没有、机器人送餐、刷脸入住，各种设备之间的互动都需要通过智能系统完成。有个团队正在做类似的项目，但是他们不想把时间消耗在底层硬件的驱动程序开发上面，而是要把更多精力投入在提升场景设计和智能体验之中。

各种单品的设计和使用是门锁、照明、家电、服务机器人等智能硬件企业的专长，这个团队只希望将业务层面的逻辑做好，门禁、室温、亮度、音乐等功能模块最好就像乐高积木一样，按需调用、自主配置就行。

于是团队和智能硬件企业协商了各自的分工，智能硬件企业做好物理设备的数字化建模，定义输入输出，提供云原生的驱动程序，他们就可以直接在数字化模型的基础上实现各种酷炫的场景，整个业务逻辑的跑通一个多月就能搞定。

另外一个故事是关于建筑结构监测。一些“年近中年”的楼宇有可能结构已经发生了变化，经受不了地震等小概率事件的“骚扰”。第二个项目团队最牛的地方在于通过力学仿真，多年实践积累了很好的振动监测算法，可以掌握建筑物的稳定情况，判断是否出现地基沉降，及时做好应对天灾、预防人祸的万全准备。

至于传感器怎么安装，数据怎么采集，信号怎么上传，项目团队需要借助硬件企业的强项。与上面相似的分工协作又一次上演，各环节、各专业、各业务各司其职，硬件企业完成物理设备的数字化建模，将数据采集上来，项目团队直接调用数据进行分析，通过各种报表和可视化的界面最终呈现。

云原生边缘计算还有一个优点就是，可靠。

云、网、万物互联的世界里存在太多的不可靠，因此高可靠性无疑是极大的竞争力。这里更多是指软件层面的可靠，进而提升整个系统的可靠性。比如通过在不同边缘硬件之间调配算力、启动多重应用以备不时之需、应用宕机之后快速重新启动，以及应用之间调用时充分考虑熔断等措施，增强系统的可靠性。

边缘计算在很多情况下只有一个硬件，没有冗余、没有备份，在这种情况下，万一硬件宕机了怎么办？如此厄运并不存在故事里，而是存在于大多数数字化转型中企业深深的噩梦里。我们还是通过例子来说明。

例如在一套水务系统中，需要监控一根输水管道内部的压力，通过每隔一段距离安装的压力传感器上传的数据来测算。管道中有时会发生一种现象，名叫水锤。水锤是一种形象的说法，它是指由于阀门突然开启或关闭，水流冲击管道，产生的一种严重水击，有些老化管道有可能在水锤的冲击下突然爆裂。这就存在一个问题，万一其中一个压力传感器先于管道被“锤”坏了，不能发送正确数据该如何知晓、如何修正。

云原生边缘计算又要出场了。每个传感器通过低功耗广域网LPWAN与边缘计算节点通讯，如果边缘节点发现3个相邻的传感器，其中一个传感器不好好工作，进一步根据历史经验数据判断，这个传感器出现了明显故障。这时边缘节点就可以利用其余两个传感器的数值，修正故障传感器的上传数据，完成校验和补偿，提升整个系统的可靠性。

现在越来越多的物联网边缘乃至终端设备都可以支持云原生应用。ARM在今年10月发布了全新品牌Neoverse，并与企业级容器管理平台合作，使工程师们在万亿级智能设备的环境中，能够轻松部署基于云原生的物联网终端、边缘计算和数据中心节点。

嵌入式计算是否会终结？

云原生边缘计算让嵌入式系统与上层应用的开发工作，不再那么泾渭分明，系统集成与业务运营之间的界限也正在变得模糊，融合成为主流，跨界成为常态。原本没有交集的工作，产生了越来越多的碰撞“火花”。

过去OT和IT经常你说东我说西，很难沟通。OT团队缺乏IT专业知识来实施部署边缘计算，IT团队又缺乏对工艺和运营的理解，来构建和完善满足业务流程的创新应用程序。云原生边缘计算通过对物理设备进行数字化建模的过程，优化了OT与IT之间的交互界面。

过去做硬件的人不用管软件，但是做软件的人必须兼顾，既看硬件又编软件。随着云原生边缘计算的演进，OT与IT之间彼此解耦的趋势更加明显。大家通过实践形成了共同遵守的共识，IT与OT可以更好的做到术业有专攻。这就让之前没有太多OT运营技术积累的团队，有机会扩展自己的边界，更快更好的发挥自己的IT优势，实现业务场景的创新。

至于云原生边缘计算是否会终结嵌入式计算，我仍旧想引用Frederick Brooks的观点，那就是“没有银d”——没有任何一种技术或管理上的进展，能够独立在10年内大幅度提高软件的生产率、可靠性和便利性。对于物联网边缘来说，没有银d。祝愿云原生边缘计算和嵌入式计算走好各自的路，且行且珍惜。