微服务与事件驱动架构（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传递领域事件，触发读模子更新。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]