Thiết kế Microservices: Giao tiếp qua gRPC vs REST API – Đánh giá hiệu năng và độ phức tạp

Điểm nghẽn khi các Microservices gọi nhau bằng REST/JSON#

Khi tách một hệ thống nguyên khối (Monolith) thành 20 Microservices, lưu lượng mạng giao tiếp nội bộ giữa các dịch vụ (East-West Traffic) tăng lên gấp nhiều lần.

Nếu sử dụng REST API truyền thống:

• Dữ liệu dạng JSON là chuỗi văn bản (text-based), kích thước cồng kềnh.
• Chi phí parse/stringify JSON tiêu tốn rất nhiều chu kỳ CPU.
• Mỗi request HTTP/1.1 phải mở kết nối TCP mới hoặc bị nghẽn Head-of-line blocking.

gRPC (phát triển bởi Google) sử dụng Protocol Buffers (Protobuf) và chạy trên nền HTTP/2 là giải pháp tối ưu cho bài toán này.

Định nghĩa Contract chuẩn với Protobuf#

syntax = "proto3";
package user;

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

message UserRequest {
  int64 user_id = 1;
}

message UserResponse {
  int64 user_id = 1;
  string full_name = 2;
  string email = 3;
  repeated string roles = 4;
}

Kết quả đo lường hiệu năng thực tế#

Kiến trúc đề xuất: "Bên ngoài REST, bên trong gRPC"#

• API Gateway đối ngoại: Tiếp nhận request từ Web/Mobile bằng REST/JSON để thân thiện với trình duyệt.
• Giao tiếp nội bộ giữa các Service: 100% dùng gRPC để tối đa hóa tốc độ và giảm thiểu độ trễ mạng.

Góc thảo luận#

Team bạn có đang ứng dụng gRPC trong hệ thống không? Khâu chia sẻ file .proto giữa các repository được quản lý như thế nào?

Xem thêm nội dung liên quan:

• Học Thiết kế Microservices Thực chiến
• Bộ đề trắc nghiệm System Design