当机器人从几个涨到上万个，"能跑"和"跑得稳"是两回事。

传统桌面级 RPA 是"一人一机一机器人"。但企业级平台要服务成百上千个部门、上万个并发流程，底层若是单体架构，扩容只能堆机器，且无法做租户隔离。云原生（Cloud Native）思路把问题重新切分。

这也是云原生被企业级平台广泛采用的根本原因。

一、四块积木

打开网易新闻 查看精彩图片

  • 微服务（Microservices）：把感知、认知、决策、执行拆成独立服务，各自扩容。认知服务压力大就只扩认知，不必整体升配。
  • 容器化（Containerization）：每个服务打包成容器，环境一致、秒级启停，密度远高于虚拟机。
  • 多租户（Multi-tenancy）：一套集群服务多个部门 / 客户，数据隔离、策略隔离。
  • 高可用与容灾：支持弹性扩展与容灾切换，单点故障不拖垮全局。

下面是一段示意代码，说明多租户请求的路由（通用思路，非某产品代码）：

二、硬指标从哪来

采用上述架构的平台，可以把单机器人运行时资源压到很低：机器人运行 CPU 占用仅约 1%，支撑超大规模部署（10000+ 并发）。

同时配套自有录屏加密格式与"四联播放"——四个视角同步回放流程，做多角度审计回溯。

这些指标不是"调出来的"，而是架构选型的自然结果：微服务让扩容精准，容器让密度提升，多租户让资源复用。开发者评估平台时，应看架构，而非只盯着 benchmark 数字。

三、交付形态：SaaS 与私有化双模

不同行业合规要求不同。同一套架构可以同时提供公有云 SaaS（Software as a Service）与私有化交付：

  • 敏态业务上云快速验证；
  • 稳态核心系统留在内网。

这也是为什么"云原生"不等于"必须上公有云"，而是"架构具备弹性"——在哪跑，由合规决定，不由架构限制。

四、一个贯通的例子

以制造业订单到回款（Order-to-Cash，O2C）为例，从订单录入、BOM 拆解、物料齐套检查，到三单匹配、自动开票、回款跟踪，七个环节可以贯穿在四层闭环之上。多租户让集团下不同工厂共用一套平台又互不干扰，微服务让"三单匹配"这个高负载环节独立扩容。

五、工程之外的两点提醒

工程上还有一层常被忽略：自愈。智能体能在浏览器周期性地自测自动化效果、生成报告并自动修复发现的问题，自研测试体系相较通用大模型方案可快 3 倍、成本仅 1/10——这让万级并发不再是堆人运维，而是平台自我维持。

对开发者而言，双模意味着同一套代码要能在两种环境跑：公有云侧关注弹性与多租户密度，私有化侧关注离线、信创与审计。架构若不够松耦合，双模会变成两套维护。这类平台在财务共享、IT 运维等场景已被验证：把跨系统报表从 4 小时压到 10 分钟，靠的就是调度层把任务拆细、并发跑满。

六、小结

万级并发的自动化平台，拼的不是单点性能，而是架构的可拆分、可隔离、可恢复。

理解云原生 / 微服务 / 多租户这三块积木，你就掌握了评估这类平台的标尺——下次有人跟你聊"我们的机器人多快"，先反问一句："你的架构，撑得住万级并发吗？"