如果你从事高流量应用开发，发现数据库账单持续攀升，或是Kubernetes集群消耗的云积分越来越多，却找不到明确原因……

这不是关于花哨的机器学习或是亿级用户规模的故事。

而是关于一个看似普通的架构决策，它悄然无声，几乎不为人知，却能在三年内累计为节省超过千万美元成本。

它很少引人关注，既没有收获奖项，却实实在在地改变了我们的技术生态。

如果你的数据库资源使用量无缘无故地持续上涨，或是发现云服务账单出现异常波动……

这个经历可能会彻底改变你对架构设计的思考方式。

图片

基础设施费用突增的那个月份

那是周五下午，仪表盘突然亮起红色警报——并非因为服务中断，而是当月AWS费用预测比上月激增了38%。

我们既没有运行大规模批处理作业，也没有重要的产品发布，甚至没有新增业务区域，仅仅是流量略有增长。

但不知为何，我们的基础设施成本呈现爆发式增长。

我收到了熟悉的Slack消息：

"是不是有新的自动扩容配置？"

"有人调整了实例规格吗？"

"或许只是CloudWatch统计误差？"

不，全都不是！

我们即将通过艰难的方式，学习关于数据库连接的宝贵一课。

连接泛滥的隐性成本

我们的架构在纸面上看起来"完美无缺"。

我们部署了几十个基于Spring Boot的微服务，每个服务都维护着独立的PostgreSQL连接池。

虽然启用了自动扩缩容功能——当流量上升时，Pod会自动扩容，理论上一切都能弹性扩展。

但问题是……每个新启动的Pod都会创建50-100个新的数据库连接。

而且我们在4个区域同时部署服务。

让我们来算一笔账：

12个微服务 × 每个服务3个副本 × 4个部署区域 × 每个Pod 100个连接

这相当于对同一个数据库集群有超过14,000个潜在并发连接。

而我们的数据库呢？

它正默默承受着巨大的资源压力。

我们的原始架构示意图如下：

┌───────────────────┐ │ Service A │ ┌───────────────────┐ └───────────────┘ │ ┌───────────────────┐ │ Service B │ ┌───────────────────┐ │ ┌───────────────▶ PostgreSQL │ └───────────────────┘ ... │ ┌───────────────────┐ │ Service N │ ┌───────────────────┐ └───────────────────┘ Hundreds of long-lived connections

每个Pod都是成本炸弹

理论上，连接池是高效的资源管理机制。

但实际情况呢？

随着自动扩缩容、滚动部署以及蓝绿发布策略的同时实施——连接数量会急剧增加，即使实际业务流量没有明显变化。

我们当时实际上在承担：未被实际使用的连接占用的数据库内存、需要更多只读副本、更大的实例规格以及更高的网络传输费用。

我们的PostgreSQL集群开始表现出异常症状。

延迟显著上升，垃圾回收活动加剧。

突然间，每个微服务都成了资源消耗的元凶。

但真正的罪魁祸首是我们的架构设计。

改变一切的决策

我们没有选择重写服务代码。

也没有更换数据库系统。

更没有引入Kafka进行"解耦"。

我们只是引入了一个共享连接代理——PgBouncer，以事务池模式运行在Kubernetes集群内部。

现在，每个微服务不再直接与PostgreSQL通信，而是通过PgBouncer进行连接管理。

PgBouncer实现了连接复用，它汇聚了所有微服务的连接请求，为数据库创造了喘息空间。

几乎是一夜之间，我们的成本图表变成了这样：

┌───────────────────┐ │ Service A │ ┌───────────────────┐ └───────────────────┘ │ ┌───────────────────┐ │ Service B │ ┌───────▶ PgBouncer ────────▶ PostgreSQL │ └───────────────────┘ ... │ ┌───────────────────┐ │ Service N │ ┌───────────────────┐ └───────────────────┘ Connection pooling handled outside the app

为什么PgBouncer效果如此显著

它及时终止空闲连接（事务模式意味着查询完成后立即将连接返回给池。）显著减少了活跃连接数量（从约14,000个减少到不足400个稳定连接。）保护PostgreSQL免受连接风暴的冲击（在部署或故障转移期间不会出现峰值。）让服务启动更迅速（不再需要等待完整的连接池或数据库握手过程。）

而所有这些改进，都是在没有触动任何业务逻辑代码的情况下实现的。

我们的部署方案（Spring Boot配置示例）

从服务端来看就是这么简单：

yaml# application.yml (Spring Boot)spring: datasource: url: jdbc:postgresql://pgbouncer-cluster:6432/mydb username: myuser password: ${DB_PASSWORD} hikari: maximum-pool-size: 20 minimum-idle: 5 idle-timeout: 30000 connection-timeout: 20000 max-lifetime: 600000

注意端口号——6432是PgBouncer的默认监听端口。

业务逻辑无需任何改动，只是把JDBC连接字符串指向了PgBouncer代理。

我们的实际收益（基于真实生产环境指标）

我们没有编写复杂的基准测试。

我们在线上观察了真实的生产指标：

数据库内存使用量下降了47% Pod启动时间减少了22% 负载下的数据库CPU使用率从75%降至38% 数据库集群规模减半（从12个节点减少到6个节点） 云账单每月降低了超过30万美元

推算三年累计收益？

累计节省了1080万美元。

没有引入新的技术框架，没有戏剧性的重构，仅仅是一个微小的架构转变。

为什么少有人讨论这个话题

因为它听起来不够"酷炫"。

没有工程师会在LinkedIn上发帖说：

"我们添加了PgBouncer，节省了数百万美元。"

它不是"颠覆性"的创新——但它可能是我们做过的影响最深远的改进之一。

架构设计并非总是关乎技术创新，有时候，它关乎消除那些甚至没人意识到的系统摩擦。

什么时候应该考虑使用？

在以下情况下，你应该考虑使用PgBouncer（或RDS Proxy，或任何连接池代理）：

你运行着10个以上具有自动扩缩容功能的微服务 你的数据库在部署期间显示高内存或CPU使用率 你经常遇到max_connections错误 你为更大型的数据库集群支付额外费用 只是为了避免随机超时 你的服务有时在启动时因为等待数据库连接而挂起

如果你正在经历以上任何一种情况，那可能正在悄无声息地浪费资金，就像我们当初一样。

我们学到的（但没人告诉我们的）经验

1、默认连接池大小存在风险

HikariCP允许设置为100并不意味着你应该这么做。

2、自动扩缩容可能会冲击你的数据库

虽然可以扩展计算资源，但应该集中管理数据库连接。

3、架构才是真正节省成本的地方

不是在代码逻辑里，也不是在缓存策略中，而是在服务间通信的架构设计里。

4、没人会因为解决看不见的问题而获得赞誉

但往往这些看不见的问题，才是代价最高的系统瓶颈。

为什么这个故事对我很重要

我们在代码审查期间没有发现这个问题。

它没有出现在我们的单元测试中。

也没有出现在负载测试里。

也没有出现在CI/CD流水线中。

它出现在我们的财务报表上。

这就是架构变得真实的地方——当它不再是理论，而是开始以百万美元为单位显现时。

最后一点想法

你不需要通过重写整个后端来节省数百万美元。

你只需要审视你正在扩展的是什么——以及它是在帮助你还是在消耗你。

你是否也在为连接数量而非吞吐量付费？

你是否遇到过类似的扩展瓶颈？

你使用了PgBouncer、RDS Proxy还是其他解决方案？

欢迎留下您的见解，让我们共同分享那些虽未获得足够赞誉，却始终在幕后保驾护航的技术故事。

作者丨The Atomic Architect 编译丨Rio

来源丨网址：https://medium.com/@the_atomic_architect/how-one-architecture-decision-quietly-saved-us-10-million-and-nobody-noticed-until-it-was-gone-b4ddf0e0d874