Tôi chắc chắn rằng dòng tiêu đề đã gây ra phản ứng lành mạnh - “à, nó lại bắt đầu rồi…” Nhưng hãy để tôi thu hút sự chú ý của bạn trong 5-10 phút và tôi sẽ cố gắng không làm bạn thất vọng.
Cấu trúc của bài viết sẽ như sau: lấy một nhận định mang tính khuôn mẫu và bộc lộ “bản chất” sự xuất hiện của khuôn mẫu này. Tôi hy vọng điều này sẽ cho phép bạn xem xét việc lựa chọn mô hình trao đổi dữ liệu trong các dự án của mình từ một góc độ mới.
Để hiểu rõ RPC là gì, tôi đề xuất xem xét tiêu chuẩn . Với REST không có sự rõ ràng. Và nó không nên như vậy. Mọi thứ bạn cần biết về REST - không thể phân biệt được với .
Yêu cầu RPC nhanh hơn và hiệu quả hơn vì chúng cho phép bạn thực hiện yêu cầu hàng loạt.
Vấn đề là trong RPC bạn có thể gọi nhiều thủ tục cùng một lúc trong một yêu cầu. Ví dụ: tạo một người dùng, thêm hình đại diện cho anh ta và trong cùng một yêu cầu, đăng ký cho anh ta một số chủ đề. Chỉ cần một yêu cầu, và có bao nhiêu lợi ích!
Thật vậy, nếu bạn chỉ có một nút phụ trợ, yêu cầu hàng loạt sẽ có vẻ nhanh hơn. Bởi vì ba yêu cầu REST sẽ yêu cầu tài nguyên nhiều hơn gấp ba lần từ một nút để thiết lập kết nối.
Lưu ý rằng yêu cầu đầu tiên trong trường hợp REST phải trả về ID người dùng để thực hiện các yêu cầu tiếp theo. Điều này cũng ảnh hưởng tiêu cực đến kết quả chung.
Nhưng cơ sở hạ tầng như vậy chỉ có thể tìm thấy ở các giải pháp nội bộ và Doanh nghiệp. Phương án cuối cùng là trong các dự án WEB nhỏ. Nhưng các giải pháp WEB chính thức và thậm chí cả những giải pháp được gọi là HighLoad, đều không đáng để xây dựng. Cơ sở hạ tầng của họ phải đáp ứng các tiêu chí về tính sẵn sàng và tải trọng cao. Và bức tranh đang thay đổi.
Các kênh hoạt động cơ sở hạ tầng theo kịch bản tương tự được đánh dấu màu xanh lá cây. Hãy chú ý cách RPC hoạt động bây giờ. Yêu cầu chỉ sử dụng cơ sở hạ tầng trên một nhánh từ bộ cân bằng đến phần phụ trợ. Mặc dù REST vẫn thua trong yêu cầu đầu tiên, nhưng nó bù lại thời gian đã mất bằng cách sử dụng toàn bộ cơ sở hạ tầng.
Chỉ cần đưa vào kịch bản không phải hai yêu cầu làm giàu mà là năm hoặc mười... và câu trả lời cho câu hỏi “ai thắng bây giờ?” trở nên không rõ ràng.
Tôi đề nghị có một cái nhìn rộng hơn nữa về vấn đề. Sơ đồ cho thấy các kênh cơ sở hạ tầng được sử dụng như thế nào, nhưng cơ sở hạ tầng không giới hạn ở các kênh. Một thành phần quan trọng của cơ sở hạ tầng tải cao là bộ đệm. Bây giờ chúng ta hãy lấy một số loại tạo phẩm của người dùng. Nhiều lần. Giả sử là 32 lần.
Xem cơ sở hạ tầng RPC đã được cải thiện đáng kể như thế nào để đáp ứng nhu cầu tải cao. Vấn đề là REST sử dụng toàn bộ sức mạnh của giao thức HTTP, không giống như RPC. Trong sơ đồ trên, sức mạnh này được hiện thực hóa thông qua phương thức yêu cầu - GET.
Các phương thức HTTP, trong số những thứ khác, có chiến lược bộ nhớ đệm. Bạn có thể tìm thấy chúng trong tài liệu tại . Đối với RPC, các yêu cầu POST được sử dụng, không được coi là bình thường, nghĩa là, việc lặp lại nhiều lần các yêu cầu POST giống nhau có thể trả về các kết quả khác nhau (ví dụ: sau khi mỗi nhận xét được gửi, một bản sao khác của nhận xét này sẽ xuất hiện) ().
Do đó, RPC không thể sử dụng hiệu quả bộ đệm cơ sở hạ tầng. Điều này dẫn đến nhu cầu “nhập” bộ đệm phần mềm. Sơ đồ hiển thị Redis trong vai trò này. Ngược lại, bộ đệm phần mềm yêu cầu nhà phát triển thêm một lớp mã bổ sung và những thay đổi đáng chú ý trong kiến trúc.
Bây giờ chúng ta hãy đếm xem có bao nhiêu yêu cầu REST và RPC “đã sinh ra” trong cơ sở hạ tầng đang được xem xét?
yêu cầu
Hộp thư
để phụ trợ
tới hệ quản trị cơ sở dữ liệu
vào bộ đệm mềm (Redis)
TỔNG
REST của
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
So với sơ đồ đầu tiên, sự khác biệt là rất đáng chú ý. Bây giờ lợi ích của REST đã trở nên rõ ràng. Nhưng tôi đề nghị không dừng lại ở đó. Cơ sở hạ tầng được phát triển bao gồm CDN. Thường thì nó cũng giải quyết được vấn đề chống lại các cuộc tấn công DDoS và DoS. Chúng tôi nhận được:
Đây là lúc mọi thứ trở nên thực sự tồi tệ đối với RPC. RPC đơn giản là không có khả năng ủy thác khối lượng công việc cho CDN. Chúng ta chỉ có thể dựa vào hệ thống để chống lại các cuộc tấn công.
Có thể kết thúc ở đây được không? Và một lần nữa, không. Các phương thức HTTP, như đã đề cập ở trên, có “ma thuật” riêng. Và không phải vô cớ mà phương thức GET được sử dụng rộng rãi trên Internet. Lưu ý rằng phương pháp này có thể truy cập một phần nội dung, có thể đặt các điều kiện mà các thành phần cơ sở hạ tầng có thể diễn giải trước khi quyền kiểm soát được chuyển sang mã của bạn, v.v. Tất cả điều này cho phép bạn tạo cơ sở hạ tầng linh hoạt, dễ quản lý, có thể xử lý các luồng yêu cầu thực sự lớn. Nhưng trong RPC phương pháp này... bị bỏ qua.
Vậy tại sao huyền thoại cho rằng các yêu cầu hàng loạt (RPC) nhanh hơn lại dai dẳng đến vậy? Cá nhân tôi, có vẻ như hầu hết các dự án đơn giản là không đạt đến mức độ phát triển mà REST có thể thể hiện sức mạnh của mình. Hơn nữa, trong những dự án nhỏ, anh ấy sẵn sàng bộc lộ điểm yếu của mình hơn.
Việc lựa chọn REST hay RPC không phải là sự lựa chọn tự nguyện của một cá nhân trong một dự án. Sự lựa chọn này phải đáp ứng được yêu cầu của dự án. Nếu một dự án có thể tận dụng mọi thứ nó thực sự có thể ra khỏi REST và nó thực sự cần nó, thì REST sẽ là một lựa chọn tuyệt vời.
Nhưng nếu để có được tất cả lợi ích của REST, bạn cần thuê chuyên gia devops cho dự án để nhanh chóng mở rộng quy mô cơ sở hạ tầng, quản trị viên quản lý cơ sở hạ tầng, kiến trúc sư thiết kế tất cả các lớp của dịch vụ WEB... và dự án , đồng thời, bán ba gói bơ thực vật mỗi ngày... Tôi sẽ gắn bó với RPC, bởi vì... giao thức này tiện dụng hơn. Nó sẽ không yêu cầu kiến thức sâu về cách hoạt động của bộ nhớ đệm và cơ sở hạ tầng, nhưng sẽ tập trung nhà phát triển vào các lệnh gọi đơn giản và dễ hiểu đối với các quy trình mà anh ta cần. Việc kinh doanh sẽ được hạnh phúc.
Các yêu cầu RPC đáng tin cậy hơn vì chúng có thể thực hiện các yêu cầu hàng loạt trong một giao dịch
Thuộc tính này của RPC là một lợi thế rõ ràng, bởi vì Thật dễ dàng để giữ cho cơ sở dữ liệu nhất quán. Nhưng với REST thì mọi chuyện ngày càng phức tạp hơn. Yêu cầu có thể đến các nút phụ trợ khác nhau một cách không nhất quán.
“Nhược điểm” này của REST chính là mặt trái của ưu điểm được mô tả ở trên - khả năng sử dụng hiệu quả tất cả các tài nguyên cơ sở hạ tầng. Nếu cơ sở hạ tầng được thiết kế kém, và thậm chí còn hơn thế nếu kiến trúc của dự án và cơ sở dữ liệu nói riêng được thiết kế kém, thì đây thực sự là một nỗi đau lớn.
Nhưng các yêu cầu hàng loạt có đáng tin cậy như vẻ ngoài của chúng không? Hãy xem xét một trường hợp: chúng tôi tạo một người dùng, làm phong phú hồ sơ của anh ấy bằng một số mô tả và gửi cho anh ấy một SMS kèm theo bí mật để hoàn tất đăng ký. Những thứ kia. ba cuộc gọi trong một yêu cầu hàng loạt.
Chúng ta hãy nhìn vào sơ đồ. Nó trình bày một cơ sở hạ tầng với các yếu tố sẵn sàng cao. Có hai kênh liên lạc độc lập với cổng SMS. Nhưng... chúng ta thấy gì? Khi gửi SMS thì xảy ra lỗi 503 - dịch vụ tạm thời không khả dụng. Bởi vì Việc gửi SMS được đóng gói trong một yêu cầu hàng loạt, sau đó toàn bộ yêu cầu phải được khôi phục. Các hành động trong DBMS bị hủy bỏ. Khách hàng nhận được một lỗi.
Lần thử tiếp theo là xổ số. Hoặc yêu cầu sẽ nhấn vào cùng một nút nhiều lần và trả về lỗi hoặc bạn sẽ gặp may và nó sẽ được thực thi. Nhưng điều quan trọng nhất là ít nhất một lần cơ sở hạ tầng của chúng ta đã hoạt động vô ích. Có tải nhưng không có lãi.
Được rồi, hãy tưởng tượng rằng chúng ta đã căng thẳng (!) Và suy nghĩ về lựa chọn khi nào yêu cầu có thể được hoàn thành thành công một phần. Và chúng tôi sẽ cố gắng hoàn thành lại phần còn lại sau một khoảng thời gian (Cái nào? Phía trước có quyết định không?). Nhưng xổ số vẫn như cũ. Yêu cầu gửi SMS có khả năng thất bại lần nữa là 50/50.
Đồng ý, từ phía khách hàng, dịch vụ có vẻ không đáng tin cậy như chúng tôi mong muốn... còn REST thì sao?
REST lại sử dụng sự kỳ diệu của HTTP, nhưng bây giờ có mã phản hồi. Khi xảy ra lỗi 503 trên cổng SMS, phần phụ trợ sẽ phát lỗi này tới bộ cân bằng. Bộ cân bằng nhận được lỗi này và không ngắt kết nối với máy khách, gửi yêu cầu đến một nút khác để xử lý yêu cầu thành công. Những thứ kia. khách hàng nhận được kết quả như mong đợi và cơ sở hạ tầng xác nhận tiêu đề cao là “có khả năng truy cập cao”. Người dùng hạnh phúc.
Và một lần nữa đó không phải là tất cả. Bộ cân bằng không chỉ nhận được mã phản hồi là 503. Khi phản hồi, theo tiêu chuẩn, bạn nên cung cấp mã này với tiêu đề “Thử lại sau”. Tiêu đề này làm rõ cho bộ cân bằng rằng không đáng để làm phiền nút này trên tuyến đường này trong một thời gian nhất định. Và các yêu cầu gửi SMS tiếp theo sẽ được gửi trực tiếp đến một nút không gặp vấn đề gì với cổng SMS.
Như chúng ta có thể thấy, độ tin cậy của JSON-RPC được đánh giá quá cao. Thật vậy, việc tổ chức tính nhất quán trong cơ sở dữ liệu sẽ dễ dàng hơn. Nhưng sự hy sinh, trong trường hợp này, sẽ là độ tin cậy của toàn bộ hệ thống.
Kết luận phần lớn tương tự như kết luận trước. Khi cơ sở hạ tầng đơn giản, tính rõ ràng của JSON-RPC chắc chắn là một điểm cộng. Nếu dự án liên quan đến tính sẵn sàng cao với tải trọng cao, REST có vẻ như là một giải pháp chính xác hơn, mặc dù phức tạp hơn.
Ngưỡng đầu vào REST thấp hơn
Tôi nghĩ rằng phân tích ở trên, làm sáng tỏ những định kiến đã có về RPC, đã cho thấy rõ ràng rằng ngưỡng để vào REST chắc chắn cao hơn so với RPC. Điều này là do nhu cầu hiểu biết sâu sắc về cách thức hoạt động của HTTP, cũng như nhu cầu có đủ kiến thức về các thành phần cơ sở hạ tầng hiện có có thể và nên được sử dụng trong các dự án WEB.
Vậy tại sao nhiều người cho rằng REST sẽ đơn giản hơn? Ý kiến cá nhân của tôi là sự đơn giản rõ ràng này đến từ việc REST tự thể hiện. Những thứ kia. REST không phải là một giao thức mà là một khái niệm... REST không có tiêu chuẩn, có một số nguyên tắc... REST không phức tạp hơn HTTP. Sự tự do rõ ràng và tình trạng hỗn loạn thu hút “các nghệ sĩ tự do”.
Tất nhiên, REST không phức tạp hơn HTTP. Nhưng bản thân HTTP là một giao thức được thiết kế tốt và đã chứng minh được giá trị của nó qua nhiều thập kỷ. Nếu không có hiểu biết sâu sắc về bản thân HTTP thì không thể đánh giá được REST.
Nhưng về RPC - bạn có thể. Nó là đủ để có đặc điểm kỹ thuật của nó. Vậy bạn có cần ? Hay nó vẫn còn phức tạp REST? Bạn quyết định.
Tôi chân thành hy vọng rằng tôi đã không lãng phí thời gian của bạn.
Nguồn: www.habr.com
