在使用了几种不同的消息传递和RPC系统后，我得出的结论是，您最终总是需要某种传统的RPC、和推送事件。否则，你不可避免地会遇到一些投票黑客。
例如，HTTP最初只支持RPC风格的方法（GET和POST立即返回响应）。人们意识到推送事件是必要的，所以使用长时间的民意调查对其进行了黑客攻击。最终，服务器发送的事件解决了这一问题。
CoAP（基于UDP的HTTP的轻量级版本）还通过向GET请求添加"monitor"选项来支持推送事件。这是一个非常优雅的解决方案。
但这两种都不是Thrift风格的RPC，我的意思是编写一个接口定义文件，并且有一些工具可以将该接口编译为您选择的语言的本地代码。此后，您可以调用远程过程，就好像它们是本地过程一样。
所以我的问题是，有没有Thrift风格的RPC系统可以让你订阅推送事件，并在事件到达时调用回调（或类似的）？
是：
- gRPC支持"流式传输"，这意味着单个逻辑RPC调用实际上可以在每个方向上涉及多个消息
- Cap‘n Proto支持对象功能，允许连接的任何一方向另一方发送对象引用，可以对其进行调用。例如，客户端可以调用服务器上的方法，并作为方法参数之一提供回调对象。回调对象实现了一些预定义的RPC接口。当服务器调用回调对象时，它正在对客户端进行回调。事实上，Cap‘n Proto连接是完全对称的：在协议级别，客户端和服务器之间没有区别
（披露：我是Cap‘n Proto的作者，也是Protocol Buffers v2的作者，尽管我不隶属于gRPC。）