So sánh giữa RPC (Remote Procedure Calls) và Messaging

Giới thiệu

Trong lĩnh vực lập trình phân tán có một số phương pháp được thiết lập để giải quyết vấn đề truyền tin giữa các chương trình riêng biệt.

Trong rất nhiều các giải pháp, từ các hoạt động socket cấp thấp (low-level) cho đến cấp cao (high-level) và các hệ thống trao đổi thông tin trong lĩnh vực cụ thể, có hai cách tiếp cận "cấp trung (middle-level)" đặc biệt thú vị ở chỗ chúng ẩn đi những chi tiết thực thi đồng thời cung cấp một giao diện chung có thể được triển khai trong một loạt các lĩnh vực ứng dụng. Hai giải pháp đó là truyền tin hướng RPC và messaging.

Bài viết này sẽ cố gắng làm nổi bật sự khác biệt chủ yếu giữa hai phương pháp truyền tin này.

Ưu và nhược của RPC

RPC, đó là chữ viết tắt của Remote Procedure Calls (tạm dịch là các cuộc gọi thủ tục từ xa), là một khái niệm nhằm cố gắng khái quát một lời gọi thủ tục thông thường trong trường hợp mà caller và receiver không cùng nằm trong một process - và được phân tán trên các máy riêng biệt.

Mục tiêu chính của phương pháp này là làm cho lời gọi từ xa RPC tương tự như thể lời gọi thủ tục thông thường cục bộ và ẩn đi việc truyền dữ liệu đi về qua mạng.

Mục tiêu này rất hấp dẫn ở chỗ nó có khả năng cho phép chuyển sự phân tán của hệ thống cuối cùng vào một quyết định ở thời điểm triển khai - hay nói cách khác, từ quan điểm của lập trình viên thì không quan trọng việc cuộc gọi đó là cục bộ hay từ xa miễn là nó có cú pháp giống nhau, và quyết định cuối cùng về sự phân tán của các thành phần hệ thống riêng lẻ có thể được thực hiện sau này. Việc loại bỏ khía cạnh phân tán từ code có thể mang lại rất nhiều lợi ích cho các dự án vì ở giai đoạn đầu thì các chi tiết cuối cùng của việc triển khai thường chưa được biết đầy đủ. Lập trình viên có thể tùy biến chuyển từ lời gọi cục bộ sang lời gọi từ xa RPC mà không thay đổi quá lớn cấu trúc ban đầu của chương trình.

Tuy nhiên, những lợi ích tiềm năng của RPC cũng có cái giá của nó:

• Trong cơ chế gọi hàm trong nội bộ một process, lập trình viên thường không quan tâm đến thời gian chuyển thực thi từ đối tượng gọi (caller) vào đối tượng bị gọi (receiver). Thời gian này rất ngắn, chương trình nạp biến cục bộ của caller vào stack. Ngược lại trong mô hình RPC thực tế, khoảng thời gian truyền tham số đối tượng gọi (caller) đến đối tượng bị gọi (receiver) ở xa, rồi kết quả trả về sẽ đi từ receiver về tới caller là không nhỏ. Lập trình viên đành phải chấp nhận hoặc lờ đi hoặc đặt cơ chế hết hạn (time out). Cách lập trình viên tối ưu chương trình cục bộ là chia nhỏ chương trình thành nhiều đối tượng gọi nhau, hoặc các hàm tái sử dụng được gọi lại. Tuy nhiên với RPC, cách chia nhiều hàm để gọi này chưa chắc hợp lý khi thời gian trễ mỗi lần gọi RPC là khó có thể bỏ quả, càng nhiều lần gọi, tổng thời gian trễ sẽ tăng, khả năng nghẽn cổ chai do kiểu hỏi đáp liên tục sẽ tăng. Nhiều nơi gọi là chatty ~ gọi vặt liên tục.
• Đối với lời gọi cục bộ, đối tượng gọi (caller) và đối tượng bị gọi (receiver) nằm trong cùng một process. Kiểu tham số truyền được kiểm tra nghiêm ngặt khi biên dịch. Việc viết unit test để kiểm tra cũng đơn giản. Tuy nhiên với lời gọi RPC, tham số gửi đi, dữ liệu kết quả trả về sẽ phải quá trình chuyển đổi: serialize và de-serialize, hay còn gọi là marshalling. Đối với lời gọi RPC, việc kiểm tra kiểu có nhiều rủi ro hơn nhiều, chưa kể rủi ro dữ liệu bị nghe lén hoặc bị thay đổi trên đường truyền. Việc bảo mật lời gọi RPC dẫn đến cần phải mã hóa, gắn kèm chữ ký kiểm tra... khiến thư viện bên dưới của caller và receiver sẽ phải làm việc nhiều hơn, độ trễ lại cao hơn. Chưa kể đồng hồ thời gian ở máy tính chứa caller và receiver có thể sai khác nhau, hệ điều hành cũng như phần mềm, ngôn ngữ lập trình cũng khác nhau, kiểu dữ liệu có sự sai khác...

Vấn đề của RPC là bởi nó ẩn đi thực tế phân tán ở mức cú pháp, điều này gây khó khăn hơn cho các lập trình viên để giải quyết đúng đắn các thách thức cố hữu đi kèm với các khía cạnh vật lý của phân tán.

Messaging như một giải pháp thay thế

Messaging là một khái niệm truyền tin khác rất nhiều so với RPC trong đó nó không cố gắng che giấu đi những khía cạnh vật lý của truyền dữ liệu từ caller đến receiver. Nó che giấu phần nào các chi tiết thực thi, nhưng không đến mức bác bỏ các khái niệm liên quan đến các chi phí run-time trong việc trao đổi dữ liệu.

Messaging là một khái niệm truyền tin có thể được giải thích một cách dễ dàng vì có những điểm tương đồng với hệ thống e-mail. Điều quan trọng nhất của những điểm tương đồng này là một thực tế rằng các message được công nhận là các thực thể first-class, và người dùng nghĩ rằng mỗi message là một cái gì đó hữu hình. Trọng tâm ở đây không phải là để ẩn đi (hiding) những thách thức trong truyền thông, thay vào đó là sẽ đóng gói (encapsulation) và đưa ra một hình thức mà người dùng có thể tương tác được. Trong hệ thống e-mail, một message là một cái gì đó không những được truyền đi, mà nó cũng có thể được sao lưu hoặc in ấn.

Sau đây là một danh sách chưa đầy đủ về các ưu điểm có thể có, tùy thuộc vào việc thực thi, thể hiện các tính chất thường có của một hệ thống messaging:

• Khả năng quản lý và phản ứng với các chậm trễ (delay) trong truyền tin. Một hệ thống messaging có thể có các thời gian timeout được kiểm soát với mức độ tùy ý - thậm chí ở cấp độ của các message riêng lẻ.
• Khả năng giám sát tiến độ (và ước lượng thời gian thực tế) của việc truyền dữ liệu vật lý.
• Các mức độ ưu tiên của message cho phép tầng giao vận (transport layer) phân biệt các message dựa trên tầm quan trọng của chúng.
• Khả năng lưu trữ các message một cách đáng tin cậy (message persistency) hoặc cho phép tách rời hoàn toàn các sender và receiver trong giới hạn thời gian thực thi của chúng. Nhờ khả năng này receiver không nhất thiết phải lắng nghe hoặc sống khi message truyền tới. Hoặc message có thể được gửi lại nhiều hơn 1 lần.
• Nội dung message có thể thay đổi - các message có thể có những phần mà không nhất thiết phải tuân theo bất kỳ cấu trúc tĩnh nào đó, điều này cung cấp sự linh hoạt hơn trong việc quản lý sự phát triển của một hệ thống phân tán (bạn hãy đọc bài viết What Is Wrong With IDL để biết thêm chi tiết).
• Khả năng thích nghi với cả các hệ thống giao vận trực tiếp và gián tiếp, bao gồm cả việc có thể tự động tái tạo lại nội dung. Trong hệ thống e-mail, danh sách mail (bao gồm cả phần archives) là những ví dụ tốt về các hệ thống giao vận gián tiếp mà không cần bất kỳ phần mở rộng nào cho các khái niệm cơ bản của e-mail.
• Message tagging, meta-information và tracing - ví dụ, hoàn toàn có thể thu được một báo cáo đầy đủ về con đường vận chuyển đã được "ghé thăm" bởi một message cho đến khi message này đến được đích của nó. Nhờ phần meta-information, các message cũng có thể trở thành bộ phận của những cấu trúc truyền thông ở cấp cao hơn. Trong hệ thống e-mail, chúng được gọi là "threads" trong các nhóm thảo luận cho thấy một ứng dụng có thể có của những khái niệm này.
• Các tính năng liên quan đến bảo mật như chữ ký số của nội dung dữ liệu và các thẻ truy cập (access token) có thể được sử dụng cho mỗi message để kiểm soát chi tiết việc ai có quyền làm những gì trong hệ thống phân tán đó.
• Nếu như RPC thường là "1 gọi 1" hay "Peer to Peer", thì messaging lại có nhiều mô hình đa dạng hơn:
  • Một gọi nhiều.
  • Một gọi cho nhóm nhưng chọn đối tượng phản hồi đầu tiên.
  • Tùy vào đặc tính hoặc nội dung thông điệp, quyết định đối tượng nào sẽ được nhận.
  • Phân tải đều đặn kiểu xoay vòng: round robin
  • Phân tải nhưng có nhớ được lần trước thông điệp được gửi đến đối tượng nào, nay gửi đúng đối tượng đó để đảm bảo hai bên có đầy đủ lịch sử trò chuyện.

Danh sách trên cho thấy những bất cập trong cơ chế RPC mở ra cơ hội lớn khi chuyển qua sử dụng cơ chế messaging.

Vẫn có thể sử dụng messaging như một thực thi phân tán của các "cuộc gọi (call)" và trong thực tế thì phương pháp hướng đối tượng sử dụng thuật ngữ "message" để ám chỉ các yêu cầu có thể được gửi giữa các đối tượng (object). Tuy nhiên, lợi thế của messaging là bằng cách thể hiện thực tế của truyền thông trong một hình thức hữu hình của message như một thực thể first-class, các lập trình viên có nhiều cơ hội để mở rộng sang các miền chức năng khác hoặc là do cảm thấy không thoải mái với những ràng buộc của một "lối tư duy gọi thủ tục (procedure call mindset)" hay chỉ vì không thể thực hiện được theo cách cũ.

Bản dịch của Phùng Tùng Huy, thực tập sinh lập trình web tại TechMaster có sự chỉnh sửa của giảng viên hướng dẫn
Link bài viết tham khảo: http://www.inspirel.com/articles/RPC_vs_Messaging.html