技术人读历史,不是为了背人物。
是为了看清——系统为什么会崩。
如果把东汉末年当成一套大型单体系统,
那么“十常侍乱政”,就是一次典型的:
权限设计失败 + 代理人失控 + 单点依赖崩溃
今天我们不用史学视角,
我们用架构视角。
东汉:一个设计有缺陷的单体系统
系统角色映射
| 历史角色 | 架构角色 |
|---|---|
| 皇帝 | Root 账号 |
| 士族官僚 | 业务层 Service |
| 宦官 | Gateway / Proxy |
| 外戚 | 插件模块 |
| 军阀 | 分布式节点 |
核心逻辑很简单:
1 | Root → 业务层 → 地方执行 |
宦官本来只是接口层。
系统第一次偏移:代理开始“拥有逻辑”
在汉灵帝时期,发生了一个关键变更:
皇帝为了制衡士族,开始更多依赖宦官。
本来:
1 | Root → Service |
变成:
1 | Root → Proxy → Service |
问题来了。
当 Proxy 掌握:
- 信息过滤权
- 人事推荐权
- 访问控制权
它就不再是接口层。
它开始拥有“决策权”。
这叫:
Proxy 升级为 Logic Server
这一步,是系统真正的转折点。
致命操作:删除业务层(党锢之祸)
汉桓帝
汉灵帝
清流士族批评宦官。
系统选择了一个极端操作:
1 | rm -rf business_layer |
这就是历史上的“党锢之祸”。
后果是什么?
系统结构变成:
1 | Root |
只剩一个代理。
这在架构里叫:
单点失效(SPOF)
权限系统彻底崩溃:卖官鬻爵
汉灵帝为了填补财政亏空,开启了:
1 | POST /buy_office |
权限直接售卖。
这意味着:
- RBAC 失效
- 能力不再是晋升标准
- 钱成为权限函数
系统等式变成:
1 | 权限 = f(金钱) |
这就是把权限系统与支付系统耦合。
任何技术人都知道:
当权限可以用钱直接购买,系统就失去了“可信性”。
并发冲突:系统进入写入风暴
后来发生什么?
何进想清理宦官。
宦官先发制人。
然后军阀入京——董卓。
系统进入:
1 | Thread A:宦官 |
同时写 Root 状态。
结果:
1 | Fatal Error: Authority Corrupted |
真正的架构问题是什么?
很多人说:
“宦官太坏。”
这不是架构师的思维。
架构师问的是:
为什么系统允许他们这么做?
答案是五个错误:
1️⃣ 权限边界模糊
2️⃣ 代理层可篡改输入
3️⃣ 业务层被清空
4️⃣ 权限与金钱耦合
5️⃣ 没有审计系统
这是一套没有:
- 审计日志
- 权限隔离
- 多副本校验
- 容灾机制
的单体系统。
它在高负载(社会动荡)下崩溃是必然。
如果重构东汉
我会做四件事:
① 最小权限原则
宦官只能管理宫廷,不得参与人事。
② 决策、执行、审计三权分离
独立监察服务,日志不可篡改。
③ 多信道信息输入
皇帝不得只依赖单一代理。
④ 财政与人事彻底解耦
禁止任何形式的“买官接口”。
架构哲学:历史给技术人的三句话
- 代理永远会膨胀。
- 当权限设计错误,道德会失效。
- 系统崩溃从来不是因为“坏人”,而是因为“结构”。
东汉不是亡于宦官。
它亡于:
一套没有边界、没有制衡、没有日志的系统。
为什么技术人一定要读历史?
因为:
- 公司架构会犯同样的错误
- 团队治理会走同样的弯路
- 创始人会重复皇帝的路径
当创始人只信任“身边人”;
当业务层被清洗;
当权限可以交易;
当审计形同虚设;
系统就已经在倒计时。
结尾
两千年前的东汉告诉我们:
架构的失败,不是流量问题,不是运气问题。
是权限模型的问题。
如果你是 CTO,
如果你是创始人,
如果你是技术负责人,
请记住一句话:
任何没有制衡的代理,最终都会成为系统的主人。
👇👇👇 扫码体验小程序 👇👇👇

👇👇👇 扫码关注公众号 👇👇👇
