You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@eventmesh.apache.org by ch...@apache.org on 2023/01/30 06:44:02 UTC

[incubator-eventmesh] branch revert-2959-patch-1 created (now 66ca90237)

This is an automated email from the ASF dual-hosted git repository.

chenguangsheng pushed a change to branch revert-2959-patch-1
in repository https://gitbox.apache.org/repos/asf/incubator-eventmesh.git


      at 66ca90237 Revert "Update 01-workflow.md"

This branch includes the following new commits:

     new 66ca90237 Revert "Update 01-workflow.md"

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@eventmesh.apache.org
For additional commands, e-mail: commits-help@eventmesh.apache.org


[incubator-eventmesh] 01/01: Revert "Update 01-workflow.md"

Posted by ch...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

chenguangsheng pushed a commit to branch revert-2959-patch-1
in repository https://gitbox.apache.org/repos/asf/incubator-eventmesh.git

commit 66ca9023719217e6082481240f5574c175a3f7c1
Author: Eason Chen <qq...@gmail.com>
AuthorDate: Mon Jan 30 14:43:58 2023 +0800

    Revert "Update 01-workflow.md"
---
 docs/en/design-document/01-workflow.md | 359 +++++++++++++++++----------------
 1 file changed, 181 insertions(+), 178 deletions(-)

diff --git a/docs/en/design-document/01-workflow.md b/docs/en/design-document/01-workflow.md
index 549e48a4f..fecae1ee6 100644
--- a/docs/en/design-document/01-workflow.md
+++ b/docs/en/design-document/01-workflow.md
@@ -1,258 +1,261 @@
-#事件网格工作流程
+# EventMesh Workflow
 
-## 业务问题
-假设您正在为电子商务商店构建一个简单的订单管理系统。 该系统应该能够接收和提供来自商店网站的新订单。 供应流程应该能够处理所有订单、处理付款以及处理发货。
+## Business Problem
 
-为了实现高可用性和高性能,您使用事件驱动架构 (EDA) 构建系统,并构建微服务应用程序来处理商店前端、订单管理、支付处理和发货管理。 您将整个系统部署在云环境中。 为了处理高工作负载,您可以利用消息传递系统来缓冲负载,并扩展多个微服务实例。 该架构可能类似于:
+Imaging you are building a simple Order Management System for an E-Commerce Store. The system should be able to receive and provision new orders from a store website. The provisioning process should be able to process all orders, handle payments, as well as process shipments.
+
+For high availability and high performance, you architect the system using event-driven architecture (EDA), and build microservice apps to handle store frontend, order management, payment processing, and shipment management. You deploy the whole system in a cloud environment. To handle high workloads, you leverage a messaging system to buffer the loads, and scale up multiple instances of microservices. The architecture could look similar to:
 
 ![Workflow Use Case](../../images/design-document/workflow-use-case.jpg)
 
-虽然每个微服务都在自己的事件通道上运行,但 EventMesh 在进行事件编排方面起着至关重要的作用。
+While each microservice is acting on its own event channels, EventMesh plays a crucial role of doing Event Orchestration.
 
 We use [CNCF Serverless Workflow](https://serverlessworkflow.io/) to describe this Event Workflow Orchestration.
 
-## CNCF 无服务器工作流
+## CNCF Serverless Workflow
 
-CNCF Serverless Workflow 定义了一个供应商中立、开源且完全由社区驱动的生态系统,用于定义和运行面向 Serverless 技术领域的基于 DSL 的工作流。
+CNCF Serverless Workflow defines a vendor-neutral, open-source, and fully community-driven ecosystem for defining and running DSL-based workflows that target the Serverless technology domain.
 
-无服务器工作流定义了一种领域特定语言 (DSL) 来描述无状态和无状态基于工作流的无服务器功能和微服务编排。
+Serverless Workflow defines a Domain Specific Language (DSL) to describe stateful and stateless workflow-based orchestrations of serverless functions and microservices.
 
 More details could be found in its [official github site](https://github.com/serverlessworkflow/specification)
 
-## 事件网格工作流程
+## EventMesh Workflow
+
+We leverage Serverless Workflow DSL to describe the EventMesh workflow. Based on its spec, the workflow is consists of a series of workflow states used to describe the control-flow logic. At this time we only support event related workflow states. See the supported states in [Workflow DSL Design](#workflow-dsl-design-wip).
 
-我们利用无服务器工作流 DSL 来描述 EventMesh 工作流。 根据其规范,工作流由一系列用于描述控制流逻辑的工作流状态组成。 目前我们只支持与事件相关的工作流状态。 请参阅 [工作流 DSL 设计](#workflow-dsl-design-wip) 中的支持状态。
+A `workflow state` can include applicable `actions`, or services/functions that should be invoked during workflow execution. These `actions` can reference reusable `function` definitions which define how these functions/services should be invoked. They can also reference events that trigger event-based service invocations, and events to wait for that denote completion of such event-based service invocation completion.
 
-“工作流状态”可以包括适用的“操作”,或应在工作流执行期间调用的服务/功能。 这些“动作”可以引用可重用的“功能”定义,这些定义定义了这些功能/服务应该如何被调用。 它们还可以引用触发基于事件的服务调用的事件,以及等待表示此类基于事件的服务调用完成的事件。
 In EDA solution, we usually defined our event-driven microservice using AsyncAPI. Serverless workflow `function` definitions support defining invocation semantics using AsyncAPI. See [Using Funtions for AsyncAPI Service](https://github.com/serverlessworkflow/specification/blob/main/specification.md#using-functions-for-async-api-service-invocations) for more information.
 
-### 异步API
+### AsyncAPI
 
-AsyncAPI 是一项开源计划,旨在改善事件驱动架构 (EDA) 的当前状态。
-我们的长期目标是让使用 EDA 就像使用 REST API 一样简单。
-从文档到代码生成,从发现到事件管理。
-您现在应用于 REST API 的大多数流程也适用于您的事件驱动/异步 API。
+AsyncAPI is an open source initiative that seeks to improve the current state of Event-Driven Architectures (EDA).
+Our long-term goal is to make working with EDAs as easy as it is to work with REST APIs.
+That goes from documentation to code generation, discovery to event management.
+Most of the processes you apply to your REST APIs nowadays would be applicable to your event-driven/asynchronous APIs too.
 
 See AsyncAPI detail in the [official site](https://www.asyncapi.com/docs/getting-started)
 
-### 工作流程示例
+### Workflow Example
 
-在这个例子中,我们构建了上面订单管理系统的事件驱动工作流。
+In this example, we build the event-driven workflow of the Order management system above.
 
-首先,我们需要为我们的微服务应用程序定义 AsyncAPI 定义。
+First, we need to define AsyncAPI definitions for our microservice apps.
 
-- 在线商店应用
+- Online Store App
 
 ```yaml
-异步API:2.2.0
-信息:
-   标题:在线商店应用程序
-   版本:'0.1.0'
-渠道:
-   商店/订单:
-     订阅:
-       operationId:newStoreOrder
-       信息:
-         $ref : '#/组件/新订单'
+asyncapi: 2.2.0
+info:
+  title: Online Store application
+  version: '0.1.0'
+channels:
+  store/order:
+    subscribe:
+      operationId: newStoreOrder
+      message:
+        $ref : '#/components/NewOrder'
 
 ```
 
-- 订购服务
+- Order Service
 
 ```yaml
-异步API:2.2.0
-信息:
-   title: 订单服务
-   版本:'0.1.0'
-渠道:
-   订单/入库:
-     发布:
-       operationId:发送订单
-       信息:
-         $ref : '#/组件/订单'
-   订单/出站:
-     订阅:
-       operationId: processedOrder
-       信息:
-         $ref : '#/组件/订单'
+asyncapi: 2.2.0
+info:
+  title: Order Service
+  version: '0.1.0'
+channels:
+  order/inbound:
+    publish:
+      operationId: sendOrder
+      message:
+        $ref : '#/components/Order'
+  order/outbound:
+    subscribe:
+      operationId: processedOrder
+      message:
+        $ref : '#/components/Order'
 ```
 
-- 支付服务
+- Payment Service
 
 ```yaml
-异步API:2.2.0
-信息:
-   title: 支付服务
-   版本:'0.1.0'
-渠道:
-   付款/入站:
-     发布:
-       operationId:发送付款
-       信息:
-         $ref : '#/组件/OrderPayment'
-   支付/出站:
-     订阅:
-       operationId:付款收据
-       信息:
-         $ref : '#/组件/OrderPayment'
+asyncapi: 2.2.0
+info:
+  title: Payment Service
+  version: '0.1.0'
+channels:
+  payment/inbound:
+    publish:
+      operationId: sendPayment
+      message:
+        $ref : '#/components/OrderPayment'
+  payment/outbound:
+    subscribe:
+      operationId: paymentReceipt
+      message:
+        $ref : '#/components/OrderPayment'
 ```
 
-- 寄件服务
+- Shipment Service
 
 ```yaml
-异步API:2.2.0
-信息:
-   title: 运输服务
-   版本:'0.1.0'
-渠道:
-   装运/入境:
-     发布:
-       operationId:sendShipment
-       信息:
-         $ref : '#/组件/OrderShipment'
+asyncapi: 2.2.0
+info:
+  title: Shipment Service
+  version: '0.1.0'
+channels:
+  shipment/inbound:
+    publish:
+      operationId: sendShipment
+      message:
+        $ref : '#/components/OrderShipment'
 ```
 
-定义完成后,我们将定义描述订单管理业务逻辑的订单工作流。
+Once that is defined, we define the order workflow that describes our Order Management business logic.
 
 ```yaml
 id: storeorderworkflow
-版本:'1.0'
-规格版本:'0.8'
-名称:商店订单管理工作流
-状态:
-   - 名称:接收新订单事件
-     类型:事件
-     关于事件:
-       - 事件参考:
-           - 新订单事件
-         动作:
-           - 事件参考:
-               triggerEventRef:OrderServiceSendEvent
-               resultEventRef:OrderServiceResultEvent
-           - 事件参考:
-               triggerEventRef:PaymentServiceSendEvent
-               resultEventRef:PaymentServiceResultEvent
-     过渡:检查付款状态
-   - 名称:检查付款状态
-     类型:开关
-     数据条件:
-       - 姓名:支付成功
-         条件:“${.payment.status =='成功'}”
-         过渡:发送订单发货
-       - 名称:付款被拒绝
-         条件:“${.payment.status =='拒绝'}”
-         结束:真
-     默认条件:
-       结束:真
-   - 名称:发送订单发货
-     类型:操作
-     动作:
-       - 事件参考:
-           triggerEventRef:ShipmentServiceSendEvent
-     结束:真
-事件:
-   - 名称:NewOrderEvent
-     来源:文件://onlineStoreApp.yaml#newStoreOrder
-     类型:asyncapi
-     种类:消费
-   - 名称:OrderServiceSendEvent
-     来源:文件://orderService.yaml#sendOrder
-     类型:asyncapi
-     种类:生产
-   - 名称:OrderServiceResultEvent
-     来源:文件://orderService.yaml#processedOrder
-     类型:asyncapi
-     种类:消费
-   - 名称:PaymentServiceSendEvent
-     来源:文件://paymentService.yaml#sendPayment
-     类型:asyncapi
-     种类:生产
-   - 名称:PaymentServiceResultEvent
-     来源:文件://paymentService.yaml#paymentReceipt
-     类型:asyncapi
-     种类:消费
-   - 名称:ShipmentServiceSendEvent
-     来源:文件://shipmentService.yaml#sendShipment
-     类型:asyncapi
-     种类:生产
+version: '1.0'
+specVersion: '0.8'
+name: Store Order Management Workflow
+states:
+  - name: Receive New Order Event
+    type: event
+    onEvents:
+      - eventRefs:
+          - NewOrderEvent
+        actions:
+          - eventRef:
+              triggerEventRef: OrderServiceSendEvent
+              resultEventRef: OrderServiceResultEvent
+          - eventRef:
+              triggerEventRef: PaymentServiceSendEvent
+              resultEventRef: PaymentServiceResultEvent
+    transition: Check Payment Status
+  - name: Check Payment Status
+    type: switch
+    dataConditions:
+      - name: Payment Successfull
+        condition: "${ .payment.status == 'success' }"
+        transition: Send Order Shipment
+      - name: Payment Denied
+        condition: "${ .payment.status == 'denied' }"
+        end: true
+    defaultCondition:
+      end: true
+  - name: Send Order Shipment
+    type: operation
+    actions:
+      - eventRef:
+          triggerEventRef: ShipmentServiceSendEvent
+    end: true
+events:
+  - name: NewOrderEvent
+    source: file://onlineStoreApp.yaml#newStoreOrder
+    type: asyncapi
+    kind: consumed
+  - name: OrderServiceSendEvent
+    source: file://orderService.yaml#sendOrder
+    type: asyncapi
+    kind: produced
+  - name: OrderServiceResultEvent
+    source: file://orderService.yaml#processedOrder
+    type: asyncapi
+    kind: consumed
+  - name: PaymentServiceSendEvent
+    source: file://paymentService.yaml#sendPayment
+    type: asyncapi
+    kind: produced
+  - name: PaymentServiceResultEvent
+    source: file://paymentService.yaml#paymentReceipt
+    type: asyncapi
+    kind: consumed
+  - name: ShipmentServiceSendEvent
+    source: file://shipmentService.yaml#sendShipment
+    type: asyncapi
+    kind: produced
 ```
 
-对应的工作流程图如下:
+The corresponding workflow diagram is the following:
 
 ![Workflow Diagram](../../images/design-document/workflow-diagram.png)
 
-## EventMesh 工作流引擎
+## EventMesh Workflow Engine
 
-在下面的架构图中,EventMesh Catalog、EventMesh Workflow Engine 和 EventMesh Runtime 运行在三个不同的处理器中。
+In the following architecture diagram, the EventMesh Catalog, EventMesh Workflow Engine and EventMesh Runtime are running in three different processors.
 
 ![Workflow Architecture](../../images/design-document/workflow-architecture.jpg)
 
-运行工作流的步骤如下:
+The steps running the workflow is the followings:
+
+1. Deploy the Publisher and Subscriber Apps in the environment.
+   Describe the App APIs using AsyncAPI, generate the asyncAPI yaml.
+   Register the Publisher and Subscriber Apps in EventMesh Catalog using AsyncAPI.
 
-1. 在环境中部署发布者和订阅者应用程序。
-    使用 AsyncAPI 描述 App API,生成 asyncAPI yaml。
-    使用 AsyncAPI 在 EventMesh 目录中注册发布者和订阅者应用程序。
+2. Register the Serverless Workflow DSL in EventMesh Workflow Engine.
 
-2. 在 EventMesh Workflow Engine 中注册 Serverless Workflow DSL。
+3. EventMesh Workflow Engine query the EventMesh Catalog for Publisher and Subscribers required in Workflow DSL `function`
 
-3. EventMesh Workflow Engine查询EventMesh Catalog for Publisher和Subscribers在Workflow DSL`function`中需要
+4. Event-driven Apps are publish events to EventMesh Runtime to trigger the Workflow. EventMesh Workflow Engine also publish and subscribe events for orchestrating the events.
 
-4. 事件驱动的应用程序是将事件发布到 EventMesh Runtime 以触发工作流。 EventMesh Workflow Engine 还发布和订阅事件以编排事件。
+### EventMesh Catalog Design
 
-### EventMesh目录设计
+EventMesh Catalog store the Publisher, Subscriber and Channel metadata. consists of the following modules:
 
-EventMesh Catalog 存储发布者、订阅者和频道元数据。 由以下模块组成:
+- AsyncAPI Parser
 
-- 异步 API 解析器
+  Using the SDK provided by AsyncAPI community (see [tool list](https://www.asyncapi.com/docs/community/tooling)),
+  parse and validated the AsyncAPI yaml inputs, and generate the AsyncAPI definition.
 
-使用AsyncAPI社区提供的SDK(参见[工具列表](https://www.asyncapi.com/docs/community/tooling)),
-   解析并验证 AsyncAPI yaml 输入,并生成 AsyncAPI 定义。
-- 发布者、频道、订阅者模块
+- Publisher, Channel, Subscriber Modules
 
-   从 AsyncAPI 定义存储发布者、订阅者和频道信息。
+  From the AsyncAPI definition store the Publisher, Subscriber and Channel information.
 
-### EventMesh 工作流引擎设计
+### EventMesh Workflow Engine Design
 
-EventMesh 工作流引擎由以下模块组成:
+EventMesh Workflow Engine consists of the following modules:
 
-- 工作流解析器
+- Workflow Parser
 
-   使用 Serverless Workflow 社区提供的 SDK(参见支持的 [SDKs](https://github.com/serverlessworkflow/specification#sdks)),
-   解析和验证工作流 DSL 输入,并生成工作流定义。
+  Using the SDK provided by Serverless Workflow community (see supported [SDKs](https://github.com/serverlessworkflow/specification#sdks)),
+  parse and validated the workflow DSL inputs, and generate workflow definition.
 
-- 工作流模块
+- Workflow Module
 
-   它管理一个工作流实例生命周期,从创建、开始、停止到销毁。
+  It manages a workflow instance life cycle, from create, start, stop to destroy.
 
-- 状态模块
+- State Module
 
-   它管理工作流状态生命周期。 我们支持事件相关的状态,下面支持的状态列表是 Work-in-Progress。
+  It manages workflow state life cycle. We support the event-related states, and the supported state list below is Work-in-Progress.
 
-   | 工作流状态 | 说明 |
-   | --- | --- |
-   | 操作 | 执行 Actions | 中定义的 AsyncAPI 函数
-   | 活动 | 检查定义的事件是否匹配,如果匹配则执行定义的 AsyncAPI 函数 |
-   | 切换 | 检查事件是否与事件条件匹配,并执行定义的 AsyncAPI 函数 |
-   | 并行 | 并行执行定义的 AsyncAPI 函数 |
-   | 为每个 | 迭代 inputCollection 并执行定义的 AsyncAPI 函数 |
+  | Workflow State | Description |
+  | --- | --- |
+  | Operation | Execute the AsyncAPI functions defined in the Actions |
+  | Event | Check if the defined Event matched, if so execute the defined AsyncAPI functions |
+  | Switch | Check the event is matched with the event-conditions, and execute teh defined AsyncAPI functions |
+  | Parallel | Execute the defined AsyncAPI functions in parallel |
+  | ForEach | Iterate the inputCollection and execute the defined AsyncAPI functions |
 
-- 动作模块
+- Action Module
 
-   它管理动作中的函数。
+  It managed the functions inside the action.
 
-- 功能模块
+- Function Module
 
-   它通过在 EventMesh Runtime 中创建发布者和/或订阅者来管理 AsyncAPI 函数,并管理发布者/订阅者的生命周期。
+  It manages the AsyncAPI functions by creating the publisher and/or subscriber in EventMesh Runtime, and manage the publisher/subscriber life cycle.
 
-     | AsyncAPI 操作 | EventMesh 运行时 |
-     | --- | --- |
-     | 发布 | 出版商 |
-     | 订阅 | 订户 |
+    | AsyncAPI Operation | EventMesh Runtime |
+    | --- | --- |
+    |  Publish | Publisher |
+    | Subscribe | Subscriber |
 
-- 事件模块
+- Event Module
 
-   它使用工作流 DSL 中定义的规则管理 CloudEvents 数据模型,包括事件过滤器、关联和转换。
+  It manages the CloudEvents data model, including event filter, correlation and transformation using the rules defined in the workflow DSL.
 
-- 重试模块
+- Retry Module
 
-   它管理事件发布到 EventMesh Runtime 的重试逻辑。
+  It manages the retry logic of the event publishing into EventMesh Runtime.


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@eventmesh.apache.org
For additional commands, e-mail: commits-help@eventmesh.apache.org