作者 | 优素福
自 2014 年推出 AWS 以来，该技术的采用率逐年增加。 这是因为它为云服务开发人员提供了一款令人难以抗拒的产品，其主要优势如下：
这些好处是通过该技术的一些特性来实现的。 应用程序是一个无状态的分布式系统，可以根据需求进行扩展，并提供基于事件的异步开发模式。 正是由于这些特性，该技术为云环境提供了理想的解决方案。
然而，事情真的如想象中那么理想吗？
经过进一步调查可以发现，毫无疑问，很多开发者在应用过程中也陷入了这种模式的反模式，尤其是那些利用率较高的场景。 随着越来越多的行业受益，我们必须清醒地认识到什么有效、什么无效。 毫无疑问，它是有效的，但如果使用方式错误，可能会导致许多问题，并且会让业界远离这项技术。
因此，本文的主要目的是揭示困扰该架构的反模式以及如何避免它们，从而推动应用程序的成功并提高其采用率。
1 异步特性的缺陷
在异步场景中，应用程序往往是最合适的。 埃里克·约翰逊（Eric ）在伊斯坦布尔演讲中介绍了“异步思维方式”的概念。 随后，他在推特上发表了较长版本的演讲。
然而，其备受喜爱的异步特性也是其最大的反模式。 在理解这句话之前，你需要记住，它是一种按需付费的模式。 所以当一个（译者注：在，各个函数被调用，下同。）或者一个服务正在等待另一个异步调用或者服务返回响应结果时，第一个就处于空闲状态。 就等第二个的回复吧。
这是单体架构向架构过渡过程中不注重细节的结果。 例如，在单片系统中，方法可能需要执行读取和写入操作。 但是，为了避免阻塞整个控制流等待此操作，可以异步进行调用。 该方法允许继续调用另一个方法来执行其他任务，只是在方法结束时等待响应结果。 第二种方法可能是开始按照您自己的方式操作 S3。
当上面的逻辑迁移到上面的时候，就不能用同样的方式来处理了。 因为每个方法都会映射到每个单独的方法，但您需要记住，每个方法都可能会超时，或者只完成其剩余的任务，然后变得空闲等待回调。
结果是闲置的也会被收取费用，因为它在技术上是活跃的。 尽管只是在等待，但仍然有一个节点提供所有必要的基础设施来提供服务。
当许多连接在一起时，这个问题会更加严重。 在此过程中，一个对另一个进行异步调用，等待响应，而另一个对另一个进行调用，或者读取和写入存储服务。
这大大增加了不可靠情况的可能性，因为第一个情况可能会超时。 当函数调用云服务提供商外部的存储设备或本地存储服务时，这种情况可能会更糟。
解决方案
解决方案并不是放弃异步模型，因为问题的关键不在于异步调用，而在于组合这些调用的方式。 例如，在分解单片系统时，通常会有一个控制器，这不仅增加了不必要的开销，而且还增加了超时导致不可靠的概率。
在这个例子中，解决方案很简单，只需重新思考控制流程即可。 因此，上图中的函数构造可以转化为下图所示的结构：
从图中可以看出，现在有3个通用任务，每个任务都是由流程中的前一个任务触发的。 此外，在任何平台上拥有三个独立的系统可能会被认为效率低下。 但是，必须记住，在这种情况下，成本取决于执行时间，而不是 CPU 资源。 因此，如果使用EC2实例来安排这个任务，上图中的结构可能会有很大的不同。
由此可见，如果采用正确的方式，异步可以带来巨大的好处。 它减少了执行时间，同时在必要时启用并行化。 不过，如果不加以控制，异步不仅会损害系统的要求，还会损害整个收入模型。
2 分享不是采用
构建的目标是用独立且高度解耦的组件来分解业务逻辑。 但这说起来容易做起来难。 开发人员经常遇到这样的场景：必须在他们之间共享某些库或业务逻辑，或者只是一些基本代码。 这就导致了一定程度的依赖和耦合，违背了架构的初衷。
不同的依赖于一些共享的代码和逻辑，这会带来一系列的问题。 最突出的问题是影响可扩展性。 随着系统规模和功能的相互依赖性不断增加，错误、停机和延迟的风险成倍增加。 微服务诞生的出发点就是为了避免这些问题。 另外，其卖点之一也是其可扩展性。 通过共享逻辑和代码库将功能耦合在一起的系统不仅不利于微服务，而且也不利于可扩展性的核心价值。
下图描述了这种场景，因为A中数据逻辑的变化会导致B中数据通信和处理方式发生必要的变化。根据实际使用情况，C也可能受到影响。
解决方案
在研究解决方案之前，必须承认，在某些场景下可能没有解决方案，必须共享代码逻辑或代码库。 此类问题出现在机器学习的应用中，其中大型库必须在不同库之间共享以处理测试、验证和训练数据。 在这个过程中，需要使用相同的模型对训练数据集进行验证和强化。
在大多数情况下，共享代码库和逻辑需求不仅是一种反模式，而且也是一种技术限制。 例如，AWS 对 /tmp 目录中的存储空间限制为 512MB。 这意味着开发人员在构建 AWS 代码时必须意识到这一点并合理使用它。 毕竟/tmp目录主要用于临时存储，所以一旦节点被移除，/tmp目录的内容将不再存在。
AWS 最近通过发布备受期待的 EFS 和 AWS 集成解决了这个问题。 这种新的集成方法允许通过集成 EFS 实例来访问共享类库或数据。 但这并不能成为相互依存合理性的基础。 仅仅因为某些事情目前可以实现并不意味着它是解决上述反模式陷阱的最佳解决方案。
因此，这个方案目前只是最基本、最有效的方案，是一个起点，需要持续构建架构意识。 耦合和相互依赖并不是因为它们的引入而出现的新问题。 行业内的各个团体提出并实施了许多解决方案来提高认识。
例如，当今最流行的解决方案之一是 DRY（Don't），这是 Hunt 和 David 于 1999 年在他们的《实用程序员》一书中首次提出的概念。 替代DRY的方式是WET（Write Twice）。
一般来说，相互紧密耦合会使微服务和效益归零。 了解如何构建云架构模式是有效避免这个问题的唯一方法。 将业务场景分解为单独的场景在概念上可能并不容易，但这仍然是一项必须完成的活动，并且需要仔细完成。
3 多小才算是真正的小
事实证明，将大型、紧凑的业务案例分解为更小的、单独的概念的行为很可能会导致有害的粒度级别。 拆解单个系统无疑是有利的，但是我们也必须注意一些开销问题，否则间接成本最终会超过收益，所以我们必须找到这个平衡点。
可以预见的最大开销之一是这些实例直接通信的开销要求。 这是可以想象的，因为它是事件驱动的。 因此，有必要确保事件可以在架构的不同组件之间流动，就像单体系统具有流控制一样。
每个人之间通信事件的需要使人们直接使用 API。 这无形中会增加工作量、安全风险和等待时间。 随着数量的增加，这个问题将会呈几何级数增加。
主要目标是将复杂的基础设施抽象出来，以便人们可以更加关注业务逻辑。 但很明显，随着业务逻辑被拆分成各个部分，逐渐达到平衡点，额外的开销逐渐超过拆分带来的好处。 所以这种情况可以归类为反模式。
解决方案
云提供商非常清楚使用无服务器的开销。 例如，AWS发布了一个事件总线服务——AWS。 该服务缓解了与在它们之间传递事件相关的问题，甚至允许第三方工具将事件发送到 AWS 基础设施。 然而，这并不能完全解决问题。
如果你想找到解决方案，你需要知道什么场景会导致这个问题。 众所周知，使用可以提高开发的易用性。 它相对容易构建，因此开发人员倾向于不断创建新的，从而导致过度设计。
因此，解决方案应该从开发过程开始就开始思考架构设计，深入理解业务逻辑。 这可以通过首先分析客户期望如何使用应用程序、根据使用场景考虑性能问题和用例来实现。
主要目标还是了解用户期望采用的流程，以及应用程序预计在哪些区域会经历更高的负载。 因此，更清楚地了解这些要求将有助于确定实际需要的内容及其范围。 首先要做的就是与产品经理或其他人一起制定业务的目标和流程。
4 递归不是朋友
递归是计算机科学中不可或缺的概念，它会降低计算机计算的复杂度。 相关文献中广泛使用的“大O表示法”就是递归的典型应用。 然而，在 中，递归可能会产生意想不到的效果。 特别是，它的可扩展性会大大加剧这种影响，应该抵制递归的使用，特别是在递归算法导致无限递归的场景中。
在对容器或其他以 CPU 为中心的实例进行编程时，核心问题是最大化 CPU 利用率，因为递归会增加处理能力。 一一会不断地自行触发，这会导致各个线程中的触发器数量呈指数级增长。
在这种情况下，最大化实例的 CPU 利用率不是问题，因为它会自动扩展。 理论上，可以添加无限数量的工作节点来满足最严格的递归算法。 但从成本角度来看，递归会导致DoW(on)攻击。
请记住，在某些场景下，计费不仅包括计算能力，还包括调用和运行时间。 结果是，递归可能会导致云提供商费用激增。 选择这种模式是为了节省成本，这种使用方式抵消了优势。 你以为成本下降了，但实际上恰恰相反。
解决方案
显而易见的解决方案是在构建无服务器应用程序时注意代码库中的递归算法。 然而，某些应用程序可能仍然需要递归。 例如，在机器学习应用中，模型会被反复训练，直到训练或验证数据达到一定的有意义的准确性。 然而，问题是可以提供多少递归？
正如前面提到的，递归函数的最大威胁是无限递归的可能性。 然而，大多数情况下，这是一个意想不到的结果，程序理论上不需要专门处理无限递归。 因此，如果您需要使用递归，请务必对其进行严格测试，并尽可能完全避免此类问题。
此外，您还可以在两者之间传递数据以保持递归计数，并设置故障安全开关以在递归计数达到一定数量时停止正在运行的数据。 这将使系统知道递归发生了多少次，并允许可配置的限制随时间变化，同时考虑到无服务器应用程序成本和其他因素。 这样，您的系统就知道实际发生了多少次递归，并允许配置随时间变化的限制，同时牢记无服务器应用程序的成本和其他因素。
5 结论
无服务器无疑彻底改变了在云服务之上构建应用程序的方式。 然而，这种新的模型和架构有其独特的反模式。
如果您不小心，这些反模式很容易就会浮现出来，并消除选择无服务器架构的所有好处。 事实上，根据问题的严重程度，无服务器架构对业务应用程序的弊大于利。
然而，该技术的优点极大地促进了其应用。 因此多年来，云社区的采用率很高。 有必要积极了解如何在无服务器场景中构建软件，同时小心避免反模式。 俗话说，能力越大，责任越大！
原文链接
