有了 HTTP，为什么还要推出 RPC？

RPC 和 HTTP 都是网络通信协议，但它们有以下区别

定义

• RPC 是一种客户端调用远程服务器上的函数或方法，并获得返回值的机制；
• HTTP 是一种应用层协议，广泛用于在 Web 浏览器和 Web 服务器之间交换数据

使用

• RPC 通常用于分布式系统中，系统内不同机器间的通信，而 HTTP 主要用于 Web 应用程序，基于客户端和服务器之间的请求和响应；
• RPC 通常使用二进制协议来传递数据，而 HTTP 使用文本协议（HTML、XML 或 JSON）来传递数据，字节大小和序列化耗时都更重

性能 & 监管

• 两者都常用于实现服务，RPC 服务主要工作在 TCP 协议之上（也可在 HTTP 协议），而 HTTP 服务工作在 HTTP 协议之上，所以 RPC 服务天然比 HTTP 服务更轻量，效率更高；
• RPC 是为高性能而设计的，所以速度比 HTTP 快，一个 RPC 系统需要更多的监管和管理工作，而 HTTP 系统的监管和管理工作相对较少

采用 RPC 和 HTTP 的选择主要考虑以下因素

通信类型

• RPC 通常用于不同机器之间的通信和远程服务调用；
• HTTP 适合于 Client/Server 之间的信息交互以及 Web Service 等应用领域

可扩展性

• RPC 通常更适合需要较高的性能、可靠性和可维护性的大规模应用程序；
• HTTP 则对于一些简单的系统，可以快速开发和与其他系统交互

数据传输

• RPC 使用的是自己的二进制数据协议，数据传输效率通常比 HTTP 高，但类型限制较多；
• HTTP 虽然传输效率较 RPC 低，但是在信息传递较自由的通信模型中，HTTP 更适合接收和传输 JSON、XML 和 HTML等不同类型的数据

RPC 和 HTTP 都是常用的通信协议，适用于不同的场景。通常，RPC 更适用于高性能、低延迟、数据量较小的场景，而 HTTP 更适用于分布式、可扩展、传输数据量较大的场景。

一般来说，RPC 适用于需要高性能、低延迟、高并发、安全的分布式系统，如互联网广告、金融支付、在线游戏等。而 HTTP 适合于需要灵活、兼容、易扩展的 Web 应用程序，例如电子商务、社交网络、博客网站等。

RPC 的使用场景

• 大型分布式系统，如数据挖掘、大数据处理等；
• 高并发的游戏、电商、社交网络等；
• 跨平台的 API 编程；
• 敏感数据传输，如财务、医疗、军事领域

HTTP 的使用场景

• Web 应用编程；
• 浏览器客户端与 Web 服务器的交互；
• 基于 REST 的 Web 服务；
• 嵌入式系统、物联网、移动设备等

需要注意的是，使用 RPC 和 HTTP 并没有对错之分，主要考虑场景及使用需求。如果对效率要求更高，并且开发过程使用统一的技术栈，那么 RPC 还是不错的；如果需要更加灵活，跨语言、跨平台，显然 HTTP 会更合适。这些只是一些常见的使用场景，实际情况会有所不同，还需要根据具体需求来选择适合的通信协议。

实际项目中的抉择

容器间或者微服务架构中，各个服务之间的通信可以使用 HTTP 或者 RPC 协议，具体取决于应用场景和需求。
使用 HTTP 协议时，可以采用 RESTful 风格的 API 设计，利用 HTTP 方法和状态码进行通信，可以通过简单、轻量的 JSON/XML 数据格式传输数据，易于调试和管理，适合于较为简单的业务场景。
而使用 RPC 协议时，通常需要使用 Protobuf、Thrift、gRPC 等序列化框架进行数据传输，能够实现更高效的远程通信，更好的性能优化和更多的扩展，更适合于复杂业务场景和高并发的应用。
在实际应用中，需要根据具体场景和需求进行选择。如果应用场景较为简单，RPC 统一的方式可能过于准确，反而会降低开发效率。如果应用场景比较复杂并且需要高效率，尤其是对于高性能、低延迟的场景，则选择 RPC 协议则相对更加合适。

gRPC 的简单示例

• https://github.com/k102817923/grpc_study