微服务架构 vs. 单体架构：质量属性对比与实例分析
1. 可用性（Availability）
- 微服务
优势：服务独立，故障隔离。例如，Netflix 使用微服务架构，当推荐服务宕机时，视频播放服务仍可正常运行。
劣势：依赖分布式系统的复杂性（如服务发现、熔断机制）。需额外工具（如 Hystrix）保障可用性。 - 单体
优势：无网络通信依赖，单点故障概率低（若部署在单一可靠节点）。
劣势：组件紧耦合，一处崩溃可能导致系统整体不可用。例如，早期 eBay 的单体架构在流量激增时频繁宕机。
运维关注点：
微服务需监控每个服务的健康状态（如 Prometheus + Grafana），单体则需关注整体系统的冗余备份。
2. 可修改性（Modifiability）
- 微服务
优势：服务独立修改和发布。例如，Uber 的支付服务可单独升级支付网关，无需影响行程计算模块。
劣势：接口变更需考虑兼容性，可能引发服务间协作问题。 - 单体
优势：代码集中，简单功能修改可能更快（如小型 CMS 系统）。
劣势：牵一发而动全身。例如，早期 Amazon 单体代码库中，修改商品目录逻辑需重新测试整个系统。
开发关注点：
微服务需严格定义 API 契约（如 Swagger/OpenAPI），单体需依赖模块化设计减少耦合。
3. 性能（Performance）
- 微服务
劣势：网络延迟高（远程调用）、序列化开销。例如，电商购物车服务频繁调用库存服务可能增加延迟。
优化手段：缓存（Redis）、异步通信（Kafka）。 - 单体
优势：本地调用高效，适合高吞吐场景。例如，高频交易系统（如股票交易）常采用单体保证低延迟。
实例：
Twitter 早期用单体架构处理推文，性能瓶颈后转向微服务拆分（推文发布、时间线生成独立服务）。
4. 可部署性（Deployability）
- 微服务
优势：独立部署，支持灰度发布。例如，Spotify 每天部署上千次，不同团队独立发布功能。
劣势：需复杂编排工具（如 Kubernetes）。 - 单体
劣势：全量部署风险高，回滚成本大。例如，银行系统每月一次深夜部署，停机时间长。
运维工具：
微服务依赖 CI/CD 流水线（如 Jenkins + Docker），单体需脚本化部署流程。
5. 安全性（Security）
- 微服务
优势：细粒度安全控制（如服务间 OAuth 鉴权）。例如，AWS 对不同微服务实施最小权限策略。
劣势：攻击面扩大（每个服务暴露 API）。 - 单体
优势：内部调用无需网络暴露，减少中间人攻击风险。
劣势：一旦被入侵，全系统沦陷。例如，2017 年 Equifax 数据泄露因单体漏洞被利用。
实践：
微服务需 API 网关（如 Kong）统一鉴权，单体需强化边界防护（如 WAF）。
6. 可测试性（Testability）
- 微服务
优势：单元测试隔离，模拟依赖容易（如 WireMock）。
劣势：集成测试复杂，需环境模拟（如 Docker Compose）。 - 单体
优势：端到端测试简单（所有组件本地运行）。
劣势：测试范围大，修改后需全量回归测试。
实例：
Netflix 的 Chaos Monkey 工具专门测试微服务容错性，而传统 ERP 系统（如 SAP）依赖完整测试套件。
7. 能源效率（Energy Efficiency）
- 微服务
劣势：资源冗余（多个服务实例 + 基础设施），能耗较高。例如，IoT 边缘计算场景可能避免微服务。 - 单体
优势：资源利用率高，适合资源受限场景。例如，嵌入式医疗设备常采用单体节省电量。
平衡方案：
部分企业采用混合架构，核心服务微服务化，边缘模块保持单体。
总结：选择架构的决策因素
- 选微服务：需快速迭代、大规模团队协作、高可用性需求（如电商、社交平台）。
- 选单体：简单应用、资源受限场景、强事务一致性需求（如传统银行核心系统）。
混合案例：
Airbnb 初期用单体快速验证业务，用户量增长后逐步拆分微服务（如支付、搜索独立部署）。