Video học lập trình mỗi ngày

Câu hỏi này đề cập đến những lựa chọn cốt lõi của dự án có thể hơi hướng mở rộng kiến trúc phân tán thay vì đúng hơn là microservices, vì vậy hãy để tôi giải thích trước tiên.

Đừng để sự yêu ghét ở đây, có thể bạn hay sử dụng rest api và sẽ ghét ai đó nói về rpc hoặc ngược lại. Hai thằng này nó không phải là kẻ thù để mà loại trừ lẫn nhau mà sự khác biệt nằm ở tình huống và các yêu cầu cụ thể của công ty.

--

Trước tiên tôi muốn chỉ cho anh em xem hai thằng này nó nằm ở đâu trong kiến trúc mà tôi đã trình bày ở bài viết này: gRPC vs Rest API dùng khi nào? Ở đâu? Xem đồng nghiệp giải thích

Ở đó giải thích rất rõ về ranh giới của RPC. Và đó cũng là sự khác biệt giữa hai thằng http và rpc.

Khi nào sử dụng RPC?

Để trả lời nhanh thì đầu tiên RPC được sử dụng nhiều ở các dự án phức tạp tham gia ở nhiều bên điển hình là Microservices.

Lúc này đây các bên tham gia đều có một tiêu chí đó là CALL API với tần suất CAO, nhưng đòi hỏi là LATENCY phải thấp. Ham hố đúng không? Nhưng cũng không hẳn là không múc được chuyện đó, khi sử dụng RPC thì có thể khả thi ngoài ra TCP cũng là sự lựa chọn tốt trong tình huống này.

Tôi đã xây dựng một dự án Microservices giao tiếp các module với nhau dựa vào TCP, và nó giải quyết rất tốt các anh em có thể xem nó tại Series: Hành trình backend nestjs().

Vì vậy động lực cốt lõi của RPC có thể đáp ứng được chuyện này. Về lý thuyết mỗi request của http đều thiết lập 3 bước để connect TCP (Anh xem đọc thêm về 3 cái bắt tay này AI...). Ngay cả với Keep-Alive, các yêu cầu vẫn được xử lý tuần tự trên một kết nối duy nhất. Trong điều kiện xử lý đồng thời cao, hoặc một số lượng lớn kết nối được mở hoặc các yêu cầu được xếp vào hàng đợi. Đây chính là nguyên nhân làm chậm.

Vậy gRPC hoạt động ra sao? gRPC hoạt động trên HTTP/2, cho phép hàng trăm yêu cầu đồng thời trên một kết nối duy nhất. Giao thức RPC do chúng tôi tự phát triển, kết hợp với việc quản lý nhóm kết nối, tối đa hóa khả năng tái sử dụng kết nối.

Tôi đã tự mình kiểm tra một số dữ liệu với cùng một logic nghiệp vụ, so với RPC không sử dụng pool kết nối, độ trễ P99 giảm từ 10ms xuống 0.2ms mỗi lần thiết lập kết nối TCP mới, và QPS tăng gần 10 lần. Đây không phải là kỹ thuật gì quá ghê gớm mà chính là giảm chi phí của quá trình bắt tay của kết nối TPC mà thôi.

Anh xem có thể đọc bài viết thực hành chi tiết tại đây:

Cách sử dụng gRPC: Triển khai Order Service Go, Java! Độ trễ gần như KHÔNG CÓ | Từng bước...

Tất nhiên lý thuyết chỉ là bước đệm và quan trọng khi gặp được keyword này có gắng móc nó ra và tìm hiểu nó một cách chính xác nhất. Vì Để thực sự hiểu về RPC, bạn cần tự xây dựng một hệ thống tương tự như trên...

Có gì khó khăn trong việc lập trình cho bản thân hay công ty cứ nhắn nhé...