微服务是什么，不只是业务拆分
按业务模块拆分并保证隔离，是微服务的起点，但远远不是它的全部定义。
如果只做到「拆分业务模块」，更接近 模块化单体（Modular Monolith）。真正的微服务，还必须具备以下硬核特征。
1. 独立的部署单元（进程隔离）
微服务拆分后，每个模块必须运行在独立的进程中（甚至独立的机器/容器）。
代码层面的隔离（例如不同的 Java 包）不够：一处代码崩溃，整个应用仍会挂掉。微服务要求：支付服务挂了，订单服务必须还能正常运行（只是功能降级）。
2. 独立的数据库（数据隔离）
这是最容易忽略的一点。真正的微服务不仅隔离业务代码，更要隔离数据存储：
- 订单服务有自己的订单库，用户服务有自己的用户库
- 绝对不允许多个服务共享同一个数据库表
- 服务之间只能通过 API 调用数据，不能直连对方的数据库
3. 独立的研发与运维生命周期
每个微服务可以由不同的团队（甚至不同的编程语言）独立开发、独立发布上线。
修改「商品详情」的 Bug，只需要重新发布商品服务，不需要等整个大应用重新编译、打包、重启，也不影响正在运行的交易服务。
4. 去中心化的治理（通信与容错）
拆开之后，服务之间如何协作？微服务架构通常还需要配套能力：
- 服务发现：服务之间能互相找到对方
- API 网关：统一入口、路由与鉴权
- 熔断 / 降级：防止一个服务变慢拖垮整个系统（这在单体中不会发生）
三种架构，一张对比
| 形态 | 比喻 | 特点 |
|---|---|---|
| 单体应用 | 所有部门在同一栋写字楼（同一进程）办公 | 内部方法调用极快；一旦内存溢出，全公司瘫痪 |
| 按业务拆分（模块化单体） | 各部门在同一园区不同楼层，共用食堂和机房（共享数据库） | 有业务隔离；数据库锁表时，所有部门仍受影响 |
| 真正的微服务 | 各部门在城市不同独立办公楼，自有水电系统（独立数据库），靠 API 通信 | A 楼停电，B 楼仍正常运行；但网络不可靠，需要分布式事务等治理手段 |
精炼定义
微服务 = 按业务能力拆分 + 独立进程部署 + 独立数据存储 + 通过 REST/RPC 通信 + 配合服务治理（熔断、注册中心、配置中心）
如果只做了拆分，却没有引入分布式事务、服务注册和容错机制，架构大概率会变成「拆散了的分布式单体」——比原来的大应用更痛苦。
高并发场景里，微服务常用于把热点服务（如秒杀）单独扩容；但拆分前要先确认边界清晰、团队能驾驭分布式复杂度，否则收益远小于成本。