开发者需警惕的4大“成本炸弹”：控制不好，小项目也会变成巨坑！

【CSDN 编者按】在云计算和基础设施服务迅速普及的今天，随着用户数激增和需求变化，隐藏成本也可能悄然增加，并最终威胁到项目的财务健康。为此，本文作者通过一些真实案例，揭示了这些“成本爆炸”的潜在陷阱，并提出了有效的成本控制策略，希望避免产品被不可预见的成本拖垮的情况。

原文链接：https://newsletter.fractionalarchitect.io/p/33-be-careful-exploding-costs-that

作者 | MJ    翻译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

基础设施成本可能会出人意料地增加，从而威胁到项目的成功。以下是软件项目中一再导致预算问题的几个常见原因。

所有的软件架构决策都涉及权衡取舍，这一点开发者都理解且熟知，但有一个经常被忽视的重要方面：财务影响。

导致意外成本的因素有很多，包括未能充分防范 DoS 和 DDoS 攻击、在不加分析的情况下进行过多的日志记录、过度使用昂贵的存储层以及对自动扩展功能缺乏限制。

为 DoS 和 DDoS 攻击做好准备

今年大约五、六月份，我在 Reddit 上看到一则帖子，有人描述了他们遇到的问题。简单来说，他的静态网站托管费用高达 10.4 万美元。

你可能会问：“什么？一个静态站点要超过 10 万美元？太离谱了吧。”但确实如此，而账单金额如此之高的原因是该网站遭遇了一次 DoS 攻击。在其托管服务的基础计划中，前 100 GB 流量是免费的，但超过部分每 100GB 收取 55 美元。

对此情况，不同的人有不同看法。有些人认为责任在作者自己，他应该仔细阅读并分析计费信息，因为提供商明确规定超出 100 GB 的部分每 100 GB 收费 55 美元。另一些人则认为，在这种情况下，服务商应该有一些内置机制来防御 DDoS 攻击。我认为两方的观点各有道理，但当前的重点不是追责，而是看看如何避免这种情况的发生。

通常，DoS 和 DDoS 攻击发生在以下三个层之一：应用层（第 7 层）、传输层（第 4 层）和网络层（第 3 层）。所以首先，你可以通过减少潜在的攻击点来降低风险。逻辑很简单——攻击点越少越好。

接下来，可以使用云服务提供商提供的现成解决方案。例如在 Azure 中，就是 Azure Front Door；在 AWS 中，则是 AWS Shield。另一个选择是使用像 Cloudflare 这样的第三方服务。我个人非常喜欢后者，因为它与上述云平台无缝集成，并且价格相对便宜。

代价昂贵的错误：成本爆炸的真实案例

另一个成本激增的案例是 Cara 应用程序。根据 Gergely Orosz 的描述，这款应用程序采用了 Vercel 的无服务器架构，并且运行良好。但问题在于某个时间点，该应用突然爆红，导致运营成本飙升，仅运行几天就产生了 9.8 万美元的高昂费用。

我认为，这对任何希望构建面向公众、可能一夜爆红的应用开发者而言，都是一个很好的教训。但前提是，以下“准备工作”至少要做好一个：

（1）准备足够的资金

• 获得投资支持（确保获得投资（风投、天使投资人或个人资本）

• 准备好应对重大的基础设施成本

• 根据需求动态扩展基础设施

这种方式的优点是，可确保所有用户的服务可用性；而挑战在于需要大量的资金支持。

（2）设定限制的可控扩展

• • 明确基础设施的上限（如 2-3 个服务器实例）

  • 接受高峰时段部分用户可能会遇到服务不可用的情况

  • 向用户透明地说明这些限制

这种方式的优点在于，可控的成本和易于管理的基础设施；而挑战在于高需求时期可能会导致用户不满。

（3）从第一天起就优化成本

• 从应用程序开发之初，就专注于优化应用性能和资源利用

• 目标是大幅降低运营成本（例如降至未优化前的 10%）

• 实施高效的缓存策略

• 选择性价比高的服务提供商和技术

这种方式的优点在于，能在成本和性能之间取得平衡，挑战是初期需要大量的优化工作（但从长远来看收益颇丰）。

存储的隐性成本

在基础设施成本高涨的问题中，数据存储是最常见的问题之一。我见过太多次文件被存储在云服务的热存储层中，而实际上这些文件访问频率极低。

乍一看，云提供商对热存储层每 GB 收费 0.023 美元，似乎很少。对于仅存储几百兆字节的应用程序来说，月成本确实很小——大约只有两美分。然而，当应用程序的存储需求呈指数级增长时，真正的挑战就出现了。

以构建一个社交媒体应用为例，我们来分解一下这个场景：

• 用户基数：1000 万

• 存储容量：每位用户 100 张图片

• 最大图片大小：5MB

计算如下：10,000,000用户 × 100张图片 × 5MB = 5PB = 每月 115,000 美元

是不是很震惊？这说明我们不能被小规模的成本所误导。看起来是几分钱的成本，在大规模运营时可以迅速攀升到六位数。

由日志产生的高昂成本

作为一名软件开发者，我很清楚多数开发者都有一个习惯：喜欢记录一切。我说的一切，真的就是一切！

下面我分享一个例子，来展示这种做法有多昂贵。在一个我参与的项目中，预计的日志成本大约为每月 1 万美元。然而，最后实际账单竟超过了 10 万美元——是预期的十倍！

问题出在哪里？我们发现团队记录了大量根本没人查看或使用的信息。

解决方法既简单又有效：他们减少了不必要的日志，并最终切换到了另一个日志平台。这样，我们仅保留了真正帮助我们监控和修复系统问题的日志。减少开支时，“少即是多”——尤其在云账单方面尤为如此。

以上，就是基础设施成本意外暴涨的可能原因和相应解决方案，你对此有什么看法吗，或者在项目或产品中遇到过类似情况吗？

推荐阅读：

▶BAT、微软、字节等AI专家齐分享，2024全球机器学习技术大会全议题发布！

▶鸿蒙生态崛起，开发者如何抓住这波“红利”？

▶200+ 技术大咖汇聚星城，2024 1024 程序员节圆满落幕！