忆梦|Serverless的4种错误打开方式自2014年AWS发布Lambda以来

自 2014 年 AWS 发布 Lambda 以来， Serverless 技术的采用率逐年上升。这是因为 Serverless 提供了云服务开发人员无法抗拒的产品，其主要优势如下：

将服务器管理的工作抽象给了供应商
随用随付模式，您只需要为你使用的量来付费
可自动扩展并且高可用

这些好处是通过这种技术具备的一些特性来实现的。 Serverless 的应用程序是无状态的分布式系统，可以根据需求进行扩展，提供的是基于事件的异步开发模式。正是因为这些特性，这种技术才为云环境提供了理想的解决方案。
不过，它是否真的像期望的那样理想吗？
经过进一步的调查可以发现，毫无疑问，在 Serverless 的应用过程中，很多开发者也陷入了该模式的一种反模式里面，特别是那些高度利用 Serverless 的场景。随着越来越多的行业从中获得好处，我们必须要清醒地认识到哪些东西是有效的，哪些是无效的。毫无疑问， Serverless 是有效的，不过错误的使用方式也会让它引发很多问题，使行业远离此项技术。
因此，本文的主要目的是揭示那些困扰 Serverless 体系架构的反模式以及如何规避他们，从而推动 Serverless 应用的成功，提升其采用率。
异步特性中的瑕疵在异步的场景中， Serverless 应用程序往往最合适。埃里克·约翰逊（Eric Johnson）在伊斯坦布尔 ServerlessDays 演讲中提出了一个概念，即“Serverless 的异步思考方式” 。之后，他去了 ServerlessDays Nashville 上发表了更长的演讲版本。
不过，受到追捧的异步特性也是其最大的反模式。在理解这句话之前，你需要记住， Serverless 是即付即用的模式。因此当一个 function（译者注：Serverless 中，每个函数被称为 function ，下同。）或者一个服务在等待另一个异步调用的 function 或者服务返回响应结果时，第一个 function 是处在空闲状态的。只需要等待第二个 function 的响应即可。
这是从单体架构转换到无服务架构过程中，不关注细节导致的结果。例如，在一个单体的系统中，一个方法可能需要执行读写 DynamoDB 的操作。然而，为了避免等待此项操作而阻塞整个控制流，可以使用异步的方式进行调用。允许该方法继续调用另一个方法执行其他任务，只是在方法的最后等待 DynamoDB 的响应结果。第二个方法可能是按照自己的方式开始操作 S3 。
当上面的逻辑迁移到 Serverless 上面时，不能用相同的方式处理。因为每个方法会映射到每个单独的 Serverless 的 function 上面，但是你需要记住的是，每个 function 都有可能会超时，又或者只完成了他们剩余的任务，之后变成空闲状态等待回调。
结果就是这个处在空闲状态的 function 也会被收费，因为在技术层面上它是活跃状态的。尽管 function 只是在等待，仍有一个 worker 节点使用所有必需的基础架构为该 function 提供服务。
当很多 function 连接在一起的时候，这个问题会更加严重。在流程中，一个 function 对另一个 function 进行异步调用，等待响应，而第二个 function 对另一个 function 进行调用，又或者在对存储服务进行读写操作。

这大大增加了出现不可靠情况的概率，因为第一个 function 有可能会超时。当函数调用的是云服务供应商之外的存储设备或者本地存储服务时，这个情况有可能会更糟糕。
解决方案
解决方案并不是放弃异步的模式，因为问题的关键点不在于异步调用，而是在于合并此类调用的方式。例如，在分解单体系统时，通常存在控制器的 function ，这只会增加不必要的开销，而且还会增大超时带来的 function 不可靠的概率。