Serverless架构调研

少于 1 分钟阅读

Contact me

或者用邮件交流 jacky.wucheng@foxmail.com

概念

Serverless是一种技术架构。该技术的意义是:站在开发者的角度,自己不再关心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的服务,我们就能实现出一套完整的业务架构。

```
           +--------+        +--------+        +--------+
  Request  |        | Event  |        |        |        |
---------->|  BaaS  |------->|Function|------->|  BaaS  |
           |        |        |        |        |        |
           +--------+        +--------+        +--------+
```

FaaS的核心是

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

优势

  • 让开发者只专注于自己的核心业务,极大提升开发效率,直接推动了一种NoOps的团队模式的发展。
  • 每个Function在独立的进程中运行,且完全无状态,FaaS自动负责水平扩展。
  • 大量节省成本,我们只为Function运行时间付费。

劣势/局限

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

Serverless架构原则

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

应用场景

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

市场格局

其他项目

参考资料