初识Serverless

导读

• 回顾架构的演进过程，我们不难发现，研发运维人员正在逐渐地把关注点从机器上移走，不再去管理机器，Serverless 正是在这样的背景下应运而生。
• Serverless 的愿景应该是 Write locally, compile to the cloud，即代码只关心业务逻辑，由工具和云去管理资源。

Serverless 的价值

1. 不用关心服务器 ：任何一台服务器都可能出现故障，如何自动识别故障，摘除有问题的实例，这是 Serverless 平台必须具备的能力；此外，操作系统的安全补丁升级，需要做到不影响业务， 自动完成；日志和监控系统需要默认打通；系统的安全策略需要自动配置好以避免风险；当资源不够时，需要能够自动分配资源并安装相关的代码和配置等。
2. 自动弹性 ：今天的互联网应用都被设计成可伸缩架构，当业务有比较明显的高峰和低谷时，或者业务有临时的容量需求时（比如营销活动），Serverless 平台都能够及时且稳定地实现自动弹性。为了实现这个能力，平台需要有非常强大的资源调度能力，以及对应用各项指标（如 load、并发）非常敏锐的感知能力。
3. 按实际资源使用计费 ：用户是按实际使用的资源付费的，例如一个请求实际使用了一台 1core2g 规格资源 100ms 的时间，那么用户就只需要为该规格的单价乘以时间（即100ms）付费。类似的，用户如果用的是 Serverless 数据库， 那么就只需要为 query 实际消耗的资源，以及数据存储的资源付费。
4. 更少的代码，更快的交付速度 ：基于 Serverless 架构的代码通常会重度使用后端的服务，将数据、状态管理等内容从代码中分离出去；此外，更彻底的 FaaS 架构则把代码的 Runtime 也交给了平台管理。 这就意味着，同样的应用，Serverless 模式下的代码相比 Serverful 模式会少很多，因此不论是从分发还是启动，都会更快。Serverless 平台也通常能够提供非常成熟的代码构建发布、版本切换等特性，提升交付速度。

什么是 Serverless 架构？

按照 CNCF 对 Serverless 计算的定义，Serverless 架构应该是采用 FaaS（函数即服务）和 BaaS（后端服务）服务来解决问题的一种设计。Serverless 有一个根本的理念是一直没有改变的，即让用户最大化地专注业务逻辑，其它的特征如不关心服务器、自动弹性、 按使用计费等，都是为了实现这个理念而服务。

场景示例：

1.静态WEB信息展示站点 （展示信息、更新频率少、不确定访问量）

优点：

• 可运维性：无需管理服务器，比如操作系统的安全补丁升级、故障升级、高可用性，这些云服务（OSS，CDN）都帮着做了
• 可扩展性：无需对资源做预估和考虑未来的扩展，因为 OSS 本身是弹性的，使用 CDN 使得系统延迟更小、费用更低、可用性更高
• 成本：按实际使用的资源付费，包括存储费用和请求费用，没有请求时不收取请求费用；
• 安全性：这样一个系统甚至看不到服务器，不需要通过 SSH 登录，DDoS 攻击也交给云服务来解决。

2.单体和微服务应用（电商APP）

如何让手机客户端和不同浏览器都能受益于 Serverless 架构呢？这又牵扯出了 另一个词——Backend for fronted（BFF），即为前端定做的后端，这受到了前端开发工程师的推崇，Serverless 技术让这个架构广泛流行，因为前端工程师可以从业务角度出发直接编写 BFF，而无需管理服务器相关的令前端工程师更加头疼的事情。

3.事件触发型：买家秀（发表图片和视频评论，对上传的图片和视频进行压缩、水印、审核等）

• Serverless 让生产者发送事件，维护连接枢纽都从用户职责中省略了，而只需关注消费者的逻辑，这就是 Serverless 的价值所在。
• 函数计算服务还集成其它云服务事件源，让你更方便地在业务中使用一些常见的模式， 如 Pub/Sub、事件流模式、Event Sourcing 模式

4.服务编排 ：订单流程（多步骤流程，可能持续很长时间，需要失败重试、回滚）
这个场景涉及到多个分布式写的问题，这是引入微服务架构导致的最麻烦的一个问题，解决这个问题的一个经典模式是 Saga 模式，而实现这种模式有两种不同架构：

• 采用事件驱动模式，驱动流程完成。（有一个消息总线，感兴趣的服务如库存服务监听事件，监听者可以使用服务器或者函数，这个架构模块是松耦合的，职责清晰。不足之处是随着流程变得更长更加复杂，这个系 统变得难以维护）
  
• 基于工作流的 Saga 模式。（各个服务之间是独立的，是有一个集中的协调者服务来调度单个业务服务，业务逻辑和状态由集中协调者维护。依赖于云服务，比如阿里云的 Serverless 工作流服务，这些事情都可以交给平台来做，用户又回到了只需关注业务逻辑的状态）

5.数据工作流 （随着业务的进一步发展，数据变得越来越多，这时候就可以挖掘数据的价值。比如，分析用户对网站的使用行为并做相应的推荐，一个数据流水线包括数据采集、处理、分析等多 个环节。）

• 日志服务（SLS）提供了数据采集、分析和投递功能；
• 函数计算（FC）可以对日志服务的数据进行实时处理，将结果写入其它服务，如日志服务、OSS；
• Serverless 工作流服务可以定时批量处理数据，通过函数定义灵活的数据处理逻辑， 构建 ETL 作业；
• 数据湖分析（DLA）提供了 Serverless 化的交互式查询服务，它使用标准 SQL 分析对象存储(OSS)、数据库（PostgreSQL / MySQL 等）、NoSQL（TableStore 等）等多个数据源的数据。

以上案例的运用共性：

将业务逻辑中与业务不相关的工作剥离出去，交给平台和服务完成

---

函数计算

函数计算是什么？

在函数计算架构下，开发者只需要编写业务代码并监控业务运行情况。

使用场景

主要为三类：

• Web 应用：可以是各种语言写的，这种可以是使用 Serverless 框架新编写的程序， 也可以是已有的应用。比如可能是小程序后端，也可能是 Web API；
• 对计算能力有很强的弹性诉求的应用：比如 AI 推理、音视频处理、图文转换等；
• 事件驱动型的应用：Web Hook、定时任务等。

函数计算是如何工作的？

函数计算是事件驱动的全托管计算服务。

• 函数计算是事件驱动的无服务器应用，事件驱动是说可以通过事件源自动触发函数执行，比如当有对象上传至 OSS 中时，自动触发函数，对新上传的图片进行处理。函数计算支持丰富的事件源类型，包括日志服务、对象 存储、表格存储、消息服务、API 网关、CDN 等。
• 除了事件触发外，也可以直接通过 API/SDK 直接调用函数。
• 调用可以分为同步调用与异步调用，当请求到达函数计算后，函数计算会为请求分配执行环境，如果是异步调用， 函数计算会将请求事件存入队列中，等待消费。

函数计算执行流程

所以，为了减小冷启动带来的影响，要尽可能避免冷启动，降低冷启动带来的延时。

如果业务场景不适合使用预留实例，那就要设法降低冷启动的延时。Initializer 函数是实例的初始化函数，可以将一些耗时的公共逻辑放到 Initializer 中，比如在 NAS 中加载依赖、建立连接等。

开发流程

函数调试

调试本身就是 Serverless 架构的一大弱点。

云端调试虽然不太符合我们的开发习惯，但是这种调试方法可以 100% 模拟“现场场地”。

---

未完待续。。。 以上均摘自阿里云开发者社区。