Việc ra quyết định lựa chọn sử dụng dịch vụ nào trên nền tảng đám mây để hệ thống đạt hiệu quả thực tế tốt nhất sẽ phụ thuộc vào yêu cầu cụ thể và thiết kế ban đầu của hệ thống. Để mọi người cùng tham khảo thì trong bài viết này, mình đề xuất thiết kế luồng dữ liệu cho 3 loại gói tin chính trong ứng dụng nhà thông minh là: dữ liệu cảm biến, dữ liệu điều khiển và dữ liệu trạng thái.
1. Thiết kế luồng dữ liệu cảm biến: đây là luồng dữ liệu quan trọng nhất trong hầu hết các hệ thống IoT, các cảm biến được xem là giác quan của một hệ thống IoT. Dữ liệu cảm biến giúp kích hoạt các giải pháp IoT trong ứng dụng thực tế. Đối với thiết kế của một hệ thống đơn giản, dữ liệu từ thiết bị gửi đến máy chủ thường sẽ gửi trực tiếp đến cổng (port) một tiến trình chuyên biệt như web server, serverless function,… tiến trình này sẽ liên kết với CSDL thực hiện việc lưu trữ dữ liệu hoặc các logic khác.
Hình 1. Thiết kế của hệ thống IoT đơn giản
Tuy nhiên kiến trúc như vậy sẽ chỉ vận hành tốt trong điều kiện hệ thống có quy mô nhỏ, số lượng thiết bị và dữ liệu ít, khó khăn khi cần mở rộng nâng cấp hệ thống. Mình và nhóm đề xuất thiết kế luồng dữ liệu cảm biến với quy trình 4 bước nhằm đảm bảo tính tin cậy, khả năng mở rộng đối với lượng dữ liệu lớn theo thời gian ở Hình 2.
Hình 2. Kiến trúc luồng dữ liệu cảm biến theo quy trình 4 bước
Chi tiết các bước:
(1) Thiết bị sẽ kết nối đến đám mây qua các giao thức ứng dụng trên nền giao thức TCP (MQTT, Websocket hoặc HTTP) tích hợp các phương thức bảo mật, xác thực được cung cấp bởi đám mây, sau đó có thể gửi dữ liệu an toàn đến đám mây qua kết nối đã được thiết lập.
(2) Dữ liệu sau khi gửi đến đám mây sẽ được đưa vào hàng đợi chuyên dụng (tiêu chuẩn hoặc FIFO) trước khi đẩy đến dịch vụ thực hiện các logic chính của hệ thống được xây dựng dưới dạng serverless function. Đây là bước khác biệt so với các mô hình đơn giản, vì trong trường hợp dữ liệu được gửi lên tăng đột biến không đoán trước được, trong thời gian serverless function đang thực thi một sự kiện thì có thể có hàng trăm nghìn gói tin khác được gửi lên sẽ dẫn đến tình trạng lỗi thắt cổ chai làm mất gói tin. Việc sử dụng cơ chế hàng đợi lưu trữ trước khi đẩy đến các dịch vụ xử lý phía sau sẽ mang lại các ưu điểm như khả năng mở rộng, chịu tải cao tránh trường hợp xảy ra lỗi thắt cổ chai làm mất gói tin, có thể lựa chọn sử dụng hàng đợi theo cấu trúc FIFO hoặc tiêu chuẩn tùy ứng dụng cụ thể đảm bảo tính linh động, ngoài ra giúp tăng thêm lớp bảo mật và xác thực tài nguyên truy cập dữ liệu.
(3) Dữ liệu được tổ chức lưu trữ ở hàng đợi sẽ được serverless function thực hiện đọc ra và xử lý tuần tự theo các logic được lập trình sẵn trước khi lưu vào CSDL.
(4) Dữ liệu được lưu trữ vào CSDL theo định dạng và cấu trúc NoSQL được tạo sẵn.
2. Thiết kế luồng dữ liệu điều khiển và cập nhật trạng thái: Trong các hệ thống IoT, một tính năng quan trọng khác điều khiển từ xa và đồng bộ trạng thái thiết bị. Vấn đề đặt ra là việc điều khiển, cập nhật trạng thái thiết bị sẽ đến từ nhiều nguồn khác nhau (từ ứng dụng website, ứng dụng điện thoại, điều khiển tại chỗ) rất dễ xảy ra xung đột nên cần có một quy trình truyền, nhận, xử lý dữ liệu đảm bảo các yêu cầu: ứng dụng người dùng có thể giám sát trạng thái hiện tại của thiết bị, ứng dụng người dùng có thể điều khiển thiết bị từ xa, thiết bị có thể được điều khiển tại chỗ, giải quyết được bài toán về đồng bộ trạng thái thực của thiết bị và trạng thái hiển thị trên ứng dụng người dùng, giải quyết được bài toán về điều khiển từ xa khi thiết bị mất kết nối với đám mây. Mình đề xuất sử dụng mô hình tổ chức dữ liệu thiết bị gọi là Current state (Trạng thái hiện tại) sẽ được tổ chức lưu trữ thành 2 khối riêng biệt trong CSDL theo kiến trúc No-SQL gọi là reported và desired được trình bày trong Hình 3.
Hình 3. Mô hình lưu trữ và luồng dữ liệu trạng thái thiết bị
- Reported: đại diện cho trạng thái thực của thiết bị, chỉ có thiết bị mới được cập nhật trạng thái vào khối này. Ứng dụng nếu muốn biết được trạng thái hiện tại của thiết bị để thực hiện tính năng giám sát sẽ thực hiện truy vấn đọc dữ liệu từ khối reported này.
- Desired: đại diện cho trạng thái điều khiển, cập nhật mà ứng dụng mong muốn thiết bị thực hiện, các ứng dụng khác nhau có thể cùng cập nhật trạng thái vào khối này. Dữ liệu của khối này sẽ tự động được gửi đến thiết bị khi có yêu cầu điều khiển mới từ ứng dụng hoặc thiết bị có thể chủ động đọc dữ liệu từ khối này khi cần thực hiện quá trình đồng bộ. Sau khi đọc dữ liệu từ khối desired, thiết bị sẽ xử lý yêu cầu và thực hiện đồng bộ trạng thái lên khối reported.
Mô hình reported-desired phân tách dữ liệu của thiết bị và ứng dụng thành hai khối riêng biệt đảm bảo tính độc lập, không bị xung đột hoặc bất đồng bộ trong quá trình sử dụng vì các nguyên tắc:
- Dữ liệu ở khối reported được cập nhật bởi thiết bị, giá trị chỉ thay đổi khi trạng thái thực thiết bị thay đổi, vì vậy ứng dụng khi đọc trạng thái hiện tại của thiết bị sẽ không bị sai đảm bảo độ tin cậy khi theo dõi giám sát từ xa.
- Trong trường hợp thiết bị mất kết nối đến đám mây, ứng dụng vẫn có thể thực hiện yêu cầu cập nhật trạng thái từ xa vào khối desired và không lưu đè vào khối reported tránh làm sai trạng thái thực của thiết bị; thiết bị có thể đọc về và xử lý yêu cầu khi trực tuyến trở lại và cập nhật ngược lại reported khi thành công để đồng bộ với ứng dụng.
Khi triển khai thực tế, ngoài mục đích giải quyết các bài toán về quá trình điều khiển, giám sát, đồng bộ trạng thái các thiết bị có tính năng điều khiển từ xa và tương tác tại chỗ (ví dụ: relay, đèn, quạt,…), dữ liệu lưu trữ ở CSDL Trạng thái hiện tại có thể được sử dụng kết hợp lưu trữ thêm các thông số khác của thiết bị như giá trị cảm biến, thông số hoạt động,… vì mặc dù giá trị cảm biến thường có CSDL riêng lưu theo cấu trúc chuỗi thời gian phục vụ giám sát phân tích số lượng lớn nhưng nếu tận dụng CSDL Trạng thái hiện tại này để lưu trữ giá trị cảm biến gần nhất thì sẽ rất thuận tiện cho việc truy xuất giá trị tức thời thay vì phải kết nối truy vấn đến CSDL tập trung với dung lượng dữ liệu lớn sẽ tiêu tốn nhiều tài nguyên và thời gian thực thi hơn. Mỗi loại dữ liệu khác nhau như vậy được xem là một Khối dữ liệu trong mô hình ở trên.
Qua bài chia sẻ này, hi vọng các bạn đã có thể tham khảo và hiểu thêm vềkiến trúc các luồng dữ liệu trong ứng dụng nhà thông minh sử dụng điện toán đám mây IoT, từ đó có được thiết kế phù hợp cho ứng dụng cụ thể của các bạn.
Chúc các bạn thành công!