第2章：架构演进——从单体应用走向微服务，接口高可用面临的挑战

咱们干后端的，这几年感受最深的就是架构在变。十年前扛一个单体项目，代码全堆在一个包里，部署就一个 WAR 包往 Tomcat 里扔。现在呢？你随便拆个新项目，张口就是十几个微服务。变化是好事，但高可用这块的玩法，彻底不一样了。

我记得刚带团队那会儿，维护过一个老的单体电商系统。每次上线都像在拆弹，一个接口改了，全链路的回归测试跑一整天。更头疼的是，订单模块的一个小 bug，能把整个应用的 JVM 堆栈打满，结果所有接口都超时。这是单体架构的典型痛点——故障隔离性太差。

后来我们切了微服务。服务拆开了，故障确实隔离了，但新的麻烦冒出来了一堆。

单体架构：简单时代的隐忧

先说说单体。说白了所有逻辑都在一个进程里跑。内部调用就是本地方法调用，时延微秒级，不需要考虑网络抖动。但问题也在这：

• 耦合紧：一个模块挂了，整个应用瘫痪。
• 扩展难：你没法只给支付模块加机器，得整体扩。
• 上线风险高：任何小修改都得全量发布。

我在电商项目里遇到过这种情况：双11流量上来，订单服务扛不住，但因为和用户服务、商品服务跑在同一个进程中，CPU 被打满后所有接口都开始报 502。用户登不上去，商品详情也刷不出来。这就是单体架构的血泪教训——故障没有边界。

微服务：拆开了，挑战反而变多

微服务的核心思路是「高内聚、低耦合」。每个服务独立部署、独立扩缩容、独立运维——听起来很美。但当你把进程间的本地调用换成网络调用后，高可用面临的全是新课题。

你想想看，以前一个函数调用，现在变成了一次 HTTP/ RPC 请求。网络是不可靠的，延迟是波动的。这带来的第一个冲击就是：接口响应时长不再是确定的。

挑战一：网络延迟与不确定性

本地方法调用，延时基本上在纳秒级。跨进程网络调用，哪怕在同一个机房，1ms～5ms 也是常见的。跨可用区？那可能 10ms 以上。还记得我们做秒杀系统时，订单服务跨了两个 AZ 部署，平时 RTT 稳定在 3ms，有一次光缆被挖断，直接飙升到 300ms。接口超时率暴涨，前端体验就是一直接触失败。

挑战二：服务依赖与雪崩效应

微服务之间通常存在复杂的调用链。你调我，我调他，他调数据库。一旦某个下游服务变慢，上游的线程就会被打满，最终形成链路阻塞。这就是雪崩效应。

我有一个血的教训。有一个查询接口，依赖三个子服务。其中商品详情服务因为数据库连接池满了，响应从 20ms 涨到 2s。结果上游服务配置的超时时间是 3s，所有进来的请求都卡在等待上，线程池耗尽后整个 API 网关都瘫痪了。影响面从「查询接口不可用」扩散到「所有接口不可用」。

挑战三：数据一致性的分布式难题

单体架构下，一个事务把多个操作包在一起。数据库层面 ACID 帮你搞定一切。但在微服务里，每个服务有自己的数据库。跨服务的事务怎么做？不能用本地事务了。

我个人习惯在关键业务场景用 Saga 模式 或 最终一致性。比如订单服务创建订单后，通过消息队列通知库存服务扣减库存。如果扣减失败，就发补偿消息回滚订单。但这套机制的复杂度比单体事务高一个数量级——你需要保证消息不丢失、不重复、顺序性。

挑战四：监控与可观测性的缺失

单体时代，你只要看一个应用的日志和指标就够了。微服务呢？几十个进程分布在几十台机器上，调用链路跨三个机房。一个 502 报错，你去哪个服务查日志？

我见过最惨的情况是一个线上事故排查了整整两天，最后发现是一个配置中心的键写错了。因为没有全链路的 trace，根本定位不到问题节点。

核心对比：单体 vs 微服务的高可用视角