| 架构，Technology

Serverless架构研究

概念

Serverless是一种技术架构。按AWS官方对于Serverless的介绍：

1
无服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如AWS Lambda服务），客户端逻辑和服务托管远程过程调用的组合。

该技术的意义是：站在开发者的角度，自己不再关心IaaS层的基础设施的购买、运维、配置，也不关心自己应用的配置、部署、高可用这些PaaS层的东西，而是专注于实现业务逻辑的核心代码，其他的东西全部借助于公有云提供的服务实现。这种架构里，开发者自己并不接触Server，所以有了Serverless这个词。该模式下，开发者的效率是最高的，基本是100%的核心业务+0的业务支撑，而传统的IaaS架构里，我们在用20%的时间开发核心业务 + 80%的时间提供周边业务支撑。

Serverless的技术最早来自于AWS在2014年推出的Lambda服务，该服务目前支持Javascript, Python和JVM系语言(Java、Clojure、Scala等)。

技术原理

Serverless架构里使用到了两种技术：

  • BaaS：Backend as a Service，如AWS RDS。BaaS可以认为是PaaS中提供纯服务的那部分Service。
  • FaaS：Function as a Service，如AWS Lambda。

FaaS中的Function就是我们需要100%专注的核心业务。Function又是由事件Event驱动的，再结合上公有云提供的BaaS的服务，我们就能实现出一套完整的业务架构。

1616678072228

FaaS(函数即服务) 的核心是

  • 核心业务代码Function，FaaS包含了运行核心代码的一切必要条件。
  • Function通过Event得到触发，Event由FaaS框架定义。
  • Function生命周期短，随时创建，运行完就销毁。如AWS的Lambda最长运行时间是5分钟。
  • Function代码必须做到完全无状态。
  • FaaS负责水平扩展问题。

此处列举了部分常见的函数触发事件：

​ 1.HTTP触发器。

​ 2.日志服务触发器。

​ 3.定时触发器。

​ 4.CDN事件触发器。

​ 5.对象存储触发器。

​ 6.MNS主体触发器。

​ 7.API网关触发器。

​ 8.消息队列Kafka版Connector触发器

​ 不同的云服务厂商提供的触发事件上存在细微差别。

​ 函数计算是事件驱动的全托管计算服务。使用函数计算，你无需采购与管理服务器等基础设施，只需要编写并上传代码。函数计算为你准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。

​ 函数计算工作流程如下图所示（以阿里云为例）：

函数计算流程

  1. 开发者使用编程语言编写应用和服务。函数计算支持的开发语言请参见开发语言列表。
  2. 开发者上传应用到函数计算。上传途径包括：
    • （推荐）通过函数计算控制台上传。
    • （推荐）通过命令行工具Funcraft上传更多信息，请参见Funcraft。
    • 通过API或SDK上传。更多信息，请参见SDK列表。
    • 通过命令行工具fcli上传。更多信息，请参见通用操作。
  3. 通过第三方服务商提供的一些事件触发函数执行。触发方式包括OSS、API网关、日志服务、表格存储以及函数计算API、SDK等 。

​ 4. 动态扩容以响应请求，请求量激增时Serverless架构可以实现自动毫秒级扩容，该过程对您和您的用户均透明无感知。

  1. 根据函数的实际执行时间按量计费。函数执行结束后，可以通过账单来查看执行费用，收费粒度精确到1毫秒。更多信息，请参见实例规格及使用模式。

​ 最初“无服务器”意在帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作。Serverless 并不意味着没有服务器，而是指由第三方供应商负责后端基础结构的维护，以服务的方式为开发者提供所需功能，例如数据库、消息，以及身份验证等。

Serverless的优点

  • 让开发者只专注于自己的核心业务，极大提升开发效率，直接推动了一种NoOps的团队模式的发展。
  • 每个Function在独立的进程中运行，且完全无状态，FaaS自动负责水平扩展。
  • 大量节省成本，减少交付周期，我们只为Function运行时间付费。
  • 安全性有更高的保证，数据安全和运行时安全以及异常响应不需用户实现，云服务可解决此类问题。

Serverless劣势/局限

  • 受到Event触发事，FaaS才创建出新进程来服务，这里有启动时延，不适合频繁调用的任务。
  • Serverless架构无法用于极高并发环境，该环境下进程的创建和销毁代价太高。
  • Function运行时间受限，且无法常驻内存。
  • Function完全无状态，需要借助外部服务才能实现状态共享，提升架构复杂度， 多函数维护和管理是问题。
  • 极大依赖厂商的BaaS服务，且各厂商的BaaS服务接口不同，导致迁移困难。
  • 缺乏工具，集成测试困难，调试困难，监控困难。

Serverless架构原则

  • Serverless架构是SOA概念的自然延伸，按照特性的需求编写特定的函数。
  • 编写单一用途的无状态函数，让测试更加容易，让后期灵活编排成复杂服务更加容易。
  • 最灵活、最强大的无服务器设计是事件驱动型的，在合适的情况下，构建事件驱动的、基于推送的系统常常有利于降低成本和系统复杂性。
  • 创建更强大的前端。数据签名的令牌让前端可以与不同的服务直接通信，从而让函数的执行尽可能快，可以提升性能，降低成本。
  • 尽量使用第三方BaaS服务减少核心代码的复杂度。

应用场景

由上述的优势和劣势，可见Serverless适用于“简单应用后端架构”，而不适用于“大型复杂应用后端架构”。在一个大型应用架构中，我们可以将其中无状态，事件触发的业务拆成Serverless架构，让他成为复杂应用架构的一种有效补充。

市场格局

其他项目

Serverless发展

​ 从现状来看，2014年AWS推出lambda到现今，已过去6年，Serverless相关技术与工具发展迅速，尽管Serverless目前仍存在一些缺点还没有得到较好的解决，但考虑到Serverless的巨大优点，越来越多的用户考虑使用Serverless服务。

​ 2019 年 12 月咨询公司 O’Reill发布 Serverless 使用调研中，已有 40% 的受访者所在的组织采用了 Serverless。2020 年 10 月，中国信息通信研究院发布的《中国云原生用户调研报告》指出：“Serverless 技术显著升温，近 30%的用户已在生产环境中应用。”

​ 2019 年下半年，阿里云函数计算宣布推出 2.0，支持预留模式，全面解决冷启动延迟大的问题；推出单实例多请求问题，较少实例支持重 IO 高并发类型请求调用；支持自定义运行时，支持一键迁移传统 Web 架构服务器。2.0 的出现让函数计算在业务和规模上实现了巨大升级。

​ 在经历了过去的线下场景考验后，世纪联华将各渠道商的业务及旗下的“联华鲸选 APP”，以及线上交易、定时抢优惠券、秒杀业务也全部从 ECS 迁移到了函数计算 2.0，在开启预留模式调整好单实例多并发的模式后，面对平时数十倍的流量请求也能轻松应对。

​ 世纪联华

​ 比较上述的“时间-流量图”及“时间-延迟”两图可以看到，急剧上升的突发流量对用户造成的延迟变化影响非常小，从用户的反馈来说，基本感受不到较为明显的延迟，使用Serverless，减轻的不只是研发人员的心理压力，还有工作量。

​ 相信随着越来越多的使用Serverless服务成功案例的诞生，更多的开发者与用户将会关Serverless, Serverless相关技术发展以及使用率都将迎来巨大的提升。

参考资料

1
2
3
4
5
           +--------+            +--------+        +--------+
  Request  |        |   Event    |        |        |        |
---------->|  BaaS  |----------->|Function|------->|  BaaS  |
           |        |            |        |        |        |
           +--------+            +--------+        +--------+