目录

  1. 从业务层级来简单说说
  2. “应用”到底有没有“价值”
  3. 这个应用很“open”

曾经,有人问我:阿里云函数计算的服务和函数是啥关系?我相信至今还有小伙伴没有搞清楚他们之间彼此的联系。

这几天阿里云又正式发布了一个“概念”:应用。那么阿里云函数计算单单这个层面,就已经有了三层概念:函数-服务-应用,真的是让人有点晕乎乎的。

从另一个角度来看,关注阿里云 Serverless 的小伙伴,应该发现了两个事情:

  1. 阿里云函数计算不仅仅发了“应用”,还正在热推“应用”,并且在多个公众号发PR文;
  2. 阿里云函数计算基于“应用”搞了一期体验活动:一键部署网盘;

为什么阿里云函数计算发布了这么多功能,只有少数的功能会伴随着体验活动一起来做运营?那么这个“应用”到底是何方神圣?他和现在“服务”,“函数”有啥关系?

从业务层级来简单说说

首先,我们要明确,现在很多概念都是抽象的,没有绝对的,尤其是资源和业务层级进行关联后。例如,函数对应的是啥?是一个函数,是一个方法,还是一个功能,一段业务,再或者是一个框架?其实并没有严格划分,所以我们本次的探索一定要基于一种“中庸之道”,一种“可意会难言传”的微妙感觉。

其次,因为所有的名词都是抽象的,对应的不同开发任务,不同业务可能有若干的差别,所以以下的探索仅仅是针对“绝大部分情况”而言的。

在说函数-服务-应用之前,我先放一张自己的想法:

通过这张图,大家不难发现,所谓的:

  • 应用:指的是一个稍微上一层的概念,他实际上是一个或多个FaaS资源与一个或多个BaaS资源的结合。例如,我的一个相册小程序后端,使用了一个函数计算服务(下面包括了三个函数),一个域名,一个存储桶,一个NAS,一个MySQL数据库,一个Redis数据库,以及相对应的VPC资源,日志资源等,而这些,在一定程度上,可以认为是一个应用。因为就我个人角度而言,这些FaaS与BaaS资源联合,实现了一个完整的应用功能,或者业务能力;
  • 服务:这里的服务,在一定程度上指的是函数计算的服务,他实际上是一种对函数的分组,或者说是我们认为某些有关联且可以按照某些规则分组到一起的函数,只不过这里面的分组有一个特殊点,那就是他是带有一定配置的。换句话来说,函数计算的服务,是在使用指定日志存储、VPC、NAS等资源的函数中,具有相同业务属性或者完成某些业务目标,具有相关联的函数集合。所以函数计算的服务实际上是“服务层面的配置”与“一系列的函数资源”;
  • 函数:这个相对来说可以认为是业务层面的一种资源;例如,上面所说的相册小程序后端业务中有三个函数:
    • 函数1: 实现REST风格的API,来为我的小程序提供若干的功能。例如对相册的增删改查、对照片的增删改查等;
    • 函数2: 上传后的照片会被存储到对象存储,通过对象存储触发该函数,实现异步的图片压缩、图片的Image Caption,图片中人物的聚类
    • 函数3: 定时进行相对应资源进行清理/处理/校对/分析等;

综上可以看到:

函数,更多是一种资源,对应到我们业务应该是某种业务的粒度;服务,更多是一种函数的集合,并抽象出一定的配置;应用,更多业务和资源的一种结合。

“应用”到底有没有“价值”

函数计算已经有了服务和函数的概念,初步来看,函数和服务都是“一种资源”,那么已经有了这两层概念,再在上面增加一个“应用”的概念,并且应用更多不像是一种“资源”,而是一种“逻辑”,一种将“资源”关联起来的“逻辑”,那么应用的价值是什么?为什么要有应用,为什么要用应用呢?

其实从我的角度,“应用”在一定程度上是一种心智的升级,即从资源向业务逻辑升级的过程。除此之外,“应用”的出现也意味着之后Serverless架构所交付的可能就真的是“应用”了,这句话怎么理解呢?通过现在的函数计算“应用”来看,我们不难发现,现在的“应用”:

  1. 对应了一个代码仓库,往往可以粗略认为一个repo就是一个应用;
  2. 只需要把业务代码放在github(push/release)就可以触发应用构建、发布(涉及到不同资源的发布等);
  3. 之后的监控、告警、多环境等功能,甚至是应用的整体删除,都可以在这个层面直接来做了;

所以,这就是“以应用纬度玩转Sererless架构”的一种思路,当然,不可否定的是,现在的“应用”还有很多功能在完善的过程中,但是我们也可以看到,他也正在更细腻,更精致,更有趣。

所以,应用在一定程度上,是一种更贴近业务层的全生命周期管理能力,是一种让开发者,让业务团队可以更关注自身业务逻辑,自身应用,自身功能的一种“思想升级”。相对比,传统资源层面的应用部署和管理,“应用”显得更为专业,更为清晰,可以在一个页面看到所有的资源,以及对这些资源进行适当的管理:

除此之外,应用一共被部署多少次,每次的结果/日志,什么样子的,都是可以直接查看的(也可以随时回滚):

在不久的将来,监控、告警、环境划分都将会以应用纬度进行体现,这将会是“业务开发的一个福音”,至少,我自己也在吃自己的狗粮,我是越吃越“上瘾”。

这个应用很“open”

阿里云函数计算所推出的“应用”,是一个非常有趣的能力,他有两种创建方法,一种是可以直接导入一个符合Serverless Devs规范的应用,另外一种则是通过已有的模板进行快速创建:

通过上面的图,我们不难发现,在应用中,有各种web框架、web应用、人工智能案例可供参考。所以不难发现,应用一方面,在努力解决如何让Serverless可以快速Onboarding的“痛点”(上手/体验门槛比较高),另一方面,也在以更多的案例赋能开发者可以简单、快速、方便的上手Serverless架构(甚至有很多应用开箱即用)。

以头几天朋友让我帮忙写的一个PNG图片无损压缩的应用为例:

我作为一个社区贡献者,开发完应用,只需要填写一个官方的应用收录表单(开发应用与提交表单参考:https://github.com/Serverless-Devs/Serverless-Devs/discussions/439):

审核通过之后,就可以自动同步到应用中心,供更多人测试/使用。别人在使用的时候,也是简单的点两下:

  1. 创建

  2. 部署

  3. 体验

整个过程“行云流水”,非常顺利。目前,应用中的模板有包括AI目标检测、OCR识别等在内的数十个社区贡献的应用:

所以这里说Open,也是在指,阿里云函数计算的“应用”,实际上是和社区开源项目 Serverless Devs 呼应的,换句话来说,阿里云函数计算拥抱开源已经拥抱到“把自己当作开源的子集”,换句话来说就是,这个“应用”的所有案例/模板,实际上是Serverless Devs 应用中心的另一种表现:努力开源、贡献力量、开源建设、开放生态,这才是和开发者一起玩转Serverless架构的态度,当然,我也非常希望有更多的开发者,可以和我们一同玩转Serverless架构,现在真的有越来越多的社区项目出现,我相信这只是开始。

欢迎您关注我的博客,也欢迎转载该博客,转载请注明本文地址: http://bluo.cn/alibaba_app_service_function/ 。有关于Serverless等相关问题欢迎联系我:80902630

微信号抖音号