微服务与事件驱动架构（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传递领域事件，触发读模型更新。