给算法岗擦屁股的人应该明白那种痛苦的感觉。为了解耦不同服务之间的程序，但又能像调用原生函数一样调用远程函数，我在过去写下了 rpc.py。用了一段时间之后，过年守岁的时候闲着没事花了一夜把 coverage 提高到了 100%，修了几个隐藏的小 bug，现在基本稳定。
当然在造轮子之前我了解和使用过 grpc，怎么说呢……用起来挺蛋疼的。注册很麻烦，调用很麻烦，和其它服务配合起来也很麻烦。于是研究了一下 grpc 的原理，自己写了一个。
由于是基于 ASGI/WSGI 这两个通用网关协议的，所以 HTTP 部分我就可以偷懒不处理了，用社区发展十几年的成果就行。你想用 HTTP/1.0 、1.1 还是 2.0，或者更激进点直接 3.0，都可以。Python 社区都有现成方案。
基于这两通用网关协议，还有一个好处就是可以方便的和现有的 Django 、Bottle 、Flask 、Starlette 、FastAPI 、Sanic 、CherryPy 、Responder 、IndexPy……总之你能想到的支持这两个协议中至少一种的任何 Web 框架集成。也就是说，鉴权之类的工作，都可以用现成的。自己独立弄一个是不存在的，如果可以，这辈子我都不想自己造轮子了。
序列化协议上是天然解耦的，目前只内置了 JSON 、pickle 和 msgpack，如果大家还有什么高性能序列化协议，可以提 PR 或者发个 Discussion 。当然，也可以只在自己代码里用，自己注册一个还是很方便的。
基于 Type hint，可以自动转换类型，客户端在调用的时候还会主动检查类型。当然你不用 Type hint 也是可以正常用的。基于 Type hint 生成文档，似乎新框架都自带这个了哈哈哈
https://github.com/abersheeran/rpc.py
最后，造这个轮子的主要原因就是之前某项目大概有上千个函数需要批量转成可远程调用的接口。历史包袱、历史包袱。
1
Select Language