[原创] 我让 Hermes 把古法 RPC 重新炼成了高并发调度平台：r0rpc 实战

RPC 没有死。
它只是从热闹处退到了角落里，继续替很多逆向、爬虫、自动化场景扛最硬的活。

这篇文章不打算写成一本说明书。
说明书讲“怎么用”，但我更想讲清楚另一件事：为什么在协议逆向越来越重、风控链路越来越长、真机环境越来越难复刻的今天，RPC 这种看起来有点“古法”的方案，反而还有生命力。
更重要的是，这次不是单纯拿 Sekiro 改一改，也不是写一个能转发请求的玩具 demo。
这次我让 Hermes 参与设计和实现了一套自己的 RPC 调度平台：r0rpc。
它有后台，有权限，有账号，有 group，有 action，有设备在线状态，有请求缓存，有成功率统计，有 WebSocket 长连接，有 Xposed demo，有 Python 模拟端，有性能压测脚本，也能一键部署。
一句话概括：

r0rpc 不是“把手机开个口子给外面调一下”。
它更像是把一批手机设备接进后端体系里，变成可管理、可观测、可压测、可扩展的 RPC 资源池。

而 Hermes 最让我震惊的地方也在这里：我不是让它补一个函数，不是让它写一段示例代码，而是把一个偏工程化、偏系统设计、偏实战落地的需求丢给它，它真的能把事情拆开、推进、验证，再持续修正。
这就很离谱。
先说结论
如果你只想看结论，可以直接看这一段。


对比项
早期 Sekiro 使用体验
r0rpc 当前实现


管理后台
没有完整后台界面，设备和 action 基本靠调用方自己记
有后台，可管理账号、group、action、设备


设备在线
不直观，在线状态排查成本高
后台能看在线设备，接口也能查 group 下在线设备


成功率统计
不方便沉淀
按设备、action、请求结果统计成功率


请求记录
不方便长期回看
请求参数和结果可缓存，默认按配置保留


group 管理
调用时比较自由，但容易乱
group 必须后台创建并启用，才能被 app 调用


高并发
中高并发下容易抖动
单设备压到 200-256 并发仍可用，两设备 200-400 并发更舒服


可观测性
弱
后台能看设备、请求、成功率、耗时


部署
自行组合
MySQL / Redis 可 Docker，也可接外部服务

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-291419.htm

6666 好文

大佬带带弟弟

好东西，感谢分享

tql