BẢN CHẤT CỦA RPC OVER HTTP: KHI CÁC HÀM GỌI NHAU XUYÊN TƯỜNG LỬA

1. Phá Vỡ Khái Niệm: RPC Là Gì? (The Core)

RPC (Remote Procedure Call) hay Gọi thủ tục từ xa, là một mô hình giao tiếp liên tiến trình (IPC).

Hãy tưởng tượng bạn đang code một logic tính phí vận chuyển. Bình thường, bạn viết một hàm calculateShippingFee() và gọi nó ngay trong cùng một tiến trình trên server. Nhưng khi hệ thống phình to, hàm tính phí này được tách ra thành một service riêng (ví dụ viết bằng Go) nằm trên một con server khác.

RPC giúp ứng dụng (ví dụ viết bằng Node.js) của bạn có thể gọi hàm calculateShippingFee() ở server Go kia giống hệt như đang gọi một hàm cục bộ, che giấu đi toàn bộ sự phức tạp của việc đóng gói dữ liệu, kết nối mạng và chờ luồng phản hồi. Bản chất của RPC là tập trung vào Hành động (Action/Verb), khác với REST tập trung vào Tài nguyên (Resource/Noun).

2. Tại Sao Lại Phải "Over HTTP"? (The Why)

Thời sơ khai, RPC chạy trực tiếp trên giao thức TCP/UDP với các port ngẫu nhiên hoặc port tùy chỉnh (ví dụ: port 135 của Microsoft RPC).

Nhưng ác mộng xảy ra khi triển khai lên Internet:

• Các hệ thống Tường lửa (Firewall), Proxy, hay Load Balancer của các công ty thường có nguyên tắc "Zero Trust": Đóng toàn bộ các port lạ và chỉ mở duy nhất Port 80 (HTTP) và Port 443 (HTTPS) để phục vụ web. Nếu bạn dùng RPC thuần, các gói tin sẽ bị tường lửa chặn đứng ngay ngoài cửa.

Giải pháp: Đi nhờ xe HTTP (Tunneling)

Để lách qua các khe cửa hẹp của tường lửa, các kỹ sư đã đóng gói (bọc) các gói tin RPC vào bên trong phần "Body" của một HTTP Request (thường là phương thức POST).

Hệ thống mạng nhìn vào thấy đây là gói tin HTTP đi qua port 443 nên vui vẻ mở cửa cho qua. Khi đến đích, Server sẽ lột bỏ lớp vỏ HTTP để lấy ra lệnh RPC bên trong và thực thi. Đó chính là RPC over HTTP.

3. Sự Lột Xác Trong Thế Giới Backend Hiện Đại

RPC over HTTP không phải là một công nghệ mới, mà nó đã trải qua 3 giai đoạn tiến hóa cực kỳ mạnh mẽ:

1. Thời kỳ đồ đá (XML-RPC & SOAP): Dữ liệu được bọc trong định dạng XML nặng nề, cồng kềnh. Giao thức này parse (giải mã) rất tốn CPU và băng thông.
2. Thời kỳ quá độ (JSON-RPC): Thay vì XML, Payload được chuyển sang định dạng JSON nhẹ nhàng hơn nhiều. Bạn gọi hàm bằng cách gửi một đoạn JSON như: {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}.
3. Kỷ nguyên tối thượng (gRPC over HTTP/2): Đây là chuẩn mực của các hệ thống Microservices hiện nay. Google đã tái sinh RPC bằng cách kết hợp Protobuf (nén dữ liệu thành nhị phân siêu nhỏ thay vì chuỗi Text như JSON) và HTTP/2 (hỗ trợ multiplexing - truyền nhiều luồng dữ liệu song song trên một kết nối duy nhất). Nhờ vậy, gRPC đạt tốc độ gọi hàm nhanh gấp 7 đến 10 lần so với RESTful API thông thường.

4. Khi Nào Nên Dùng RPC over HTTP Thay Vì REST?

Với tư cách là một kỹ sư hệ thống, Hiếu có thể cân nhắc sử dụng kiến trúc này trong các trường hợp sau:

• Giao tiếp nội bộ (Internal Microservices): Khi Service A (Node.js) cần nói chuyện với Service B (Golang) hàng triệu lần mỗi phút, dùng REST/JSON sẽ gây nghẽn băng thông và tốn CPU để parse chuỗi. Chuyển sang gRPC (RPC over HTTP/2) sẽ tối ưu hóa toàn bộ quá trình này.
• Bản chất nghiệp vụ phức tạp: Nếu nghiệp vụ của bạn không phải là các thao tác CRUD cơ bản (GET, POST, PUT, DELETE trên một đối tượng cụ thể), mà là các hành động trừu tượng như "Kích hoạt luồng hoàn tiền" hay "Gửi cảnh báo", việc dùng RPC (POST /RefundTransaction) sẽ phản ánh đúng bản chất kỹ thuật hơn là cố "gò ép" nó thành REST.

💡 Lời Kết

RPC over HTTP thực chất là sự kết hợp giữa triết lý gọi hàm siêu tốc của RPC và tính phổ quát, dễ dàng vượt tường lửa của HTTP. Việc hiểu sâu kiến trúc này — đặc biệt là sự tiến hóa lên gRPC — là chìa khóa để xây dựng những hệ thống Backend phân tán có khả năng chịu tải siêu việt trong tương lai.