Auto-sync: update nexus workspace
This commit is contained in:
@@ -1,108 +1,49 @@
|
||||
---
|
||||
title: "Event-Driven Architecture"
|
||||
type: concept
|
||||
tags:
|
||||
- Architecture
|
||||
- Event-Driven
|
||||
- Serverless
|
||||
- AWS
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
- public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091
|
||||
- public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Event-Driven Architecture（事件驱动架构）是一种软件设计范式，在该模式下，系统组件通过产生和消费事件（Event）进行异步通信，而非通过直接的函数调用或请求-响应模式。事件是系统中发生的重要动作或状态变化的声明式通知，事件消费者无需知道事件产生者的存在。
|
||||
|
||||
## Core Principles
|
||||
|
||||
| 原则 | 描述 |
|
||||
|------|------|
|
||||
| 异步通信 | 生产者和消费者解耦，无需同步等待响应 |
|
||||
| 事件声明 | 事件代表"发生了什么"，而非"该做什么" |
|
||||
| 松耦合 | 生产者和消费者之间无直接依赖 |
|
||||
| 可扩展 | 新增消费者无需修改生产者代码 |
|
||||
|
||||
## Event Anatomy
|
||||
|
||||
典型事件包含：
|
||||
|
||||
```json
|
||||
{
|
||||
"event_id": "uuid",
|
||||
"event_type": "ORDER_CREATED",
|
||||
"source": "order-service",
|
||||
"timestamp": "2026-04-14T10:00:00Z",
|
||||
"data": { /* 业务相关数据 */ }
|
||||
}
|
||||
```
|
||||
|
||||
## AWS Event-Driven Stack
|
||||
|
||||
| 组件 | 角色 | 说明 |
|
||||
|------|------|------|
|
||||
| [[Amazon-EventBridge]] | 事件总线 | 接收、过滤、路由事件到目标 |
|
||||
| [[AWS-Lambda]] | 事件消费者 | 响应事件执行处理逻辑 |
|
||||
| [[Amazon-SNS]] | 事件发布/订阅 | 一对多广播消息 |
|
||||
| [[Amazon-SQS]] | 事件队列 | 可靠的事件持久化和顺序处理 |
|
||||
| [[Amazon-DynamoDB]] | 事件源 | DynamoDB Streams 触发 Lambda |
|
||||
| [[Amazon-S3]] | 事件源 | S3 事件通知触发 Lambda |
|
||||
|
||||
## Serverless 中的事件驱动
|
||||
|
||||
[[AWS-Lambda]] 是事件驱动架构的核心执行单元：
|
||||
|
||||
- **事件即触发器**：Lambda 函数不主动运行，由事件触发
|
||||
- **事件源映射**：Lambda 轮询 Kinesis、DynamoDB Stream、SQS 获取事件
|
||||
- **状态变化即事件**：S3 对象上传、API Gateway 请求、DynamoDB 写入等均为事件
|
||||
|
||||
## Event Patterns
|
||||
## EDA 三组件与事件代理类型
|
||||
|
||||
| 组件 | 角色 | 说明 |
|
||||
|------|------|------|
|
||||
| 事件生产者（Producer） | 产生事件 | 服务检测到状态变化时发布事件 |
|
||||
| 事件消费者（Consumer） | 消费事件 | 订阅并处理事件，执行对应业务逻辑 |
|
||||
| 事件代理（Broker） | 路由/存储 | 分事件路由器和事件存储两类 |
|
||||
|
||||
**事件路由器（Event Routers）**——按规则过滤事件并路由到正确消费者：
|
||||
- [[Amazon-EventBridge]]：更丰富，支持 Schema 注册、跨服务触发
|
||||
- [[Amazon-SNS]]：一对多广播（Fan-out）
|
||||
|
||||
**事件存储（Event Stores）**——流式持久化事件，消费者自行过滤：
|
||||
- [[Amazon-SQS]]：标准队列（乱序/高性能）/ FIFO 队列（有序/Exactly-Once）
|
||||
- [[Kinesis-Data-Streams]]：有序事件流，支持重放
|
||||
|
||||
## 编排模式：Choreography vs Orchestration
|
||||
|
||||
| 模式 | 特点 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| Choreography（编排） | 各微服务自主通信，无中央协调者 | 简单、独立的跨服务交互 |
|
||||
| Orchestration（编排） | 中央协调者（如 [[AWS-Step-Functions]]）控制工作流步骤 | 复杂业务流程、需要事务保障 |
|
||||
|
||||
## 生产级最佳实践
|
||||
|
||||
1. **幂等性（Idempotency）**：同一操作执行一次或多次产生相同结果。[[AWS-Lambda]] 异步调用会自动重试，因此幂等性是处理重复消息的关键——尤其适用于订单、支付等场景。
|
||||
|
||||
2. **事件排序**：
|
||||
- **有序**：SQS FIFO 或 Kinesis Data Streams
|
||||
- **乱序可接受**：标准 SQS 或 EventBridge（消费者自行处理乱序）
|
||||
|
||||
3. **团队独立性**：采用去中心化所有权，平台团队提供基础设防（Cloud CoE），消费者团队自主按需消费事件。
|
||||
|
||||
## Event Patterns
|
||||
1. **Pub/Sub**：SNS 主题广播，多消费者订阅同一事件类型
|
||||
2. **Event Streaming**：Kinesis/DynamoDB Stream 持久化事件流，支持重放
|
||||
3. **Fan-Out**：SNS 主题或 EventBridge 规则将事件分发到多个消费者
|
||||
4. **Competing Consumer**：同一消息同一时间只有一个消费者处理（SQS）
|
||||
5. **Dead-Letter Queue（DLQ）**：处理失败事件，防止消息丢失
|
||||
6. **Saga Pattern**：通过事件序列协调分布式事务
|
||||
7. **Event Sourcing**：完整记录所有状态变化事件作为唯一真相来源
|
||||
|
||||
## Connections
|
||||
- [[Event-Driven-Architecture]] ← is_execution_model_of ← [[Serverless-Computing]]
|
||||
- [[Event-Driven-Architecture]] ← uses ← [[Amazon-EventBridge]]
|
||||
- [[Event-Driven-Architecture]] ← executed_by ← [[AWS-Lambda]]
|
||||
---
|
||||
title: "Event-Driven Architecture"
|
||||
type: concept
|
||||
tags:
|
||||
- EDA
|
||||
- Architecture
|
||||
- Cloud
|
||||
- Microservices
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- EDA
|
||||
- Event Driven Architecture
|
||||
- 事件驱动架构
|
||||
|
||||
## Definition
|
||||
事件驱动架构（EDA）是一种软件架构范式，通过在松耦合的生产者（Producer）和消费者（Consumer）之间传递事件（Event）来实现系统解耦。事件是状态变化或更新的通知，触发异步处理和响应。
|
||||
|
||||
## Core Components
|
||||
- **Event Producer**：事件的产生者，感知状态变化并发布事件
|
||||
- **Event Consumer**：事件的订阅者和处理者，响应事件执行相应逻辑
|
||||
- **Event Broker**：事件的中介路由器，负责分发和传递事件
|
||||
|
||||
## Event Broker Types
|
||||
- **Event Router**（事件路由器）：过滤并路由事件到正确的消费者（SNS / EventBridge）
|
||||
- **Event Store**（事件存储）：流式存储事件，消费者自行过滤所需事件（SQS / Kinesis）
|
||||
|
||||
## Key Design Principles
|
||||
- **Decoupling**：生产者和消费者完全解耦，独立演进
|
||||
- **Scalability**：各组件可独立扩展
|
||||
- **Resilience**：局部故障不影响整体系统
|
||||
- **Idempotency**：幂等性保证异步重试不产生副作用
|
||||
|
||||
## Best Practices
|
||||
- 稀疏事件（sparse events）适合频繁变化的数据，但消费者可能需要额外查询详情
|
||||
- 完整状态事件（full state）包含更多细节，但受 EventBridge 负载大小限制
|
||||
- 事件排序需使用 SQS FIFO 或 Kinesis Data Streams
|
||||
- EventBridge 最佳实践：每个订阅者使用单一规则、避免为自定义事件使用默认事件总线、使用死信队列处理失败事件
|
||||
|
||||
## Related Messaging Patterns
|
||||
- [[Fan-Out-Pattern]]：扇出模式
|
||||
- [[Competing-Consumer-Pattern]]：竞争消费者模式
|
||||
- [[Choreography]]：编舞模式
|
||||
- [[Orchestration]]：编排模式
|
||||
|
||||
## Sources
|
||||
- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]
|
||||
- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
|
||||
|
||||
Reference in New Issue
Block a user