本文对serverless架构的基础概念,工作原理,应用场景以及具体产品进行详细解析。
serverless:无服务器架构,即在无需管理服务器等底层资源的情况下完成应用的开发和运行,是云原生架构的核心组成部分。
通俗来说,如果将购买一台物理服务器比作 买车 ,购买云服务器就类似于 租车 (租赁期间需要驾驶和维护,且即使闲置也需付费),那么serverless则类似于 出租车 (只需乘坐,按里程计费)。
从技术层面来说,我们可以简单理解为: serverless = FaaS + BaaS 。一个完整的serverless应用一般由FaaS层负责无状态的计算,由BaaS层负责状态的存储:
各个平台对云函数的实现在原理上基本相似,核心都是动态的启动实例去执行函数代码,且完成后实例会保留一定时间窗口。大致的底层架构如下图,其中步骤(1) (2) (3) (4) 为冷启动调用流程,(5) 为非冷启动调用。
用户在控制台(或命令行)提交函数代码到云平台,并进行函数配置。代码一般会被作为静态资源保存(如对象存储),而函数的元信息会被存入数据库中(如MySQL)。
云函数的触发可以分为同步和异步两种情况:
云函数的执行可以分为窗口内首次执行(冷启动)和非首次执行两种情况:
从执行的原理也可看出,云函数理论上是支持无限自动扩容的。
由于serverless按量计费的特点,其实现机制就必须要在函数调用时才去启动运行环境,也就是冷启动问题。虽然保留一定时间可以让后续的请求无需加载,但如果在极短时间内并发大量请求,还是会同时启动多个容器,影响首个请求的响应时间。前面也说到,云函数的特性和机制决定了它的应用场景,对于同时要求高并发、低时延的场景并不是特别适合。
对于冷启动问题,下面以腾讯云的 云函数SCF 为例进行验证。使用Postman的批量测试功能(Collection Runner)对云上部署的一个hello world函数进行串行测试。
从图中可以看出,一段时间内的首次请求耗时会比其他请求的耗时高出一个数量级。
冷启动的优化主要针对同步的请求,首先分析下冷启动耗时的组成,主要是容器的拉起和代码的下载(当然也有资源调度和网络配置等,这里暂不讨论)。
1. 代码缓存 :可以设计多级缓存,比如在宿主机上进行代码包缓存,以及在可用区(AZ)内部进行缓存,这样后续的首次启动就可以快速就近获取,而无需再次从对象存储下载。
2. 容器预创建 :一个优化思路就是预加载,也就是预测将会到来的请求,提前拉起容器实例,从而减少耗时。有以下几种可能的方案:
下面介绍比较适合使用serverless技术的几种场景。
利用云函数可以快速部署一个rest API应用,目前的云厂商基本都支持大部分node,Python和php的web框架,如koa、Express.js、Next.js、Flask、Django、Laravel等等。
这种web架构是前后端分离,即云函数中的后台接口只提供数据,页面的渲染在浏览器进行。可以将前端的代码部署到对象存储中,并使用相关云数据库作为数据存储,这就成为一个完整的云上Full Stack应用。
SSR(Server-Side Rendering):后端渲染,即页面直接在后台进行渲染,浏览器只负责显示。这种比较传统的web架构很适合应用于serverless,只需将整个后端代码部署到云函数即可,好处有:1.利于seo,2.降低系统复杂度,易于部署。
serverless很适合用于流量分布不均的轻量应用,比如一些活动页面,可能一个周期内只有很短的一段时间会有大量访问,且需要长期的维护,此时为这个应用去购买高配置的服务器显然是不划算的。使用serverless之后则可以完全解决这个问题,按量计费降低了成本,既免去了长期运维又不需要担心扩容问题。
云函数本身是无状态的,所以天然适合无状态任务,如果需要状态存储则需要借助BaaS层的组件。云函数的优势是可以与云提供商下的其他服务(比如数据库、缓存、对象存储、CDN、AI、转码等)打通,在函数中使用SDK连接各个组件(但这同样意味着将在云产商绑定的道路上越走越远)。以下是一些适用场景: