微服务架构概述
问题
什么是微服务架构？与单体架构、SOA 有什么区别？微服务有哪些优缺点？
答案
架构演进
三种架构对比
| 维度 | 单体架构 | SOA | 微服务 |
|---|---|---|---|
| 部署单元 | 一个大应用 | 多个服务 | 大量小服务 |
| 通信 | 进程内调用 | ESB 企业服务总线 | REST/gRPC/MQ |
| 数据 | 共享数据库 | 可共享 | 每服务独立数据库 |
| 团队 | 一个团队 | 按功能分 | 按业务领域分 |
| 技术栈 | 统一 | 相对统一 | 各服务可独立选型 |
| 部署 | 整体部署 | 服务级部署 | 独立部署 |
| 扩展 | 整体扩展 | 服务级扩展 | 服务级精确扩展 |
微服务核心特征
| 特征 | 说明 |
|---|---|
| 服务独立 | 每个服务独立开发、部署、扩展 |
| 围绕业务 | 按业务领域（DDD）拆分，而不是技术层 |
| 去中心化 | 去中心化治理、去中心化数据管理 |
| 基础设施自动化 | CI/CD、容器化、编排 |
| 容错设计 | 熔断、降级、限流、重试 |
微服务技术全景
微服务的优缺点
| 优点 | 缺点 |
|---|---|
| 独立部署，快速迭代 | 分布式系统复杂性（网络、一致性） |
| 技术栈灵活 | 运维成本高（需要完善基础设施） |
| 故障隔离 | 服务间通信延迟 |
| 按需扩展 | 数据一致性难保证 |
| 团队自治 | 测试复杂（集成测试难） |
| 易于理解（单个服务小） | 服务拆分需要经验 |
不要为了微服务而微服务
微服务不是银弹。小团队（< 10 人）、业务简单的项目，单体架构可能更合适。微服务的价值在大规模团队和复杂业务中才能体现。
评估标准：如果单体架构下团队间频繁冲突、部署周期长、无法按需扩展，再考虑拆分微服务。
常见面试问题
Q1: 什么时候应该使用微服务架构？
答案：
适合微服务的场景：
- 团队规模大：多个团队并行开发，需要独立部署
- 业务复杂：有明确的业务边界，适合按领域拆分
- 弹性需求：不同模块流量差异大，需按需扩展
- 快速迭代：需要频繁独立发布，降低发布风险
不适合的场景：
- 初创项目（业务边界不清晰）
- 小团队（< 5 人）
- 简单 CRUD 系统
Q2: 微服务和 SOA 的本质区别？
答案：
- 通信方式：SOA 依赖重量级的 ESB（企业服务总线），微服务用轻量级的 REST/gRPC
- 粒度：微服务粒度更细，一个 SOA 服务可能对应多个微服务
- 数据：微服务强调每服务独立数据库，SOA 可能共享
- 治理：微服务去中心化，SOA 集中管理
本质上微服务是 SOA 的轻量化演进。
Q3: 微服务的挑战有哪些？怎么应对？
答案：
| 挑战 | 应对方案 |
|---|---|
| 分布式事务 | Seata、MQ 事务消息、Saga |
| 服务调用链复杂 | 链路追踪（SkyWalking） |
| 数据一致性 | 最终一致性 + 对账 |
| 运维复杂 | Docker + Kubernetes + CI/CD |
| 服务雪崩 | 熔断限流降级 |
| 配置管理 | 配置中心 |