Bạn đang quan tâm đến Techmaster Việt Nam – Học là có việc phải không? Nào hãy cùng PHE BINH VAN HOC theo dõi bài viết này ngay sau đây nhé!
Video đầy đủ Techmaster Việt Nam – Học là có việc
phần 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 thông báo giữa các chương trình riêng biệt.
Trong nhiều giải pháp khác nhau, từ hoạt động socket cấp thấp đến cấp cao và hệ thống truyền thông theo miền cụ thể, có hai cách tiếp cận: “cấp trung bình” đặc biệt thú vị vì chúng ẩn chi tiết triển khai trong khi cung cấp giao diện điều đó có thể được triển khai trong nhiều lĩnh vực ứng dụng. cả hai giải pháp đều là rpc và định hướng nhắn tin.
Bạn đang xem: Rpc là gì
Bài viết này sẽ cố gắng làm nổi bật những điểm khác biệt chính giữa hai phương pháp giao tiếp này.
ưu và nhược điểm của rpc
rpc, viết tắt của các lệnh gọi thủ tục từ xa, là một khái niệm cố gắng tổng quát hóa một lệnh gọi thủ tục phổ biến trong trường hợp người gọi và người nhận không ở trong cùng một quy trình và được phân phối trên các máy riêng biệt.
Tham khảo: Test case là gì? Thành phần test case cần nắm – ITNavi
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 hấp dẫn vì nó có khả năng cho phép việc phân phối cuối cùng của hệ thống trở thành một quyết định tại thời điểm thực hiện; nói cách khác, không phải theo quan điểm của lập trình viên. không quan trọng nếu cuộc gọi là cục bộ hay từ xa miễn là nó có cùng cú pháp và quyết định cuối cùng về cách bố trí của các thành phần riêng lẻ của hệ thống có thể được đưa ra sau đó. Loại bỏ khía cạnh phân tán của mã có thể rất có lợi cho các dự án vì các chi tiết cuối cùng của việc triển khai thường không được biết đầy đủ trong giai đoạn đầu. lập trình viên có thể tùy chỉnh chuyển đổi từ lệnh gọi nội bộ sang lệnh rpc từ xa mà không làm thay đổi quá nhiều 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 đi kèm với cái giá phải trả:
- Trong cơ chế gọi hàm bên trong của một tiến trình, người lập trình nói chung không quan tâm đến thời gian truyền thực thi từ người gọi đến đối tượng được gọi (người nhận). thời gian này rất ngắn, chương trình tải biến cục bộ của người gọi trên ngăn xếp. ngược lại, trong mô hình rpc thực, thời gian cần để truyền tham số từ người gọi đến người nhận được gọi từ xa, và sau đó kết quả trả về sẽ đi từ người nhận đến người gọi là không nhỏ. nhà phát triển phải chấp nhận hoặc bỏ qua hoặc đặt cơ chế thời gian chờ. cách các lập trình viên tối ưu hóa các chương trình cục bộ là chia nhỏ chương trình thành nhiều đối tượng gọi hoặc các hàm có thể sử dụng lại được gọi lại. tuy nhiên với rpc, cách tách nhiều chức năng để gọi như vậy là không hợp lý khi thời gian trễ của mỗi cuộc gọi rpc rất khó bỏ lỡ, càng nhiều cuộc gọi thì tổng thời gian trễ sẽ tăng lên, khả năng bị nghẽn cổ chai do loại câu hỏi liên tục và câu trả lời sẽ tăng lên. nhiều nơi được gọi là người nói chuyện ~ việc lặt vặt liên tục.
- đối với các cuộc gọi nội hạt, người gọi và đối tượng được gọi thực hiện cùng một quy trình. loại tham số được truyền vào được kiểm tra nghiêm ngặt tại thời điểm biên dịch. việc viết các bài kiểm tra đơn vị để kiểm tra cũng đơn giản. tuy nhiên, với lệnh gọi rpc, các tham số được gửi đi, dữ liệu kết quả sẽ cần được chuyển đổi: serialize và deserialize, còn được gọi là marshalling. đối với các cuộc gọi rpc, việc kiểm tra kiểu rủi ro hơn nhiều, chưa kể đến nguy cơ dữ liệu bị chặn hoặc giả mạo trong quá trình truyền tải. sự bảo mật của cuộc gọi rpc dẫn đến việc phải mã hóa, đính kèm chữ ký xác minh… khiến thư viện bên dưới của người gọi và người nhận phải làm việc nhiều hơn, độ trễ sẽ cao hơn. Chưa kể đồng hồ thời gian trên máy tính chứa người gọi và người nhận có thể 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, kiểu dữ liệu cũng khác …
Vấn đề với rpc là nó che giấu thực tế phân tán ở cấp độ cú pháp, khiến các lập trình viên khó giải quyết thỏa đáng những 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.
nhắn tin thay thế
nhắn tin là một khái niệm giao tiếp rất khác với rpc ở chỗ nó không cố gắng che giấu các khía cạnh vật lý của quá trình truyền dữ liệu từ người gọi đến người nhận. che khuất một phần chi tiết triển khai, nhưng không quá nhiều để bác bỏ các khái niệm liên quan đến chi phí thời gian chạy trong trao đổi dữ liệu .
Xem thêm: Hologram là gì? Tìm hiểu công nghệ trình chiếu và ứng dụng của nó hiện nay
Nhắn tin là một khái niệm giao tiếp có thể dễ dàng giải thích do những điểm tương đồng với hệ thống email. Điều quan trọng nhất trong số những điểm tương đồng này là thực tế là các thông báo được công nhận là các thực thể hạng nhất và người dùng nghĩ về mỗi thông báo như một cái gì đó hữu hình. trọng tâm ở đây không phải là che giấu các thách thức giao tiếp, mà là gói gọn và trình bày một cách để người dùng tương tác. Trong hệ thống email, tin nhắn là thứ không chỉ được truyền đi mà còn có thể được sao lưu hoặc in ra.
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à ứng phó với sự chậm trễ trong giao tiếp. hệ thống nhắn tin có thể đã tùy ý kiểm soát thời gian chờ, ngay cả ở cấp độ tin nhắn riêng lẻ.
- giám sát tiến độ (và khả năng ước tính thời gian) của quá trình truyền dữ liệu vật lý.
- mức độ ưu tiên của tin nhắn cho phép lớp truyền tải phân biệt các tin nhắn dựa trên mức độ quan trọng của chúng.
- khả năng lưu trữ tin nhắn một cách đáng tin cậy (độ bền của tin nhắn) hoặc cho phép tách biệt hoàn toàn người gửi và người nhận trong thời gian thực thi giới hạn. Nhờ khả năng này, người nhận không cần nghe hoặc trực tiếp khi tin nhắn đến. hoặc tin nhắn có thể được chuyển tiếp nhiều lần.
- nội dung của tin nhắn có thể thay đổi: tin nhắn có thể có các phần không nhất thiết phải tuân theo bất kỳ cấu trúc tĩnh nào, giúp linh hoạt hơn trong việc quản lý quá trình phát triển của tin nhắn. hệ thống phân tán (đọc idl có vấn đề gì để biết thêm chi tiết).
- khả năng thích ứng với các hệ thống phân phối trực tiếp và gián tiếp, bao gồm cả khả năng phát nội dung tự động. trong hệ thống email, danh sách gửi thư (bao gồm cả kho lưu trữ) là ví dụ điển hình về hệ thống gửi gián tiếp không yêu cầu bất kỳ phần mở rộng nào về thông tin cơ bản về email.
- gắn thẻ thư, thông tin meta và theo dõi – ví dụ: có thể có được một báo cáo đầy đủ về tuyến đường vận chuyển đã được tin nhắn “ghé thăm” cho đến khi tin nhắn này đến đích. Nhờ siêu thông tin, thông điệp cũng có thể là một phần của cấu trúc giao tiếp cấp cao hơn. trong hệ thống email, chúng được gọi là “chuỗi” trong các nhóm thảo luận cho biết khả năng áp dụng những khái niệm này.
- các tính năng liên quan đến bảo mật, chẳng hạn như văn bản. Chữ ký điện tử của nội dung dữ liệu và mã thông báo truy cập có thể được sử dụng cho mỗi tin nhắn để kiểm soát chi tiết ai được phép làm những gì trong hệ thống phân tán đó.
- nếu rpc thường là “1 cuộc gọi 1” hoặc “ngang hàng “, nhắn tin có nhiều mô hình đa dạng hơn:
- cuộc gọi đến nhiều người.
- cuộc gọi đến nhóm nhưng chọn người đầu tiên trả lời.
- tùy thuộc vào đặc điểm hoặc nội dung của thông điệp, quyết định đối tượng nào sẽ nhận được thông báo đó.
- phân phối tải đều theo mô hình xoay vòng: luân phiên
- phân phối nhưng có thể nhớ lần trước thông điệp đã được gửi cho đối tượng nào, bây giờ hãy gửi đúng đối tượng để đảm bảo cả hai bên đều có lịch sử trò chuyện đầy đủ.
Danh sách trên cho thấy những thiếu sót trong cơ chế rpc mở ra cơ hội lớn khi chuyển sang cơ chế nhắn tin.
Vẫn có thể sử dụng tin nhắn như một triển khai phân tán của “cuộc gọi” và trong thực tế, cách tiếp cận hướng đối tượng sử dụng thuật ngữ “tin nhắn” để chỉ các yêu cầu có thể được gửi giữa các đối tượng. tuy nhiên, lợi thế của nhắn tin là bằng cách thể hiện thực tế của giao tiếp ở dạng hữu hình của thông điệp như một thực thể hạng nhất, các nhà phát triển có nhiều cơ hội hơn để mở rộng sang các lĩnh vực chức năng khác, vì họ không thoải mái với những hạn chế của một “thủ tục gọi tâm lý “hoặc đơn giản là vì nó không thể được thực hiện theo cách cổ điển.
bản dịch của phung tung huy, techmaster web developer, được biên tập bởi người hướng dẫn, link dẫn đến bài viết tham khảo: http://www.inspirel.com/articles/rpc_vs_messaging.html
Xem thêm: Gửi mail với Sendgrid bắt đầu từ đâu và như thế nào?
Như vậy trên đây chúng tôi đã giới thiệu đến bạn đọc Techmaster Việt Nam – Học là có việc. Hy vọng bài viết này giúp ích cho bạn trong cuộc sống cũng như trong học tập thường ngày. Chúng tôi xin tạm dừng bài viết này tại đây.
Website: https://phebinhvanhoc.com.vn/
Thông báo: Phê Bình Văn Học ngoài phục vụ bạn đọc ở Việt Nam chúng tôi còn có kênh tiếng anh PhebinhvanhocEN cho bạn đọc trên toàn thế giới, mời thính giả đón xem.
Chúng tôi Xin cám ơn!
Xem thêm: