微服务与事件驱动架构（EDA）

微服务架构

微服务架构核心特征

• 服务自治：每个服务拥有独立的代码库、数据库和运维流程。
• 轻量级通信：服务间通过API（REST/gRPC）或消息队列（如Kafka）交互。
• 去中心化治理：允许技术栈多样化（如不同服务使用Java、Go、Python）。
• 故障隔离：单个服务故障不影响全局系统可用性。

微服务的核心设计原则

• 领域驱动设计

  • 限界上下文（Bounded Context） ：根据业务领域划分服务边界（如“订单上下文”与“支付上下文”），避免模型混杂。

  • 上下文映射（Context Mapping） ：

    防腐层（Anti-Corruption Layer） ：隔离外部服务的模型变更（如适配第三方支付接口）。

    发布语言（Published Language） ：通过共享事件格式（如Avro Schema）实现跨服务通信。

• 服务拆分策略

  • 基于业务能力拆分：按业务功能划分服务（如用户服务、物流服务）。
  • 基于数据边界拆分：确保每个服务拥有独立数据库（如订单服务用MySQL，商品服务用MongoDB）。
  • 基于变更频率拆分：高频变更模块独立为服务（如促销活动服务），避免频繁全系统发布。

• 服务通信机制

  • 同步通信：

    RESTful API：简单易用，适合外部系统集成（如移动端调用）。

    gRPC：基于HTTP/2的高性能RPC框架，适合内部服务间通信。

  • 异步通信：

    消息队列（如Kafka/RabbitMQ） ：解耦服务，实现最终一致性（如订单创建后发送事件通知库存服务）。

    事件溯源（Event Sourcing） ：通过事件日志重建状态（如用户积分变更历史）。

微服务的技术支撑体系

• 服务治理

  • 服务发现：

    客户端发现：服务消费者通过注册中心（如Eureka、Consul）获取服务实例列表。

    服务端发现：通过负载均衡器（如Nginx、K8s Service）路由请求。

  • 熔断与降级：

    熔断器（Circuit Breaker） ：当服务失败率超过阈值时，快速失败（如Hystrix、Sentinel）。

    降级策略：返回缓存数据或默认值，保障核心流程可用（如商品详情页降级显示静态信息）。

  • 配置中心：动态管理服务配置（如Apollo、Nacos），支持灰度发布和实时生效。

• 数据一致性管理

  • 分布式事务挑战：(CAP定理约束)在一致性（C）与可用性（A）之间权衡，跨服务调用可能因网络中断导致数据不一致。
  • Saga模式：将事务拆分为多个本地事务，通过补偿操作回滚（如“订单创建”成功后若“库存扣减”失败，则触发“订单取消”补偿）。
  • TCC：业务层实现两阶段提交（电商支付场景：预扣款（Try）→ 确认（Confirm）→ 取消（Cancel））。
  • 事件驱动最终一致性：通过消息队列保证事件可靠传递（如订单服务发布“订单已支付”事件，库存服务消费后扣减库存）。

• 可观测性

  • 日志聚合：使用ELK（Elasticsearch + Logstash + Kibana）或Loki集中管理日志，支持分布式追踪（Trace ID）。
  • 指标监控：Prometheus采集服务指标（如QPS、延迟），Grafana可视化展示。
  • 链路追踪：Jaeger或SkyWalking追踪跨服务调用链，定位性能瓶颈（如查询超时的根因是数据库慢查询）。

• API网关

  • 路由转发：将外部请求分发到内部服务（如/api/orders路由到订单服务）。
  • 鉴权与限流：验证JWT令牌，限制每秒请求数（如防止爬虫滥用）。
  • 协议转换：将HTTP请求转换为gRPC或GraphQL协议。
  • 代表实现：Kong、Spring Cloud Gateway、Envoy。

• 服务网格（Service Mesh）

  • 架构模式：通过Sidecar代理（如Envoy）接管服务间通信，实现非侵入式治理。
  • 流量管理：金丝雀发布、A/B测试。
  • 安全通信：mTLS加密、服务身份认证。
  • 可观测性：自动生成指标和追踪数据。
  • 代表框架：Istio、Linkerd。

事件驱动架构（EDA）

事件驱动架构核心理念

• 异步通信：事件生产者无需等待消费者处理结果。
• 事件持久化：事件通常被持久化存储，支持重放和审计。
• 最终一致性：通过事件传播实现数据一致性，而非强一致性。
• 动态响应：系统可灵活响应未知或未来新增的消费者。

事件驱动架构的核心组件

• 事件（Event） ：系统中发生的状态变化或业务动作的描述（如“订单已创建”“库存已扣减”）。

• 事件生产者（Event Producer） ：检测状态变化并发布事件（如订单服务在订单创建后发布OrderCreated事件）。

  • 数据库变更捕获（CDC） ：如Debezium监听MySQL binlog。
  • 业务逻辑显式触发：代码中主动调用事件发布接口。

• 事件消费者（Event Consumer） ：订阅并处理事件，执行后续业务逻辑（如库存服务消费OrderCreated事件扣减库存）。

  • 即时处理：实时响应（如发送短信通知）。
  • 批处理：定时批量处理（如生成每日报表）。

• 事件通道（Event Channel） ：传输和存储事件的媒介，解耦生产者与消费者。

  • 消息队列：Kafka、RabbitMQ（支持点对点、发布/订阅）。
  • 事件总线：Apache Pulsar、AWS EventBridge（支持复杂路由规则）。

事件驱动架构的通信模式

• 发布/订阅（Pub-Sub） ：生产者将事件发布到特定主题（Topic），所有订阅该主题的消费者都会接收事件。

• 事件流（Event Streaming） ：事件以有序、不可变日志形式持久化，支持重放和历史追溯。

  • Kafka：通过分区（Partition）保证事件顺序，消费者按偏移量（Offset）读取。
  • 事件溯源（Event Sourcing） ：用事件日志作为系统状态的唯一来源（如银行账户通过交易事件重建余额）。

分层架构与CQRS模式

分层架构（Layered Architecture）

• 表现层（Presentation Layer） ：处理用户交互，如HTTP请求、页面渲染（Spring MVC、React/Vue前端框架）。
• 业务逻辑层（Business Logic Layer） ：封装业务规则与流程（如订单创建、库存扣减），避免将业务逻辑泄漏到表现层或数据层。
• 数据访问层（Data Access Layer） ：提供数据持久化接口，如操作数据库、缓存（JPA、MyBatis、Redis客户端）。
• 基础设施层（Infrastructure Layer） ：提供通用技术能力（如日志、消息队列、文件存储）。

CQRS模式（Command Query Responsibility Segregation）

• 命令端（Write Model）

  • 流程：接收命令（如CreateOrderCommand）→ 执行业务逻辑 → 生成事件（如OrderCreatedEvent）。
  • 领域驱动设计（DDD） ：聚合根（Aggregate Root）封装业务规则。
  • 事件溯源（Event Sourcing） ：通过事件日志重建状态（可选）。

• 查询端（Read Model）

  • 流程：订阅事件 → 更新读模型（如生成订单列表视图）。
  • 物化视图（Materialized View） ：定期同步写库数据到读库。
  • 实时同步：通过CDC（如Debezium）捕获数据库变更。

分层架构与CQRS的结合（DDD架构）

• 表现层：接收HTTP请求，区分命令（POST/PUT）与查询（GET）。

• 应用层：

  • 命令处理器：调用领域模型执行业务逻辑，发布事件。
  • 查询处理器：从读模型获取数据，组装DTO。

• 领域层：定义聚合根、实体、值对象，封装核心业务规则。

• 基础设施层：

  • 写存储：MySQL处理事务性操作。
  • 读存储：Redis缓存热点数据，Elasticsearch支持复杂查询。
  • 事件总线：Kafka传递领域事件，触发读模型更新。