影刀RPA店群自动化系统演进：从单店脚本到企业级矩阵平台

影刀RPA店群自动化系统演进：从单店脚本到企业级矩阵平台

任何一套企业级系统都不是一蹴而就的。
我们这套影刀RPA店群自动化平台，从第一行代码上线到今天，经历了五次大的重构。
每次重构都不是因为之前的设计“错了”，而是业务体量上了一个台阶，原来的架构撑不住了。

这篇文章不讲某个具体模块的实现，而是以时间为轴，复盘整个系统的演进历程。
希望通过这个“过来人”的视角，帮你避开我们曾经踩过的坑，理解架构演进的节奏。

关键词：单体脚本、批处理框架、调度分离、服务化、平台化。

一、阶段一：单店脚本时代（0-10家店铺）

最早的需求很简单：把拼多多订单每天同步到自家ERP。
我们写了一个影刀RPA流程，手动点一下，跑一个店铺。
流程里写死了店铺的账号密码、订单页面的选择器、导出路径。
这个阶段谈不上架构。
代码就是一个.flow文件，逻辑全在影刀编辑器里。
运行方式：打开影刀客户端，选择流程，点击“运行”。

遇到的问题

店铺从1个变成3个，每个店铺要单独改流程里的账号配置。
手动运行三个流程，一个跑完再跑下一个，耗时很长。
运营白天要用电脑，RPA只能晚上跑，第二天早上来看结果。

当时的解法

我们把账号配置抽到了外部Excel文件，RPA流程启动时读取。
然后用Windows任务计划器，凌晨2点启动影刀命令行，依次执行三个店铺的流程。

# 简陋的批处理脚本youdao_cli run--flowsync_order.flow--paramshop001 youdao_cli run--flowsync_order.flow--paramshop002 youdao_cli run--flowsync_order.flow--paramshop003 ```**这个阶段的关键教训：配置和逻辑必须分离。** 哪怕只改一个店铺的账号，都不应该动流程文件。 ---## 二、阶段二：批处理框架（10-50家店铺）店铺数量到10家后，串行跑一晚上跑不完。 我们开始尝试并行：在虚拟机上开多个影刀客户端，同时跑不同店铺。 但手工管理十几个影刀窗口太混乱了。 **第一次工程化尝试：用Python调度多个RPA进程。**```python# simple_scheduler.pyimportsubprocess from concurrent.futuresimportThreadPoolExecutor shops=load_shops_from_db()with ThreadPoolExecutor(max_workers=5)as executor:forshopinshops: executor.submit(run_rpa_flow, shop)```同时引入了简单的日志：每个店铺的RPA输出重定向到独立文件。 页面元素定位器仍然硬编码在RPA流程里，但开始使用变量传入。### 遇到的问题多线程同时操作同一个指纹浏览器时，登录态互相干扰。 某些店铺的RPA流程卡死，导致整个线程池挂住。 没有重试机制，网络波动一次就失败，第二天人工重跑。 日志分散在几十个文件里，排查问题要一个个翻。### 当时的解法引入**进程隔离**：每个RPA任务用独立的浏览器实例，用完销毁。 加入**超时控制**：单个任务超过5分钟就kill子进程。 最简陋的**失败记录**：把失败的店铺ID写入一个文本文件，第二天手动重跑。 **这个阶段的关键教训：并发不是随便开几个线程就完事的，资源隔离和异常处理才是核心。** ---## 三、阶段三：调度与执行分离（50-200家店铺）店铺突破50家后，单机资源不够了。 我们开始使用多台服务器，每台跑一部分店铺。 但任务分配变成了新问题：手工把店铺列表分成几份，分别部署到不同机器，修改配置很麻烦。 **核心设计决策：引入中心调度器。** 调度器只负责任务分发，不执行RPA。执行节点从消息队列拉任务。 这个阶段我们正式采用了 **RabbitMQ + Redis** 的架构。 - RabbitMQ：存储待执行任务，支持优先级 - - Redis：记录店铺状态、任务结果、去重 - - 多个执行节点：每个节点运行消费者进程```python# 调度器伪代码def dispatch_task(shop_id, task_type): task={"shop_id":shop_id,"type":task_type,"created_at":now()}rabbitmq.publish("task_queue", task)redis.setex(f"task_status:{task['id']}",3600,"pending")```执行节点启动时注册到调度器，通过心跳保活。 调度器会检测节点心跳，超时未响应的节点上的任务会被重新分配。 **这个阶段我们还做了两件重要的事：**1. **浏览器实例池**：每个节点预先启动N个指纹浏览器，任务来了直接复用，减少启动开销。2.2. **任务重试与死信**：失败任务自动重试3次，仍失败则进入死信队列，人工介入。### 遇到的问题调度器本身成为单点。如果调度器挂了，整个系统瘫痪。 死信队列里的任务没人看，积压越来越多。 店铺的Profile（登录态）存储在节点本地，节点挂了，该节点上的店铺需要重新登录。### 当时的解法调度器做简单的主备：主节点挂掉，备节点接管（需要共享Redis和MQ状态，实际只解决了进程级故障，没解决网络分区）。 死信队列加了一个简单的Web页面，运营可以查看、重试。 店铺Profile开始做NFS共享存储，多个节点可访问同一份Profile。 **这个阶段的关键教训：中心化调度带来了便利，也引入了新的单点。高可用要从第一天就考虑。** ---## 四、阶段四：服务化与平台化（200-500家店铺）店铺到200家后，业务需求也复杂起来。 不仅仅是订单同步，还有商品上架、批量改价、自动回复、竞品监控等十几个任务类型。 每个任务类型的调度策略不同：有的需要实时（自动回复），有的可以延迟（报表导出）。 **核心设计决策：从“任务队列”升级为“任务编排引擎”。** 我们引入了工作流定义：一个业务场景（比如“上架新商品”）可能包含多个步骤：登录→上传图片→填写属性→提交审核→通知运营。 这些步骤需要按顺序执行，中间某步失败要能回滚或重试。 我们设计了一套**DSL（领域特定语言）**来描述工作流。```yaml name: product_upload steps: - action: login - - action: upload_images - retry:2- - action: fill_attributes - - action: submit - on_failure: notify_ops -```编排引擎解析YAML，调用对应的RPA原子动作。 **这个阶段还做了：** - **多租户与权限**：不同运营团队只能看到自己的店铺，操作需审批。 - - **API网关**：对外提供REST API，允许其他系统触发RPA任务（例如ERP下单后自动同步库存）。 - - **定时与触发**：支持cron表达式定时任务，也支持webhook触发。 - - **可视化监控大盘**：实时展示各节点负载、任务成功率、店铺健康度。### 遇到的问题RPA流程越来越多，版本管理混乱。改了某个流程，忘了通知所有人，导致线上跑的还是旧版本。 店铺Profile在NFS上，性能越来越差，NFS服务器成为新瓶颈。 测试成为大问题：修改一个通用动作，需要回归测试所有依赖它的工作流。### 当时的解法引入**流程版本管理**：每个RPA流程有版本号，任务执行时指定版本。支持灰度发布（先让10%店铺用新版本）。 放弃NFS，改用**节点亲和性 + 异步复制**。每个店铺固定在某节点上，节点间通过rsync同步Profile（延迟可接受）。 建立**回归测试流水线**：每次代码合并自动触发测试套件，模拟核心流程。 **这个阶段的关键教训：当系统复杂度上升到一定程度，流程版本、测试、发布规范比代码本身更重要。** ---## 五、阶段五：智能化与自适应（500+店铺）到了500家店铺，人工配置已经跟不上变化了。 平台页面经常改版，每次改版都需要运维手动去更新几十个流程的定位器。 代理IP池里总有坏IP，手工剔除很慢。 不同店铺的负载不均，有些节点忙死，有些闲死。 **核心设计决策：引入“控制平面”和智能决策。** 我们开始做： - **自愈能力**：系统自动检测页面变化（对比DOM指纹），发现变化后尝试用AI推荐新的选择器（基于页面语义）。 - - **动态负载均衡**：调度器根据各节点的实时CPU/内存/队列长度，动态调整任务分配权重。 - - **智能代理池**：代理IP被平台封禁时，自动标记并更换，同时分析被封特征（如某个IP段被封概率高），提前规避。 - - **行为异常检测**：通过历史数据训练模型，预测哪些店铺可能即将被风控，提前触发静默续期或降低操作频率。```python# 简单的自适应调度def get_node_weight(node): cpu=node.cpu_percent mem=node.mem_percent queue=node.queue_length# 负载越高，权重越低weight=(100- cpu)*0.4+(100- mem)*0.3+ max(0,100- queue *2)*0.3returnmax(0, weight)```### 遇到的问题智能化增加了系统复杂性。AI推荐的选择器有时不准，导致任务失败。 动态负载均衡在节点间频繁迁移任务，Profile跨节点访问又变慢。 异常检测模型误报，把正常店铺也降权了。### 当前的解法智能功能都以“建议”模式运行，最终决策仍由人工确认（或配置白名单）。 负载均衡优先考虑节点亲和性，只在节点负载严重不均时才迁移。 异常检测设定了置信度阈值，只有高置信度才自动执行。 **这个阶段的关键教训：智能化要渐进，不能为了“智能”而牺牲稳定性。人工确认机制永远要保留。** ---## 六、架构演进的通用规律回顾这五个阶段，我发现了一些普遍规律： **1. 配置外置**：从硬编码到配置文件，再到配置中心，变化最早发生。 **2. 状态分离**：无状态的计算节点和有状态的存储（Profile、队列）必须分离，才能水平扩展。 **3. 异步解耦**：从同步调用到消息队列，是吞吐量提升的关键转折点。 **4. 可观测先行**：没有日志、指标、追踪，系统越复杂越难维护。 **5. 自动化测试**：手动回归测试在规模面前毫无意义。 **6. 优雅降级**：不是所有功能都要保证100%可用，核心链路优先。 ---## 七、给后来者的建议如果你正在从头搭建店群自动化系统，我的建议是： **不要急着做“大平台”。** 先从10个店铺开始，跑通一个完整闭环。 然后扩展到30个店铺，你自然会遇到并发问题。 解决并发后再到100个，你会需要调度分离。 再到300个，你会需要服务化和编排。 每一步的痛点会自然推动架构演进。 超前设计往往带来不必要的复杂度。 **但有三件事可以从第一天就做：** - 结构化日志（JSON格式） - - 配置与代码分离 - - 核心操作的幂等设计 这三件事成本很低，但后期改造成本极高。 ---## 八、写在最后从单店脚本到支持500+店铺的矩阵平台，我们走了三年。 每次重构都伴随着阵痛，但也让系统更加健壮。 这篇文章没有贴大段代码，而是想传达一种演进式的工程思维。 **系统不是设计出来的，是长出来的。** 希望我们的经验能让你在合适的阶段做合适的事，少走弯路。 --- 作者：林焱