Mẹo nhỏ: Để tìm kiếm chính xác các tác phẩm của Phebinhvanhoc.com.vn, hãy search trên Google với cú pháp: "Từ khóa" + "phebinhvanhoc". (Ví dụ: tác phẩm chí phèo phebinhvanhoc). Tìm kiếm ngay
217 lượt xem

Techmaster Việt Nam – Học là có việc

Theo dõi PHEBINHVANHOC trên

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à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.

Mô hình RPC (Remote Procedure Calls)

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ờ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 .

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.

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

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:

Bài viết cùng chủ đề:

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *