Kịch bản
Ngày nay, nhiều hệ thống được phân phối, nghĩa là chúng bao gồm nhiều thành phần (hoặc dịch vụ siêu nhỏ) trên các máy khác nhau. Điều này đặt ra một câu hỏi: làm thế nào để các thành phần này giao tiếp với nhau? Ví dụ, làm thế nào một lớp trong hệ thống B có thể giao tiếp với một dịch vụ trong hệ thống D? Lúc đầu, tôi coi việc sử dụng các yêu cầu HTTP là một giải pháp phổ biến, nhưng sau đó tôi nhận ra rằng phương pháp này sẽ không hoạt động nếu không có trình duyệt. Đó là khi tôi phát hiện ra Gọi thủ tục từ xa như một giải pháp khác. Và đây chỉ là “ghi chú” khi tôi tìm hiểu về gRPC.
Thư viện khách hàng
Nếu chúng tôi đang phát triển phía máy khách, chúng tôi không cần phải lo lắng về cách thức hoạt động của thư viện máy khách (thư viện SOAP hoặc thư viện máy khách HTTP), cách chúng có thể thiết lập kết nối để giao tiếp hoặc phương thức giao tiếp là gì, chẳng hạn như đơn hướng hoặc hai chiều? Tất cả những điều này được quản lý bởi trình duyệt đằng sau hậu trường:
- Thiết lập kết nối với máy chủ.
- Quyết định sử dụng giao thức nào bằng Thỏa thuận Giao thức Tầng Ứng dụng.
- Mã hóa dữ liệu bằng SSL (Lớp cổng bảo mật) hoặc TLS (Bảo mật lớp truyền tải), mà bạn có thể biết bằng biểu tượng khóa trên trang web của mình hoặc giao thức HTTPS.
- Kiểm tra phiên bản HTTP mà máy chủ hỗ trợ và sử dụng phiên bản phù hợp. Do đó, về phía khách hàng, chúng tôi chỉ cần “tìm nạp” và nhận được phản hồi được định dạng đẹp mắt. Vì vậy, điều gì sẽ xảy ra nếu không có trình duyệt?
Bạn phải có một thư viện ứng dụng khách, chẳng hạn như thư viện SOAP hoặc thư viện ứng dụng khách HTTP hiểu được giao thức bạn sử dụng, điều đó có nghĩa là bạn phụ thuộc vào ứng dụng khách HTTP của bên thứ ba và có ai đó đang duy trì ứng dụng khách đó cho bạn. Nhưng điều gì sẽ xảy ra nếu thư viện máy khách của bạn chỉ hỗ trợ HTTP/1.1 và người quản lý của bạn muốn cập nhật hệ thống để sử dụng HTTP/2.0 nhằm tận dụng các tính năng của nó? Giờ đây, bạn chỉ có thể loại bỏ người quản lý của mình hoặc thay đổi thư viện ứng dụng khách hoặc tự mình thực hiện chức năng.
gRPC
Đầu tiên, bất cứ khi nào chúng tôi tạo bất kỳ giao thức mới nào, chúng tôi phải phát triển và duy trì thư viện máy khách cho mọi ngôn ngữ mà chúng tôi muốn hỗ trợ. gRPC do Google phát triển, hỗ trợ các ngôn ngữ lập trình phổ biến nhất như C#, C++, Go, Java, Python, v.v.
Thứ hai, gRPC sử dụng HTTP/2, cho phép kết nối có độ trễ thấp hơn và chúng tôi có thể tận dụng lợi thế của một kết nối duy nhất từ máy khách đến máy chủ (được mô tả trong HTTP/2 có thể giúp sử dụng kết nối hiệu quả hơn và sử dụng hiệu quả hơn tài nguyên máy chủ), cũng như đây là cách triển khai ẩn, Google chỉ làm việc đó cho bạn. Ví dụ: khi gRPC chuyển sang sử dụng HTTP/3, bạn không cần lo lắng về ứng dụng của mình, nó chỉ hoạt động bình thường.
HTTP/2 cũng hỗ trợ kết nối hai chiều và kết nối không đồng bộ, sau đó máy chủ có thể truyền tin nhắn với máy khách (phản hồi/thông báo không đồng bộ, v.v.).
Thứ ba, gRPC sử dụng định dạng thông báo không phụ thuộc vào ngôn ngữ là bộ đệm giao thức. Vì vậy, bất kể ngôn ngữ của máy chủ và máy khách của bạn là gì, chúng có thể giao tiếp thông qua bộ đệm giao thức nơi bạn biên dịch tệp proto thành định dạng nhị phân và khi bạn nhận được tệp nhị phân trên máy khách, bạn sẽ giải tuần tự hóa nó thành ngôn ngữ máy khách của mình.
ngôn ngữ bất khả tri
Chúng ta có thể quen với định dạng payload là JSON trong REST API, nhưng trong gRPC, nó là các bộ đệm giao thức (Protobufs).
Protobuf là một định dạng dữ liệu không phụ thuộc vào ngôn ngữ được sử dụng để tuần tự hóa dữ liệu có cấu trúc. Dưới đây là các bước cơ bản để làm việc với nó:
- Xác định dữ liệu trong tệp proto
- Biên dịch sang bất kỳ ngôn ngữ nào chúng tôi sử dụng
- Sử dụng tệp đã biên dịch để tạo đối tượng Protobuf được tuần tự hóa
Vậy tại sao chúng ta cần sử dụng Protobufs trên JSON?
Protobuf được tạo ra không chỉ là một định dạng tin nhắn, nó còn là một bộ quy tắc và công cụ để xác định và trao đổi tin nhắn.
Protobuf nhanh hơn JSON, vì chúng ở định dạng nhị phân nhỏ gọn hơn. (Có rất nhiều điểm chuẩn hiệu suất giữa JSON và Protobufs)
chế độ gRPC
RPC đơn nguyên: Đây là chu trình yêu cầu-phản hồi đồng bộ điển hình trong đó máy khách đưa ra yêu cầu tới máy chủ và sau đó chờ nhận phản hồi từ máy chủ.
RPC phát trực tuyến của máy chủ: Khi máy khách đưa ra một yêu cầu duy nhất tới máy chủ nhưng mong đợi nhiều phản hồi (một luồng phản hồi) từ máy chủ. Ví dụ: một nền tảng phát trực tuyến video, chúng tôi thực hiện một yêu cầu duy nhất tới một trang nhưng nhận được một luồng phản hồi. Máy khách lắng nghe một sự kiện (thường bằng phương thức onDataReceived) và bất cứ khi nào máy chủ gửi dữ liệu, sự kiện sẽ được kích hoạt thì máy khách sẽ nhận được dữ liệu, điều này hoạt động chính xác như WebSockets.
Client Streaming RPC: Điều này ngược lại với Server Streaming, về cơ bản, máy khách sẽ gửi một luồng dữ liệu đến máy chủ. Điều này có thể được sử dụng nếu chúng tôi gửi một tệp lớn và chúng tôi không muốn gửi tất cả trong một yêu cầu nên chúng tôi phân chia chúng thành nhiều phần. RPC truyền trực tuyến hai chiều: Về cơ bản, đây là nơi cả máy khách và máy chủ có thể gửi các luồng dữ liệu cho nhau. Hai luồng hoạt động độc lập, vì vậy máy khách và máy chủ có thể đọc và ghi theo bất kỳ thứ tự nào họ muốn. Ví dụ: máy chủ có thể đợi để nhận tất cả các tin nhắn của máy khách trước khi viết phản hồi của nó hoặc nó có thể luân phiên đọc một tin nhắn sau đó viết một tin nhắn hoặc một số kết hợp đọc và viết khác. Thứ tự của các tin nhắn trong mỗi luồng được giữ nguyên. Đây thực chất là WebSockets, được sử dụng nhiều nhất trong các trò chơi trực tuyến, ứng dụng trò chuyện, v.v.
Quy trình làm việc của gRPC
- Xác định hợp đồng dịch vụ truyền thông — Các dịch vụ có thể được xác định bằng các tham số cơ bản và kiểu trả về
- Tạo mã gRPC từ tệp
.proto. Trình biên dịch đặc biệt tạo mã hoạt động từ các tệp.protođược lưu trữ với các lớp thích hợp cho ngôn ngữ đích mong muốn - Triển khai máy chủ bằng ngôn ngữ đã chọn
- Tạo sơ khai ứng dụng khách để gọi máy chủ — Sau đó, các yêu cầu được xử lý bởi máy chủ và ứng dụng khách Dưới đây là một số tính năng của HTTP/2 sẽ hỗ trợ kiến trúc của gRPC trở nên nhanh hơn và linh hoạt hơn. Như tôi đã nói các thuộc tính của gRPC ở trên và bạn có thể thấy một lợi thế rất lớn mà chúng ta có thể tận dụng: Lớp khung nhị phân. Giao tiếp HTTP/2 được chia thành các thông báo nhỏ hơn và được đóng khung ở định dạng nhị phân. Không giống như HTTP/1.1 dựa trên văn bản, nó làm cho việc gửi và nhận tin nhắn trở nên nhỏ gọn và hiệu quả.
Nhiều yêu cầu song song. Mặc dù HTTP/1.1 chỉ cho phép xử lý một yêu cầu tại một thời điểm, nhưng HTTP/2 hỗ trợ nhiều lệnh gọi qua cùng một kênh. Hơn thế nữa, giao tiếp là hai chiều — một kết nối duy nhất có thể gửi cả yêu cầu và phản hồi cùng một lúc.
Truyền trực tuyến. Giao tiếp thời gian thực không chỉ có thể thực hiện được với HTTP/2 mà còn có hiệu suất cao nhờ tạo khung nhị phân — mỗi luồng được chia thành các khung có thể được ưu tiên và chạy qua một kết nối TCP, do đó giảm tải cho việc sử dụng và xử lý mạng .
Sau khi triển khai cả máy chủ và máy khách gRPC, tôi đã biên soạn một danh sách các ưu và nhược điểm:
ưu
- Nhanh và gọn vì nó sử dụng định dạng nhị phân thay vì JSON, nặng hơn dữ liệu nhị phân. Ngoài ra, HTTP/2 nén tải trọng nhị phân nhiều hơn để nó thực sự nhỏ hơn JSON rất nhiều và chúng tôi có thể giảm RTT nhiều hơn nữa trong TCP.
- Một thư viện khách hàng được duy trì bởi Google và cộng đồng mã nguồn mở! Không cần phụ thuộc vào client bên thứ ba hay tự duy trì, ngay cả REST chúng ta cũng có rất nhiều thư viện HTTP client và điều đó có thể dẫn đến các vấn đề như tôi đã mô tả lúc đầu.
- Hủy yêu cầu, điều này không thể thực hiện được trong môi trường không trạng thái. Mỗi kết nối trong HTTP/2 đều có một streamID và gRPC có thể chỉ cần sử dụng nó để yêu cầu máy chủ hủy kết nối, cũng như lắng nghe sự kiện hủy, điều không thể thực hiện được trong HTTP/1.1.
- Lợi ích từ HTTP/2, tất cả các chế độ phát trực tuyến như phát trực tuyến trên máy khách, phát trực tuyến trên máy chủ, hai chiều, thu gọn và nén trong HTTP/2 và kết hợp với Protobuf thật mạnh mẽ.
Nhược điểm
- Vẫn còn rất trẻ và không có nhiều hỗ trợ. Khi tôi gặp lỗi khi sử dụng gRPC, không có nhiều thông tin về lỗi trên Google hoặc Stackoverflow, tôi phải làm theo các tài liệu và tự gỡ lỗi.
- Hỗ trợ trình duyệt. Do gRPC phụ thuộc nhiều vào HTTP/2.0 nên không thể gọi trực tiếp dịch vụ gRPC từ trình duyệt. Để thực hiện điều này, bạn có một lớp proxy để thực hiện chuyển đổi giữa HTTP/1.1 và HTTP2.
- Khó học. gRPC rất khác so với các API REST nên cần có thời gian để làm quen. Tôi thấy khó làm quen với Protobuf, vì vậy chỉ cần sử dụng REST càng lâu càng tốt.
Đó là tất cả những gì tôi đã tự nghiên cứu về gRPC trong thời gian rảnh rỗi. Cảm ơn bạn đã đọc. Nếu có bất kỳ điểm không chính xác hoặc lỗ hổng nào trong kiến thức của tôi, xin vui lòng sửa lỗi cho tôi. Tôi thực sự đánh giá cao bất kỳ đầu vào.