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 <[email protected]> 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:  -虽然每个微服务都在自己的事件通道上运行，但 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:  -## 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.  -运行工作流的步骤如下： +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: [email protected] For additional commands, e-mail: [email protected]
