Tóm Tắt
Giới thiệu
Trong nghành lập trình phân tán có một số ít chiêu thức được thiết lập để xử lý yếu tố truyền tin giữa những chương trình riêng không liên quan gì đến nhau .Trong rất nhiều những giải pháp, từ những hoạt động giải trí socket cấp thấp ( low-level ) cho đến cấp cao ( high-level ) và những mạng lưới hệ thống trao đổi thông tin trong nghành đơn cử, có hai cách tiếp cận ” cấp trung ( middle-level ) ” đặc biệt quan trọng mê hoặc ở chỗ chúng ẩn đi những chi tiết thực thi đồng thời cung ứng một giao diện chung hoàn toàn có thể được tiến hành trong một loạt những nghành ứ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.
Bạn đang đọc: So sánh giữa RPC (Remote Procedure Calls) và Messaging
Ư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ô hình RPC (Remote Procedure Calls)
Mục tiêu chính của chiêu thức này là làm cho lời gọi từ xa RPC tựa như như thể lời gọi thủ tục thường thì cục bộ và ẩn đi việc truyền tài liệu đi về qua mạng .Mục tiêu này rất mê hoặc ở chỗ nó có năng lực được cho phép chuyển sự phân tán của mạng lưới hệ thống ở đầu cuối vào một quyết định hành động ở thời gian tiến hành – 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 hành động ở đầu cuối về sự phân tán của những thành phần mạng lưới hệ thống riêng không liên quan gì đến nhau hoàn toàn có thể được triển khai sau này. Việc vô hiệu góc nhìn phân tán từ code hoàn toàn có thể mang lại rất nhiều quyền lợi cho những dự án Bất Động Sản vì ở quy trình tiến độ đầu thì những cụ thể sau cuối của việc tiến hành thường chưa được biết khá đầy đủ. Lập trình viên hoàn toà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 biến hóa quá lớn cấu trúc bắt đầ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 tiễn phân tán ở mức cú pháp, điều này gây khó khăn vất vả hơn cho những lập trình viên để xử lý đúng đắn những thử thách cố hữu đi kèm với những góc nhìn 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.
Cơ chế gửi tin nhắn (messaging)
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 chưa ổn trong chính sách RPC mở ra thời cơ lớn khi chuyển qua sử dụng chính sách messaging .Vẫn hoàn toàn có thể sử dụng messaging như một thực thi phân tán của những ” cuộc gọi ( call ) ” và trong trong thực tiễn thì giải pháp hướng đối tượng người tiêu dùng sử dụng thuật ngữ ” message ” để ám chỉ những nhu yếu hoàn toàn có thể được gửi giữa những đối tượng người tiêu dùng ( object ). Tuy nhiên, lợi thế của messaging là bằng cách biểu lộ thực tiễn của truyền thông online trong một hình thức hữu hình của message như một thực thể first-class, những lập trình viên có nhiều thời cơ để lan rộng ra sang những miền tính năng khác hoặc là do cảm thấy không tự do 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 hề thực thi đượ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
Source: https://final-blade.com
Category : Kiến thức Internet
