Serverless 概念入门

Corey2026/8/13大约 17 分钟

Serverless · 概念入门（合并）

一、现阶段云原生应用领域

可参考CNCF相关链接：https://landscape.cncf.io/

1.5 云原生安全技术

基础设施安全：存储安全（加密存储、容灾备份）、网络安全（网络策略管理、访问控制）、计算安全（系统加固、资源隔离）

应用安全：应用数据安全、应用配置安全、应用环境安全

云原生研发安全：代码托管、代码审计、软件管理、可信测试、可信构建

容器生命周期安全：运行时安全、容器构建（镜像扫描、镜像签名）、部署安全（合规部署）、组件安全

安全管理：身份认证、访问授权、账号管理、审计日志、密钥管理、监控告警

二、现阶段云原生应用领域的痛点

2.1 IT基础设施运维的痛点

早期的IT基础设施运维多数情况下还采用“人肉”运维模式，随着自动化运维水平的提高，IT基础设施运维才逐步走上了自动化的道路，由于时代的发展，社会的进步，自动化运维阶段时间非常短，我们现在已逐渐进入智能化运维（AIops）阶段或无运维(Noops)阶段。

痛点：
1）无论哪个阶段我们都需要学习大量的技术才能满足运维的要求
2）技术分枝越来越多，工作过程中需要选择技能方向
3）由于涉及大量系统的集成，出现问题时，需要花费大量的时间排查及解决
以上痛点对于开发者来说，不能够让其专注于自己的业务代码，反而去关注IT基础设施运维，导致其精力分散太多。

有人说IT基础设施运维那么复杂，那我们直接使用PaaS云平台好了，不用再关心IT基础设施及应用运行环境，直接使用容器化技术部署业务代码，简单易用，只要掌握好PaaS云平台管理就可以了，那么问题就来了，我们要想使用PaaS云平台是不是需要搭建？是不是还需要掌握其核心概念及应用原理，当出现故障时甚至比IT基础设施排除故障更麻烦，例如：PaaS云平台我们使用Kubernetes建设完成，却发现开发人员或运维人员使用它的门槛很高，我们可以使用Jenkins，Helm, Chart来简化CI/CD流程，但其配置及运维管理依然复杂。开发人员需要关注容器构建、扩缩容、流量控制等等实现细节。为了降低开发者使用K8S技术的门槛需要简化服务管理的复杂度。

2.3 Kubernetes平台应用方式及应用痛点

Kubernetes作为一个通用目的的PaaS云平台，开发者拥有很大的自由度，但由于技术经验和习惯的不同，开发者使用K8S的方式也各不相同：
1）将K8S工作负载（Pod）当成虚拟机使用;
2）将Dubbo服务作为K8S工作负载，使用Dubbo框架做服务治理;
3）将Spring Boot框架下的微服务部署在K8S集群中，使用Spring Cloud工具套件做微服务治理；
4）基于HTTP通信协议的典型微服务。
5）K8S虽然支持各种编排方式，但复杂度也会大大增加，对运维工作提出了巨大挑战。我们需要一种简单有效的服务编排标准来解决开发与运维管理复杂度问题
6）K8S本身并没有解决低频使用的服务资源占用问题，依然有大量服务、作业即使很少被使用，但依然占据着CPU和内存资源，导致计算资源的使用率较低，我们需要一种全新的方式来提高计算资源使用率。
在云原生时代，Kubernetes和Istio的引入给微服务的开发和部署提供了完整的解决方案，同时也带来了更高的维护复杂度，因此我们需要提供了一套简洁的方案来解决微服务的管理问题，即让开发人员不知道IT基础设施或PaaS云平台的存在。

为什么要引入Serverless

为什么要引入Serverless?

一、IT系统资源应用及软件后端架构演进过程

1.1 资源应用演进过程

1.1.1 物理机

物理机，就是我们能够看得见摸得着的物理设备，对于开发者来说，如果想使用物理机是非常麻烦的，早期的物理机部署应用步骤如下：

1）把物理机托管到机房

2）连接电源和网络

3）安装操作系统

4）部署应用运行环境

5）为主机申请静态IP地址及域名备案

6）部署FTP类软件用于上传所开发的程序

所以对于开发人员来说，部署比较繁琐，维护困难，需要专业的运维人员参与，而且一台配置较高的物理机，如果只运行单一应用程序，用不了太多的资源，会导致物理机资源浪费。

1.1.2 虚拟机

为了防止物理机资源被大量浪费，我们可以把物理机分隔为虚拟机给开发人员使用，虚拟机所起到的作用主要为打包物理机计算资源（CPU、Memory、硬盘、网络），开发人员仅需要使用适当的资源即可，物理机交给专业的运维人员负责即可，在云时代甚至可以直接购买云厂商的云主机（虚拟机），物理机运维交由云厂商负责维护。

随着软件架构的发展，应用程序对于计算机系统资源的需求不再是单一不可选择的方式提供了，完全可以独立开发了，例如：应用程序与数据库分开，这样开发人员仅需要关注于业务代码的开发，而不需要再对数据库进行维护，这样应用程序与后端数据存储就实现了松耦合。

当应用程序与后端数据存储分开部署后，我们也是希望保证我们的系统能够正确运行，当应用程序对计算资源需求增加时，我们应该让用户在无感知状态下完成资源的增加，这样就需要大量的虚拟机资源，每次增加虚拟机我们都要初始化应用程序运行环境，而这一动作是非常复杂且繁重的，对于专业的运维人员来说也是非常困难的，需要专业的技能与技巧才能完成初始化配置，如果有一种技术，即使通过虚拟机增加计算资源需求，现实服务器扩容，也能非常轻松的搞定应用程序运行环境，甚至能够让应用程序在秒级启动，这就是容器技术。

1.1.3 容器

从1979年在UNIX系统中使用chroot到2008的LXC，再到2013年的Docker容器管理工具，人们一直在寻求高效使用物理机资源的方法，容器化技术可以让我们把应用程序及其运行环境一同打包，在任意Linux主机上运行，有了这项技术，可以不用再考虑应用程序使用的计算资源扩展时配置环境的问题了，大大提高了应用开发的交付效率。随着容器技术不断应用，容器管理的需求也越来越多，2014年由google开源了其使用已久的容器编排技术方案——Kubernetes。

1.1.4 对于使用计算资源的终极希望

做为企业的经营者，对使用计算资源的终极希望是:当用户访问量大时，应用系统能够自动扩容资源抵御流量洪峰；当用户访问量小时，应用系统能够自动回收资源节约计算资源或把节约出的资源提供给其它高需求计算资源的应用，以实现计算资源自动调配。但是长期以来，这仅仅只是一种希望，并没有现成的技术解决方案，直到最近二三年，人们的这种希望才真正有了落地方案:Serverless。

1.2 软件后端架构演进过程

1.2.1 单体服务架构

整个系统的所有功能单元整体部署到同一进程，既所有代码可以打包成一个或多个文件，进一步细分：简单单体模式、MVC模式、前后端分离模式、组件模式和类库模式等

1.2.2 分布式服务架构

整个系统的功能单元分散到不同的进程，然后由多个进程共同提供不同的业务能力，主要分类有：面向服务的架构(SOA)、分布式服务架构（DSA）、微服务架构（MSA）

1.2.3 微服务架构

最早出现于2011年，关键点：

由一些独立的服务共同组成应用系统
每个服务单独部署、独立运行在自己的进程中
每个服务都是独立的业务
分布式管理
遵循低耦合、高内聚的原则

下面我们提到的Serverless同样是一种微服务架构设计模式，由于其更小，所以我们也可以称之为超微服务。

二、Serverful

2.1 根据IT系统资源应用定义

Serverful就是物理机、虚拟机、容器计算资源使用方式，必须需要更多的人员参与，所以对使用人员技能要求高。

2.2 UC伯克利大学论文定义

2019年UC伯克利大学一篇论文《Cloud Programming Simplified: A Berkeley View on Serverless Computing》中提及：“在云的上下文中，Serverful计算就像使用计算机底层编程语言---汇编语言编程一样”，例如c=a+b这样简单的表达式，如果使用汇编描述，就必须先选择几个寄存器，把值加载至寄存器，进行数学计算，再存储结果。

在今天这样的IaaS云环境下，Serverful计算就必须先找到需要分配或找到可用的资源，然后加载代码和数据，再执行计算，将计算的结果存储起来，最后还需要管理资源的释放。

2.3 Serverful对人员技能栈要求

三、 Serverless

3.1 Serverless定义

3.1.1 CNCF（云原生计算基金会）对Serverless定义

Serverless架构应用是采用FaaS（函数即服务）和BaaS(后端即服务)来解决问题的一种设计。

3.1.2 使用者层面对Serverless定义

1）Serverless（无服务器架构）指的是由开发者实现的业务逻辑运行在无状态的计算容器中，它由事件触发，完全被第三方管理，其业务层面的状态则被存储在数据库和其他存储资源。

2）Serverless不代表不需要服务器，而是说开发者不用过多考虑服务器的问题，计算资源作为服务而不是服务器的概念出现。

3）Serverless是一种构建和管理基于微服务架构的完整流程，允许开发者在服务级别而不是服务器级别来管理应用部署，这大大降低了软件开发的复杂度，使得开发者可以快速迭代，更快速地开发软件。

3.2 Serverless组成

3.2.1 FaaS

无服务器架构不仅仅是函数计算，还包含各类后端服务，FaaS是无服务器架构的一种实现，它包含了一个标准化的运行时框架，用于构建执行函数。

3.2.2 BaaS

我们把硬件的管理、服务的搭建、缓存、存储、消息中间件等全部做好，并封装起来以接口的方式提供服务，这就是BaaS，称为后端即服务。其就是一个黑盒，不需要知道怎么做，甚至如何做，需要什么直接通过接口调用即可。

例如：我们向数据库上传数据或用户上传的照片需要裁剪后存储到存储系统，这就需要我们编写业务逻辑代码去完成的功能，把逻辑代码写好后，前面说到的所有的服务器及运行环境都放到了BaaS当中，那么如何让这些代码运行起来呢？因为代码的运行需要运行环境的，怎么办？我们只要将代码交给Serverless就行了，Serverless中有一个专门用于运行逻辑代码位置，这个位置就是前面我们所提到的FaaS,FaaS是以函数的方式运行代码的，本质上其就是一个函数运行平台，大多数云计算平台提供的Serverless都支持node.js,php,java,python,go等编程语言，开发者可以选择自己喜欢的编程语言编写函数并且运行，对于开发者来说使用FaaS几乎就是使用serverless的一切，开发者对底层运行服务器是无感知的，云平台会负责资源的调度及管理工作。

3.3 Serverless特点

无运维指的是无需要管理IT基础设施
事件驱动指的发生某一访问事件后，对应的应用程序才会运行，第一次运行等待时间较长，一般为3-5秒左右（冷启动），第二次访问与正常访问时间一样
函数不是持续运行的，而是由一定的条件进行触发，例如http请求事件或消息事件，或者定时器等等，产生事件的源头我们称这之为触发器，FaaS平台会集成这些触发器
按量付费，ms级，按FaaS函数执行的次数，执行时消耗的CPU、内存等等资源进行计费的，用多少付多少，如果不用就不需要付费
同时，FaaS会根据并发量自动生成多个实例，以响应用户的访问请求，BaaS根据资源需求量自动调配后端的资源，理论上调配资源量是无上限的，这也就实现了不同访问量的弹性伸缩，而且是实时的弹性伸缩
Serverless是计算与存储分离的架构，即FaaS与BaaS分别运行。分开部署与收费。这使得应用的存储不再是应用的一部分，而是演变成独立的云服务器，降低了数据丢失的风险，而且应用本身也变成了无状态的应用，更容易进行调度和扩缩容，基于FaaS与BaaS,你的应用就实现了自动的弹性伸缩。

Serverless应用场景

一、异步及高并发

对于异步的、高并发的，并易于并行化成独立工作单元的工作负载

二、低频或零星请求

对于应用系统访问低频或有零星访问请求，但具有较大不可预测扩容变化需求的工作负载

三、无状态

对于应用系统是无状态的、短期运行的，对冷启动（一般为3-5秒）延迟不敏感的工作负载

四、业务需求变化迅速

对于企业业务需求变化迅速，要求能够快速开发实现的场景