前言
很高兴有这个机会和大家分享我们总结的关于边缘计算的架构模式,也就是我们所说的基于能力的系统架构 —— COA。
什么是 COA 呢?我想通过一个很普遍的问题——电源问题来解释。电源问题一直是移动电脑,特别是手机用户体验的一个关键问题。我想每个人都有过因为手机电量低而带来不便的经历,有的人甚至告诉我,光看到这张图片,就会引起某种不适。
那么我们是怎么解决这个问题的呢?获得持续的电力供应,是手机运转的一个基本要求。
我想每个人对上面这些图片都不会陌生,机场的充电站、五花八门的充电宝以及各种各样的共享电源。解决手机的供电是一个问题,那为什么我们有这么多不同的方案呢?这是因为手机获得持续电源供应的能力,是一个关键能力,我们必须用各种手段来保证,在各种场景下对手机的持续供电。
手机需要持续的电力供应
如果把这个问题抽象来看,我们可以看到手机获得持续电力供应的能力,是有很多不同的方案来支持的。
比如手机集成的电池,这是基本方案,如果没有,手机也就不是手机了,就变成座机了;充电宝是一个本地方案,因为你手机需要连接在本地的充电宝实例上;而电源插座是基于服务架构的解决方案,你把手机插在插座上,这个插座就是你访问电力公司电力供应服务的接口;而在更极端的情况下,你可能还会用其他的替代电源,比如太阳能板,甚至手摇发电机。
这个例子说明什么呢?它说明对于系统所需的关键能力,比如获得持续电力的能力,我们经常需要多个替代方案来确保能力的存在。比如您的手机没电了,你会在乎你的电源插头插在哪里吗?你会在乎充电宝的形状和颜色吗?这些都不是关键。你需要的就是供电的能力,至于这个能力是不是基于服务的架构,以及这个能力是如何提供的,这都不那么关键。
这个例子让我们思考,在设计程序的时候,能不能提供一种设计语言,让开发者表述系统所需的能力,比如供电,而不是考虑系统能力的交付方式。无论这个能力是通过远程的服务调用本地的容器,或者是局域网的服务代理实现的功能,这些都不重要,这些都是运维的问题,而不是系统设计和开发的问题。我们希望可以总结出一套设计模式,并在此基础上建立一个工具和服务的生态系统,这就是我们提出 COA 这个概念的初衷。需要说明一下,COA 这个概念虽然是我们提出的,但是这种架构并不是我们发明的,COA 是我们基于对现有系统的观察总结,在此基础上,我们定义了 COA 的一些基本部件,以及这些部件可能实施的方式。
我们再用另外一个例子对 COA 的意义进行说明,这次我们考虑一个需要人工智能支持的程序。人工智能比如脸部识别,交互的方法也很多,您可以用固化或者半固化的硬件,比如 ASIC 或者 FPGA;您也可以通过调用已有程序库或 SDK,比如在进程中调用 url 来进行物品识别;当然您还可以用进程外的方式,比如调用一个本地的 Docker 容器;最后您也可以调用云平台上的服务,比如微软的机器视觉服务等等。
在这个场景中,获得 AI 的能力,比如脸部识别的能力是你所关心的,而这个能力是怎么交付给你的?这也应该是运维的问题。而且 AI 的模型层出不穷,对系统的需求也不一样,把能力交付转化成运维问题,允许您的程序可以被动地甚至主动地调解本身的行为,来适应不同的部署场景。比如我们曾经有一个智能交通灯的系统,在缺省情况下,它把高清晰的视频传到云上进行识别,当发现人行道上有轮椅,它就会延长绿灯的时间,以保证残障人士有充足的时间过马路。但是如果网络带宽不允许,它就会转换成低分辨率的图像,而且如果网络断开了,它就会转到一个本地的模型,本地模型精度差一些,但是还是可以提供持续识别功能的。那么对于这个系统来讲,轮椅的识别是一个必要的能力,这个能力具体是怎么交付的,甚至在运行的过程中是怎么选择的,这个就应该是一个运维问题。
基于能力的系统架构
COA 的理念,就是把运维问题从开发者角度分离,所以 COA 的核心,就是让开发者专注于能力,而不是能力的交付。如果我们有一个对能力的通用的描述、发现和使用的系统,那么我们很多的系统就可以做到平台无关、位置无关、甚至技术无关。以手机充电问题为例:
平台无关:你连到国内的插座和国外的插座这是无关的,至于对不同国家插座的电源、电压以及插座样式的适配,这是运维问题;
位置无关:你用哪个插座哪个充电宝,你的手机在哪,与你程序的设计及开发也是无关的;
技术无关:你的电源是电池,还是火电、水电、核电、太阳能……,这些都无关。
COA 就是把这些能力的实施和交互的方式,彻底地从开发者这里分离出来。
我们从另外一个角度看——运营方面,运营也会有更灵活和更精确的控制。比如你随便选择了一家数据库公司,然后用这个公司的 SDK 来进行开发,结果公司倒闭了,这就是个问题。而 COA 允许你在选择能力供应商时,同时考虑功能性和非功能性的需求。而作为运维,您可以独立评估选择供应商,然后根据不同的部署场景,选择不同的能力供应商。它可能是本地的,也可能是远程的,甚至是人工的,这都不影响程序的架构和代码,同时您也可以灵活选择部署方案。另外您可以用创新性的替代方案来取代原来的方案,回到人工智能问题,大概在一年前,谷歌的 BERT 还很厉害,但现在微软的 GPT-3展现出了无与伦比的能力,有了 COA 您就可以在运营过程中对这个模型进行选择,甚至综合多方的结果提供一个更佳的方案,这些都是一个运维的问题,而不是开发的问题。
能力代理
实现基于能力的系统架构,需要几个重要的系统部件,第一个就是能力代理。能力代理是指通过代理的方式,把能力供应者的细节封装起来。能力代理具有如下功能:
第一,根据环境的变化选取能力的提供者。比如上文提到的轮椅检测方案,根据网络带宽的情况和网络连接的情况,能力代理可以动态地选择不同的能力提供者,然后能力提供者在此基础上可以提供更多的优化功能。
第二,提供本地缓存,不需要所有的服务都是远程调用;它可以批处理,把分散的处理做成小的批次,然后统一提交给服务器;甚至它还可以做一些其他的,例如压缩、加密等中间件的功能。
第三,在本地环境里,比如在一个局域网内,如果能力代理之间可以相互发现,我们就可以实现更高级的功能——伙伴间的动态调用。例如,在智能家居环境中,用普通的手机进行比较复杂的图形计算时,我可以把这个能力临时代理给我的游戏机,通过游戏机的 GPU 功能来进行图像处理,就可以实现伙伴间的动态调用过程。
第四,基于功能性和非功能性需求动态发现提供者。能力代理的发现功能和我们普通所说的服务发现的过程不太一样。因为在发现能力的过程中,我们可以同时考虑功能性和非功能性的需求。比如在发现一个能力供应商的时候,我们不但要考虑系统的性能、表现,甚至供应商本身的资质也是我们考虑的要素。
能力发现
说到能力发现,还要解释它和服务发现有什么不同。传统范畴的服务发现,是基于语法的发现,比如说我要做一个相加的服务,我可能通过服务发现的模式,找到一个相加的服务,它有相加的名字,但是我无法知道相加服务是不是真的在进行加法的计算。
而能力发现模式是由用户来提交他所要实现能力的意图,然后系统根据意图进行语义上的发现,通过发现的过程可以真正发现一个可以进行相加计算的服务。然后我们可以把非功能性的因素也考虑进来,比如它的 SLA、安全性、供应商资质等,所以能力发现实际上是一个比较复杂的系统。
我认为,能力发现应该是一个基于多向量(包括功能性和非功能性向量)的几率发现系统。但是在生产部署环境中,基于几率的发现系统,很可能是不能满足需要的。因此,我们就设计了,在发现之后可以通过一个固化过程,把所发现的供应商,提供成一个特定的能力组合,在能力组合的基础上,您可以提供比较明确的版本的控制和供应商的控制。能力发现也需要我们提供表达用户意图的方式,通过一个通用的词库,基于自然语言的方式来实现对于用户意图的解析。
示例:lets 系统
在 COA 的基础上,我们设想了一个系统——lets,上图展示了用 lets 进行编程的一些示例。
脸部识别:我们可以通过 lets 命令行:lets detect face→输入图片→输出图片,系统就可以对输入图片进行脸部识别,然后再输出图片上叠加脸部的方框;
物品追踪:在 python 里进行物品追踪,需要导入 lets 程序包,然后 lets track orange,在 cameraStream1 的视频流上进行橙子的追踪;
文字总结:比如用 C# 编程的时候,用 lets class 来调用 summarize(方法:lets summarize 输入文本→产生输出文本),对一段文字进行总结。
这就是我们设想的 lets 系统在使用时在开发者上的体验。大家可以看到,我们把 AI 的能力完全封装在 proxy 的后面,对于开发者来说, AI 的能力到底是远程的服务,还是本地的容器,还是本地的 SDK,这些都不重要。你所需要的就是描述你程序所要实现的功能,然后通过 COA 的 proxy 把这些功能呈现给你的程序。作为运维来说,它可以根据具体的部署场景来选择功能具体的交付方式。
完整 COA 系统架构
完整的 COA 系统,可能还需要很多其他组件,由于篇幅原因,本文只提到了 COA 系统架构的部分组件。COA 并不是我们的发明,而是我们对一些现有程序,特别是一些基于边缘计算的系统模式的总结,我们希望可以和大家一起创建一个比较通用的 COA 架构系统,来实现我们所设想的通用模块,可以使 COA 的应用程序更容易地开发和使用。
-
FPGA
+关注
关注
1625文章
21638浏览量
601349 -
asic
+关注
关注
34文章
1183浏览量
120251 -
人工智能
+关注
关注
1791文章
46700浏览量
237215
发布评论请先 登录
相关推荐
评论