当前位置：首页 > news >正文

【架构演进】RPA 只能手动点运行？手把手教你引入“事件驱动”机制，打通 ERP 自动化的全闭环流水线

news 2026/4/14 4:55:54

背景引入：RPA 自动化的“半自动”困境

在深入参与了多个电商团队的数字化转型后，我发现业界对 RPA（机器人流程自动化）的使用普遍停留在“任务级”，而非“系统级”。

最典型的业务场景是：运营人员利用第三方工具从 1688 导出一份 Excel，手动清理一下格式，然后打开 RPA 软件，导入表格，点击“开始运行”，接着看着 RPA 在妙手 ERP 里一行行录入数据。

这种被称为**“有人值守（Attended）”或“定时调度”**的模式，存在一个致命的逻辑断层：它依然高度依赖人工来作为流水线的“启动器”和“数据搬运工”。只要负责导表的员工今天请假了，整个自动化流水线就会停摆。

如何让自动化系统拥有真正的“自主意识”，实现全链路的无人值守？本文将结合我近期重构的一套“妙手 ERP 全自动上架底座”，分享如何将后端开发中经典的**“事件驱动架构（EDA）”与“消息队列（MQ）”**引入 UI 自动化领域。

一、架构重构：从“轮询与人工触发”到“事件驱动（EDA）”

在传统的 RPA 脚本中，程序通常是“死”的。要让它活起来，我们需要引入生产者-消费者模型（Producer-Consumer Model），彻底解耦“数据获取”与“页面执行”。

我们为这套系统设计了以下三层架构：

1. 生产者层（Event Producer - 敏捷探针）

使用 Python 编写分布式的轻量级探针（如基于aiohttp或DrissionPage的监听脚本）。这些探针 7x24 小时运行在云端，专门负责“监听”外部事件：

上游断网监控：监听竞品店铺的上新动作，一旦发现爆款，立即触发抓取。
内部系统 Webhook：当公司的自有选品系统（或进销存系统）中，某批商品的状态被标记为“审核通过，准许上架”时，系统自动发送一个 HTTP POST 请求（Webhook）。

2. 消息代理层（Message Broker - 缓冲池）

探针获取到数据后，不直接调用 RPA，而是将包含商品完整信息的 JSON Payload 推送到一个中间件（如Redis List或RabbitMQ）中。

这一步极其关键。它起到了削峰填谷的作用。即使上游在 1 分钟内推送了 1000 个上架任务，系统也不会崩溃，任务会被安全地存放在队列中。

3. 消费者层（Event Consumer - RPA Worker）

这是真正执行交互的 RPA 引擎。我们将其改造成了一个常驻后台的守护进程（Daemon Process）。它利用长轮询（Long Polling）或 Pub/Sub 机制，持续监听 Redis 队列。

二、核心代码逻辑与 Worker 消费机制

下面是一段简化后的 Python 中台与 RPA 引擎交互的伪代码逻辑，展示了 Worker 是如何“吃”掉队列中的任务并执行 ERP 填表的：

Python

import redis import json import time # 连接到 Redis 消息队列 r = redis.Redis(host='localhost', port=6379, db=0) QUEUE_NAME = "miaoshou_upload_tasks" def rpa_worker(): print("RPA 守护进程已启动，正在监听上架任务队列...") while True: # 阻塞式读取队列（BLPOP），没有任务时进程休眠，不消耗 CPU task_data = r.blpop(QUEUE_NAME, timeout=0) if task_data: try: # 解析 JSON 任务流 payload = json.loads(task_data[1].decode('utf-8')) sku_id = payload.get("sku_id") print(f"[{time.strftime('%H:%M:%S')}] 接收到事件触发，开始处理 SKU: {sku_id}") # ------ 核心业务逻辑 ------ # 调用底层的 RPA 驱动，在妙手 ERP 前端执行 UI 自动化填表 execute_miaoshou_ui_automation(payload) print(f"SKU: {sku_id} 上架成功，流水线流转完毕。") except Exception as e: print(f"处理任务失败: {e}，将错误写入死信队列(DLQ)") # 将失败任务推入 Dead Letter Queue 供人工复核 r.lpush("miaoshou_dlq", task_data[1])

三、引入事件驱动架构（EDA）的业务价值

当我们把 UI 自动化升级为这样的事件驱动架构后，业务形态发生了质的飞跃：

极度敏捷的响应：“发现爆款 -> 数据清洗 -> 压入队列 -> 唤醒 RPA 上架”，整个过程可以在 5 秒内闭环。您的店铺永远比同行先一步铺上最新款。
横向扩容（Scale-Out）能力极强：如果队列里积压了 5000 个任务，单台机器来不及跑怎么办？只需要在局域网内多开几台电脑，运行相同的 RPA Worker 脚本。它们会自动“抢占式”地从同一个 Redis 队列里取任务。无缝实现了多机并发的分布式自动化集群。
系统级解耦，无痛迭代：妙手 ERP 的前端页面改版了？没关系，生产者和队列完全不用动，只需要微调消费者（RPA）的点击逻辑即可。极大地降低了代码的维护耦合度。
RPA店群开发，不再担心一台电脑运行不了几个账号！