Serverless概述

概念

  我们把 Serverless 拆解为 server 和 less 两个单词，从字面上推断词意即为“少服务器的，亦或是无服务器的”。当然这并非指应用架构中是没有服务器资源的，而是通过 Serverless 这种服务形态，用户在使用对应的服务时，不需要关心或较少关心服务器的硬件资源、软件资源、稳定性等等，这些通常已经由云计算厂商提供设施、服务和 SLA 保障，完全托管给云计算厂商。而用户只需要专注自己应用代码本身，上传执行函数到相应云计算平台，按照函数运行的时长按量付费即可。

演进

  云计算诞生之前，大部分计算资源是处于“裸金属”状态的物理机，运维人员选择对应规格的硬件，建设机房的 IDC 网络，完成服务的提供，投入硬件基础建设和维护的成本很高。
  云计算诞生后，用户可以直接购买云主机（VM），把基础物理硬件和网络的管理都交由供应商管理，多用户租用一台物理机，但每台云主机对用户来说就像是单独的一台物理机，用户之间相互隔离。这种模式减少了用户硬件管理成本，站在平台的角度，我们通常称之为 IaaS（Infrastructure-as-a-Service）。
  随着软件的发展和容器技术的兴起，计算环境由 VM 发展到更小粒度的容器，在容器中可以运行不同的软件服务，PaaS（Platform-as-a-Service） 和 CaaS（Container-as-a-Service） 也开始映入眼帘。用户使用平台基础软件如 Database、消息等开发自己的应用，使用容器镜像构建和部署应用，最后托管给平台。此时基础设施的运维更加下沉，开发者只需关注基础软件和容器。
  继续向前发展，应用的运行演变为更细粒度函数的运行，用户开发特定业务的处理函数，托管给函数平台，按需使用相关的后端服务，通过特定条件的触发完成开发者业务逻辑函数的计算。用户无需为应用持续付费，只需支付函数运行时产生的资源消耗费用，而这，就是 Serverless 服务的模型。

Serverless的历史

【发轫之始】
  2012年云基础设施服务提供商Iron.io的副总裁Ken 提出软件的未来 ，首次提出来Serverless概念， 以下是原文的一段摘录：

Even with the rise of cloud computing, the world still revolves around servers. 
That won’t last, though. Cloud apps are moving into a serverless world, and 
that will bring big implications for the creation and distribution of software 
and applications.

【初出茅庐】
  AWS的Lambda产品发布，Serverless正式走上云计算的舞台

【崭露头角】
  众多laaS和Paas厂商相继入场

【未来已来】
  随着容器技术，IoT，5G，区块链等技术的快速发展， 技术上对去中心化，轻量虚拟化，细粒度计算等技术需求愈发强烈，而Serverless必将借势迅速发展。

业界产品

• iron.io
• AWS Lambda
• Google Cloud Functions
• Azure Functions
• IBM OpenWhisk
• 阿里云函数计算

架构

  如上文的描述，Serverless 架构由两部分组成，即 Faas 和 BaaS。

Faas

  FaaS（Function-as-a-Service）即为函数运行平台，用户无需搭建庞大的服务系统，只需要上传自己的逻辑函数如一些定时任务、数据处理任务等到云函数平台，配置执行条件触发器、路由等等，完成基础函数的注册。

BaaS

  BaaS（Backend-as-a-Service）包含了后端服务组件，它是基于 API 的第三方服务，用于实现应用程序中的核心功能，包含常用的数据库、对象存储、消息队列、日志服务等等。

Baas和Paas的区别

  PaaS需要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的。其次从功能上讲，BaaS可以看作PaaS的一个子集，即提供第三方依赖组件的部分。
  BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来，再做成外部服务，而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理，开发团队再也不用自己编写或者管理实现这些功能的代码。

Serverless工作机制

  Serverless 其实是通过事件驱动的，当一个任务被触发时，比如 HTTP 请求，API Gateway 接受请求、解析和认证，传递对应参数给云函数平台，平台中执行对应回调函数，配合 DB、MQ 等 BaaS 服务在特定容器中完成计算，最终将结果返回给用户。函数执行完成后，一般会被 FaaS 平台销毁，释放对应容器，等待下一个函数运行。

优缺点

  讲完 Serverless 的基本架构，我们来谈谈它的优点和缺点。

  根据 Serverless 的特性，我们可以总结出以下优点：

  同样，Serverless 是一把双刃剑，它也有一些缺陷需要我们了解，以便取长补短：

• 云厂商强绑定 当你决定使用公有云的 Serverless产品时，它们常常会和厂商的其他云产品相绑定，如对象存储、消息等等，这意味你需要同时开通其他的服务，将导致你的应用与平台强绑定，迁移成本剧增。

• 不适合长时间任务 云函数平台会限制函数执行时间，如阿里云 Function Compute 最大执行时长为 10
  min，如果你的任务时间超长，那么你需要拆分编排你的函数执行流程，并在一个函数执行结束时唤起另一个函数执行。这将增加编码的复杂度，而且花费上可能高于购买一个长时间运行的实例。

• 冷启动时间 函数运行时，执行容器和环境需要一个准备的时间，尤其是第一次启动时时间可能会较长。对一个 HTTP请求来讲，可能会带来响应时延的增加，产生性能毛刺。

• 调试与测试 由于本地环境和平台运行环境的差异性，开发者需要不断调整代码，打印日志，并提交到函数平台运行测试，会带来一些开发成本和产生一些费用。

应用场景

  结合以上的优缺点，实践中我们可以发掘 Serverless 的落地场景，目前阶段 Serverless 主要适合以下的应用场景：

• 定时任务 通过时间触发对应的函数任务，完成开发者业务逻辑的处理。

• 数据加工 通过事件驱动件机制，在特定的条件下触发，对系统的日志进行整合，或者对多媒体文件进行加工等等。

• 低频请求 用户可以按照频次付费，而无需构建一个应用来应对这些必要的但是量小的请求。

• IoT 物联网场景下，大部分是用户对设备的操控，用户对时延的容忍度较高，也是典型的事件触发且低频场景。

• 认知计算 适用于某些 AI 场景，如聊天机器人。

结语

  目前，国内 Serverless 的发展还处于早期阶段，一些配套和服务处于待完善阶段，而且大型成功案例较少。但这并不妨碍我们对技术革新的热衷，站在前端工程师的角度看，Serverless 的持续发展，在将来可以使前端更加容易的使用 Node.js 等语言搭建一个完善的应用，只需关注前后端的业务逻辑本身，而较少关心底层庞大的软硬件系统和运维知识。未来也可能给前后端工作流程带来一定变革，比如更统一的技术栈、设计规范和数据结构；更高的开发效率——应用搭建、联调时间的缩短，促使 Web 前端工程师向 Web 应用工程师进化转型。
参考文章：
https://www.zoo.team/article/serverless
https://www.jianshu.com/p/85d8bcd6ad81
https://blog.csdn.net/cc18868876837/article/details/90672971