关于云原生-cloud-native:从电源问题出发带你揭秘新体系结构范式-COA

2次阅读

共计 4130 个字符,预计需要花费 11 分钟才能阅读完成。

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

导读 :本文整顿自 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 的应用程序更容易地开发和应用。

8 月 18 日云原生微服务峰会第一天,大佬们是怎么答复云原生和微服务的关系的?

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际,做最懂云原生开发者的公众号。”

正文完
 0