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和图片等静态资源和后台接口，因此对比单个业务接口，通过浏览器完成一个完整业务流程明显大大增加执行耗时和错误率。

puppeteer

  • 说明： 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技术的手段。