无服务器并不意味着DevOpsLess或NoOps

编译丨千山

51CTO读者成长计划社群招募，咨询小助手（微信号：TTalkxiaozhuli）

3月底，在云界有一件盛事发生。

亚马逊云科技于3月30日举办亚马逊云科技创新大会。据会议信息显示，这届大会的高主题是“全面拥抱Serverless时代”。

有心的朋友应该注意到了，从去年到今年，无论是此前的AWS re:Invent大会还是阿里云云栖大会，抑或是即将召开的这个会议，Serverless都是当仁不让的主角。

不管是AWS还是阿里云，都在坚定推进核心产品全面Serverless化。中美两大云巨头同时押Serverless，无疑是在向全行业传递出这样的信号：Serverless 是云计算的未来。

那么Serverless真有这么香吗？

“无服务器（Serverless）”这个概念最早出现在2012年，但真正为人熟知却始于——2014年Amazon Lambda服务推出时，时至今日，这一理念已经成为业内热词。

所谓“无服务器”，并不是指真的无需服务器，其指代的更多是一种云应用程序开发和执行模型。允许开发人员构建和运行代码，而无需管理服务器，也无需为闲置的云基础架构付费。

当选择无服务器和Lambda来搭建云架构时，你需要了解固有的限制，以便在应用程序和代码的规模以及复杂性开始增长时进行扩展。

在构建应用程序代码时，无服务器是快速升级的一个好选择，但有一个常见的误解，即无服务器意味着DevOpsLess或NoOps，而事实并非如此。

更重要的是，有时你必须提前在设计和架构上进行投资，以避免后来遇到瓶颈或招致大量技术债务。

一、无服务器问题的快速概述

当应用程序开始增长时，如果你不提前计划，很快就会遇到无服务器范式特有的挑战。很多人在开始尝试无服务器时很可能意识不到，为什么他们需要提前设计。

1.问题一：节流

Lambda节流是可以同时运行的实例数量的结果。

AWS Lambda默认一个账户的区域并发限制为1000，也就是可以同时处理1000个请求。一旦到达上限，新的请求会被节流。当然你可以请求提高此阈值，不过要注意，这会产生成本影响。因此在检查架构设计并确保你确实需要它之前，不应自动提高阈值。

需要直面的现实是，你同时运行的事件或服务越多，你就会越快地遇到瓶颈。如果你计划安全在无服务器架构上运行，那么就有必要在编写第一行代码的时候就考虑到这一点。

即使今天你只需要满足小规模请求的设计，但必须尽早考虑，当你有数千个（甚至更多）租户或客户时，这是否会线性缩放。根据构建资源、Lambda和微服务的方式（以及每个服务的“微”程度），如果将服务分解为太小的块，则最终可能会由于过多并行事件的限制而中断整个服务链流。