使用原生 asyncio 和 zeroMQ 编写的异步 rpc 库，现已支持代理节点的互通

[firejoke]

gate-rpc

一个月前写的一个异步 rpc 库
因为初衷就是为了优化一个使用中的分布式 NoSQL 软件而写的，所以在 rpc 调用没啥问题后，就开始写代理节点的互通，参考之前的 Client-Majordomo-Worker 的流程，新增了 GATE_COMMAND 一系列命令和处理 Majordomo 节点间的请求和回复。
节点间是使用的 ZeroMQ 的 ROUTE socket ，因为 ROUTE socket 的限制，所以在连接其他节点前需要先使用一个临时的 ZeroMQ REQ socket 打个招呼获取对方的 id ，然后才能使用自身的 ROUTE socket 连接上去。
下一步就是使用这个 rpc 库写一个分布式的 NoSQL 软件。

[lesismal]

我委婉点评价吧：用消息队列实现 RPC 真的是我见过的最差的设计之一了。。

[firejoke]

@lesismal 为什么呢？也许你没用过 ZeroMQ ？（接受不同意见，接受所有建议，感谢你浪费时间）

[L1shen]

zeromq 最好别看是一个消息队列吧，当成一个通信库看可能好一些

[firejoke]

@L1shen 是的，我就是当网络通信用的，他的文档里示例也是作为网络库最多

[lesismal]

对不起，#1 是我草率了，没了解过 zeromq 、以为是消息队列发布订阅的方式实现的 rpc ，如果只是用 zeromq 做网络库、那 ok ，我向 OP 道歉！

简单扫了下 gaterpc 代码，其他一点看法不知道是否准确，python 我不熟，如果不对请指正：
1. 一些地方用了 await asyncio.sleep(1)，例如 connect 相关的，connect 之后 await asyncio.sleep(1)，这个感觉应该根据实际的连接成功为好，固定等待这么久可能性能上不够友好了
2. 看到注释里有这么一段：
“客户端，TODO: 对于没有收到回复的请求记录并保存下来，可以设置重试次数来重新请求。”
不建议框架层自己做重试，因为 timeout 并不代表对方一定没收到，有可能对方收到了请求并进行了处理但连接异常、
回包没收到，因为框架层不知道应用层业务特点、无法保证幂等之类的，由用户在应用层自行处理重试可能会更好

[firejoke]

@lesismal connect 后的一个休眠是最近加的代理节点间的一个临时连接，因为用的是 REQ socket ，在异步处理时，需要先用 asyncio.sleep 让出当前运行时，临时连接用完后，使用节点间的 ROUTE socket 相互第一次连接，也需要使用 asyncio.sleep 让出运行时，用 sleep(0.1)或者用被特殊处理的 sleep(0)也行，这里当时测试用了 sleep(1)后没改，是个错误，谢谢！