Skip to main content

Các chức năng chi tiết trên Magistrala

Hệ thống Magistrala (SuperMQ) được thiết kế theo mô hình microservices cực kỳ chặt chẽ, tập trung vào khả năng mở rộng (scalability) và bảo mật đa tầng. Dưới đây là chi tiết các thành phần lõi mà bạn quan tâm:

1. Domain (Miền quản trị)

Domain là cấp độ cao nhất trong kiến trúc đa người dùng (Multi-tenancy). Nó tạo ra một ranh giới biệt lập hoàn toàn cho dữ liệu và tài nguyên.
  • Chức năng: Tách biệt các khách hàng hoặc các dự án lớn. Mọi thứ bên trong Domain (Clients, Channels, Groups) đều thuộc quyền sở hữu riêng của Domain đó.
  • Đặc điểm: Một hệ thống SuperMQ có thể chạy hàng nghìn Domain cùng lúc mà không lo chồng chéo dữ liệu.
User domain relationship: Trong hệ thống Magistrala, khi một người dùng mới đăng ký, họ sẽ không mặc định có quyền truy cập vào các tên miền (domains). Quy trình quản lý quyền truy cập được quy định như sau:
  • Lời mời tham gia: Quản trị viên tên miền (Domain Administrator) phải gửi lời mời và chỉ định vai trò cho người dùng trong tên miền đó. Các vai trò phổ biến bao gồm: Quản trị viên (administrator), Biên tập viên (editor), Người xem (viewer) hoặc Thành viên (member).
  • Đối tượng mời: Quản trị viên có thể mời những người đã có tài khoản trên Magistrala hoặc mời người dùng mới thông qua địa chỉ Email.
  • Chấp nhận lời mời: Sau khi đăng ký tài khoản thành công, người dùng có thể chấp nhận các lời mời tham gia vào tên miền.
  • Quyền tạo tên miền: Tất cả người dùng trong Magistrala đều có quyền tự tạo tên miền mới.
  • Quyền hạn mặc định: Người tạo ra tên miền sẽ nghiễm nhiên trở thành Quản trị viên của tên miền đó.
Note: Không có cách nào để hạn chế user tự tạo nhiều domain, channel và client (có thể tự tạo app riêng để quản lý). Hiện tại, phần billing service có thể hạn chế user tự tạo nhiều channel và client trong 1 domain nhưng phần này vẫn chưa hoàn thiện và chưa có api.

2. Member & Role (Thành viên & Vai trò)

Đây là lớp quản lý con người trong hệ thống.
  • Member Domain: Là một User được gán vào một Domain cụ thể. Một User có thể là thành viên của nhiều Domain.
  • Role (Vai trò): Định nghĩa quyền hạn thông qua SpiceDB (Relationship-based Access Control).
    • Administrator: Toàn quyền quản lý Domain.
    • Editor/Viewer: Quyền hạn chế hơn chỉ được thao tác hoặc xem dữ liệu (Hiện tại chỉ có role admin, Editor và Viewr phải custom lại role).
Note: Trong một domain, ta có thể điều chỉnh role ở Domain role và Group role. Domain role có quyền hạn cao nhất để điều chỉnh thiết bị phía dưới. Vai trò của Group role còn hơi mơ hồ (vì Domain role đã bao gồm hết tất cả các action).

3. Invitation (Lời mời)

Cơ chế để mở rộng thành viên trong Domain một cách bảo mật.
  • Chức năng: Admin gửi một lời mời (thường qua Email hoặc Token) cho một User khác.
  • Quy trình: Lời mời sẽ có trạng thái (Pending, Accepted, Rescinded). Khi User chấp nhận, hệ thống tự động tạo mối quan hệ (Relationship) trong SpiceDB để cấp quyền cho User đó vào Domain.

4. Group (Nhóm tài nguyên)

Group dùng để tổ chức các Client (Thiết bị) và Channel (Kênh) theo cấu trúc thư mục hoặc logic nghiệp vụ.
  • Chức năng: Gom nhóm thiết bị theo vị trí (Tầng 1, Tầng 2) hoặc chức năng (Nhóm cảm biến, Nhóm cơ cấu chấp hành).
  • Phân quyền: Bạn có thể gán quyền cho một User chỉ được quản lý một Group nhất định thay vì toàn bộ Domain.
Note:  Một group có thể add nhiều client và channel nhưng một client hoặc channel không add nhiều group, không có chức năng share trực tiếp client và channel của group này qua cho group khác. Nhưng có thể share gián tiếp thông qua rule engine (cái này sẽ viết trong trang khác).

5. Client (Thiết bị/Ứng dụng)

Trong Magistrala, Client (trước đây gọi là Thing) đại diện cho bất kỳ thực thể nào kết nối vào hệ thống.
  • Chức năng: Có thể là thiết bị phần cứng (cảm biến) hoặc ứng dụng phần mềm.
  • Danh tính: Mỗi Client có một bộ IDKey duy nhất để xác thực (Authentication) khi kết nối qua MQTT, HTTP, hoặc CoAP.

6. Channel (Kênh truyền thông)

Channel là "đường ống" để dữ liệu đi qua.
  • Chức năng: Kết nối các Clients với nhau. Một Client muốn gửi tin nhắn cho Client khác hoặc lên Server thì cả hai phải cùng được "Connect" vào một Channel.
  • Bảo mật: Đây là lớp bảo mật thứ hai. Ngay cả khi Client có Key đúng, nhưng nếu không được Connect vào Channel, tin nhắn sẽ bị chặn ngay lập tức.

7. Message (Tin nhắn)

Dữ liệu thô di chuyển trong hệ thống.

  • Định dạng: Thường tuân theo chuẩn SenML (Sensor Measurement Lists) để đồng nhất dữ liệu từ nhiều loại cảm biến khác nhau.

  • Luồng đi: Client -> Adapter (MQTT/HTTP) -> Message Broker (NATS/RabbitMQ) -> Writer (Postgres/InfluxDB).

Note: Để có thể lưu và query dữ liệu trên message, ta cần phải tạo rule để các dữ liệu từ channel phải được đưa vô internal DB (database khác vẫn còn test). Có thể query dữ liệu từng field và từng mốc thời gian khác nhau. Ta còn có thể filt và query từng thiết bị, protocol, data name, ...

8. Alarm & Report (Cảnh báo & Báo cáo)

Lớp xử lý dữ liệu sau khi đã được lưu trữ.
  • Alarm: Theo dõi dữ liệu thời gian thực. Nếu nhiệt độ > 50°C, hệ thống tạo ra một trạng thái "Alarm".
  • Report: Tổng hợp dữ liệu từ Postgres/InfluxDB theo thời gian (ngày, tuần, tháng) để xuất ra các biểu đồ hoặc file PDF/CSV phục vụ phân tích xu hướng.

9. Rule Engine (Công cụ quy tắc)

Đây là "bộ não" tự động hóa của hệ thống.
  • Chức năng: Cho phép thiết lập các logic "Nếu - Thì" (If-This-Then-That).
  • Ví dụ: "Nếu (Cảm biến nhiệt độ > 30°C) THÌ (Gửi tin nhắn bật điều hòa tới Channel điều khiển)".
  • Cấu trúc: Thường bao gồm Source (Nguồn tin), Filter/Logic (Điều kiện), và Action (Hành động: gửi email, gọi webhook, hoặc gửi ngược lại tin nhắn MQTT).