Skip to content

Commit

Permalink
Merge pull request #1 from suopovate/suopovate-patch-1
Browse files Browse the repository at this point in the history 
update 02RocketMQEventBridgeOverview.md
  • Loading branch information
@supervate
supervate authored Oct 20, 2023
2 parents 2065ac8 + c9ccd6d commit 4463c6f
Showing 1 changed file with 7 additions and 7 deletions.
14 changes: 7 additions & 7 deletions versioned_docs/version-5.0/07-eventbridge/02RocketMQEventBridgeOverview.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ Event，则是明确已经发生的事情。比如

### 2、无期望
```text
事件是客观的描述一个事物的状态或属性值的变化，但对于如何处理事件本身并没有做任何期望。 相比之下，Command和Query则都是有期望的，他们希望系统做出改变或则返回结果，但是Event只是客观描述系统的一个变化。
事件是客观的描述一个事物的状态或属性值的变化，但对于如何处理事件本身并没有做任何期望。 相比之下，Command和Query则都是有期望的，他们希望系统做出改变或者返回结果，但是Event只是客观描述系统的一个变化。
```
举个例子： 交通信号灯，从绿灯变成黄灯，只是描述了一个客观事实，本身并没有客观期望。在不同国家地区，对这个事件赋予了不同的期望。 比如，在日本黄灯等于红灯，而在俄罗斯闯黄灯是被默许的。

Expand All @@ -62,7 +62,7 @@ Event，则是明确已经发生的事情。比如
对比我们常见的消息，因为上下游一般是确定的，常常为了性能和传输效率，则会做到尽可能的精简，只要满足“计划经济”指定安排的消费者需求即可。
## RocketMQ EventBridge 的典型应用场景
### 场景1：事件通知
微服务中，我们常常会遇到需要把一个微服务中生产的消息，通知给其他消费者。这里我们对比三种方式：
微服务中，我们常常会遇到需要把一个微服务中生产的消息，通知给其他消费者的场景。这里我们对比三种方式：

A：强依赖方式

Expand All @@ -74,7 +74,7 @@ B：半解耦方式

B：完全解耦方式

这种方式下，消费者不需要引入SDK订阅Broker，只需要按照自己的业务领域模型设计API，消息服务会将上游的事件，过滤并转换成API需要的事件格式。既没有调用链路上的依赖，也没有业务上的依赖。当上游生产者的事件数据格式发生变化时，消息服务会做兼容性校验，可以拒绝生产者发送事件或则进行告警。
这种方式下，消费者不需要引入SDK订阅Broker，只需要按照自己的业务领域模型设计API，消息服务会将上游的事件，过滤并转换成API需要的事件格式。既没有调用链路上的依赖，也没有业务上的依赖。当上游生产者的事件数据格式发生变化时，消息服务会做兼容性校验，可以拒绝生产者发送事件或者进行告警。


![image](../picture/07eventbridge/ThreeStages.png)
Expand All @@ -85,7 +85,7 @@ B：完全解耦方式
![image](../picture/07eventbridge/EventCenter.png)

## RocketMQ EventBridge 是如何工作的？
为了解决上述两个应用场景中提到的问题，EventBridge从5个方便入手：
为了解决上述两个应用场景中提到的问题，EventBridge从以下5个方面入手：

**第1. 确定事件标准：**
因为事件不是给自己看的，而是给所有人看的。它没有明确的消费者，所有都是潜在的消费者。所以，我们需要规范化事件的定义，让所有人都能看得懂，一目了然。目前CNCF旗下的CloudEvent,以逐渐成为广泛的事实标准，因此，我们选取了CloudEvent 作为我们的EventBridge的事件标准。
Expand All @@ -97,9 +97,9 @@ B：完全解耦方式
事件格式用来描述事件的具体内容。这相当于市场经济的一个买卖契约。生产者发送的事件格式是什么，得确定下来，不能总是变；消费者以什么格式接收事件也得确定下来，不然整个市场就乱套了。

**第4. 订阅"规则"：**
我们得给消费者一个，把投递事件到目标端的能力，并且投递前可以对事件进行过滤和转换，让它可以适配目标端API接收参数的格式，我们把这个过程叫做创建订阅规则。
我们得给消费者一个，把事件投递到目标端的能力，并且投递前可以对事件进行过滤和转换，让它可以适配目标端API接收参数的格式，我们把这个过程叫做创建订阅规则。

**第5. 事件总线：**
最后我们还得有一个存储事件的地方，就是最图中最中间的事件总线。
最后我们还得有一个存储事件的地方，就是下图中最中间的事件总线。

![image](../picture/07eventbridge/HowEventBridgeWork.png)
![image](../picture/07eventbridge/HowEventBridgeWork.png)

0 comments on commit 4463c6f

Please sign in to comment.