关于云计算:从零入门-Serverless-函数计算的开发与配置

37次阅读

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

导读: 在本篇文章中,“基本概念”局部次要对函数计算最外围的概念进行具体介绍,包含服务、函数、触发器、版本、别名以及相干的配置;“开发流程”局部介绍了基于函数计算开发的残缺开发部署流程。

基本概念

  1. 服务

服务是函数计算资源管理的单位,同一个服务下有很多函数,这些函数共享服务的网络配置、权限配置、存储配置、日志配置。

服务能够对应成一个“利用”,这个利用由很多函数独特组成,这些函数具备雷同的拜访权限、网络配置,日志也记录到雷同的 logstore。这些函数自身的配置能够各不相同,比方同一服务下有的函数内存是 3G,有的函数内存是 512M,有些函数用  Python 写,有些函数用 Node.js 写。

当然,如果利用比较复杂,同一个利用也能够对应多个服务,这里没有强绑定关系。###

1)服务配置

服务的几个外围配置:

日志配置: 开发者的代码在函数计算平台运行,如何查看函数运行产生的日志呢?在 Server 化的开发方式中,日志都打到对立的文件中,通过 Logstash/Fluentd 这种日志收集工具收集到 ElasticSearch 中,并通过 Kibana 这种可视化工具查看日志及指标。然而在函数计算中,运行代码的机器由函数计算动态分配,开发者无奈本人收集日志,函数计算须要帮忙开发者投递日志。日志配置就是起到这个作用,配置 LogConfig 设置日志服务的 Project 和 Logstore,函数计算会将函数运行中产生的日志投递到开发者的 Logstore 里。

然而为了胜利投递日志,单单配置 Logtore 还不够,函数计算是没有权限向开发者的 Logstore 投递日志的,须要用户授予函数计算向指定的 Logstore 写数据的权限,有了这个受权后,函数计算就能够名正言顺地向开发者的 Logstore 投递日志了。

文件存储配置: 函数计算中每个函数都是独立的,在不同的执行环境中执行,如果用户有一些公共文件心愿多个函数共享怎么办呢?在传统 Server 化的开发方式中,好办,将公共文件放到磁盘就好了,各个都去磁盘的同一地位读取,函数计算中的机器是函数计算动态分配的,开发者无奈当时将文件存入磁盘,那怎么办呢?能够挂载 NAS,在服务中挂载 NAS 后,函数就能够像拜访本地文件系统一样拜访 NAS 上的文件了。

网络配置: 网络配置顾名思义就是设置函数的网络拜访能力,次要有两种,一个是函数中是否能够拜访公网,这是个布尔型的开关,默认是开启的,如果不须要拜访公网能够敞开开关。另一个是函数是否能够拜访指定 VPC,VPC 是专有网络,专有网络内的数据比拟秘密,是不能通过公共互联网拜访的。如果须要函数拜访 VPC 内的资源,比方函数须要拜访 VPC 内的 RDS,那就须要授予函数计算拜访指定 VPC 的能力,原理是用户受权赋予弹性网卡 ENI 拜访 VPC,并将此 ENI 插入到 FC 中执行用户函数的机器上,从而使函数能够拜访 VPC 内资源。

权限: 函数计算是云原生的架构,与云上许多服务产生交互,阿里云有十分严格的权限限度,函数计算是没有能力拜访开发者的其余云资源的,当开发者须要函数计算拜访其余云服务的时候就须要显示授予函数计算权限。

权限次要有两个利用场景:一个是授予函数计算拜访其余服务的权限,比方方才提到的受权函数计算拜访开发者的日志服务、受权函数计算创立 ENI。另一个是受权函数能够拜访开发者的云资源,这个是什么呢?举个例子,函数中须要拜访 OSS 获取对象,然而又不想裸露 AK,那怎么办呢?开发者能够配置服务中的 Role 有拜访 OSS 的权限,函数执行过程中,函数计算会 assumeRole 生成一个长期 AK,并将这个 AK 存储到函数的上下文 context.credentials 里,开发者在代码中应用 context.credentials.access_key_id/context.credentials.access_key_secret/context.credentials.security_token  去创立 OSS Client 就能够了。

  1. 函数

“函数计算”中函数堪称是外围概念,函数是治理、运行的根本单元,一个函数通常由一系列配置与可运行代码包组成。

1)函数配置

函数的配置如上图所示:

  • Runtime 是函数运行时的环境类型: 函数计算目前反对 Node.js/Python/Java/C#/PHP 等开发环境,同时也反对 Custom Runtime 自定义运行时;
  • Code 是函数代码包: 函数计算的后端是只认代码包的,各个开发工具会主动帮您打包。比方您能够间接在管制台上编写代码,控制台会主动为您打包创立 / 更新函数,您能够在本地编写 / 调试函数,通过命令行工具 Funcraft 部署到函数计算,Funcraft 也会帮您打包;
  • Handler 是入口函数: 您在代码包中写了好多函数,那函数计算到底从哪里开始执行呢,就从您指定的入口函数开始执行;
  • Timeout 是函数超时工夫: 如果函数执行超过这个工夫,函数会被强制进行执行;
  • MemorySize 是为函数调配的执行环境内存: 目前取值范畴是 128M~3G,如果函数耗用内存超过调配的内存,会 OOM;
  • Initializer 是初始化函数: 有什么用呢?之前咱们介绍函数计算执行环境的时候讲到,函数计算会为函数调配执行环境,第一次调配的时候会有冷启动,以后申请执行实现后,函数计算也不会立刻开释,如果在一段时间内有新的申请达到会复用这个执行环境。Initializer 中的逻辑会在调配执行环境后执行,且保障同一个执行环境执行且只执行一次,那就能够将一些建设连贯、加载依赖等耗时的操作放到 Initializer 函数中执行;
  • InitializerTimeout 就是 Initializer 函数的最大运行工夫。
  1. 触发器

往期课程中介绍了函数计算反对的丰盛的事件源类型,在事件驱动的计算模型中,事件源是事件的生产者,函数是事件的解决者,触发器提供了一种集中、对立的形式来治理不同的事件源。当事件产生时,如果满足触发器定义的规定,事件源会主动调用触发器所对应的函数。

典型的应用场景包含对上传至 OSS 中的对象进行解决,比方图像处理、音视频转码、OSS zip 包解压,以及对 SLS 中的日志进行荡涤、解决、转存,在指定工夫触发函数执行等等。

  1. 版本 & 别名

上文介绍了服务、函数、触发器,开发者就能够基于函数计算将利用搭建起来了,但又有一个新问题: 开发者有了新需要须要更新代码,如何保障线上利用不受影响,平滑迭代上线呢? 为了解决这个问题,函数计算引入了版本和别名。

版本相当于服务的快照,包含服务的配置、服务内的函数代码及函数配置。当您开发和测试实现后,就公布一个版本,版本枯燥递增,版本公布后,已公布的版本不能更改,您能够持续在 Latest 版本上开发测试,不会影响已公布的版本。调用函数时,只须要指定版本就能够调用指定版本的函数。

那新问题又来了,版本名称是函数计算指定的枯燥递增的,每次公布版本,都会有一个新的版本, 那每次发完版本后,客户端还要改代码执行最新的版本吗? 为了解决这个问题呢,咱们引入了别名,别名就是指向特定服务版本的指针,公布后,只须要将别名指向公布的版本,再次公布后,再切换别名指向最新的版本,客户端只须要指定别名就能够保障调用线上最新的代码。同时别名反对灰度公布的性能,即有 10% 的流量指向最新版本,90% 实践指向老版本。回滚也非常简单,只须要将别名指向之前的版本即可疾速实现回滚。

开发流程

如上图所示,开发者首先创立服务,设置日志、权限等配置,而后创立函数,在以后版本(Latest 版本)下编写代码开发函数,测试通过后公布版本,第一次公布的版本为版本 1,创立别名 prod 指向版本 1,就能够对外提供服务了。

客户端调用函数的日志会记录在开发者配置的 Logstore 里,函数计算提供齐备的监控图表,利用上线后,开发者能够通过监控图表和日志查看利用的健康状况。

当开发者有新需要时,持续在 Latest 版本更改代码开发函数,测试通过后公布版本,这次公布的版本为版本 2,切换别名流量 10% 到版本 2,即可实现利用的灰度公布,察看一段时间没有问题,就能够切换 100% 的流量到版本 2 了。

正文完
 0