3、微服务架构基础
3.1 微服务定义
微服务架构是一种将单一应用程序划分为一组小型、独立服务的软件架构风格。每个服务围绕业务能力构建，拥有独立的数据库、独立的部署流水线，并通过轻量级通信机制（通常是 HTTP/REST 或 gRPC）相互协作。
与传统的单体架构不同，微服务不再将代码打包成一个巨大的部署单元，而是将系统拆解为多个自治的“微”服务。这里的“微”并非指代码量少，而是指服务粒度足够小，能够被一个小型团队独立开发、测试、部署和扩展。
核心洞察： 微服务架构的本质是“业务能力”的分布式实现。它不是为了技术而技术，而是为了解决单体应用在规模扩大后遇到的开发效率低、部署耦合高、扩展不灵活等实际问题。
3.2 核心原则
微服务架构并非简单的代码拆分，它遵循一组严格的设计原则，这些原则是保证架构长期健康演化的基石。
| 原则 | 定义 | 关键实践 |
|---|---|---|
| 单一职责 | 每个服务只负责一个特定的业务功能或领域边界，高内聚、低耦合。 | 一个服务只修改一个业务原因；服务内部变化不影响其他服务。 |
| 自治性 | 每个服务可以独立开发、部署、扩展和运维，不依赖其他服务的运行时状态。 | 独立数据库、独立 CI/CD 流水线、独立进程运行。 |
| 去中心化 | 消除单点瓶颈和集中式控制，服务间通过轻量级协议通信，数据存储去中心化。 | 每个服务选择最适合自己的数据库（Polyglot Persistence）；避免集中式 ESB。 |
常见误区： 很多团队将微服务简单理解为“把单体代码按功能模块拆成多个项目”，却忽略了自治性和去中心化原则，导致服务间强依赖、共享数据库、部署仍需协调，最终陷入“分布式单体”的困境。
3.3 单体架构 vs 微服务架构
为了更直观地理解两种架构的差异，下表从多个维度进行对比：
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 部署单元 | 单个 WAR/JAR 包，包含所有功能 | 多个独立进程，每个进程一个服务 |
| 扩展方式 | 整体水平扩展，无法按需扩展 | 按服务粒度独立扩展，资源利用率高 |
| 技术栈 | 统一技术栈（如 Java + Spring） | 服务间技术栈可异构（Java、Go、Node.js 混用） |
| 数据库 | 共享单一数据库 | 每个服务拥有独立数据库（数据去中心化） |
| 团队协作 | 团队按技术层划分（前端、后端、DBA） | 团队按业务能力划分（全功能小团队） |
| 故障隔离 | 一个模块故障可能导致整个应用宕机 | 单个服务故障不影响其他服务（需熔断、降级） |
| 开发效率 | 初期快，代码膨胀后构建、测试、部署变慢 | 初期慢（需搭建基础设施），规模扩大后效率稳定 |
3.4 典型微服务架构图
一个完整的微服务系统通常包含以下核心组件：API Gateway、服务注册与发现、配置中心 以及 服务间通信。下图展示了这些组件之间的协作关系。
3.5 组件详解
3.5.1 API Gateway
API Gateway 是系统的统一入口，负责将外部请求路由到内部微服务。它承担了以下职责：
- 路由转发： 根据请求路径、域名或 Header 将请求转发到对应的后端服务。
- 认证授权： 统一处理 JWT、OAuth2 等认证逻辑，减轻后端服务负担。
- 限流熔断： 防止突发流量冲垮后端服务，支持基于令牌桶、滑动窗口等算法。
- 协议转换： 将外部 HTTP 请求转换为内部 gRPC 或消息队列调用。
3.5.2 服务注册与发现
在微服务架构中，服务实例的 IP 和端口是动态变化的（如扩缩容、故障迁移）。服务注册与发现组件解决了“如何找到服务”的问题。
- 服务注册： 服务启动时向注册中心注册自身元数据（服务名、IP、端口、健康检查接口）。
- 服务发现： 客户端（或 API Gateway）从注册中心获取目标服务的实例列表，并基于负载均衡策略选择一个实例进行调用。
- 健康检查： 注册中心定期探测服务实例的健康状态，剔除不健康的实例。
3.5.3 配置中心
配置中心用于集中管理微服务的配置信息，实现配置的动态更新而不需要重启服务。
- 配置集中化： 所有服务的配置（数据库连接、开关、阈值）统一存储在配置中心。
- 动态刷新： 配置变更后，服务通过监听机制实时拉取最新配置，实现热更新。
- 环境隔离： 支持开发、测试、生产等多环境配置管理，避免人为错误。
3.5.4 服务间通信
微服务之间的通信方式主要分为两类：
| 通信方式 | 协议 | 适用场景 | 示例 |
|---|---|---|---|
| 同步通信 | HTTP/REST、gRPC | 实时性要求高、请求-响应模式 | 订单服务调用用户服务获取用户信息 |
| 异步通信 | 消息队列（Kafka、RabbitMQ） | 解耦、削峰填谷、事件驱动 | 订单创建后发送消息给通知服务和物流服务 |
架构决策提示： 在 Helm Chart 设计微服务时，需要为每个服务定义独立的 Service、Deployment、ConfigMap 和 Secret。API Gateway 通常作为独立的 Chart 或子 Chart 部署，而服务注册发现和配置中心则作为基础设施层，通过依赖关系注入到业务服务中。后续章节将详细讲解如何将这些组件映射为 Helm Chart 的资源模板。