微服务架构详解
什么是微服务？
微服务是一种架构风格，它将一个大型应用构建成一系列按业务领域划分的、小的、自治的服务集合。简单来说，就是将系统按业务拆分成多个子系统，每个子系统都是完整、可独立运行的，子系统间通过 HTTP 协议或消息队列（如 RocketMQ、Kafka）进行通信。
微服务的特点
| 特点 | 说明 |
|---|---|
| 解耦 | 同一系统内的服务大部分可被解耦，便于构建、修改和扩展 |
| 组件化 | 微服务是相互独立的组件，可被轻易替换和升级 |
| 业务能力 | 每个服务专注于单一的业务能力 |
| 自治 | 开发者和团队可独立工作，提高开发速度 |
| 持续交付 | 允许持续发布新版本，通过自动化手段创建、测试和批准 |
| 职责明确 | 服务被视为需要长期负责的项目，而非一次性交付物 |
| 去中心化管理 | 无标准化技术栈限制，开发者可为问题选择最佳工具 |
| 敏捷性 | 支持敏捷开发，新功能可快速开发或丢弃 |
微服务的优势
- 独立开发：基于各服务的独有功能，可并行开发。
- 独立部署：每个服务可独立部署到应用中。
- 错误隔离：单个服务故障不影响整个系统。
- 混合技术栈：不同服务可用不同语言和技术构建。
- 按粒度扩展：可针对需求扩展特定组件，无需全量扩展。
为什么需要微服务？
传统单体架构的局限
传统企业级应用通常分为三部分：
- 客户端用户界面（浏览器中的 HTML/JavaScript）
- 数据库（统一的关系型数据库）
- 服务端应用（处理 HTTP 请求、执行领域逻辑、检索更新数据库、返回 HTML）
单体架构的问题：
- 任何微小变更都需要重新构建和部署整个应用。
- 随时间推移，模块化结构难以维护，一个模块的变更容易影响其他模块。
- 扩展时需整体扩展，无法按需部分扩展。
微服务的解决方案
微服务将应用拆分为一组可独立部署的服务，每个服务：
- 可独立部署和扩展
- 提供坚实的模块边界
- 可用不同编程语言编写
- 可由不同团队管理
组件化与服务
组件：可独立替换和升级的软件单元。
组件化的两种形式：
- 库（libraries）：被链接到程序，通过内存函数调用（进程内）。
- 服务（services）：进程外组件，通过 WebService 或 RPC 通信。
服务作为组件的优势：
- 可独立部署，修改单个服务无需重新部署整个应用。
- 接口更清晰，远程调用机制强制了接口的规范性。
服务作为组件的代价：
- 远程调用比进程内调用更消耗资源。
- API 需设计为粗粒度，增加使用难度。
- 跨进程职责调整更复杂。
围绕业务功能组织
传统组织按技术层面划分团队（UI 团队、业务逻辑团队、数据库团队），导致任何变更都需跨团队协作，耗时耗力。
微服务的组织方式：围绕业务功能组织团队，每个团队是跨职能的，包含开发所需的所有技能（用户体验、数据库、项目管理）。团队负责对应服务的全生命周期。
康威定律：设计系统的组织，其产生的设计等同于组织之间的沟通结构。
产品不是项目
传统模式：项目完成后移交给运维团队，开发团队解散。
微服务理念：团队负责产品的整个生命周期（"you build, you run it"），开发者需关注软件运行状况，增加用户联系，承担售后支持。
强化终端，弱化通道
微服务倾向于：
- 强化终端：服务内包含完整业务逻辑。
- 弱化通道：采用简单的通信机制，而非复杂的企业服务总线（ESB）。
常用通信协议：
- HTTP 请求-响应（RESTful API）
- 轻量级消息总线（如 RabbitMQ、ZeroMQ）
分散治理
微服务反对集中式治理，提倡用合适的工具解决合适的问题：
- 不同服务可用不同语言开发（如 Node.js 做报表页面，C++ 做高性能组件）。
- 不同服务可用不同数据库。
- 团队共享有用的工具和库，但不强制标准化。
分散数据管理
-
概念层面：不同系统中的同一概念可能含义不同，通过领域驱动设计（DDD）的限界上下文（Bounded Context）进行管理。
-
数据存储层面：每个服务管理自己的数据库，可以是相同数据库的不同实例，也可以是不同类型的数据库（Polyglot Persistence）。
-
事务处理：避免分布式事务，采用最终一致性和补偿机制。
基础设施自动化
微服务高度依赖自动化：
- 持续集成/持续部署（CI/CD）
- 自动化测试
- 自动化部署到多种环境
云计算（如 AWS）的发展极大简化了微服务的构建、发布和运维。
容错性设计
服务作为组件意味着应用必须能容忍服务故障：
- 客户端需设计优雅的降级方案。
- 监控系统实时检测服务状态（如请求数、业务指标）。
- 自动化故障检测和恢复（如 Netflix 的 Simian Army）。
- 仪表盘显示服务上下线状态、吞吐量、延迟等。
设计改进与演进
微服务支持持续的设计改进：
- 服务应该是可替换的，甚至可报废的。
- 可将临时性功能独立为服务，过期后直接移除。
- 持续观察服务变更频率，合并频繁一起变更的服务，拆分很少一起变更的服务。
总结
| 维度 | 传统单体架构 | 微服务架构 |
|---|---|---|
| 部署 | 整体部署，牵一发而动全身 | 独立部署，按需发布 |
| 扩展 | 全量扩展 | 按服务粒度扩展 |
| 技术栈 | 统一 | 多样（混合技术栈） |
| 组织 | 按技术划分团队 | 按业务划分团队 |
| 数据 | 单一数据库 | 每个服务独立数据库 |
| 故障影响 | 整体不可用 | 局部隔离 |
| 开发速度 | 慢，需跨团队协调 | 快，团队自治 |
微服务架构通过服务化、分散治理、自动化运维、容错设计等原则，解决了传统单体架构在规模化、敏捷性、可靠性方面的挑战，成为现代云原生应用的主流架构风格。
浙公网安备 33010602011771号