1. API架构演进史：从单体应用到微服务，为什么我们需要API？
说实话，我入行那会儿，压根儿没听过「API」这个词。那时候写代码，就是在一个大项目里堆逻辑，前端页面、后端处理、数据库访问全揉在一起。你想想看，一个几百兆的 WAR 包，部署一次要重启半小时，改一行代码都得提心吊胆。
后来项目越做越大，团队从几个人变成几十人，那个单体应用就开始「卡脖子」了。我记得有一次线上事故，就因为一个模块的内存泄漏，整站挂了两个小时。老板拍桌子问：「你们不是刚上线吗？」——嗯，从那以后，我开始认真思考一个问题：软件到底该怎么拆？
1.1 单体架构：一切从「大泥球」开始
早期的企业应用，基本都是单体架构。所有功能模块——用户管理、订单处理、支付、报表——都跑在同一个进程里，共享同一个数据库。
- 代码库统一管理，开发初期效率极高
- 部署简单：一个 WAR/JAR 包搞定
- 测试方便：本地启动就能跑全链路
- 但……扩展困难，牵一发动全身
我在一家电商公司做过一个项目，刚开始单体架构跑得挺欢。但半年后，订单模块和用户模块开始「打架」——订单模块要升级数据库连接池，用户模块死活不同意，怕影响登录。你看，这就是单体架构的典型痛点：模块之间没有明确的边界。
1.2 为什么需要API？从「函数调用」到「服务契约」
单体应用里，模块之间通过函数调用通信。比如 UserService.getUserById() 直接调用 OrderService.getOrdersByUserId()。这种方式在同一个进程里没问题，但一旦模块要独立部署，函数调用就失效了。
这时候，API 就登场了。说白了，API 就是服务之间的「契约」。它规定了：
- 你能给我什么数据？
- 你需要什么参数？
- 返回格式是什么？
- 出错时怎么处理？
1.3 从单体到SOA：第一次「拆」的尝试
2000 年代初期，SOA（面向服务架构）开始流行。它的核心思想是：把业务功能拆成独立的服务，通过 ESB（企业服务总线）进行通信。
| 对比维度 | 单体架构 | SOA |
|---|---|---|
| 通信方式 | 进程内函数调用 | SOAP/XML 消息 |
| 服务粒度 | 无明确边界 | 粗粒度业务服务 |
| 耦合度 | 高耦合 | 中耦合（依赖 ESB） |
| 部署方式 | 统一部署 | 独立部署 |
| 典型协议 | 无 | SOAP、WSDL |
SOA 确实解决了一部分问题，但 ESB 本身成了新的瓶颈。我记得有个项目，ESB 挂了，所有服务都连不上。运维同事调侃说：「ESB 不挂，项目不黄；ESB 一挂，全员放假。」——嗯，这显然不是我们想要的。
1.4 微服务崛起：API 成为「一等公民」
2014 年左右，Martin Fowler 和 James Lewis 正式提出了微服务架构。它的核心变化是：每个服务都有自己的数据库、自己的 API、自己的部署单元。
为什么微服务需要 API？因为服务之间不再通过 ESB 通信，而是通过轻量级的 HTTP/REST 或 gRPC 直接调用。API 不再是「可选项」，而是服务之间的「生命线」。
1.5 核心逻辑：API 架构演进全景图
下面这张图，是我自己总结的 API 架构演进路线。它清晰地展示了从单体到微服务的核心变化：
1.6 为什么我们需要API？三个核心理由
讲完了演进史，咱们回到最根本的问题：为什么我们需要 API？ 我总结了三个核心理由：
- 解耦：API 是服务之间的「防火墙」。只要 API 契约不变，服务内部怎么改都行。我在项目中见过太多「改一个模块，炸一片」的惨案，API 就是用来避免这种事的。
- 复用：一个设计良好的 API，可以被多个客户端复用——Web、App、第三方开发者。说白了，API 就是你的「数字资产」。
- 演进：没有 API，你根本没法做灰度发布、A/B 测试、版本升级。我记得有一次做数据库迁移，就是因为有 API 层做适配，才做到了「用户无感知」。
1.7 本章小结
从单体到 SOA，再到微服务，API 的角色越来越重要。它不再只是「接口文档」，而是服务之间的「宪法」。接下来的章节，我会带你深入 API 设计的每一个细节——从协议选择到版本管理，从安全策略到性能优化。