基于能力的完整 COA 系统架构解析

　　前言

　　很高兴有这个机会和大家分享我们总结的关于边缘计算的架构模式，也就是我们所说的基于能力的系统架构 —— 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 的应用程序更容易地开发和使用。