别为只有两台服务器的系统设计分布式架构

别为只有两台服务器的系统设计分布式架构

在技术圈里，经常能见到这样令人啼笑皆非的“架构奇观”：

一个刚上线的内部系统或初创项目，日常活跃用户只有几千人，峰值 QPS 甚至不到 50。然而打开其架构拓扑图，映入眼帘的却是全套豪华的分布式微服务军备：Kubernetes 集群、Istio 服务网格、Consul 服务发现、Jaeger 分布式追踪、Kafka 消息队列、Redis Sentinel 哨兵集群，甚至还挂着分布式事务框架。

更讽刺的是，这套系统底层的实际硬件资产，仅仅是两台 4 核 8G 的云服务器。

结果，服务器 75% 以上的 CPU 和内存资源被各类 Sidecar 代理、Prometheus 采集器、DaemonSet 以及 Java/Go 编写的中间件基础设施瓜分殆尽。留给真正跑业务代码的容器资源少得可怜，稍微来一波几十个人的并发批量导出，业务容器就因为 cgroup 内存限额被操作系统直接 OOM-Killed。

一、 沉重的“基础设施税（Infrastructure Tax）”

当我们为小体量系统引入大而全的分布式架构时，我们实际上背上了极其沉重的“税负”：

1. 算力与网络开销的无谓浪费

在单体架构下，一次函数调用只需耗费几个纳秒（直接内存寻址）。而在服务网格化的微服务中，一个简单的跨模块查询变成了：业务进程 -> Localhost Envoy Sidecar -> iptables 转发 -> 跨机器网络传输 -> 对端 Envoy Sidecar -> 对端服务进程。这不仅将响应延迟从 2ms 拉长到了 25ms，而且网络序列化与 TLS 握手白白浪费了宝贵的 CPU 算力。

2. 排障与维护心智成本呈指数级上升

在极简架构下，看日志只需一条 journalctl -u app -f 或打开本地日志文件。但在两台机器强行搭建的分布式环境里，排查一个偶发的请求超时，你需要：

• 检查 Kubernetes CoreDNS 是否发生了 DNS 解析抖动；
• 检查 Envoy 的连接池和重试熔断配置；
• 检查 etcd 是否在两台节点上发生了脑裂（两节点连法定人数 Quorum 都不满足）；
• 检查分布式链路追踪中的 TraceID 是否在某个异步协程中被漏传。

团队把 80% 的精力消耗在与中间件本身的 Bug 搏斗上，却挤占了真正解决业务 Bug 和打磨产品体验的时间。

二、 两台服务器的黄金高可用架构

对于 95% 的中小型业务系统，两台机器配合托管服务完全可以做到 99.95% 以上的高可用性与数千 QPS 的承载能力。

极简、坚固的架构方案如下：

[用户请求 (HTTPS)]
│
▼
[云厂商负载均衡器 ALB / CLB]
(负责 SSL 卸载、健康检查、轮询)
┌─────────┴─────────┐
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ 服务器 A (4C8G) │ │ 服务器 B (4C8G) │
│ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ Caddy/Nginx │ │ │ │ Caddy/Nginx │ │
│ └──────┬──────┘ │ │ └──────┬──────┘ │
│ ▼ │ │ ▼ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ 模块化单体 │ │ │ │ 模块化单体 │ │
│ │ App (Go/Node)││ │ │ App (Go/Node)││
│ └─────────────┘ │ │ └─────────────┘ │
└────────┬────────┘ └────────┬────────┘
└─────────┬─────────┘
│
▼
[云托管 PostgreSQL / MySQL] (主备读写分离)
[云托管 Redis] (轻量缓存与会话)

1. 业务层：模块化单体（Modular Monolith）

• 将用户域、订单域、通知域作为同一个代码仓库内的不同包或目录进行逻辑划分，彼此通过标准接口调用；
• 在单机上直接以 Systemd 服务或轻量 Docker Compose 容器运行，启动开销只有几百毫秒；
• 升级部署时，利用云负载均衡器的权重调节，一台一台平滑轮流重启（Rolling Update），实现零停机发布。

2. 数据层：绝不自建集群，全部拥抱云托管

• 两台服务器绝对无法搭建真正可靠的高可用数据库集群（因为无法解决脑裂与仲裁裁决问题）；
• 应当直接购买云厂商的托管 RDS 和托管 Redis。云厂商提供专业的主备切换、自动备份、点对点 PITR 恢复与监控，成本远低于工程师自建运维的人力代价。

3. 可观测性：极简轻量组合

• 日志直接按天轮转输出到本地磁盘，通过 logrotate 或轻量 promtail 异步推送到云日志存储；
• 监控使用单机 Prometheus + Grafana 或直接使用云厂商自带的基础监控 Agent，告警直接挂钩机器 CPU、内存、磁盘和核心接口 5xx 比例。

三、 架构演进的三大评估红线

什么时候才真正有理由把系统从“双机模块化单体”拆分为分布式架构？

如果你的团队只有 3~5 个人，日请求量在百万以内，那么任何引入微服务、服务网格和分布式事务的提议，本质上都是“简历驱动开发（Resume-Driven Development）”。

总结

优秀的架构师不是看他能把系统设计得多复杂，而是看他能用多简单的架构稳稳支撑业务发展。

在两台服务器的体量下，克制住对炫酷分布式概念的虚荣心，选择轻快、透明、低维护成本的模块化单体，把宝贵的算力留给业务，把宝贵的时间留给生活，才是真正的工程师智慧。