什么是微服务架构？它和单体架构有什么区别？

简化版

微服务架构是把一个大系统按业务能力拆成多个可独立开发、独立部署、独立伸缩的小服务。它和单体架构最大的区别不是“代码拆开”，而是服务边界、数据边界、发布边界和团队协作边界都被拆开了。

详细版

单体架构通常把多个业务模块放在一个应用、一个进程、一次发布里，优点是开发简单、调用直接、事务处理容易，缺点是系统变大后发布风险高、模块耦合重、扩容粒度粗。

微服务架构则围绕业务能力拆分服务，例如用户服务、订单服务、库存服务、支付服务。每个服务有自己的代码仓库或模块边界、独立运行进程、独立数据库或数据所有权，通过 HTTP、RPC、消息队列等方式通信。

面试时可以从四个角度对比：

维度	单体架构	微服务架构
部署	一个整体包	多个服务独立发布
调用	进程内方法调用	网络调用或消息通信
数据	常见共享一个数据库	强调服务拥有自己的数据
治理	较简单	需要注册发现、限流、熔断、链路追踪、配置中心

微服务适合业务复杂、团队较大、模块变化频率不一致、需要按业务独立扩容的系统；如果系统规模小、团队小、业务还没稳定，过早微服务反而会带来复杂度。

完整版教学

一、微服务真正拆的是什么

很多人会把微服务理解成“把一个项目拆成很多 Spring Boot 应用”，这个理解太浅。微服务真正拆的是系统的变化边界。

一个成熟系统里，不同业务模块的变化速度不同。比如营销活动可能每天改，支付通道可能几个月才改一次，用户基础信息相对稳定，推荐策略又可能频繁实验。如果这些模块都在一个单体里，每次营销活动上线都要带着支付、订单、用户等模块一起构建、测试、发布，风险就会被放大。

微服务把这些变化频率、业务职责、扩容需求不同的部分拆开，让每个服务围绕一个清晰业务能力独立演进。拆完之后，服务之间通过明确接口协作，而不是随便调用对方内部代码。

可以把单体看成一个大办公室，所有人共用一张桌子；微服务像多个小团队，每个团队有自己的职责、资料柜和对外窗口。小团队之间沟通成本更高，但每个团队能独立行动。

二、微服务和单体的本质差异

微服务和单体的差异不只在代码结构，而在运行时模型。

单体架构中，一个订单创建流程可能是：

Controller -> OrderService -> InventoryService -> PayService -> 同一个数据库

这些调用大多是进程内方法调用，失败概率低，事务可以用本地数据库事务包住。

微服务架构中，同样流程可能变成：

订单服务 -> 库存服务
订单服务 -> 支付服务
订单服务 -> 消息队列 -> 积分服务 / 通知服务

这里的调用跨进程、跨机器、跨网络，任何一步都可能超时、失败、重复执行或出现数据短暂不一致。所以微服务不是简单拆包，而是把本地复杂度换成了分布式复杂度。

三、微服务带来的收益

微服务的收益主要来自独立性。

第一，独立发布。订单服务改一个字段，不必重新发布整个系统。只要接口兼容，就可以独立上线。

第二，独立扩容。秒杀场景可能只有商品、库存、订单入口压力大，后台配置服务压力很小。微服务可以只扩容热点服务，成本更可控。

第三，技术异构。搜索服务可以用 Elasticsearch，推荐服务可以用 Python，核心交易服务可以用 Java。只要对外协议稳定，内部技术栈可以不同。

第四，团队自治。不同团队围绕服务负责需求、质量、上线和故障，职责更清楚。

四、微服务付出的代价

微服务最大的代价是治理复杂度。

服务多了以后，你会立刻遇到这些问题：

问题	微服务里的表现
服务怎么找	需要注册中心和服务发现
调用失败怎么办	需要超时、重试、熔断、降级
数据怎么一致	需要最终一致、可靠消息、补偿
问题怎么排查	需要日志、指标、链路追踪
配置怎么管理	需要配置中心和灰度配置
谁能访问谁	需要鉴权、网关、服务间认证

所以微服务不是免费午餐。它解决的是大系统组织与演进问题，同时引入了网络、数据、治理和运维问题。

五、什么情况下不适合微服务

如果业务还没跑通、领域边界不清、团队只有几个人、系统访问量也不大，直接做微服务通常不划算。

原因很现实：你还不知道哪些模块会稳定，过早拆分容易把错误边界固化。一旦服务边界拆错，跨服务调用会变多，数据被切碎，需求改动反而更慢。

一个更稳妥的路线是先做“模块化单体”：代码上按领域划清模块边界，数据库表设计也避免互相乱用，等业务复杂度和团队规模真的上来，再把边界稳定的模块拆成独立服务。

六、常见误区与追问

这道题要紧扣「微服务架构」本身回答，不能把它混成泛泛的微服务架构套话。面试官通常会沿着“为什么需要、流程怎么走、失败怎么兜、代价是什么”继续追问，所以回答要覆盖服务边界、通信方式、网关/BFF、数据归属、版本兼容和部署治理。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	微服务架构把系统拆成围绕业务能力的自治服务，每个服务可独立开发、部署、扩容和治理	不要停在名词解释
流程机制	按业务能力拆分 -> 定义服务接口 -> 独立数据所有权 -> 服务注册发现 -> 配置治理和发布 -> 观测与容错闭环	要说清触发点、状态变化、确认点和失败兜底
工程取舍	用户、订单、库存、支付可以独立演进，但下单链路跨服务后必须处理调用失败和数据一致性	微服务提升团队自治和独立演进能力，但会带来分布式调用、数据一致性、依赖治理和运维复杂度

微服务架构 面试拆解：
1. 按业务能力拆分
2. 定义服务接口
3. 独立数据所有权
4. 服务注册发现
5. 配置治理和发布
6. 观测与容错闭环

记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「微服务架构」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。

• 误区：微服务就是把单体拆成很多项目。 核心是业务自治、数据边界、独立部署和治理能力。
• 误区：微服务一定比单体好。 小团队或业务早期可能单体更高效，微服务有明显复杂度成本。
• 误区：用了 Spring Cloud 就是微服务。 框架只是工具，边界、数据和协作方式才是关键。
• 追问：微服务解决什么问题？ 解决大型系统团队协作、独立发布、局部扩容和技术自治。
• 追问：最大挑战是什么？ 分布式调用、数据一致性、链路治理、观测和运维复杂度。
• 追问：怎么避免分布式单体？ 清晰服务边界、独立数据、减少同步强依赖和契约治理。

七、加强记忆

记住微服务的核心：它不是为了让项目看起来更高级，而是为了解决大系统中“业务变化、团队协作、独立发布、独立扩容”的问题；但它会把简单的方法调用变成复杂的分布式协作，所以只有当收益能覆盖治理成本时才值得拆。