音视频领域的新技术应用非常多，但是在工业和IoT领域，新技术的应用却鲜有耳闻。本次LiveVideoStackCon上海站大会我们邀请到了熹乐科技YoMo框架负责人——洪小坚，为我们分享熹乐科技和YoMo会为工业和IoT带来哪些新鲜血液。
文/洪小坚
整理/LiveVideoStack
大家好，今天分享的主题是可编程的流式计算框架。大家可能都比较关心音视频领域，我们YoMo面对的场景比较偏向工业、IoT等领域。虽然是不同的场景，但是仍然有很多技术的共同点。大家听完以后会有不少收获。
今天的大纲分为自我介绍、YoMo项目背景、YoMo典型用例、YoMo技术亮点、对边缘计算的理解以及总结。
关于我和熹乐科技01
首先做一个自我介绍。
我是从年开始做技术研发，做了12年欧洲用户的电商平台。因为对边缘计算和工业互联网都很感兴趣，所以年加入了现在的创业公司——熹乐科技。目前我正在维护今天的主角——YoMo项目。
熹乐科技很多朋友都是第一次听到，下面做一个简单的介绍。熹乐科技专注于工业互联网和边缘计算，打造了YoMo开源计算框架和YCloud云服务。我们从年开始将人工智能技术应用于工业制造领域，例如计算机视觉对于地板的质量检测。熹乐科技目前持续服务了40余家工业企业。在年与“中国轻工集团”共同成立了“中轻工互联网有限公司”，主要是将边缘计算等工业互联网技术在轻工行业落地。
YoMo项目背景02
下面介绍YoMo的项目背景以及设计的原理。
首先要介绍的是开放性。随着网络的基本设施，例如5G的普及，想要实现低时延看起来还是唾手可得的。5年以后，企业之间比拼的可能就是QUIC协议这种具有开放性的、基于UserSpace的可以作一些灵活拥塞控制的算法。未来的软硬件可能都是可编程的、开放性的。
回过头看看目前业内一些主流的技术，说到实时流式计算就会联想到像Flink这种、消息队列会想到Kafka。甚至我们微服务部署很多人会想到Docker，但这些技术其实都是几年前开始设计的，都属于消费者互联网。未来会进入IoT的时代，之前的技术虽然现在还是主流，但是不一定会适合未来。我们在做产品的时候就想通过新的技术，来创造一些新的机会。
近几年新闻报道了很多工业的事故，造成了巨大的人员伤亡和经济损失。加之现在国家*策一直在鼓励安全生产，所以我们的客户就想做安全生产，例如数字化检测和预警系统等。“中轻工互联网”去年就服务了一家化工企业。
安全生产的最高等级就是实现本质安全的理论。本质安全就是不论是设备故障还是人为操作不当，都可以提前预测事故的发生。要做到本质安全，就需要做到计算连续3s的数据变化趋势。同时AI算法会对不久将来可能发生的事故做出反应。例如未来30s后可能会爆炸，这时就需要提前向化学反应堆里加阻燃剂。要做到这样的操作，还需要在1s内做到30次的计算，一次大约为33ms。如果这个计算节点部署在云计算中心，那么光数据的传输可能就已经超过该时限了。上面提到的33ms不仅仅包括数据传输，还要包括AI计算的时间。因此想要做到本质安全，就需要对传感器的数据进行实时的采集和计算。
要做到实时采集就需要低时延的传输，一是利用类似QUIC的协议，二是随着5G、WiFi6的普及，对保障低时延传输有很大的帮助。另外，我们需要对采集到数据进行毫秒级的计算，这就需要在边缘端部署才能实现。如果部署在云端，即便计算速度很快，但因为传输速度的不足也会导致毫秒级计算无法实现。除了以上两点，还需要在边缘端部署一个EdgeAI进行全维度的计算来实现预紧预测。
根据现在的趋势，将来实时计算比例会越来越高，IDC预测年实时数据计算将会占比30%。
这是目前IoT领域的一些主流协议。TCP是年诞生，距离现在已经快40年。另一个主流的MQTT协议也已经诞生20多年。随着5G的普及，这些老旧技术就像在动车铁轨上跑的绿皮火车。Google在年就提出QUIC协议，在年进行IETF的国际标准化。但是因为极大的升级成本，所以目前在工业领域目前用QUIC的并不是很多，但是在音视频领域国内外用应用的却很多。熹乐的目标就是将QUIC技术方便的应用到工业领域。
我们提出gRPCforIoT的理念。gRPC是一个很主流的微服务RPC框架。gRPCforIoT就是希望在边缘端可以实现全链路的QUICTransport。例如Client/Server服务可以通过QUIC建连从而变成P2P的模式。传统Client/Server的问题在于只有在Client请求以后Server才会响应，这种模式是单向的。而用QUIC建连之后，就是双向连接PeertoPeer，同时又是长链接。为什么是长链接？因为IoT设备数据是24小时不间断的，如果每次请求都断开、重新建连会造成时延的影响。
另外我们针对IoT领域推出自研的Codec。熹乐科技在IoT领域很重视网络传输编解码的效率方面。IoT数据的实时采集并通过长链接发送的模式和视频直播是很相像的。
IoT的设备到年将达到亿。这意味将有越来越多的设备需要进行数据采集，由此产生的APP应用也会越来越多。
现在市场对APP的开发要求越来越快，timetomarket越快越好，现在很多低代码、无代码就是为了缩短开发时间。YoMo框架十分重视开发者友好，以便开发者使用时可以节省时间。
为了节省开发时间我们提出了StreamingServerless的概念。Serverless的优势在于只需要专注几行核心代码、无需关心DevOps、自动弹性伸缩，以及按需计费，低成本。IoT领域的数据是24小时不间断产生的、没有边界，是典型的streaming场景，虽然现在已经有很多比较成熟的Serverless框架，但市面上大多数Serverless框架是面向传统的HTTPRequest/Response模式。因此我们针对该场景提出了StreamingServerless。
这是一条比较有意思的推特。这个推特是Docker的创始人在年提出来的，他在推特中提到，如果年出现WebAssembly，那么他们都没有必要去创建Docker了。WebAssembly之前跑在浏览器端比较多，现在的趋势却是跑在服务端。
WebAssembly和Docker相比具有哪些优势呢？WebAssembly的ColdStart会比Docker快倍。其次前者执行时间较后者也快10%-50%。另外WebAssembly占用的空间更小。最后WebAssembly有更灵活的安全策略，可以根据不同模块，在实例化时指定不同权限。
因为在边缘节点资源会比较受限，所以WebAssembly综合了轻量级、更优的性能、更高的安全性和多语言的特点。多语言对于Serverless尤其重要，因为现在很多主流的开发语言都支持把程序编译成WebAssembly，具有这样的特点会有很多的好处。
综合上述的方方面面，我们做了YoMo开源框架。
YoMo应用案例03
再来分享几个典型的案例。
我们在办公室部署了一个实时噪声传感器，来测试YoMo框架是否能达到低时延。因为MQTT协议需要安装MQTTBroker，所以我们在数据采集端做了一个MQTT兼容的API，这样可以减少用户的负担，无需安装MQTTBroker即可接入YoMo。为了测试实验，我们将Serverless的节点部署在宁夏的AWS，来测量北京到宁夏，再从宁夏返回北京的时延。我们的测试结果显示时延基本能稳定在30ms以内。另外像屏幕上显示的分贝值，传统的做法是把传感器数据先保存到数据库，然后再进行查询显示，这样就会造成时延的损失，所以YoMo采取通过WebSocket直接显示到屏幕上。同时用另外一个Serverless服务把数据落地到DB。
白酒智能酿造平台是一个工业级的应用。白酒行业的一大特点是很多酿酒工艺是通过老师傅的经验传授，这样是非常主观的。我们在和一个研究白酒几十年的专业研究院——中国食品发酵工业研究院合作后，获得了他们提供的硬件和相关的工业算法。接着我们对这些设备进行了实时的工艺采集和计算，把老师傅的经验数字化，从而获得稳定的工艺，提高了出酒率和效率。
海外有一个用户想做用户行为的跟踪，分析一些网站上用户什么样的行为会导致转换率的降低等问题。针对这样的场景，我们做了Geo-Distributed的分布式解决方案，将传统的中心化架构拆分成多个靠近用户的边缘节点。
最后一个案例是分布式的爬虫。我们服务了一个海外提供物流查询的SaaS公司。之前这个公司的查询都是通过proxy去获取，这样会造成很高的时延，同时稳定性也不高，更加严重的是数据隐私可能泄露。通过YoMo框架，我们在更靠近快递公司的节点部署了一个爬虫服务，通过QUIC协议，把请求通过长连接返回给美国的用户。这些服务器都是部署在用户自己的机器上，数据隐私得以保障，也节省了proxy代理的开支。
YoMofeatures04
通过之前的讲座，在座的嘉宾多少对QUIC协议有一定的了解，这些内容就快速通过。
QUIC优点是非常多的。最好的就是最下面的两点。一个是Userspace，我在开头开放性那里也提到过Userspace，可以更方便的进行软件升级。TCP内核态的升级就没有那么方便。二是拥塞控制算法。根据不同的场景进行灵活的控制，具有更高的可编程性。
QUIC在业内的应用实践音视频方面比较多。国内很多的大厂在两三年前就开始研究音视频方面的应用。QUIC对性能的提升帮助很大，包括卡顿率等等。因为看好QUIC的前景，加之工业领域应用很少，所以我们想推动QUIC在工业、IoT领域的运用。
这里视频借用了阿里手机淘宝的视频，左边采用多通道的QUIC，右边没有采用。如果WiFi出现抖动的，左边可以通过蜂窝网络流畅运行，而右边只用到WiFi就出现卡顿的情况。
自研的Y3Codec我们称它为fasterthanreal-time。如果是传统的JSON的话，就需要拿到完整数据以后进行解码。针对IoT，例如之前提到的噪声，只要获取噪声分贝的字段即可。对此，我们使用了TLV的结构。结构里的Tag相当于JSON的key。通过监听Tag是不是用户关心的，如果是就直接获取，不是则skip，再根据Length判断需要skip多少字节。
性能测试中Y3Codec相比JSON提升超10倍以上，与Protobuf相比也有明显的提升。下表所展示的是一些性能报告。
响应式的编程用excel的应用来形象的说明。假设a=b+c，那么对b、c进行修改a也会有动态的响应，这种模式是十分适合数据随着时间变化的场景。
ReactiveX也针对异步数据提供了一个良好的编程模型。ReactiveX最早是由微软提出。在操作异步数据时可以使用一些通用的方法，就会像操作同步数据一样方便，只要组合几个常用的函数就可以操作异步数据流。
假设每30ms都会传递一次数据，可实际场景可能是连续两个30ms都没有数据，第三个30ms突然出现三个数据。针对这种场景我们实际只要获取最新的数据即可。使用Rx可以简化这个问题，使用debounce即可获取每30ms内的最新一条数据。
StreamingServerless让用户不需要操作QUICStream，只需要操作RxStream。可以根据业务需求进行Operator方法的组合即可。另外市面上很多Serverless服务在本地调试比较麻烦，所以YoMo支持CLI的方式本地运行和调试。
边缘计算05
边缘计算各位多多少少也有一定了解
整个行业的趋势是从之前的大型机通过终端连接变成PC端去中心化场景。发展到移动互联时代又回到了中心化的云计算中心。到IoT时代因为数据量的巨大，需要边缘端进行分布式来缓解云计算中心的压力。边缘计算虽然越来越重要，但是边缘计算并不会取代云计算，他们会共同存在。
边缘计算的优势一是降低传输距离。二是就近计算更快的响应。第三，比较重要，边缘计算可以保护安全隐私。很多工业企业并不是很愿意把数据传输到公有云服务上，所以隐私保护显得格外重要。最后一点就是低成本。边缘计算可以减少带宽传递的成本。
云计算和边缘计算的对比发现，云计算的性能更强但时延、带宽成本较高，边缘计算恰恰相反。云计算和边缘计算在使用上互补，以满足不同场景的使用需求。
对此我们做了Geo-DistributedEdgeCloud。用户可以根据时延需求来部署在不同的地方。低时延可以部署在城市级节点。如果有数据监管要求则可以部署在私有云。另外部署在云计算中心也是可以实现的。
总结06
最后对今天的汇报进行一个总结。
YoMo的项目背景是面向未来可编程的开放性。针对网络传输提出gRPCforIoT——全链路采用QUIC以及Y3Codec高性能编解码。另外为了加快用户开发APP的速度，提出了StreamingServerless的框架。针对YoMo的使用场景，运行在WebAssembly会比Docker更加具有优势。最后边缘计算方面YoMo可以基于Geo-DistributedCloud进行就近部署。
以上就是YoMo的开源计划，希望对YoMo感兴趣的朋友们可以多多