This is an automated email from the ASF dual-hosted git repository.
shenlin pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/rocketmq-eventbridge.git
The following commit(s) were added to refs/heads/main by this push:
new 32cd445 Update RocketMQEventBridgeOverview
32cd445 is described below
commit 32cd44561657c288b984c36e6306981cee9f88ee
Author: RX-20231013JTRB\Administrator <1296853...@qq.com>
AuthorDate: Wed Nov 29 11:23:24 2023 +0800
Update RocketMQEventBridgeOverview
---
docs/cn/RocketMQEventBridgeOverview.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/cn/RocketMQEventBridgeOverview.md
b/docs/cn/RocketMQEventBridgeOverview.md
index 8575f37..c7b9aa5 100644
--- a/docs/cn/RocketMQEventBridgeOverview.md
+++ b/docs/cn/RocketMQEventBridgeOverview.md
@@ -72,7 +72,7 @@ B：半解耦方式
生产者将消息发送到消息服务，消费者订阅消息服务获取消息，并将消息解析成自己业务领域模型中需要的数据格式。这种方式做到了调用链路上的解耦，极大的降低了系统风险，但是对于消费者来说，依旧需要去理解和解析生产者的业务语义，将消息转换成自己业务领域内需要的格式。这种方式下，当消费者需要订阅多个生产者的数据的时候，需要用大量的胶水代码，为每一个生产者产生的消息做适配。另外，当上游生产者的消息格式发生变化时，也会存在风险和运维成本。
-B：完全解耦方式
+C：完全解耦方式
这种方式下，消费者不需要引入SDK订阅Broker，只需要按照自己的业务领域模型设计API，消息服务会将上游的事件，过滤并转换成API需要的事件格式。既没有调用链路上的依赖，也没有业务上的依赖。当上游生产者的事件数据格式发生变化时，消息服务会做兼容性校验，可以拒绝生产者发送事件或则进行告警。
@@ -86,7 +86,7 @@ B：完全解耦方式
### RocketMQ EventBridge 是如何工作的？
-为了解决上述两个应用场景中提到的问题，EventBridge从5个方便入手：
+为了解决上述两个应用场景中提到的问题，EventBridge从5个方面入手：
**第1. 确定事件标准：**
因为事件不是给自己看的，而是给所有人看的。它没有明确的消费者，所有都是潜在的消费者。所以，我们需要规范化事件的定义，让所有人都能看得懂，一目了然。目前CNCF旗下的CloudEvent,以逐渐成为广泛的事实标准，因此，我们选取了CloudEvent
作为我们的EventBridge的事件标准。
