技术栈经验：一年内实现20倍扩展

Source: Dev.to

一年前，我写了关于我们的技术栈的文章，介绍它是如何帮助我们运营一家精简的云计算初创公司的。此后，我们的规模增长了 20 倍以上。这种增长很刺激，但也会打破许多东西和假设，迫使你必须快速做出艰难的选择 :‑D

下面是我们在这过程中发生了哪些变化、哪些保持不变以及我们学到了什么。

保持不变的部分

有些东西就是好用。

• Frontend – 仍然是 Nuxt 搭配 TypeScript 和 Tailwind（RIP @adamwathan）。
• Backend – 仍然是 Go 搭配 Gin。
• Infrastructure – 仍然使用 Hetzner 裸金属服务器，采用 Firecracker 进行虚拟化。
• IaC – 仍然是 Terraform。
• Caching – 仍然是 Redis。
• Customer support – 仍然是 Crisp。
• Transactional email – 仍然是 AWS SES。

如果它没有坏，就别去修它。

但有很多东西已经坏了——或者继续以同样方式运行成本太高。

可观测性：Axiom → Parseable

这是我们最大的一次运营变更。去年我曾赞扬 Axiom 的日志功能；在免费套餐上它表现很好——直到我们扩容。

随着流量增长，我们需要更好的追踪和更详细的日志。我们的 Axiom 账单飙升至 €1,000 / 月 以上，并且还在继续上升。此时必须问自己：这可持续吗？ 显然不行。

于是我们迁移到了 Parseable，在 Kubernetes 上自托管，并使用 MinIO 作为兼容 S3 的存储，全部运行在裸金属服务器上。产品仍然感觉比较早期，但团队响应迅速，出现问题时能快速修复。特别感谢 Anant 和 Deba！

我会推荐它吗？ 如果你不能用大量金钱换取时间，答案是肯定的。自托管可观测性需要投入工作，但在我们的“规模”（我们仍然很小）下是值得的。我们仍然使用 Grafana 来做仪表盘和告警；这点没有改变（不过账单已经开始让人感到压力）。

对象存储：Backblaze → IONOS / Hetzner

去年我们使用 Backblaze 进行对象存储。它既便宜又可靠。问题并不在技术层面，而是政治层面。

随着业务的增长，企业客户——尤其是欧洲的客户——开始对将数据存放在美国供应商那里提出异议（GDPR、数据主权、内部政策）。他们的诉求非常明确：**不使用美国供应商！**于是，我们开始了替换所有美国供应商的行动，首当其冲的就是 Backblaze。

我们将对象存储迁移到了 IONOS 和 Hetzner。它们能和 Backblaze 相媲美吗？答案是否定的，甚至差距很大。但它们是欧洲的，勉强够用，并且满足了客户的要求。说实话，如果没有强制要求使用它们，我也不会选。感觉我们在这件事上真的没有太多选择。

CDN：Cloudflare → Bunny

与存储的情况相同。Cloudflare 是一款功能强大的产品，拥有我们永远不会使用的特性，但客户要求提供欧洲的替代方案。

Bunny 完全符合需求。它不像 Cloudflare 那样功能齐全，但能够完美满足我们的 CDN 需求。它速度快、价格合理且位于欧洲。对于我们极其简单的部署，迁移耗时不到 2 小时.

CI/CD: GitHub Actions → Namespace

GitHub Actions 为我们服务良好，但已经停滞。我们需要嵌套虚拟化来测试 Firecracker 相关内容并提升性能——GitHub 没有满足需求。

我们将 Namespace 用作我们的 runner。它是一个很棒的产品——同样是欧洲的，这在这里正成为一种趋势。仅仅是性能提升就值得我们切换。

话虽如此，我们可能最终会迁移到完全自托管的 runner。规模越大，我们想要的控制权就越多。

数据持久化：重大变更

这是我们最重要的架构改动。去年，我曾吹嘘我们把所有东西都运行在 PostgreSQL 加 Timescale 上，包括数亿条分析数据。那运行得很好，直到我们的数据库达到 2 TB。

当达到 2 TB 时，PostgreSQL 变得难以管理。糟糕的查询会把生产环境拉倒，扩展变得痛苦，数据库专家们也开始笑了。（故事的其余部分将在文章的下一部分继续…）

# About Me

2 TB is probably nothing in the grand scheme of things! I am not a Postgres pro, and honestly wasn’t planning on becoming one. Additionally, the cost just started to hurt—especially considering that we want to do another 20× in 2026.

So we built something simpler: hot data lives in **Postgres**, then gets flushed to S3 as **Parquet** files. For queries we use **DuckDB** to read directly from S3. DuckDB is **amazing**.

The results surprised us. P99 latency actually improved. Why? Most queries are “give me the last 5 minutes of metrics” or “show me the last 500 logs.” That’s all hot data sitting in Postgres. Historical queries hit S3, and DuckDB handles Parquet files like a champ. Those are, if not cached, slightly slower.

This architecture saves money, scales better, and plays to our strengths. We understand S3. We don’t understand running a 10 TB Postgres cluster. :D

Source: …

模式

回顾所有这些变化，出现了一个明显的模式：

• 全欧洲化。
  客户的压力让我们转向欧盟供应商。这不是技术决定，而是当你超越初创公司和独立黑客阶段时的商业现实。

• 大规模自托管。
  SaaS 产品很好用，直到你的账单超过某个阈值。那时你必须算算自己的时间成本是否低于他们的价格。

• 简单胜过巧妙。
  我们没有构建花哨的分布式数据库。我们把数据写入 S3 并用 DuckDB 查询。它不性感，但能工作！(其实，我觉得这种简洁本身也很性感，只是对简历导向的开发不太友好。)

What’s Next

• 我们可能很快会自行托管 CI runner。
• 我们正在评估 AWS SES 的替代方案，因为，你知道的，欧洲合规性。

技术栈会持续演进——这就是大规模构建基础设施的本质。但核心理念保持不变：保持简单，保持可维护，只有在问题迫使时才增加复杂度。

这就是我们在 2026 年的现状：规模扩大了二十倍，吸取了一些惨痛教训，技术栈比以往更具欧洲特色。

Cheers,
Jonas