大佬们，帮我看看我这个情况适合用 RPC 吗？

[c0011]

服务器是 C++写的。卖的时候要把服务器部署到客户公司内部。比如卖到两个公司 A，B。然后 A 服务器下的客户端可能只在 A 服务器内部互相通信。也有可能在 A 上的客户端与在 B 上的客户端通信。

现在的问题是跨 A B 通讯的时候比较麻烦，都是异步操作。 比如 A 去问 B 服务器客户端 b 的状态，然后 B 服务器查询完 b 的状态再返回给 A。 A 收到 B 的返回信息再从 callbacks 里找到正确的 callback，进行调用。

像这种用 rpc 技术是最适合的方式吗？ 还有更好的方式吗？

先谢过了！

[BingoXuan]

当你通过网络调用其他机器的服务时候，其实就是一种 rpc

[0NF09LJPS51k57uH]

RPC 只是一种通讯方式，与 RPC 同等概念的还可以是你们自己封装的私有协议，以及 HTTP 等公用协议，你们这个场景我觉得用不用 RPC 不是关键，只是一种通讯方式而已，关键是保证通讯的可靠性。你们的产品是直接让客户间进行通信吗。。你们自己没有服务器吗？所有的流量都走到你们这边来啊，监控和运维都好办一点，哪端有异常都能及时发现。

[c0011]

@phantomzz 跨服务器的时候，客户端都是通过服务器收发数据的，不允许客户端直接通讯。还有跨服务器通讯的时候，发起方是主服务器。因为是跨服务器，主服务器需要通过次服务器来获取到次服务器上的客户端的状态。
----
主要还是想降低程序开发复杂度，自己设计协议需要很多异步操作，还需要保存很多 callback，感觉挺麻烦的。

[c0011]

@BingoXuan 那跨服务器通讯标准做法是什么样啊？

[robot1]

有一个 c++的协程框架 libgo,可以使用 go 风格的协程，解决掉了回调问题