简介： 本文整顿自 2020 年云原生微服务大会主论坛白海石的分享《Capability Oriented Architecture for cloud and edge》，次要介绍了一种新的体系结构范式——面向能力的体系结构（COA），旨在为跨云和边缘的分布式、自适应和强壮的应用程序提供一个设计框架。

作者 | 白海石  微软云计算与边缘计算部门架构师、程序员

导读 ：本文整顿自 2020 年云原生微服务大会主论坛白海石的分享《Capability Oriented Architecture for cloud and edge》，次要介绍了一种新的体系结构范式——面向能力的体系结构（COA），旨在为跨云和边缘的分布式、自适应和强壮的应用程序提供一个设计框架。

公众号后盾回复 818 即可获取直播回看地址和大会 PPT 合集。

前言

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