边无际CTO李翔：云原生、AI与物联网的融合之路

2023年全球人工智能开发者先锋大会（GAIDC）于2月25日、26日在临港成功举办，大会深入贯彻党的二十大报告指示精神，以“向光而行的开发者”为主题，围绕AI开发者所关注的前瞻探索、开源开放、人才引育、生态培育等方面展开。本届全球人工智能开发者大会汇聚全球顶尖行业大咖，邀请到Linux开放元宇宙基金会执行董事Royal O’Brien、中国科学院院士鄂维南、中国工程院院士王坚、商汤科技联合创始人徐立，此外还有众多开发者红人、代码大神。

边无际北京科技有限公司的CTO李翔受邀参与论坛演讲，进行了“Shifu云原生赋能AIoT开发”的主题演讲，深入讲解了云原生和IoT的结合的技术路径，以及边无际公司在这该领域的实践和经验。以下为演讲原文：

1 云原生进入边缘场景

云原生这个名词相信大家都不陌生了，现在非常流行。随着云服务厂商在各大领域的逐渐攻城略地，云原生作为一个开发理念也被带入了其他各个领域，简单来说它给我们带来了四个特性：

首先是高扩展性，云原生可以根据我们的需求进行弹性伸缩，保证不浪费资源，也不会缺资源。

第二是高灵活性，它是对之前这种耦合度很高的系统进行解耦，形成一个个的小小的微服务，如此一来，服务其实就模块化了。如果哪个地方出现问题，想增加哪些方面的需求，就可以只开发这一个微服务，而不需要管其他的服务。

第三是高适应性，云原生开发理念要求我们的服务可以适应绝大多数软硬件环境，简单来说就是跨平台，不受外界环境的影响。

最后是高敏捷性，我们需要对任何问题和需求产生快速反应，持续的开发和部署。服务器和容器化编排等技术其实都是发源于云原生理念，对于企业来讲，它带来的好处就是更棒的降本增效。

云服务厂商给我们提供了基础硬件和技术软件，我们不需要花时间和精力去思考怎样买硬件，怎样配置这些硬件，这就给我们降低了很大的成本。同时，依赖于统一的开发工具，降低了软件开发者的学习成本。容器化提高效率，比如说云原生的开发者其实绝大多数都是在用敏捷开发原则，因为它们之间是相辅相成的。

每次要开发一个东西，只要关注这部分的微服务，更改这一部分的代码，而不需要去考虑是否会造成牵一发而动全身，是否会造成软件整体的直接崩塌。因为在微服务高度解耦的体系下是很难发生的，所以就不需要管不相干的服务带来的影响，只需要专注于问题本身。

如此一来，设计和开发的成本就会降低很多。同时我们进行软件更新的时候，由于微服务架构以及云计算厂商提供了大量的冗余，软件更新不会导致服务的长时间离线，用户体验变得非常高。

云原生架构的核心概念一共有6个。

1. 不可变基础设施。简单来讲它就是保证服务器是可替换的，或者说硬件是可替换的。我们在设计软件的时候完全不需要也不应该去考虑软件变化会对硬件带来什么影响。我们可以当做硬件不存在，或者说是当做这个硬件永远是适合软件的就可以了。

2. 微服务。微服务也是一个非常流行的名词，每个微服务之间彼此是独立的，这样在开发的时候就减轻了很多负担。

3. 服务网格。服务网格其实就是一个不被感知的交流层，换句话说我们在开发微服务的时候，只要保证微服务本身是可以交互的就可以了，至于他们怎么交互，微服务之间是怎么交流，微服务和用户之间是怎么交流，我们不需要管，这是服务网格自动帮我们处理的。

4. 容器。容器也是一个非常流行的词了，它能给我们带来很轻的环境、很少的资源浪费、提高了扩展性，简单来说就是跨平台这种效果。我们只需要把服务打包成容器镜像，那么它跑到哪个地方以及怎么跑都无所谓。

5. 可持续集成和可持续部署，或者说CI/CD。它给我们提供了一整套的开发和部署流程，我们只需要把代码上传，剩下的包括编译、测试、部署都是由 CI/CD来完成的，我们完全不需要管。

6. API。API是用户跟软件进行交互的最核心的东西，它是一切沟通的基石，其实用软件本质上来说就是在调API。

这六个概念可以合成一个简单的架构。用户先进行API调用，然后API调用信息通过服务网格传送给各个微服务，再进行处理。如果有新版本要更新，新版本会经由 CI/CD来部署到各个微服务之中，保证服务的顺利更新。最底下计算资源（不可变基础设施）完全不用管，它就是在那，而且会一直支持我们。

上图是关于云原生领域的发展进度。根据 CNCF （cloud native computing foundation）给的数据，从中可以发现：contributor，member，end user，project的数量逐年增长，而且越来越多，增长速度越来越快，所以我们可以说云原生在各个领域的扩展是呈燎原之势或者说是不可阻挡的潮流。

上图是以云原生为基础开发的一系列项目。从中可以看到很多著名项目，比如kubernetes，etcd以及helm等。这些我们耳熟能详的项目其实都是云原生孵化出来的，而且确实都是在各个领域有了非常广泛的应用，占有非常重要地位。

2 AIoT逐渐在边缘场景流行

AIoT现在逐渐成为一个非常火热的流行概念，是因为随着边缘计算算力的不断增长，我们可以把AI的工作放在边缘端进行。一旦提到边缘计算，那么显然这就是IoT的天下了。

现在有了AIoT这个词，或者说是AIIoT，因为AIoT是Artificial Intelligence of Things。我们现在讨论的是设备之间进行万物互联，所以是AI 和IoT。现在的趋势是：首先设备本身是越来越智能；AI运算也逐渐下沉到边缘端，很多设备本身都已经开源，自己的API、甚至是设计图也开源了。所以我们在物联网领域会遇到越来越多的可以让我们自由编程的设备、自由交互的设备。

我们发现，在线下的社区中，有很多开发者甚至在自己制造这种人工智能设备。这种智能硬件越来越多，同时也给我们带来了更多的 AIoT需求。所以当下是非常适合AIoT进行进一步的蓬勃发展。

ChatGPT的风靡全球其实给我们带来了很大启发：人类跟设备进行交互到底是在干什么？其实就是人与设备进行交流。按这个按钮是要告诉设备：你要执行这个操作。然后设备反馈绿灯一亮就是在告诉我们操作执行完成了。所以这其实是在交流。

那么如果使用GPT3或者类似的LP模型来赋能设备的话，就会发现：我们甚至就不需要看说明书来学习这个按钮是干什么的。我们只需要给设备下命令，以自然语言跟它说：“请帮我做这个”，设备就会以自然语言来回复：“我做完了”。这对于用户体验的提升以及学习成本的降低都非常有利。

上图是一个非常有趣且有启发性的Project。Ellee是一个以Jetson Xavier和GPT3联合训练出来的一个玩具熊。作者让玩具熊可以跟他孩子进行自由交流对话。

云原生其实给AIoT提供了很多非常有用的特性，甚至可以说云原生就是为AIoT开发了这些特性。比如以Kuberbetes为中心的编排系统提供了CPU管理策略，可以直接隔离CPU，也就是说保证CPU资源直接被有效利用在CPU-heavy的任务中。这就保证CPU不去掺合AI这些事了。众所周知，AI是要用到GPU的，那么Kuberbetes提供的设备插件让应用拥有可以用GPU的能力。拓扑管理策略用于保证资源有效地分配给GPU和CPU。Pod和Operator用于保证微服务的互相独立以及自动化运行。这都是非常适合AIoT在边缘端进行操作的一系列特性。

3 Shifu赋能云原生AIoT

所以边无际就开发出了Shifu这一云原生AIoT开发平台，其目的是为了把这些刚才提到了云原生和AIoT的特性进行结合，释放出更大能量。

Shifu是基于Kuberbetes的开发框架，它的核心技术或者核心特性就是结构性虚拟化。Shifu把一个个设备虚拟化成一个个微服务，这些微服务对于用户来讲就是一个API，用户可以直接通过调用API来调用设备；同时因为这些API是统一的，用户根本不需要什么学习成本就可以操纵所有的设备，这是一个非常棒的交互能力。

如上图所示，是Shifu的技术架构。可以看到最底层的物理设备就是真实设备，已经由Shifu变成了抽象的虚拟设备，一堆物理设备集群可以抽象到虚拟设备的集群，整个场景就变成了可编程的场景。由此也就有了虚拟实验室和虚拟工厂一类的东西。事物内部本身有这种安全框架，可以保证系统的安全。管控框架可以保证设备连接和交互顺利运行，以及互联框架保证设备之间的合作，平台框架可以用UI进行操作，由自动调度系统进行设备自动化以及资源调度，这就是Shifu的一个大致结构。

Shifu提供的是从接入设备到整个系统运维一整套的解决方案。首先，Shifu对市面上绝大多数的协议和驱动都是兼容的，可以即插即用，没有生态壁垒。在应用开发部分，Shifu其实给用户提供了一系列API，让用户可以自行调用，保证用户能够非常简单地调用任何设备。最后一环是系统运维，是k8s原生架构。Kuberbetes本身是一个非常好的运维工具。鉴于已应用了这种微服务架构以及统一的API，所以在运维方面也是非常简单的，提供了超高的系统稳定性，是一个从0-100的整套解决方案。

我们给Shifu的定义是连接云端和设备的桥梁。开源项目中有K3s、Edge X、EMQ之类的产品，也是服务于物联网部分，其实他们的特性其实并不完全跟Shifu一样，Shifu采用了云原生一体化架构将设备直接管起来。

所以，这是Shifu的一个非常好的竞争优势。Shifu的主要发力点其实是在工业智能制造领域，因为Shifu可以首先保证连接所有设备，然后保证整个场景智能化，以及让开发更加快速。Shifu给厂商或者客户提供了这一整套解决方案，会解决他们在云端、在边缘侧，以及在它的设备或者工业现场的接入、设备管理、运维的一系列痛点。

具体而言，我们首先实现了非常好的云边协同。Shifu可以在云端做一些比较复杂的操作，在边缘端做一些比如边缘AI算力的部署，边缘AI应用的部署这些东西，保证云和别人之间的交流是通畅的。其次可以保证对设备的百分百兼容，保证云边端这三部分可以互通有无。如果没有云或者说不想联网，那么也可以保证只在边缘侧和设备侧进行部署，也是一个非常好的、非常完整的私有化解决方案。

Shifu实现的效果是把这种传统的控制架构，比如图里的工业软件ANDON、EMS、SCADA跟底下的控制器设备进行连接的复杂性降低。在真实的工业现场。异构设备PLC、HMI的联系方式不一样，所以我们就需要考虑如何连接到MES系统，这些是需要高度定制化的，而且牵一发而动全身，非常难以复用。

Shifu就是用来改善这个问题。Shifu可以把下层部分的这些业务全部兼容，北向开放的就是完整统一的API，不需要任何学习正本，只需要进行调用。实际上我们开放的是HTTP，比如说我们在调用的时候直接调用HTTP API就可以实现这一切。这就是Shifu提供的一个非常好的统一方案。

4 Shifu应用案例

我们刚才提到了Shifu框架，其实该框架已经在很多客户那里得到了正确和广泛的应用。

第一个例子是工业4.0液体实验室。客户有一系列实验室，实验室里有一堆分液器、美标仪、液体定量器、自动导引车、机械臂等东西。我们有必要了解这些东西是干什么的吗？其实没有必要，我们不需要知道它们是什么，只需要知道有什么能力。比如说某个仪器提供摇试管的能力，那么Shifu就可以将其抽象成API，摇这个动作就是一个API，用户就可以进行调用。

Shifu对所有的设备做的都是这些事，把设备本身变成一系列API。有一个有趣的事就是机械臂和自动导引车，这两个其实可以组装到一起的，而且我们在Shifu里面也实际上真的把它俩组装成一起。这两个是一个数字完成或者说一个微服务，这是Shifu可以提供的比较高级的能力，设备的聚合。

整个流程是把机械臂安在导引车上，然后拿这些试管分别送到分液器上，再送到酶标仪上，再送到震荡器里进行处理，然后再拿下来送到另外一个机器上。Shifu控制的就是这一套流程，它管控和编排所有的设备，然后运行用户的自动化的生产逻辑。

软件的架构如上图所示。其实也并不复杂，Shifu这边有一个Shifu Controller，相当于一个中枢，这些node用户可以自己定义， processing unit包含了处理液体的东西，MovingArm是一个管理自动导引车加机械臂合起的一个聚合。其实这是一个非常简单的架构，Shifu可以支持边缘平台Prometheus，SQL，MQ等对底下数据应用。

以下是用户使用Shifu的方法。用户首先提供驱动文件（设备厂商提供），不管该文件是什么格式，是可执行文件也好，是Python Library也好，是动态链接库也好，都无所谓，直接提交到Shifu平台上，Shifu就可以给它打包，变成可以使用的东西。然后进行文件配置。

配置文件就需要用户填写一些东西了。用户填写内容包括硬件设备sku、硬件设备的名字、驱动镜像的名字、以及这个设备是怎么连接的，它的连接方式的名字以及它需要用到哪些API。就检测方法而言，有限状态机的自动化设置这些都是可选的，根据用户的需求来决定填什么内容。

简单来说有限状态机是一个比较高阶的特性，它用于实现简单自动化，决定了设备在哪个状态下接收到另外一个命令，会转移到哪一个新的状态之中，其实简单来说就是根据当前的环境以及当前的命令，进行自动化应答的一个特性。

第二个例子是我们跟中国船舶进行的第一轮合作，在中国第一艘自主大油轮船上部署有Shifu的生物降解系统。“首制船”的生物线系统是安装在每条船的一部分，然后然后船上会有很多个生物链系统来处理厨余垃圾。我们在船上部署了 Shifu Framework，保证了其可以很快速敏捷地升级或者更改，以及操控生物专业系统。

上图是交付发云边独立集群解决方案。首先我们在云端使用 k8s收集船上所有的数据进行分析，然后在边缘端（也就是船上）部署k3s，可以实现一些在边缘端做的简单应用，包括一些小AI处理，比如说实时报警、机电控制等。

第三个例子是我们跟中国船舶进行的第二次合作实现云边端协同。利用阿里的OpenYurt实现了云边的打通。如此一来，我们不仅可以保证这个系统能服务于每一艘船，还可以服务于整个船所构成的船队，或者说全球的所有船。

最后一个例子是给某央企提供的基于AR设备的AIoT远程操作和运维的场景。图示是一个AR巡检的场景，我们的目标是使用AI对于工人操作进行指导和检测。简单来讲，工人通过戴 MR头盔，可以实时根据 MR头盔给他的提示进行设备操作去进行学习，同时MR头盔也会检测操作是否出错，以及MR头盔会看周围的环境，来告诉他下一步要干什么。

Shifu把MR头盔以及场景里的机器设备，以及包括传感器进行虚拟化，然后保证 AI在处理这些东西的时候，用到的资源是足够的，并且没有任何浪费。

上图的软件架构非常像之前的液体实验室，唯一区别就是它多了一个AI core。在边缘端有一个AI core可以处理场景里的所有MR头盔给他发送的信息。MR头盔上面还也有一个AI on Device（机载AI/设备端AI），可以辅助设备处理工人现在的操作情况。Shifu接入的设备是MR头盔的数字孪生，机器上面的传感器，环境的传感器以及摄像头。

整个工作流程首先工人在这场景里面戴上MR头盔，头盔上会给他眼前显示出操作流程，工人就跟着操作流程进行处理。然后然后根据 MR头盔 POV，还有AI on Device就会判断工人操作是否正确，正确就进行下一步，错误就立马叫停，再进行其他处理。

Shifu会记录所有检测到的操作，记录设备的报警，记录每一步他做了什么。如果开启，还会以视频流或者是照片的形式记录摄像头拍到的东西。若需要，还会上传到云端或者上传到边缘端。工程师也可以远程连接到MR头盔的deviceShifu，然后开始开启视频通话。视频通话为双向通话，工程师可以看到工人的POV，工人也可以看到工程师的视频通话界面，这也是通过deviceShifu进行视频流传输来得到的。

Shifu本身也会收集来自头盔，设备，传感器，摄像头等设备的所有数据，并传输给边缘侧以及云端进行分析。这些数据包括所有，比如读数、文本模式、声音视频等所有东西。最后云端或者边缘的AI会将自己分析出来的结果传到上传到Shifu平台数据库，以及在必要的时候，通过deviceShifu告诉工人下一步操作等更加上层的提示，或者说是停止相关设备，保证操作不对其他的设备产生影响。

上述三个案例主要讲述了Shifu平台为液体实验室、船还有 MR车间到底提供了哪些云原生方面的帮助，以及AIoT方面的帮助。可以看到，客户对此是受益匪浅的。我们也希望把Shifu的这种能力提供给更多的AIoT应用场景，来帮助大家更好的降本增效。