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

例如，目前最流行的解决方案之一是 DRY（Don't Repeat Yourself），这个概念在 1999 年，是由 Andrew Hunt 和 David Thomas 在他们的图书《实用程序员》一书中首次提出。取代 DRY 的方式是 WET（Write Everything Twice）。
总体来说，将 function 之间紧紧的耦合在一起，会让微服务和 serverless 带来的收益归零。了解如何构建云架构模式是可以有效避免这种问题的唯一方案。将业务场景拆分成单独的 function，在概念上可能并不那么容易，不过这仍是必须进行的一项活动，而且还需要谨慎行事。
到底多小才算特别小【忆梦|Serverless的4种错误打开方式】将大型紧凑的业务案例拆分成较小、单独的 function 概念这件事，最终证明，有很大概率会到一种有害的粒度级别。拆解单体系统无疑是有好处的，不过也要注意一些开销的问题，否则最终会出现间接费用超过带来收益的情况，所以必须找到这个平衡点。
可以预见的最大开销之一就是这些实例直接通信的开销需求。这个是可以想象到的，因为 serverless 之间是事件驱动的。因此，就像单体大型系统具备的流量控制那样，需要确保事件可以在架构的不同组件之间流动。
在各个 function 之间交流事件的需求，会让人直接想到 Webhook 和 API 。这会无形中增加工作量、安全风险和等待的时间。随着 function 的数量不断增加，这个问题会几何倍数的增大。
Serverless 的主要目标是将复杂的基础架构抽象化，从而让人们把更多的关注重点放在业务逻辑上面。但是很明显的是，随着业务逻辑被拆分成各个 function ，慢慢达到了平衡点，额外开销也开始逐渐超过了拆分带来的收益。因此这种情况可以被列为一种反模式。
解决方案
云供应商已充分认识到使用无服务器 function 的开销。例如， AWS 发布了 serverless event bus 服务—— AWS EventBridge 。该服务减轻了与 function 之间传递事件有关的问题，甚至允许第三方工具将事件发送到 AWS 架构。但是，这不能完全解决问题。
想要找到解决方案，需要先知道什么场景会出现这种问题。使用 serverless 的 function 来提高开发便捷性这件事已经是众所皆知了。构建 function 相对来说非常容易，因此开发人员更倾向于不断创建新的 function，导致了过度设计。
因此解决方案应该从开发过程开始的时候，就开始对架构设计进行思考，并且深入理解业务逻辑。这可以先分析客户预期如何使用应用程序，根据其使用的场景来考虑性能问题以及用例，从而实现需求。
主要的目标还是了解用户期望采用的流程，以及在哪个区域的应用程序期望承受更高的负载。因此，对这些要求更为清晰的了解将有助于确定实际所需要的 function 以及它们的作用域。当务之急是与产品经理或其他人一起，制定出业务的目标和流程。
递归可不是朋友递归是计算机科学中不可或缺的一个概念，它会降低计算机计算时的复杂性，相关的文献中广泛使用的“大 O 表示法”就是递归的典型应用。不过在 serverless 中，递归可能产生无法预期的影响。特别是它的伸缩性会极大地加剧这种影响，应该抵制使用递归，尤其是在递归算法导致无限递归的场景。
在对容器或其他以 CPU 为中心的实例进行编程时，核心问题在于，由于递归会增加处理能力，从而使 CPU 利用率达到最大化。一个个 function 会不断地自我触发，这可能导致在各个线程中触发的 function 数量呈指数增长。