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

在这个例子里面，解决方案很简单，只需要重新考虑控制流程。因此上图的函数构造可以转换为如下图所示的结构：
从图里面可以看出，现在存在三个执行一般任务的 function ，每个 function 都是由流程中的前一个 function 触发。除了 Serverless 之外，在任何平台上面拥有三个单独的 function 都可能会被认为是效率低下的。但是，必须记住的是，在 Serverless 的场景下，成本取决于执行的时长，而不是 CPU 的资源。因此如果改用 EC2 实例来安排这个任务，可能跟上图的结构就会大大不同。
因此可以看出来，异步按照正确的方式来处理时会带来极大的好处。它可以减少执行的时长，同时在必要的地方支持并行化。不过，如果不加考虑，异步不仅会损害系统的需求，而且还会损害 Serverless 的整个收益模型。
共享不是收养使用 Serverless 进行构建的目标是，用独立的且高度分离的 function ，来拆解业务逻辑。不过说起来容易做起来难。而且开发人员经常会遇到必须在 function 之间共享某些库或者业务逻辑，又或者只是一些基础代码的场景。从而导致了某种程度的依赖和耦合关系，违背了 Serverless 架构的初衷。
不同的 function 之间依赖于一些共享的代码和逻辑，会带来一系列的问题。最突出的问题就是影响到了伸缩性。随着系统规模和功能之间不断地相互依赖，错误、停机和延迟的风险成倍增加。微服务诞生的出发点就是要避免这些问题的。此外， Serverless 的一大卖点也是它的可扩展性。通过共享逻辑和代码库将功能耦合在一起的系统不仅不利于微服务，而且不利于 Serverless 可伸缩性的核心价值。
下图描述了这个场景，因为 function A 中数据逻辑的变更，导致 function B 中，数据通信和处理方式也要发生必要的改变。根据实际的使用情况， function C 也可能会受到影响。
解决方案
在研究解决方案之前，必须要承认的是，在某些场景下可能没有解决方案，不得不共享代码逻辑或者代码库。此类问题出现在机器学习的应用程序中，其中大型库必须在用于处理测试、验证以及训练数据的各种 function 之间共享。在这个过程中需要使用相同的模型，在训练的数据集上进行验证和强化。
在大多数情况下，共享代码库和逻辑需求不仅是一种反模式，而且也同样是 Serverless function 的一种技术限制。例如， AWS 的 Lambda function 在 /tmp 目录下存储上的限制是 512MB 。这意味着，开发人员在构建他们 AWS Lambda function 代码的时候，必须要意识到这件事情并且合理运用。毕竟， /tmp 目录主要用于临时存储，因此，一旦 serverless 节点被移除， /tmp 目录下的内容也会不复存在。
AWS 最近通过发布备受期待的 Amazon EFS 和 AWS Lambda 集成解决了这个问题。这种新的集成方式允许 function 通过集成 Amazon EFS 实例的方式，访问共享的类库或者数据。然而，这不能成为 function 之间相互依赖合理性的一种依据。目前可以实现某些事情并不意味着它是上述反模式陷阱的最佳解决方案。
因此，这个解决方案目前只是一个最基本而且有效的解决方案，是一个需要不断构建架构意识的起点。耦合和相互依赖性并不是因为引入 serverless 而带来的新问题。业界各个团队已经提出并实施了很多提高感知度的解决方案。