[TOC] ## 微服务 ### 微服务架构的涵义 微服务架构是一种将单体应用拆分为一组小型、独立运行的服务的架构风格。 * 每个服务围绕特定业务能力构建，独立部署、独立扩展。 * 服务之间通过轻量级通信机制（如 HTTP/REST、gRPC、消息队列等）进行交互。 * 每个服务可以使用不同的技术栈和数据存储方式。 ### 微服务架构的关键原则 1. **单一职责**：每个服务只负责一个相对独立的业务功能。 2. **独立部署**：服务之间低耦合，可以单独开发、测试和发布。 3. **去中心化治理**：服务团队自主选择技术栈、数据库和部署方式。 4. **轻量级通信**：采用标准化、轻量级协议（如 REST、gRPC、消息队列）。 5. **容错与弹性**：具备故障隔离、降级、熔断、重试等能力。 6. **自动化运维**：通过持续集成、持续交付（CI/CD）和自动化监控运维来保障系统健康。 7. **数据去中心化**：每个服务拥有独立数据库，避免共享数据库带来的强耦合。 ### 微服务的数据一致性 常用解决方案 1. **事件驱动（Event-Driven）** * 服务 A 发生变更 → 发布事件 → 服务 B 订阅事件更新自己的数据。 * 优点：解耦、可扩展。 * 缺点：数据最终一致，存在短暂延迟。 2. **分布式事务** * **两阶段提交（2PC）** 或 **Saga 模式**。 * Saga 模式：通过一系列局部事务和补偿操作保证跨服务操作的最终一致性。 * 适合重要业务场景，但实现复杂。 3. **共享数据服务** * 将跨服务共享的数据集中到专门的数据服务，由各服务通过 API 访问。 * 优点：保证一致性和单一数据来源。 * 缺点：增加服务调用延迟，可能成为瓶颈。 ### 微服务的高可用性 * **服务冗余**：每个服务部署多个实例，避免单点故障。 * **服务发现**：。 * **负载均衡**：通过 LB 或服务注册中心（Consul/Nacos/Eureka）分发请求。 * **熔断与限流**：避免下游服务故障扩散，保护系统整体可用性。 * **隔离（Bulkhead）**：不同服务/模块使用独立资源池，单个服务的压力不会影响全局。 * **自动化运维**：健康检查、自动重启、自动扩容。 ### 网关的作用 * **统一入口**：客户端只需要访问网关，不需要关心后端服务的地址和数量。 * **路由转发**：根据请求路径或规则，把请求转发到对应的微服务。 * **安全控制**：在网关层做认证、鉴权、限流、防火墙，保护后端服务。 * **协议转换**：支持 REST、gRPC、WebSocket 等协议的转换，适配不同客户端。 * **负载均衡**：将请求分发到多个实例，提高系统可用性和性能。 * **聚合服务**：把多个微服务的结果拼接在一起返回，减少客户端调用次数。 * **监控与日志**：统一收集请求的访问日志、指标数据，方便监控和追踪。