忆梦|Serverless的4种错误打开方式( 四 )


在 Serverless 的场景下 , 实例的 CPU 利用率达到最大并不是问题 , 因为它可以自动伸缩 。 从理论上讲 , 可以增加无限数量的工作节点 , 甚至可以满足最严格的递归算法的需求 。 但是 , 从成本的角度出发 , 递归会导致 DoW(Denial on Wallet) 的攻击 。
时刻需要记住 , 在 Serverless 的场景下 , 计费里面不止包含计算能力 , 还包括调用和运行时间 。 结果就是递归导致你云供应商收费激增 。 选择 Serverless 模式是为了节约成本 , 而这种使用方式却抵消了这种优势 , 你以为费用下降了 , 但实际却恰恰相反 。
解决方案
显而易见的解决方案是在构建无服务器应用程序时注意代码库中的递归算法 。 但是 , 可能有些应用程序仍需要递归操作 。 例如 , 在机器学习的应用中 , 重复训练模型直到在训练数据或验证数据上达到一定有意义的精度 。 但是 , 问题是可以提供多少次递归?
就像前面说的 , 递归函数最大的威胁点是无限递归的可能性 。 不过在大多数情况下 , 这是一种意料之外的结果 , 程序理论上不需要特殊处理无限递归 。 因此如果需要使用到递归 , 请确保进行严格的测试 , 尽可能完全避免这种问题 。
此外 , 您也可以在自己的 function 之间传递数据 , 以保持一个递归计数 , 并设置一个失效保护的开关 , 以便当递归计数达到一定的数量时停止正在运行的 function 。 这将使系统知道递归发生的次数 , 并允许可配置的限制随着时间的推移而变化 , 同时考虑到无服务器应用程序的成本和其他因素 。 这样你的系统就知道递归实际发生的次数 , 并允许配置一个限制 , 可以随着时间的变化而变化 , 同时牢记成本和无服务器应用程序的其他因素 。
结论无服务器无疑正在彻底改变应用程序在云服务上面的构建方式 。 但是 , 随着这种新模型和体系结构的出现 , 它具有了自己独特的反模式 。
如果不小心谨慎的话 , 这些反模式很容易浮现 , 抹去选择无服务器架构获得的所有好处 。 实际上 , 根据问题的严重性 , 无服务器架构可能对业务应用程序有害无益 。
但是 , 该技术的优势极大地促进了其应用 。 因此多年来 , 云社区已经看到了很高的采用率 。 我们有必要积极了解如何在无服务器场景下构建软件 , 同时注意避免反模式 。 俗话说 , 强大的力量伴随着巨大的责任!
原文链接
关注我并转发此篇文章 , 私信我“领取资料” , 即可免费获得InfoQ价值4999元迷你书!