Serverless是指构建和运行不需要服务器管理的应用程序的概念。它描述了一种更细粒度的部署模型，应用程序包含一个或多个函数，代码上传到平台，然后执行，通过响应当前的确切需求进行扩缩和计费。Serverless并不意味着我们不再使用服务器来托管和运行代码，这也并不是意味着不再需要运维工程师。它指的是serverless计算服务的消费者不再需要花费时间来进行服务器配置，维护，更新，扩展和容量规划，所有这些任务和功能都由serverless平台处理，并完全将开发人员从运维业务中剥离出来。因此，开发人员只需要专注于编写应用程序的业务逻辑，而运维工程师能够将业务重点更多的放到关键性业务任务上。
一、初识Serverless
虽然按需或“花多少用多少”模式的概念可追溯到2006年一个名为Zimki的平台，但serverless一词的第一次使用是2012年来自Iron.io的IronWorker产品，一个基于容器的调度平台。
至此，公共云和私有云都出现了更多serverless解决方案，首先是BaaS产品，例如2011年的Parse和2012年的Firebase（分别由Facebook和谷歌收购）。2014年11月，AWS推出Lambda，2016年初在Bluemix上宣布了IBM OpenWhisk on Bluemix（现在是IBM Cloud Functions，其核心开源项目成为Apache OpenWhisk），Google Cloud Functions和Microsoft Azure Functions。华为Function Stage于2017年推出。在此之间，还有许多serverless框架宣布开源。每个框架（公共和私有）都具有独特的语言运行时和服务集，用于处理事件和数据。而在Serverless应用中，根据他们的功能，又可以进一步切分成不同的Serverless函数。
二、Serverless使用场景
虽然serverless计算广泛使用，但它仍然相对较新。通常，当工作负载符合以下情况时，可优选serverless架构方案：
- 异步，并发，易于并行的独立的工作单元
- 偶发的需求，在扩展要求方面存在巨大的偶发性
- 无状态，短暂的应用场景，对冷启动时间没有重大限制
- 在业务需求变更方面具有高度灵活性，需要加快开发迭代的速度
例如，对于常见的基于HTTP的应用程序，在自动扩展和更细粒度的成本模型方面有明显的优势。也就是说，使用serverless平台可能会有以下一些方面的考量。 例如，如果函数的实例数下降到零，则在一段不活动时间后函数启动可能会导致性能业务下降。因此，选择是否采用serverless架构需要考量该计算模型的弊端。
不适合IaaS，PaaS或CaaS解决方案的以非HTTP为中心和无弹性需求的工作负载同样可以利用serverless架构的按需付费。其中一些工作负载包括：
- 以响应数据库更改（insert, update, trigger, delete）的执行逻辑
- 对IoT传感器输入消息（例如MQTT消息）执行分析
- 流处理（分析或修改动态数据）
- 管理单次提取，转换和加载的作业，这些作业需要在短时间内进行大量处理（ETL）
- 通过聊天机器人界面提供认知计算（异步，但有关联）
- 调度执行时间很短的任务，例如cron或批处理样式调用
- 服务于机器学习和AI模型（检索一个或多个数据元素，如表格，NLP或图像，并与预先学习的数据模型匹配，以识别文本，面孔，异常等）
- 持续集成pipeline，按需为构建作业提供资源，而不是保留构建从属主机池等待作业分派
这些场景中的每一个都显示了serverless架构如何解决技术问题，即Iaas，PaaS或CaaS效率低下或无法实现。这些例子是：
- 在没有按需模型的情况下，有效解决了一个全新的问题
- 更有效地解决了传统的云问题（性能，成本）
- 显示“大”的维度，无论是处理的数据大小还是处理的请求
- 通过低错误率的自动缩放（向上和向下）来显示弹性
- 以前所未有的速度（从天到小时）为市场带来了解决方案
数据处理
一个常见的用例，也是最早具体化的用例之一，是响应新文件上传执行一些转换过程的函数。 例如，如果将图像上载到诸如Amazon S3的对象存储服务，则该事件触发函数，用于创建图像的缩略图版本并将其存储回另一个对象存储桶或Database-as-a-Service。 这是一个相当原子化，可并行化的计算任务示例，该计算任务不经常运行并根据需求进行伸缩。
- 使用serverless function构建了一个概念验证，使用光学字符识别来处理移动支票存款。 这种类型的工作量变化很大，发薪日的处理需求 - 每两周一次 -
可能比支付期的大部分空闲时间大几倍。 - 通过将 每个视频帧通过图像识别服务 来自动分类电影，以提取演员，情感和对象; 或处理灾区的无人机镜头以估计损坏的程度。
数据库事件触发
在此场景中，当从数据库插入，修改或删除数据时调用function。在这种情况下，它的功能类似于传统的SQL触发器，几乎就像是与主同步流并行的副作用或动作。其结果是执行一个异步逻辑，可以修改同一个数据库中的某些内容（例如记录到审计表），或者依次调用外部服务（例如发送电子邮件）或更新其他数据库，例如 DB CDC（更改数据捕获）用例的情况。 由于业务需要和处理变更的服务分布的原因，这些用例的频率以及对原子性和一致性的需要可能不同。
- 审核对数据库的更改，或确保它们满足特定质量或分析标准以进行可接受的更改
- 在输入数据时或之后不久自动将数据翻译为其他语言
IoT消息
随着连接到网络的自主设备的爆炸式增加，额外的流量体积庞大，并且使用比HTTP更轻量级的协议。 高效的云服务必须能够快速响应消息并扩展以响应其扩散或突然涌入的消息。Serverless功能可以有效地管理和过滤来自IoT设备的MQTT消息。 它们既可以弹性扩展，也可以屏蔽负载下游的其他服务。
- GreenQ的卫生用例（垃圾互联网），根据垃圾箱的相对饱满度来优化卡车取件路线。
- 在物联网设备（如AWS Greengrass）上使用serverless来收集本地传感器数据，对其进行规范化，与触发器进行比较，并将事件推送到聚合单元/云。
实时流处理
另一种非事务性，非请求/响应类型的工作负载是在可能无限的消息流中处理数据。 函数可以连接到消息源，而消息必须从事件流中读取和处理。 鉴于高性能，高弹性和计算密集型处理工作负载，这对于serverless而言非常重要。 在许多情况下，流处理需要将数据与一组上下文对象（在NoSQL或in-mem DB中）进行比较，或者将数据从流聚合并存储到对象或数据库系统中。
例子包括：
- Mike Roberts有一个很好的 Java/AWS Kinesis 示例 ，可以有效地处理数十亿条消息。
- SnapChat 在Google AppEngine上使用serverless 处理邮件。
批任务
批处理作业或计划任务
每天只需几分钟就能以异步方式进行强大的并行计算，IO或网络访问的作业非常适合serverless。作业可以在以弹性方式运行时有效地消费他们所需的资源，并且在不被使用的当天剩余时间内不会产生资源成本。
- 计划任务可以是每晚运行的备份作业。
- 并行发送许多电子邮件的作业会扩展function实例。
持续集成管道
传统的CI管道包括一个构建从属主机池，它们处于空闲等待以便分派作业。Serverless是一种很好的模式，可以消除对预配置主机的需求并降低成本。构建作业由新代码提交或PR合并触发。 调用function来运行构建和测试用例，仅在所需的时间内执行，并且在未使用时不会产生成本。这降低了成本，并可通过自动扩展来减少瓶颈以满足需求。
业务逻辑
当与管理和协调function一起部署时，在业务流程中执行一系列步骤的微服务工作负载的编排是serverless计算的另一个好用例。执行特定业务逻辑的function（例如订单请求和批准，股票交易处理等）可以与有状态管理器一起安排和协调。来自客户端门户的事件请求可以由这样的协调function提供服务，并传递给适当的serverless function。
例子包括：
交易台，处理股票市场交易并处理客户的交易订单和确认。协调器使用状态图管理交易。初始状态接受来自客户端门户的交易请求，并将请求传递给微服务function以解析请求并验证客户端。随后的状态根据买入或卖出交易指导工作流，验证基金余额，股票代码等，并向客户发送确认。在从客户端接收到确认请求事件时，后续状态调用管理交易执行的function，更新账户，并通知客户完成交易。
聊天机器人
与人类交互不一定需要毫秒级别的响应时间，并且在许多方面，稍微延迟让回复人类的机器人对话感觉更自然。因此，等待从冷启动加载function的初始等待时间可能是可接受的。当添加到Facebook，WhatsApp或Slack等流行的社交网络时，机器人可能还需要具有极高的可扩展性，因此在PaaS或IaaS模型中预先设置一个永远在线的守护程序，以预测突然或高峰需求，可能不会有作为serverless方法的高效或成本效益。
- 支持和销售机器人插入到大型社交媒体服务，如Facebook或其他高流量网站。
- 消息应用程序Wuu使用Google Cloud Functions使用户能够创建和共享在数小时或数秒内消失的内容。
移动后端
使用serverless进行移动后端任务也很有吸引力。它允许开发人员在BaaS API之上构建REST API后端工作负载，因此他们可以花时间优化移动应用程序，而不是扩展后端。 例子包括：优化视频游戏的图形，而不是在游戏成为病毒式打击时投资服务器; 或者对于需要快速迭代以发现产品/市场适合性，或者上市时间至关重要的消费者业务应用程序。另一个示例是批量通知用户或程序其他异步任务以获得离线优先体验。
例子包括：
- 需要少量服务器端逻辑的移动应用程序; 开发人员可以将精力集中在原生代码开发上。
- 使用已配置的安全策略（例如Firebase身份验证/规则或Amazon Cognito）通过事件触发的serverless计算使用直接从移动设备访问BaaS的移动应用程序。
- “Throwaway”或短期使用的移动应用程序，例如大型会议的调度应用程序，在会议前后的周末几乎没有需求，但需要极大的扩展和收缩; 在周一和周二早上的活动过
程中根据时间表查看要求，然后在午夜时分回到主题演讲。
HTTP REST API和Web应用程序
传统的请求/响应工作负载仍然非常适合serverless，无论工作负载是静态网站还是使用JavaScript或Python等编程语言按需生成响应。即使它们可能会为第一个用户带来启动成本，但在其他计算模型中存在这种延迟的先例，例如将JavaServer Page初始编译为servlet，或者启动新的JVM来处理额外的负载。好处是单个REST调用（例如，微服务中的GET，POST，UPDATE和DELETE 4端点中的每一个）可以独立扩展并单独计费，即使它们共享公共数据后端。
例子包括：
- 移植到serverless架构的澳大利亚人口普查显示了开发速度，成本改进和自动扩展。
- “如何通过无服务器将我的AWS账单削减90％。”
- AutoDesk示例：“成本只占传统云方法的一小部分（约1％）。”
- 在线编码/教育（考试，测试等）在事件驱动的环境中运行训练代码，并基于与该训练的结果和预期结果的比较向用户提供反馈。Serverless平台根据需要运行应答
检查并根据需要进行扩展，仅在代码运行的时间内需要付费。
AI应用
算法工程师训练好模型后需要把模型变成服务，Serverless计算无需运维和弹性伸缩的特性，可以助力AI工程师快速构建弹性高可用的AI应用。