Remote procedure call là gì Update 11/2024

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.

Bạn đang xem: Remote procedure call là gì

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 tinhướ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 tinnày.

Ưu và nhượccủ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ô hình RPC (Remote Procedure Calls)

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ờigọ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êncó 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 trongmô hìnhRPC 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ừ receivervề 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ọinà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ơigọi là chatty ~ gọi vặt liên tục.

Xem thêm: hạn mức tín dụng tiếng anh là gì ?

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 tinkhá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àocá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 tincó 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.

Cơ chế gửi tin nhắn (messaging)

Sau đây là một danh sách chưa đầy đủ vềcác ưu điểmcó 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 receiverkhô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.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ặcnộ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 robinPhâ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êncó đầ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.

Xem thêm: Mana Là Gì – Mana Trong Game Là Gì

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 webtại thienmaonline.vncó sự chỉnh sửa của giảng viên hướng dẫnLink bài viết tham khảo: http://www.inspirel.com/articles/RPC_vs_Messaging.html

Chuyên mục: Hỏi Đáp