Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

关于 RPC 的通知机制

  用过好几套 RPC 协议,它们都带有通知机制。包括很早以前我自己设计的一套 RPC 协议也是这样。可是最近用着用着就发现,通知机制会虽然方便,但会把 RPC 的完整性破坏掉。本来「调用」这件事就应该是一个请求对应一个响应的,即便是通知也应该知道对方是否收到通知。
  RPC 调用一般会根据消息的 id 来关联请求和响应,而通知的概念就是不希望接收响应,所以可能不会带 id。可是我就越想越不对劲了,既然 RPC 是会定义错误的,为什么认为通知就一定不会出错?还是说通知的错误就算丢掉也没关系?
  也许有人会觉得,一个请求本身无法对应多个响应,为了解决这样的场景才引入通知机制。这是不对的!RPC 协议的双方是对等的,可以互相调用的。如果希望实现事件订阅之类的功能,可以让 A 端提供一个接收事件的接口,然后向 B 端发送订阅事件的请求。B 端收到订阅请求后,如果有事件发生就去调用 A 端事先定义好的事件接收接口。这样完全基于调用的方式同样可以实现这类功能。
  即使定义成通知,它也可能遇到一些传输级别的异常,比如传输超时等。也就是说,它依然可能异常,只不过接不到业务层的异常。这时候在程序中这个通知的描述方式就会变得很奇怪。比如我们用 Promise 对象来描述一次 RPC 调用的同步返回,那么这个 Promise 对象的 then 执行方向可能就只能描述「通知在传输层上成功发出」,而其他非通知方式的调用,无论有无返回值,then 执行方向至少都可以描述「对方在业务层上已经处理」。这便是它不一致的地方。
  其实通知类型的东西也是有用的,比如用于服务监控的埋点上。这种时候确实不需要知道是否成功,因为这并不重要。但这不属于业务层的东西,可以不走 RPC 的业务级别通信。比如直接给埋点接收服务器发送一个 UDP 包来实现。总之我还是觉得,业务级别的通信都应该是可靠的,不应该有通知这种东西。
网名:
54.156.92.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^