In the choice of HTTP and RPC, some people may be confused, mainly because some RPC frameworks are complicated to configure. If you can use HTTP to achieve the same function, then why choose RPC instead of HTTP, which is easier to get started. Up.
This article mainly explains the similarities and differences between HTTP and RPC, making it easier for everyone to choose a more suitable solution based on their actual situation.
- Transfer Protocol
- RPC, can be based on TCP protocol or HTTP protocol
- HTTP, based on HTTP protocol
-
Transmission efficiency
- RPC, using a custom TCP protocol, can make the request message volume smaller, or using the HTTP2 protocol, it can also reduce the message volume and improve transmission efficiency
- HTTP, if it is based on the HTTP1.1 protocol, the request will contain a lot of useless content. If it is based on HTTP2.0, the simple package below can be used as an RPC. At this time, the standard RPC framework is more Service governance
-
Performance consumption, mainly due to the time-consuming serialization and deserialization
- RPC, can realize efficient binary transmission based on thrift
- HTTP, most of which is implemented through json, byte size and serialization time-consuming are more performance-consuming than thrift
-
Load balancing
- RPC, basically comes with a load balancing strategy
- HTTP, need to configure Nginx, HAProxy to achieve
-
Service governance (how to not affect upstream callers when downstream services are added, restarted, and offline)
- RPC can be automatically notified without affecting upstream
- HTTP requires prior notice to modify the Nginx/HAProxy configuration
Summary:
RPC is mainly used for service calls within the company, with low performance consumption, high transmission efficiency and convenient service management. HTTP is mainly used for external heterogeneous environments, browser interface calls, APP interface calls, third-party interface calls, etc.
Link: https://www.jianshu.com/p/b61695e6b473