架构设计 on Zampo Blog

我用 PostgreSQL 替换了整个技术栈，省了 6 个微服务

Fri, 17 Apr 2026 20:00:00 +0800

现代软件工程已经基本变成了"订阅管理模拟器"。

我们被云厂商洗脑了，以为即使构建一个基础应用，也需要拼凑一个脆弱的分布式网络：

等你终于把应用部署给你那"要求极高"的用户群（你自己和你妈）时，你已经欠了十几家 Y Combinator 支持的 SaaS 初创公司的钱，就为了让灯亮着。

这是一个过度工程化、价格离谱的陷阱。

但如果我告诉你，你可以把那些闪亮的云依赖全部扔进焚化炉，用一个经过 30 年验证的开源软件替换它们呢？

科技行业不想让你知道的秘密：一个久经考验的工具可以吞噬你的整个架构。

我刚刚用 PostgreSQL 替换了整个技术栈。

PostgreSQL 是一个开源对象关系数据库系统，已经活跃开发了 30 多年。

开箱即用的能力：

PostgreSQL 不只是行列存储。

它还能存储：

PostgreSQL 不是数据库，是一个数据平台。

应用 → Redis（缓存） → PostgreSQL（持久化）

问题：

使用 UNLOGGED 表做高速缓存：

Tue, 07 Apr 2026 12:16:00 +0800

这是世界上最先进的开源关系型数据库。

PostgreSQL 的能力早已超越了传统关系型数据库的范围。现代开发中，为了解决各种问题，各类花哨的工具层出不穷——缓存用 Redis、全文检索用 Elasticsearch、文档存储用 MongoDB、向量数据库用专门的方案、定时任务跑在 K8s 上。

但有时候，仅仅一个 PostgreSQL，就能覆盖大部分后端开发需求。

Sat, 04 Apr 2026 12:10:00 +0800

很多人觉得 Redis 没什么门槛。

命令不难，接入也快，压测时还总能打出很漂亮的数字。于是项目上线后，大家默认它“应该不会出事”。

但我看过不少 Redis 问题，最后都不是 Redis 自己不行，而是前面的设计太随便：Key 怎么拆，TTL 怎么设，热点怎么扛，内存打满以后怎么办，这些事一开始没想清楚，后面都会用线上故障补课。

我最近刷到一条讲 Redis 避坑的短视频，里面提到的点很典型。我没有照着转写，而是按“线上最容易出事故的顺序”重新整理成这篇文章。

如果你只记一句话，那就是：

Redis 真正危险的坑，大多不是命令层面的，而是设计层面的。