日志-2021-2

说明

本日志主要由三部分组成:

  • 简记,简要记录每天工作
  • 详记,对简记的各项条目做进一步说明,并附上小结或思考
  • 附录,将学习时的部分笔记附在最后

中短期计划,在三条线上并发:

  • 基础知识补习、基本工具的学习(知识/工程)
  • 锻炼写代码的能力
  • 就今后研究方向做初步摸索与入门(技术/学术)

简记

第0周

1/27 Wed -

  • git
    • 工作区与缓存区的概念,add、commit等指令
    • 版本的更改
    • 远程仓库建立

1/28 Thu -

  • git
    • 分枝相关,创建合并删除等
    • 多人合作
    • tag,ignore等其他辅助功能
  • 概念
    • 容器的概念
    • 重新回顾整理云计算概念

1/29 Fri -

  • 概念
    • 解决对容器概念的一些疑问
    • 容器技术能解决的问题
    • 对Serverless的初步了解、特点
    • 无服务器计算与传统的区别
  • OS
    • BIOS的功能
    • 了解OS的启动过程,POST和MBR

1/30 Sat –

  • Serverless相关
    • 如何提升服务器资源利用率
    • 无服务器如何体现,规模效应如何体现
    • 水平扩容缩容
    • 无状态服务概念
  • Linux命令
    • 查阅系统联机手册、日历计算器等
    • root和普通用户
    • 查看系统用户和当前状态

1/31 Sun -

  • Serverless
    • 为什么要无状态服务,无状态如何体现
    • 延迟体现在哪些方面
    • 测试上的问题
    • 使用腾讯云的SCF体验了最简单的FaaS
  • OS
    • 操作系统启动过程描述
    • 生成自定义OS
    • 操作系统用户界面、shell

第1周

2/1 Mon –

  • Serverless和其他架构的关系
    • 和容器、k8s的关系
    • 与FaaS的关系
    • 与微服务的关系
    • BaaS的体现
  • OS课
    • 系统调用及其实现步骤
    • 进程的概念,与程序的区别
  • Linux课
    • 了解系统状态的一些命令
    • Linux中的文本文件

2/2 Tue -

serverless相关

  • 函数计算的输入、输出
  • 事件驱动/触发
    • 什么事事件驱动
    • 相关术语
    • cloudevent规范

2/3 Wed -

函数计算冷启动

  • 什么是冷启动
  • FaaS中函数冷启动的过程
  • 各个步骤中可以优化的方法

Docker文档

  • overview

2/7 Sun –

临近春节,家中事情多,改为周记

详记

第0周

1/28 Thu -

git

接着昨天学习完了git的一些常用命令。了解了分枝的使用方法和原理,主要可以用于:在新建的分枝上开发完善后再合并到主分枝。比如用master分枝存放稳定版本的代码,在dev分枝上做修改,具体修改时还可创建其他分枝。同时使用stash和branch可以在不影响其他代码的情况下修改bug。

多人合作时,git可以跟踪自己和别人对代码的更改。两人同时对一个分枝作业时,若A先push,那么B需要pull,merge并处理冲突,然后才能push。

使用tag可以对commit进行标记,用.gitignore可以忽略不需要管理的文件。

概念

弄懂以前半懂不懂的概念

对云计算的定义、优势、分类做了回顾和简结。我是把云计算理解为服务,而这种服务可以是不同“程度“的,用户可以按需获得服务。由于云计算提供商可以”大批量“、”统一“安置和管理这些实体云服务器,使云计算具备了某些特征,比如

  • 没有地理位置的限制,移动性高,可以在各地享用服务
  • 扩展性高,可以扩容增加计算和存储的能力,实现单机无法实现的功能。
  • ……

由此,许多基于以上特征的,依赖云的新技术不断出现。

理解了容器是用来干什么的,它和VM的关系。容器的出现使应用软件不需要考虑运行环境的问题,能够以较小的开销,快速地开启或关闭应用。

其他思考

多人同时对一个对象进行作业,而互补干扰,git使用了分枝。就像是先产生了多个”平行世界“,最后收束于一个世界一样。也许“先展,后收”的思想方法可以用在其他地方。

使用类似于”指针“的东西对各分枝管理,在前进或后退版本时不需要复制大量的变更信息。

云计算带来的底层能力的提升,可以带动上层技术的发展。在开发应用时,也可以考虑其本身运行的环境(本地主机还是云服务器上?是容器中还是VM上?)

1/29 Fri -

OS

BIOS的功能:

  • 系统启动配置
  • 提供设备的I/O服务
  • 系统加电自检Power On Self-Test
  • 引导系统启动

上电后:

  1. 进行POST,初始化各硬件
  2. 从硬盘/光驱/……读入OS,OS接管计算机。
  3. 首先读取的是承载OS的实体的首扇区,存有Main Boot Record。MBR中有OS启动相关的内容。MBR会进行查找活动分区等,将分区引导记录加载到内存
  4. PBR继续控制后面的引导过程

概念

容器考虑了应用开发后部署环境的问题。将应用和它所需的库、依赖等打包成镜像。将镜像放到容器中就可以运行而不需考虑运行环境,十分便捷。这有利于应用的开发、测试、部署和维护。也能很容易地迁移服务。

使用容器技术后,容器相互隔离,应用互不干扰,服务器上的资源能够得到更充分的利用。容器能快速启动和关闭,还能动态扩容缩容等。适合业务需求随时间变化量大的服务。

Serverless中,用户甚至不许要打包镜像,只需要提交代码就能运行。应用开发方只用关注业务逻辑,可以忽略底层的基础设施以及其他辅助组件。比如不需要关心负载均衡、服务发现、安全监控、服务部署和维护等各方面的问题?

明天学习了解Serverless的基本实现原理和一些陌生概念。

其他想法

为了更方便地进行软件应用生命周期的各个部分,从VM到容器,云服务的效率在不断提高,软件应用的开发部署也更加方便简单。我感觉容器本身就是解耦和聚合的体现。而Serverless似乎是更进一步,把更多与业务逻辑无关但必要功能直接做在了云服务中,不需要用户关心。

1/39 Sat –

Serverless相关概念

Serverless中,只有请求到来时,服务实例才被开启,而非一直运行着。这样做提高了服务器的有效利用率。

用户提交的代码被服务提供方统一部署、管理、调度,也不用关心服务器选型、维护等问题。大量的工作由提供方统一完成,产生了规模效应。能使以上工作的成本更低、完成效果更好。

Serverless中的服务实例若想水平扩容,那么需要他是无状态的。无状态指某次请求的处理服务不能使用其他次请求的信息。

Linux命令

使用联机手册man可以方便地查阅各种说明书。比如命令、c语言函数库等。

计算器bc可以设置精度,并且可以支持变量、函数、条件、循环。

root用户权限很大,使用时需要警惕。用户口令以随机值+生成的hash值方式存储,即使是root也不能查到普通用户的口令。

其他思考

可能正是因为Serverless要求的这种伸缩性,不得不考虑实例容器的启动和关闭问题。而启动和关闭的开销很可能使Serverless的性能出现瓶颈,这也许是要研究快速冷启动的原因之一。似乎可以设置一些策略来控制某一服务的众多实例的开启和关闭,从而减少在开关上的开销。

1/31 Sun -

Serverless

为了灵活扩容缩容,某个容器可能的开启和关闭一定程度上是不确定的。因此一次请求不能够依赖其他次的请求。

允许一个实例容器连续响应多次对同一个函数的触发调用,这个容器的冷启动只有一次,冷启动时全局量的初始化只有一次,是可以”共享的“。但是一个请求才发起时,不能确定触发的响应是冷启动的实例还是复用之前已经存在的实例,所以只能不能依赖之前的状态。是无状态的。

延迟有低耦合的函数相互调用的延迟,以及容器冷启动的延迟(相比传统的容器架构可能会更频繁地冷启动)。

由于高度分布,所以开发者难以模拟分布式环境进行本地测试。

OS

操作系统启动,主要是初始引导核心初始化和系统初始化。

生成操作系统有一定的前提和步骤。先要根据硬件和用户需要配置功能模块和构造参数,再build成OS的映像。是二进制的。

操作系统提供给了用户控制计算机的机制——用户接口,包括操作界面系统调用。操作界面则有图形界面、命令界面和批处理命令/界面。

shell也是一种OS与用户的交互界面,通过控制台执行用户命令。shell本身不执行命令,仅仅是组织和管理命令。

其他思考

Serverless有优有劣,可能更适合于请求流量密度不固定的(伸缩性好)、无状态的服务。是否采用Serverless要结合实际业务情况来决定。

第1周

2/1 Mon –

Serverless和其他架构的关系

先前的很多Serverless实现,都是基于k8s的FaaS产品。通过扩展k8s,管理一些列的函数容器应用,以实现FaaS功能。讲业务逻辑和后端逻辑写好后,提交给FaaS平台,FaaS会将代码打包成镜像,在有事件触发时生成容器并响应。

serverless实现了FaaS和BaaS的功能。FaaS简化了容器部署、管理、扩容等一些列问题;BaaS整合第三方组件进一步辅助应用开发。

满足一定条件的微服务可以使用Serverless提供的服务运行。

OS课

系统调用是用户界面(提供给用户控制计算机的机制)的一种。通过中断进入核心态,对硬件或者进程进行操作。

进程是程序在某个数据集合上的一次运行活动,是静态的、暂存的。四大特点是:异步性、并发性、独立性、动态性。

Linux课

有一些命令可以查看当前系统的状态。比如ps查看进程状态、free查看内存使用情况、vmstat查看系统负载。还有CPU占用时间和内存中的buff/cache区等一些微妙的概念。

Linux提供了大量文本文件处理命令,把stdin/stdout也管理成文件,并充分利用了重定向和管道。可以将不同命令的输入输出和文件关联起来。

其他想法

微服务是从应用开发的架构,Serverless是云服务提供的架构。二者可以相互融合。Serverless本身也使用到了容器,用容器来管理函数,本身来讲也可以看做是容器技术在服务提供方面的新发展。

2/2 Tue -

serverless相关

函数的输入要求包含事件数据、元数据和上下文。函数的输出可以由结构化和非结构化两种形式。

事件驱动编程是一种编程范式。当有触发时,向消息/事件队列中添加一个事件,会有一个循环从队列中取出队列,并执行相应的函数。

CNCF的CloudEvent规范对事件数据在格式上做了一定的要求。

2/3 Sun -

本周的进度

结束了实习,返回家中。家里事情多,时间安排难,改为每周总结。

前段时间大概了解了Serverless的各个概念,将查找资料学习的概念内容附在后面。感觉这种概念的东西看一看过一遍就行了,全写下来有些浪费时间。但木已成舟,希望今后学其他东西的时候效率能高一些吧。

展望

周围接触的人都十分优秀,要不就和长辈们吃饭,谁谁孩子在国际知名大学留学读博,或新认识的朋友竟然又是华五的,就是小时候一起玩的那几个,也都北航中山。自己是十分渺小的。

硕士生还是应该与本科生有一定的区别的,硕士生确实得搞研究,学会搞研究的那一套思维,但做工程的能力必不可少。这二者挺难平衡的,但我相信这个学科和行业,后者是前者的基础,而前者是只能在学校里学到的。默认的道路就是先学校里科研,工作之后再工程,这是能最大化读硕三年的方法;但不会工程只搞科研是行不通的(1.真的不行,2.没这环境)。

想让二者齐头并进则需要牢固的基础和功底。读硕肯定是要搞科研的,不搞科研就没必要读学硕;但若要一心搞科研不做工程,那我觉得应该直博。二者并发必然要各种基础(特别是对我这种),但周围的环境并不理解我的这种需要。我还有7个月能大补基础,时间不多了。

弱小和无知不是生存的障碍,傲慢才是。

附录

待上传,大概一周补一次

  • git
  • 概念

概念

把不懂的概念理一理,用自己的话说一遍

重新回顾整理云计算概念

用自己的话重新说一遍

  • 云计算是什么?
    • 通过互联网提供的计算和存储服务。不需要开考虑其背后的实际物理设备的存在。
  • 云计算模型?
    • IaaS 此服务提供的是一套几乎完整的计算机,客户可以自由使用计算机软硬件资源,就像从远程配置和操纵一台主机。(像是一台虚拟机?)
    • PaaS 无需关心硬件和系统软件(由服务提供商管理),客户可以直接在此服务上部署和管理应用软件。
    • SaaS 此服务直接提供应用软件,客户只需关心如何使用该应用
  • 另一个角度分类
    • 公有云
      • 将在本地设施中可以运行程序迁移到云中去
      • 直接在云中建立程序,和云计算设施紧密结合
    • 混合云
      • 将云与本地设施连接在一起,共同服务
      • 私有云 我的理解是,在本地维护云计算设施,为内部用户提供云计算服务
  • 云计算的优势/好处?(相比自己维护一个物理的服务器)
    • 使用方便(维护成本低,节约空间,移动性高)
    • 更易获得高性能(速度快,可靠性高)
    • 灵活性更高
      • 可按需购买不同配置的服务
      • 部署类型不同的各种应用
    • 可扩展性高(按需扩大或缩减业务规模)

容器概念

将应用与其运行环境(如依赖等)打包,称为“镜像”。将镜像放到“容器”中就能运行,无需再考虑它所在的环境。

特点:

  • 方便移植(不受运行环境的变化影响)
  • 独立性好(应用间不会相互干扰)
  • lightweight(暂时没理解原因,是与虚拟机相比?)
  • 启动和释放速度更快(与VM相比,具体原因应该和他的实现方法有关)
  • 效率高
  • 一台服务器能运行更多应用实例
  • 运维时开销更少(如更新或升级)
  • 因为以上的原因,容器适合部署微服务?
  • ……待补充

为什么需要使用容器替代VM?

在容器普及之前,使用“虚拟机”划分机器资源。每个虚拟机都会使用虚拟出来的“虚拟硬件”和“虚拟OS”。并且存在一个虚拟层,从实际的机器硬件中为各个划分出来的虚拟机划分他们所需的硬件资源。

使用容器,不需要虚拟层,也没有虚拟硬件和虚拟OS的开销。只需要使用一个叫容器的程序来驱动各个应用镜像?(消耗更少的CPU和内存)

可能是因为实现方法特殊,其启动和释放速度比VM快

那么,为什么要将大型设备的资源划分成更小的组成部分?

……待解决

有利于企业的开发、测试、部署、运维?

容器应用在部署上的总开销小,开发和测试周期更短,开发和运营团队间可以更方便地移动应用给对方,合作更高效。敏捷开发?

  • 有利于企业的开发、测试、部署、运维

如何在不同平台上屏蔽运行环境?

移动性。容器提供标准化的格式,将应用和应用所需的所有组件打包。因此在不同的环境下,应用都可以依靠这些打了包的依赖组件,以相同的方式运行。

  • 服务迁移,将原有的在本地服务器上的应用装入容器,迁移部署到云端。或者在不同的云间迁移

为什么容器的伸缩性更好?

扩展。容器运行的开销比VM小(轻量),同样的设施上能运行更多的容器,容器的能更快开启和停止。一个容器服务请求多,可以短时间内开启更多的该服务实例,关闭需求少的实例。

  • ML,例如在数据分析中,可以灵活增缩所需的资源。

Serverless相关概念

什么是“无服务器”?

云计算服务提供商,维护后端基础结构,为应用提供各种基础功能。如数据库、消息和省份验证

应用开发可以更关心业务逻辑,不需要关心任何基础设施/底层实现。

特点

  • 无状态(运行在无状态的计算容器中)
  • 事件驱动(由事件触发/驱动)
  • 无状态(被第三方托管,业务层面的状态则存储在数据库或其他介质中)
  • 扩容缩容
  • ……

核心技术:

  • 函数的规范定义
  • 函数部署流水线
  • workflow设置
  • 0-m-n扩缩容
  • 快速冷启动
  • ……

开发者要做什么?

只需编写代码和选择触发器(比如RPC请求)

什么由Serverless计算提供方完成?而不需要用户

和业务逻辑无关的其他组成部分,以及运行维护。比如负载均衡、安全监控等原来开发者需要设置的内容,以及具体的服务部署、扩容缩容等

开发者不需要指定服务运行的资源载体。只需要上传代码

服务计费方式有改变:

按服务使用量收费,比如调用次数、运行时长。而不是按照占用服务器的资源

Serverless适合具有哪些特点的应用?CNCF

  • 异步的并发,组件可独立部署和扩展
  • 应对突发或服务使用量不可预测(主要是为了节约成本,因为 Serverless 应用在不运行时不收费)
  • 短暂、无状态的应用,对冷启动时间不敏感
  • 需要快速开发迭代的业务(因为无需提前申请资源,因此可以加快业务上线速度)

Serverless的使用场景?

https://gw.alipayobjects.com/os/basement_prod/24ec4498-71d4-4a60-b785-fa530456c65b.pdf

  • ETL
  • ML
  • 图像处理
  • IoT传感器数据分析
  • 流处理

优点中的几个

服务器资源利用率高的原因?按服务使用量计费的好处?

购买传统的服务器资源,购买后一直占用此服务器资源。但是这些购买的服务器并不是一直处于满负荷状态,有大量资源被闲置。

Serverless服务按使用量销售。买家不需要提前购置定量的服务器资源,而按使用量付费。计费粒度更小

这样的话,Serverless服务只在有需求到来时开启应用响应请求,在没有请求到来时可以关闭应用。这样就能Serverless服务器上总是高负荷地运行着应用,服务器资源利用率高。

Serverless中的“无服务器”体现在?

用户不需要自己维护服务器、关心服务器的运行状态和资源使用情况。更多关注业务逻辑的部分。

规模效应,多个角度

基础设施:的利用率提高,维护运营更加容易,可靠性提升。

服务使用者:开发更方便、运维更简单、服务购买成本低,获得的服务质量高。产品更新升级方便。

服务质量:弹性好,扩容缩容方便,服务可靠。

缩短开发和部署时间:

容器主要降低了部署时间,而Serverless不仅部署快,开发速度也快。

扩容缩容的例子:

AWS的Lamba中,Serverless通过事件触发函数。当有事件到来时,启动一个容器处理该事件。如果尚未处理完毕,则会再启动一个容器来处理。

至于何时关闭,应该有相应的算法,按照请求到来的流量密度,保持一定的容器实例处于开启状态,以减少频繁开启和关闭容器带来的损失。

这也许和冷启动有关

缺点中的几个

必须是无状态服务

无状态服务是什么?

对单次请求,

  • 服务响应不需要依赖其他的请求,不调用其他函数,不查看其他实例占用的内存中的信息?
  • 只依靠本次请求的信息、外部其他的信息(如数据库)

服务器不为某次请求存储信息供其他请求查看。

前一次请求不影响后一次请求

为什么Serverless要求无状态服务?

我的理解是:为了实现灵活的扩容和缩容,各个容器实例/函数间不能相互依赖,所以要求无状态服务。

有状态服务也会增加耦合度。

Serverless中的无状态和容器复用

某次请求启动了一个容器,处理完毕后,该容器不一定立即关闭。

此后,若有另一个对相同函数的请求到来,可能会直接使用之前创建的那个容器。这就使得两次请求共同使用了同一个容器。当然也就可能会共享存储在这个容器中的信息。(这种时候就不是彻底的无状态

启动一个函数的容器时(冷启动),初始化的包括:函数本身+函数之外的全局部分。每当有请求触发该函数时,实际上只进入执行函数部分,而函数之外的全局部分实际上只执行了一次,也就是不同次的请求所共有的。

在不考虑复用时,每次触发函数,都会冷启动一个容器来响应它,这时候函数才是彻底无状态的。

在存在复用的情况下,用户并不知道本次请求是否会复用之前的容器。所以每次请求不能够依赖其他次请求的信息(状态),因而需要把每次请求都看做是无状态的。

延迟

需要考虑的延迟

  • 需要考虑函数间相互调用的延迟。Serverless是低耦合的,会有大量的不同类型组件(也可以理解成不同的函数容器?)。而Serverless是高度分布式的,不同组件间的相互调用可能会有较大的延迟。
  • 容器冷启动有延迟。Serverless会按需生成或关闭函数的容器。响应服务时,需要考虑冷启动的问题,而Serverless中的冷启动不同于普通容器的冷启动,前者可能会更频繁地冷启动。

测试更麻烦

Serverless比传统的IaaS或者PaaS更加具有分布式的特点。应用的部署和运维可以交给服务提供方实现,但是测试不行。而开发方自己在本地构建高分布式的测试环境又十分的困难。

Serverless与一些其他架构的关系

发展初期,许多serverless是以kubernetes为基础的,k8s是做什么的?

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

It groups containers that make up an application into logical units for easy management and discovery.

k8s是一个容器编排引擎,自动化部署、可伸缩,管理容器化应用。我们可以用k8s创建一组容器,k8s会帮助我们对这些容器进行管理和发现等。

函数计算,或FaaS是什么?它有什么特点

在无状态容器中运行的事件驱动型计算执行模型,利用服务来管理服务器端逻辑和状态。

以函数的形式构建、运行和管理应用包。

编写业务逻辑后,部署到云服务商管理的容器中(只需提交代码,不需要自己打包?),由云服务器自动管理,按需执行。

FaaS基础架构通过事件驱动模型进行,随时待命,但不需要有后台进程一直运行,很容易进行扩展。

为了实现这些优势,带来一些限制(比如使用单次调用的时间)。需要做到函数的快速启动和运行

FaaS和Serverless的关系?

可以使用FaaS实现Serverless的一部分,Serverless除了FaaS实现的自定义函数逻辑外,还能包括了通用的服务(各种组件)。

使用FaaS时,开发者仍需要自己开发服务器端逻辑,只不过是运行在由云服务商管理的容器中。

Serverless中,也是提交到代码到容器运行,但是可能就不需要编写服务器端逻辑了,可以由Serverless中实现的BaaS的那一部分来实现。(个人理解)

FaaS商业化产品:

  • AWS lambda
  • Google Cloud Function
  • Microsoft Azure Cloud Functions
  • IBM Cloud Functions
  • ……

微服务与Serverless的关系?

我的理解,微服务是应用软件的体系架构,Serverless是提供云服务的架构。

传统微服务和传统应用架构,只要可以容器化、合适于动态扩展和状态管理(无状态、寿命短、对冷启动不敏感、请求流量密度随时间变化不均匀,不可预知),就可以使用Serverless。

BaaS在Serverless中有哪些用途?

BaaS提供了和业务逻辑无关的服务。比如认证、监控、访问数据库等。也就是后端的逻辑。

应用开发者可以通过整合第三方 BaaS 产品的完整组件来进一步简化应用开发。

配置、维护、扩展服务器等基础架构工作。云提供商负责管理云基础架构和应用扩展。

讲代码打包到容器。

部署后,有事件驱动时才运行代码(容器),可以根据需要自动扩容缩容。

函数计算、事件驱动等

函数计算的输入包括事件数据和元数据,上下文

不同事件可能有不通的元数据。事件可以包括单个记录(请求/响应模型),也可以是多个记录或微批处理(流模式)。

事件/记录特定元数据的示例

  • HTTP:path、method、header、查询参数
  • 消息队列:topic、header
  • 记录流(record stream):表、键、操作、修改事件、旧字段、新字段

调用函数时,可能希望访问平台资源或常规属性。

上下文(context)可以是一组输入属性、环境变量或全局变量。比如:函数名称、版本、ARN、内存限制、请求ID、环境变量、日志、令牌、……

函数会有如何的输出

函数输出可以是结构化的(如http响应对象)或非结构化的(如某些输出字符串)

通过返回值或其他方式的函数退出知道该函数调用是否成功

  • 将返回值给调用方(例如,HTTP请求/响应)
  • 将结果传递到工作流中的下一阶段执行
  • 输出写入日志

事件驱动是什么?

事件驱动编程事一种编程范式。程序的执行流由外部事件决定。有一个事件循环,外部事件发生时,使用回调机制来触发相应的处理。

有一个事件队列,当外部触发一个事件时,向队列中增加一个事件。有一个循环不断从队列取出事件,根据事件调用相应函数。事件一般都保存了自己的处理函数指针,每个事件都有独立的处理函数。

个人理解,事件队列中的事件应该可以交互,所以事件驱动程序的耦合性较高。

事件数据规范CloudEvent

CloudEvent是以通用格式描述事件数据的规范,提供跨服务、平台和系统的互操作性。提升可移植性和开发效率。

事件的格式有一定的规则要求。必须要支持JSON格式。也有大小的限制

有一些必要的属性:id: String、source: URI-reference、specversion: String、type: String

还有一些是可选的,比如:datacontenttype: String、dataschema:URI、subject:String、time:Timestamp

使用Json序列化CloudEvent的示例:

1
2
3
4
5
6
7
8
9
10
11
12
{
"specversion" : "1.0-rc1",
"type" : "com.github.pull.create",
"source" : "https://github.com/cloudevents/spec/pull",
"subject" : "123",
"id" : "A234-1234-1234",
"time" : "2018-04-05T17:31:00Z",
"comexampleextension1" : "value",
"comexampleothervalue" : 5,
"datacontenttype" : "text/xml",
"data" : "<much wow=\"xml\"/>"
}

ArchSummit2019深圳-周维跃Serverlee平台冷启动优化(腾讯的FaaS产品SCF)

函数冷启动

第一次部署函数实例的过程。我的理解是,生成第一个实例时有一些初始化设置和连接可以供后续实例使用。第一次启动的时间较长,而后续的较短。

过程

  • 创建VM/container
  • 下载函数(未缓存)+部署
  • VPC Net Proxy部署弹性网卡

方法

  • 轻量级虚拟机系统
  • 代码缓存
  • VPC网络代理
  • 自动扩缩容
  • 用户可以做一些事

轻量级虚拟化系统

调度上轻量化,降低调度复杂度

​ 使用更少的虚拟机配置,宿主机的可用资源离线计算

网络方面提前预下发

虚拟化方面,轻量级虚拟机快速启动

  • 提前创建虚拟机模板,基于虚拟机模板文件启动轻量级虚拟机

代码缓存

将可能使用的代码缓存下来。

网络访问的模型

函数会同时访问

  • 用户VPC中的资源,比如CVM、CDB
  • 公网、自建数据中心、有些场景下需要公网ip

弹性网卡绑定在Pod/node上访问VPC资源

ENI在同一个pod/Node内多容器共享。同pod/node内再次创建函数实例不需要重新绑定ENI(冷启动延时高,ENI消耗完后函数并发提升受限

通过vpc NET proxy转发。

在函数创建时,将ENI绑定到Proxy的转发节点上。

cold start为ms级,仅消耗一对ENI(主备节点支持高可用,秒级故障切换)

转发节点的贷款自动扩缩容

自动扩缩容

预留buffer,准备实施扩容。分级缩容,有冷却时间。

预测扩容,比如调用链上的函数。

灰度切换到另一个版本

用户的角度

代码精简,减小体积。区局变量,资源服用。定时触发保活

他的总结

从函数架构层面优化,支持更大规模的集群管理和大并发实例部署

优化轻量级虚拟机系统,降低虚拟机创建耗时

优化VPC网络转发模块,降低弹性网卡部署的耗时和资源消耗

四是自动扩缩容,避免冷启动

用户裁剪代码、复用资源、保活策略

  • pod,一组容器的集合
  • CVM,cloud virtual machine。
  • VPC,virtual private cloud
  • KVM,时linux内核提供的虚拟化架构,将内核直接充当hyperviosr(VM monitor)使用
  • QEMU时vm monitor,通过动态二进制转换来模拟CPU,并提供一系列的硬件模型。
  • QEMU-KVM,KVM负责cpu虚拟化+内存虚拟化,实现了cpu和内存的虚拟化,但kvm并不能模拟其他设备,还必须有个运行在用户空间的工具才行。KVM的开发者选择了比较成熟的开源虚拟化软件QEMU来作为这个工具,QEMU模拟IO设备(网卡,磁盘等),对其进行了修改,最后形成了QEMU-KVM。
  • 灰度系统,是用来帮助 API 服务在上线时按照受众从小到大最终至全量的发布,实现功能的灰度上线,用来保证发布的服务的质量的系统。

程序代码部署在平台上,通过事件驱动的方法触发对函数的调用。

什么是事件驱动?事件触发

待补充

待解决的概念:

  • BaaS
  • FaaS
  • 函数计算
  • 消息中间件