2022-12-22-【工程化】RPA方案
项目 RPA 方案
一、 RPA 技术
RPA(Robotic Process Automation)是指在各行业中使用软件自动化来实现原本由人类操作的计算机完成的操作。它允许软件机器人自动处理大量重复的、基于规则的工作流程任务。
流行 RPA 产品和技术有 Uipath、阿里云 RPA、Robot Framework、RPA For Python、Selenuim、Puppeteer、Playwright 等。不同产品技术各自发力点有所不同,其中 Uipath、阿里云 RPA 和 Robot Framework 着重于 web 自动化、移动端自动化、windows 自动化等办公、测试场景,而这类 RPA 产品技术覆盖场景范围较广,在 web 自动化场景做的没有太深入。RPA For Python、Selenuim、Puppeteer、Playwright 这类技术工具专注于 web 自动化场景,因此技术选型重点考虑这类技术工具。
(1)技术选型
| 技术工具 | RPA For Python | Selenuim | Puppeteer | Playwright |
|---|---|---|---|---|
| 浏览器适配 | Chrome | Chrome/FireFox/Safari 等 | Chrome | Chrome/FireFox/Safari 等 |
| 开发语言 | Python | Python、Java、JS 等 | JS | Python、Java、JS 等 |
| 运行性能 | 较优 | 一般 | 较优 | 较优 |
| 消耗资源 | 一般 | 一般 | 较优 | 较优 |
| headless 支持 | 不支持 | 支持(新版本) | 支持 | 支持 |
| 安装配置 | 复杂 | 复杂 | 较简单 | 较简单 |
| 跨平台支持 | 不涉及 | 不支持 | 不涉及 | 支持 |
| 文档 | 健全 | 健全 | 健全 | 健全 |
| 上下文功能 | 没有 | 没有 | 支持 | 支持,增强上下文隔离能力 |
| 代码自动生成 | 不支持 | 支持 | 支持 | 支持 |
| 自动等待 | 支持 | 支持 | 支持 | 支持 |
| 事件订阅 | 不支持 | 不支持 | 支持 | 支持 |
| 上传下载 | 支持 | 不支持 | 不支持 | 支持 |
- 说明:从浏览器适配、开发语言、跨平台支持、上下文功能等指标对比来,技术选型更加偏向 Playwright。
(2)实现原理

- 说明:
1、Chrome DevTools Protocol(CDP)允许三方程序对基于 Chrome 等浏览器的 web 应用进行检测、检查、调试和分析等,通过 WebSocket 建立连接 DevTools 和浏览器内核的快速数据通道。而 webdriver 方式是通过各类浏览器 driver 提供基于 CDP 一套封装方法来完成浏览器操作。
2、DevTools Protocol 直接连接浏览器方式由于少了一层 driver 调用,因此相对于 Webdriver 性能更优。
3、本质仍需要启动浏览器实例来加载页面,而一个页面涉及多个 css、js 和图片等静态资源和后台接口,因此对比单个业务接口,通过浏览器完成一个完整业务流程明显大大增加执行耗时和错误率。

- 说明:
1、Puppeteer 和 Playwright 类技术可以创建多个 Browser 实例,其中 BrowerContext 是类似无痕浏览器窗口。
2、Playwright 增强了上下文隔离能力,支持清除 cookies 和本地存储操作,可进一步重复利用 BrowerContext,提升执行效率。
(3)Playwright 技术验证
依据管理业务和后续优化思路进行的关键事项验证,已完成如下事项验证:
1、登录自动化(包括拖拽条,短信验证)
2、页面表单提交自动化(项目信息维护)
3、代码生成辅助工具(可生成大部分代码,但需要再调试)
4、弹窗处理自动化(解决不稳定、不确定的弹窗问题)
5、页面元素获取(认证二维码获取)
6、Chrome headless 模式(不需要界面 gui 渲染,性能更优)
7、事件订阅(授权完成后接口正常响应)
8、浏览器上下会会话信息存储和加载、隔离
9、容器部署
进一步验证:
1、验证单个容器实例(如 2 核 4g)能够同时加载多少个浏览器实例,计算出需投入部署资源。
macbook 验证效果:在 headless 模式下,一个 browser 大约消耗 200M 内存,一个 browserContext 大约消耗 100M 内存,因此基于一个 browser 和 N 个 browserContext 启动模式,那么 1g 内存大约可以打开 8 个无痕窗口。
二、RPA 方案设计
2.1 接口异步响应

- 说明:
1、管理平台登录需要短信验证码,因此建议提供可视化交互。
2、登录会话定期续期有可能失败,因此建议提供微乐站内信、短信等通知方式。
3、项目业务异步执行,规避耗时长问题,但有几率执行失败(登录会话续期失败、页面资源加载等原因),因此业务任务需要支持重试、不重复消费。
4、建议提供业务任务管理功能,供用户查看和手动重启任务。并且若出现业务自动化过程需要用户进行二维码扫码等操作也可以在页面提供用户操作。
5、基于 Playwright 的上下会管理能力,管理平台的会话信息可以离线存储,不需要浏览器页面进程长驻,并且可支持 RPA 服务多实例部署。
主要解决问题:
1、RPA 耗时长、接口超时问题;
2、浏览器资源瓶颈问题;
3、会话过期问题;
2.2 资源池化

- 说明:
1、池化是指预先准备部分资源,在需要时可以重复利用这部分资源,提高 RPA 执行效率,减低系统资源消耗,并且控制资源对象数量,保证程序稳定正常运行。
2、缩短 RPA 执行流程,提升自动化效率。
2.3 插件化

- 说明:
1、由于多实例服务和容器部署的原因,服务需要定期调用数据库来更新实例信息,用于标记已运行实例。例如每 10 秒更新一次实例记录的更新时间,若 10 秒内没有更新时间则认为该实例为下线实例。
2、插件安装也采用同上逻辑,定期获取插件信息来更新实例的插件安装情况,若完成安装,则更新实例插件记录(多个插件更新操作可考虑逐个更新,更新失败重试)。
三、其他
3.1 工作量评估
预估工作量如下:
1、RPA 业务和流程产品侧梳理–产品 2 人天
2、开发(pf4j 类似 java 插件化技术)—-开发 2 人
3、接口异步响应和资源池化的深化技术设计–开发 3 人天
4、资源池化开发–开发 3 人天
5、接口异步响应(不包含项目业务的 RPA 流程)开发–开发 5 人天
6、接口和功能测试–测试 5 人天
3.2 风险和问题
1、暂时没有考虑防范 RPA 手段,但目前也没有找到能够 CDP 技术的手段。