Link đến phần 1: https://iotgateway.vn/request-response-vs-publish-subscribe-phan-1-su-khac-biet-la-gi
Request-response: "Đã được kiểm chứng và đáng tin cậy"
Trong kiến trúc request - respond, mỗi máy khách sẽ mở một kết nối trực tiếp đến mỗi máy chủ, vì máy khách yêu cầu dữ liệu trực tiếp từ máy chủ.
Trong tự động hóa, máy khách thường là PC và máy chủ là PLC hoặc PAC. Vì vậy, mỗi PC sẽ mở một kết nối trực tiếp đến mỗi PLC hoặc PAC mà từ đó nó cần dữ liệu. Và bởi vì khách hàng không biết khi nào dữ liệu có thể thay đổi, nên sẽ thực hiện yêu cầu dữ liệu theo định kỳ.
Vì vậy, các máy khách PC gửi lặp đi lặp lại các yêu cầu đến máy chủ PLC và PAC — trong tự động hóa, nhanh nhất là nhiều lần mỗi giây — và các máy chủ sẽ phản hồi lại:
Hỏi: Giá trị cảm biến là gì? A: 10
Hỏi: Giá trị cảm biến là gì? A: 10
Hỏi: Giá trị cảm biến là gì? A: 10
Hỏi: Giá trị cảm biến là gì? A: 10
Hỏi: Giá trị cảm biến là gì? A: 10
Hỏi: Giá trị cảm biến là gì? A: 9
Hỏi: Giá trị cảm biến là gì? A: 9
Nếu mạng mạnh và có ít máy chủ, mô hình này sẽ hoạt động rất tốt. Miễn là máy chủ có khả năng đáp ứng các yêu cầu của khách hàng và mạng có thể xử lý được lưu lượng truy cập, thì request-respond là một phương thức giao tiếp đáng tin cậy. Đặc biệt hữu ích cho giao tiếp qua mạng nội bộ an toàn.
Về vấn đề lưu lượng lưu thông thì sao?
Tuy nhiên, trong trường hợp bạn có nhiều máy chủ với nhiều máy khách, lưu lượng truy cập trong mô hình request-respond có thể nhanh chóng trở thành vấn đề.
Sau đây là cách hoạt động. Mỗi máy khách được kết nối riêng với mỗi máy chủ mà nó cần để yêu cầu dữ liệu và mỗi kết nối sẽ được cho phép có thể mở, truy vấn, trả lời và đóng, lặp đi lặp lại.
Trong phần tương tự về xe tải của chúng ta từ phần 1, bạn sẽ thấy hệ thống này như là một hệ giao thông có một lưu lượng các xe tải liên tục — gồm xe tải rỗng, xe tải đầy - trên tất cả các kết nối này.
Ngược lại, kiến trúc pub-sub đơn giản hóa giao tiếp. Kết nối trực tiếp và các yêu cầu lặp lại đối với dữ liệu là không cần thiết.
Mạng liên kết được thay thế bằng một liên kết duy nhất từ mỗi thiết bị đến broker (còn gọi là máy chủ). Kết nối giữa clients và nhà broker được giữ mở và cực kỳ nhẹ. Chỉ có hai thứ đi qua kết nối này: dữ liệu đã được thay đổi và một tín hiệu nhỏ để cho nhà môi giới biết rằng khách hàng vẫn ở đó.
Cũng quay về ví dụ xe tải, hệ thống giao thông này có ít đường hơn và lưu lượng xe tải giảm dần.
Pub-sub: tốt cho lưu lượng lớn và mạng nhẹ
Vì vậy, mô hình pub-sub có thể sẽ là sự lựa chọn nếu bạn có nhiều máy chủ và nhiều máy khách cần chia sẻ dữ liệu và dịch vụ.
Vì broker là trung tâm thanh toán dữ liệu trung tâm, các máy chủ riêng lẻ sẽ không bị áp lực để phục vụ nhiều máy khách và các máy khách cũng không cần phải kết nối với nhiều máy chủ. Ngoài ra, tổng lưu lượng mạng bị giảm do dữ liệu được xuất và gửi trên cơ sở báo cáo theo từng ngoại lệ (RBE) — tức là chỉ khi dữ liệu thay đổi — thay vì theo khoảng thời gian đều đặn.
Pub-sub cũng phát huy khá năng khi gặp những bài toán như khó thiết lập kết nối trực tiếp giữa máy khách và máy chủ hoặc khi mạng có băng thông thấp, đắt tiền hoặc không đáng tin cậy — ví dụ: khi giám sát thiết bị ở những vị trí xa.
Các Ưu điểm cụ thể với MQTT Sparkplug
Giao thức truyền tải pub-sub MQTT thường được nhắc đến cho các ứng dụng internet vạn vật (IoT). MQTT là một tiêu chuẩn OASIS và một tiêu chuẩn ISO (https://en.wikipedia.org/wiki/MQTT). Để biết thêm về giao thức, hãy xem mqtt.org.
Ngày nay, MQTT thường được sử dụng cho các ứng dụng IoT cá nhân, MQTT có lịch sử công nghiệp. Nó được phát minh vào năm 1999 cho một ứng dụng đường ống dẫn dầu và khí đốt ở Oklahoma, nhằm giải quyết các vấn đề liên lạc đắt tiền qua các đường truyền vệ tinh từ các địa điểm xa xôi.
Sparkplug được phát triển gần đây hơn (thông số kỹ thuật được phát hành vào năm 2016) bởi Cirrus Link Solutions (thuộc sở hữu của Arlen Nipper, một trong những người đồng phát minh ra MQTT). Mục đích của nó là để công nghiệp hóa MQTT hơn nữa: giúp làm cho MQTT phù hợp với các giao tiếp quan trọng, cũng như dễ triển khai và quản lý hơn, bằng cách thêm tính năng đóng gói nhị phân, trạng thái và định nghĩa chủ đề.
Tất nhiên các vấn đề về cài đặt từ xa và kết nối mạng mỏng manh hoặc đắt tiền không chỉ giới hạn trong ngành dầu khí. Để giải quyết chúng, MQTT với Sparkplug cung cấp ba lợi ích bổ sung so với request-respond bao gồm:
- Do tải trọng được nén và dữ liệu di chuyển hiệu quả, ngay cả các thiết bị từ xa có kết nối không thường xuyên hoặc băng thông thấp cũng có thể xuất bản hoặc đăng ký dữ liệu.
- Các thiết bị ngoại tuyến có thể kết nối lại với broker, gửi hoặc nhận dữ liệu hiện tại và cả một lượng dữ liệu đệm được chỉ định để giúp lấp đầy khoảng trống.
- Và đối với các data publisher, ta có một lợi thế bảo mật quan trọng: dữ liệu được xuất bản bằng kết nối gửi đi.
Điểm cuối cùng này là điểm cân nhắc chính để thiết lập mạng và gửi dữ liệu một cách an toàn mà không cần quá nhiều sự trợ giúp từ bộ phận công nghệ thông tin (CNTT) của công ty. Tất cả tường lửa đều chặn lưu lượng đến (ví dụ: một máy khách bên ngoài yêu cầu dữ liệu từ một máy chủ nội bộ). Nhưng chúng thường cho phép các kết nối gửi đi qua các cổng TCP.
Bởi vì dữ liệu pub-sub được gửi từ các thiết bị và phần mềm chỉ sử dụng các liên lạc đi (tới nhà môi giới), các liên lạc này không yêu cầu VPN hoặc chuyển tiếp cổng. Điều đó có nghĩa là bạn có thể thường xuyên di chuyển dữ liệu đến nơi bạn cần mà không đòi hỏi nhiều thời gian hoặc nỗ lực từ phía CNTT.
Một lợi thế bảo mật quan trọng khác của kiến trúc MQTT là tất cả bảo mật được quản lý tại một nơi: broker. Tất cả Danh sách kiểm soát truy cập (ACL), tên người dùng / mật khẩu và cổng được quản lý tại broker, có thể được đặt an toàn trên mạng công ty hoặc trong đám mây. Các cổng, xác thực người dùng và ACL không bao giờ được quản lý ở phía client. Điều này đồng nghĩa với ít khả năng bị tấn công hơn.
