Introduction: The “Dimensionality Reduction” of Communication Methods
Suppose you want to convey a message to a friend:
- Writing a Letter (HTTP) Clearly write the address, affix a stamp, and wait for the mailman to deliver it. The recipient opens the letter to read it.
- Making a Phone Call (RPC) Dial directly, and once connected, have an immediate conversation, hanging up after finishing.
HTTP is like “writing a letter,” emphasizing format standardization and universality; RPC is like “making a phone call,” pursuing quick direct communication. Both can achieve communication, but their efficiency, scenarios, and costs are vastly different—what does your business need?
Round One: Core Design Philosophy – General vs. Specialized
HTTP: The “Lingua Franca” of the Internet
- Positioning A universal protocol that is cross-platform and cross-language, born for the World Wide Web.
- Characteristics
- Based on text (such as JSON/XML), human-readable, and easy to debug.
- Relies on URL paths and HTTP methods (GET/POST/PUT/DELETE) to define operations.
- Naturally suited for communication between browsers and servers, such as webpage loading and mobile app interfaces.
For example🌰: When you order takeout, the app calls the merchant’s menu interface via an HTTP request:
GET https://api.restaurant.com/menu?shop_id=123
RPC: The “Dedicated Line” for Microservices
- Positioning High-performance, high-concurrency remote service calls, optimized for distributed systems.
- Characteristics
- Calls remote services as if calling local functions (Remote Procedure Call).
- Based on binary protocols (such as Protobuf, Thrift), with small transmission size and fast parsing.
- Relies on service registry centers (such as Nacos) for automatic node discovery, eliminating the need to manually stitch URLs.
For example🌰: The order service directly calls the inventory service’s deduction interface, as if calling a local method:
// Call remote service just like a local method!
boolean success = inventoryService.deductStock(productId, 100);
Round Two: The “Life-and-Death Speed” of Performance and Efficiency
HTTP’s “Four-Wheeled Carriage”
- Advantages
- Strong universality: Any device, language, or platform can understand HTTP.
- Complete ecosystem: Caching, proxies, CDNs, and browser support are all available.
- Disadvantages
- Redundant overhead Text-based protocols have large sizes, with each request carrying a lot of headers (like Cookie, User-Agent).
- Statelessness Multiple calls cannot share context, requiring additional tokens or session IDs to be passed.
RPC’s “Maglev Train”
- Advantages
- High performance Binary protocols reduce transmission size, with serialization speed improved by 5-10 times.
- Long connections Reuse TCP connections, avoiding the “three-way handshake” overhead of HTTP.
- Service governance Built-in circuit breaking, degradation, and load balancing (like Dubbo, gRPC).
- Disadvantages
- Cross-language support requires additional adaptation (like gRPC implementing multi-language through Protobuf).
- Not friendly to the front end, requiring a gateway (like Nginx) to expose HTTP interfaces.
Performance Comparison Experiment:
- Transmitting 10KB of data:
- HTTP/1.1 (JSON): About 15ms, bandwidth usage 13KB.
- RPC (Protobuf): About 5ms, bandwidth usage 8KB.
Round Three: Applicable Scenarios – Who Rules Their Domain?
HTTP’s “Home Court”
- Scenario 1: Exposing APIs Externally For example, open platform interfaces (WeChat Pay, Map API) that need to be compatible with various clients (browsers, apps, third-party systems).
- Scenario 2: Front-end and Back-end Separation The front end requests the back-end RESTful API via HTTP to obtain JSON data for rendering the page.
- Scenario 3: Simple Lightweight Services Rapid prototype development without complex service governance.
RPC’s “Battlefield”
- Scenario 1: Internal Calls in Microservices For example, the order service calls the inventory service, requiring low latency and high throughput (tens of thousands of calls per second).
- Scenario 2: High-Performance Computing Real-time data processing, financial trading systems, where saving 1ms of latency could yield millions in profit.
- Scenario 3: Complex Service Governance Requires advanced features like link tracing, circuit breaking, and gray releases.
Ultimate Comparison Table: One Image to End the Dilemma of Choice
| Dimension | HTTP/HTTPS | RPC (like gRPC/Dubbo) |
|---|---|---|
| Protocol Type | Text Protocol (JSON/XML) | Binary Protocol (Protobuf/Thrift) |
| Performance | Low (High Latency, Large Bandwidth) | High (Low Latency, Small Bandwidth) |
| Applicable Scenarios | Front-end and Back-end Interaction, Open APIs | Internal Microservice Calls, High-Performance Computing |
| Service Governance | Relies on Gateway (like Nginx) | Built-in (Load Balancing, Circuit Breaking, Degradation) |
| Cross-Language Support | Inherent Support | Requires Protocol Adaptation (like Protobuf) |
| Development Cost | Low (Simple and Easy to Use) | Medium to High (Requires Framework Integration) |
| Typical Frameworks | Spring Boot RESTful, Express | Dubbo, gRPC, Thrift |
How to Choose? Three Soul-Searching Questions!
-
Who are your users?
- For external use by browsers and mobile devices → HTTP.
- For internal service communication → RPC.
Are you willing to sacrifice universality for performance?
- Pursuing extreme performance → RPC.
- Pursuing rapid development and cross-platform compatibility → HTTP.
What is your team’s technology stack?
- Familiar with the Spring Cloud ecosystem → OpenFeign (based on HTTP).
- Familiar with Dubbo/gRPC → RPC Framework.
The hidden answer: Adults don’t make choices!
- Use HTTP for external communication, and RPC for internal communication, converting protocols through an API Gateway (like Kong, Spring Cloud Gateway).
Conclusion: Communication Has No Superior or Inferior, Only Suitability
HTTP and RPC are like “writing a letter” and “making a phone call”:
- Writing a Letter (HTTP) is suitable for formal, cross-platform, and traceable scenarios (like contracts, announcements).
- Making a Phone Call (RPC) is suitable for urgent, high-frequency, and private scenarios (like internal collaboration).
The essence of technology selection is “solving the right problem in the right way”—after all, no one would use a phone booth to send a love letter, right? 💌📞
Easter Egg: If you are still struggling, try gRPC! It is based on HTTP/2, retaining the high performance of RPC while being compatible with the universality of HTTP—like a “video call” balancing efficiency and expressiveness!