1. 微服务架构概述
1.1 微服务定义
微服务架构是一种将单一应用程序划分为一组小型、独立服务的软件架构风格。每个服务围绕特定业务能力构建，拥有独立的数据库、部署流水线和生命周期。服务之间通过轻量级通信协议（如 HTTP/REST、gRPC 或消息队列）进行协作。
核心特征：
- 单一职责：每个服务只负责一个明确的业务领域。
- 独立部署：服务可独立构建、测试、部署和扩展。
- 去中心化治理：团队可自主选择技术栈和数据存储方案。
- 弹性与容错：单个服务故障不会导致整个系统崩溃。
1.2 与单体架构对比
单体架构将所有功能模块打包在同一个进程中运行，而微服务架构将系统拆分为多个独立进程。下表从多个维度对比两种架构的差异：
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 部署单元 | 单个 WAR/JAR 包，包含所有功能 | 多个独立服务，每个服务独立部署 |
| 扩展方式 | 整体垂直扩展或水平复制 | 按服务粒度独立扩展 |
| 技术栈 | 统一技术栈，所有模块共享 | 服务间技术栈可不同，团队自主选择 |
| 数据库 | 共享单一数据库 | 每个服务拥有独立数据库（Database per Service） |
| 团队协作 | 大型团队协作，代码冲突频繁 | 小团队自治，按业务领域划分 |
| 故障隔离 | 模块故障可能导致整个系统不可用 | 单个服务故障不影响其他服务 |
| 测试与发布 | 全量回归测试，发布周期长 | 独立测试与发布，支持持续交付 |
迁移建议：从单体架构向微服务迁移时，推荐采用“绞杀者模式”（Strangler Fig Pattern），逐步将单体中的功能模块抽取为独立服务，而非一次性重写。
1.3 微服务优缺点
优点
- 独立部署与快速迭代：每个服务可独立发布，不影响其他服务，缩短上线周期。
- 技术多样性：团队可根据业务需求选择最合适的语言、框架和数据存储。
- 弹性扩展：针对高负载服务单独扩容，节省资源成本。
- 故障隔离：服务级熔断、降级和重试机制，防止故障级联扩散。
- 团队自治：小团队全权负责服务的全生命周期，提升开发效率。
缺点
- 分布式复杂性：网络延迟、数据一致性、分布式事务等问题增加开发难度。
- 运维成本高：需要容器编排、服务发现、配置中心、日志聚合等基础设施。
- 调试与排查困难：请求跨多个服务，链路追踪和日志分析成为必备能力。
- 数据一致性挑战：跨服务的数据最终一致性需要 Saga 或事件溯源等模式支持。
- 服务间通信开销：远程调用相比本地方法调用存在性能损耗。
1.4 适用场景
微服务架构并非银弹，以下场景更适合采用微服务：
| 适用场景 | 说明 | 典型示例 |
|---|---|---|
| 大型复杂系统 | 业务模块多、逻辑复杂，单体架构难以维护 | 电商平台（订单、支付、库存、用户） |
| 高并发与弹性需求 | 部分服务流量波动大，需要独立扩缩容 | 视频直播（弹幕、礼物、推流） |
| 多团队并行开发 | 多个团队同时开发不同功能，需独立发布 | 金融科技（风控、交易、清算） |
| 技术栈多样化 | 不同模块适合不同语言或数据存储 | 数据分析平台（Python 处理 + Java 服务） |
| 持续交付与 DevOps | 需要频繁发布、快速回滚、自动化测试 | SaaS 产品（每周多次迭代） |
慎用场景：小型项目、原型验证阶段、团队规模小于 5 人、业务逻辑简单且变更不频繁时，建议优先选择单体架构或模块化单体，避免过度设计。
1.5 微服务与 Docker 的天然契合
Docker 容器为微服务提供了理想的运行环境：
- 环境一致性：容器封装了服务及其依赖，消除“在我机器上能跑”的问题。
- 轻量隔离：每个微服务运行在独立容器中，资源占用少，启动速度快。
- 弹性伸缩：结合 Kubernetes 等编排工具，可快速扩缩容服务实例。
- 版本管理：Docker 镜像标签化管理，支持灰度发布和快速回滚。
# 一个典型的微服务 Dockerfile 示例
FROM openjdk:17-jre-slim
WORKDIR /app
COPY target/order-service.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]