Nền Tảng IoT: Kiến Trúc, Giao Thức & Giao Tiếp Thiết Bị

Chào mừng bạn đến với Phase 1 của Lộ Trình IoT Patterns & Strategies! Bài viết này xây dựng nền tảng bạn cần trước khi đi sâu vào các giao thức cụ thể, data pipelines, hoặc production patterns. Chúng ta sẽ tìm hiểu cách hệ thống IoT được cấu trúc, cách thiết bị giao tiếp, và công nghệ nào phù hợp với trường hợp sử dụng nào.

Nếu bạn là backend hoặc full-stack developer, nhiều khái niệm IoT sẽ quen thuộc — message queues, APIs, databases — nhưng các ràng buộc khác nhau cơ bản. Thiết bị có hàng kilobytes RAM, mạng liên tục mất kết nối, và code của bạn có thể chạy cả thập kỷ mà không được cập nhật.

Đến cuối bài viết này, bạn sẽ hiểu toàn bộ IoT technology stack và có thể đưa ra quyết định có cơ sở về kiến trúc, kết nối, và giao thức cho bất kỳ dự án IoT nào.

Bạn Sẽ Học Được Gì

✅ Hiểu mô hình kiến trúc IoT bốn tầng
✅ Nhận biết các loại thiết bị khác nhau và ràng buộc của chúng
✅ So sánh các lựa chọn kết nối (WiFi, BLE, LoRaWAN, Zigbee, Cellular, NB-IoT)
✅ Chọn đúng giao thức truyền thông (MQTT, CoAP, AMQP, HTTP, WebSocket)
✅ Triển khai publish-subscribe, request-response, và store-and-forward patterns
✅ Hiểu digital twins và device shadow patterns
✅ Phân biệt IoT và Industrial IoT (IIoT)

Kiến Trúc IoT Bốn Tầng

Mọi hệ thống IoT, từ bộ điều nhiệt thông minh đến nhà máy công nghiệp, đều tuân theo cùng một kiến trúc phân tầng cơ bản:

Tầng 1: Tầng Cảm Nhận (Thiết Bị & Cảm Biến)

Tầng cảm nhận là nơi IoT gặp thế giới vật lý. Thiết bị cảm nhận (nhiệt độ, chuyển động, áp suất, vị trí GPS) và hành động (bật motor, mở van, hiển thị thông báo).

Các ràng buộc chính ở tầng này:

• Bộ nhớ: Vi điều khiển (MCUs) có 64KB-512KB RAM — không phải megabytes, không phải gigabytes
• CPU: Tốc độ xung nhịp 80-240MHz — chậm hơn hàng nghìn lần so với laptop của bạn
• Năng lượng: Nhiều thiết bị chạy pin hàng tháng hoặc hàng năm
• Lưu trữ: Không có ổ đĩa — firmware và dữ liệu chia sẻ vài megabytes flash memory

// Một bản đọc cảm biến điển hình trong thiết bị IoT
interface SensorReading {
  deviceId: string;
  timestamp: number;       // Unix timestamp (tiết kiệm bytes so với ISO string)
  type: "temperature" | "humidity" | "pressure" | "gps";
  value: number;
  unit: string;
  batteryLevel?: number;   // 0-100, quan trọng cho quản lý năng lượng
}
 
// Ví dụ: bản đọc cảm biến nhiệt độ
const reading: SensorReading = {
  deviceId: "greenhouse-sensor-042",
  timestamp: 1739520000,
  type: "temperature",
  value: 23.5,
  unit: "celsius",
  batteryLevel: 87,
};

Tầng 2: Tầng Mạng (Kết Nối)

Tầng mạng vận chuyển dữ liệu giữa thiết bị và tầng xử lý. Khác với phát triển web nơi bạn mặc định HTTP đáng tin cậy, kết nối IoT thay đổi rất lớn:

Tầng 3: Tầng Xử Lý (Edge & Cloud)

Đây là nơi dữ liệu cảm biến thô trở thành thông tin có thể hành động. Xử lý diễn ra ở hai cấp:

Xử lý Edge — tại hoặc gần thiết bị:

• Lọc nhiễu và các bản đọc không hợp lệ
• Tổng hợp dữ liệu trước khi gửi lên cloud (gửi trung bình, không phải mọi bản đọc)
• Chạy mô hình ML cục bộ cho quyết định thời gian thực
• Đệm dữ liệu trong thời gian mất kết nối

Xử lý Cloud — trong data center:

• Lưu trữ dài hạn trong time-series databases
• Phân tích phức tạp và huấn luyện ML
• Tương quan liên thiết bị
• Hệ thống dashboard và cảnh báo

Tầng 4: Tầng Ứng Dụng

Tầng trên cùng là nơi con người và các hệ thống khác tương tác với dữ liệu IoT:

• Dashboards: Trực quan hóa thời gian thực về sức khỏe thiết bị và metrics (Grafana, custom UIs)
• APIs: RESTful hoặc GraphQL APIs để tích hợp dữ liệu IoT vào ứng dụng kinh doanh
• Cảnh báo: Thông báo tự động khi vượt ngưỡng (nhiệt độ quá cao, thiết bị offline)
• Phân tích: Phân tích lịch sử, phát hiện xu hướng, bảo trì dự đoán
• Tự động hóa: Rules engines kích hoạt hành động dựa trên dữ liệu thiết bị (nếu nhiệt độ > 30°C, bật quạt)

Loại Thiết Bị và Ràng Buộc

Không phải tất cả thiết bị IoT đều giống nhau. Hiểu phổ thiết bị giúp bạn thiết kế chiến lược giao tiếp phù hợp:

Insight quan trọng: thiết kế giao thức và kiến trúc cho thiết bị hạn chế nhất trong hệ thống của bạn — không phải thiết bị mạnh nhất.

// Các thiết bị khác nhau gửi payloads rất khác nhau
// Cảm biến hạn chế: payload nhỏ, gửi mỗi 15 phút
const constrainedPayload = {
  id: "s042",
  t: 23.5,       // key viết tắt tiết kiệm bytes
  h: 67,
  bat: 87,
};
 
// Thiết bị edge: payload phong phú với phân tích cục bộ
const edgePayload = {
  deviceId: "edge-gateway-01",
  timestamp: "2026-02-14T10:30:00Z",
  connectedDevices: 24,
  aggregatedReadings: {
    temperatureAvg: 23.2,
    temperatureMin: 21.1,
    temperatureMax: 25.8,
    humidityAvg: 65,
  },
  alerts: [
    { sensorId: "s017", type: "lowBattery", value: 12 },
  ],
  networkStats: {
    packetLoss: 0.02,
    latencyMs: 45,
  },
};

Lựa Chọn Kết Nối

Chọn đúng công nghệ kết nối là một trong những quyết định kiến trúc IoT quan trọng nhất. Đây là framework quyết định:

WiFi

Phù hợp nhất cho: Thiết bị trong nhà có nguồn điện (ổ cắm thông minh, camera, màn hình).

• Ưu điểm: Băng thông cao, phổ biến, phát triển dễ dàng
• Nhược điểm: Tiêu thụ năng lượng cao, phạm vi hạn chế, nghẽn mạng trong triển khai dày đặc
• Sử dụng điển hình: Smart home, theo dõi tài sản trong nhà, factory HMIs

Bluetooth Low Energy (BLE)

Phù hợp nhất cho: Wearables, beacons, mạng cảm biến tầm ngắn.

• Ưu điểm: Rất tiết kiệm năng lượng, tích hợp trong smartphones, modules rẻ
• Nhược điểm: Phạm vi ngắn (10-30m), băng thông thấp, cần phone/gateway để kết nối cloud
• Sử dụng điển hình: Fitness trackers, iBeacons, proximity sensors

LoRaWAN

Phù hợp nhất cho: Triển khai ngoài trời tầm xa, tiết kiệm năng lượng.

• Ưu điểm: Phạm vi 2-15km, chạy pin hàng năm, xuyên tường tốt
• Nhược điểm: Băng thông rất thấp (50Kbps), độ trễ cao (giây), downlink hạn chế
• Sử dụng điển hình: Cảm biến nông nghiệp, hạ tầng thành phố thông minh, đo lường nước

Zigbee / Thread

Phù hợp nhất cho: Mạng mesh dày đặc trong các tòa nhà.

• Ưu điểm: Mesh tự phục hồi, tiết kiệm năng lượng, 250+ thiết bị mỗi mạng
• Nhược điểm: Phạm vi hạn chế mỗi hop, cần coordinator/border router
• Sử dụng điển hình: Chiếu sáng smart home, điều khiển HVAC, tự động hóa tòa nhà

Cellular (4G/5G)

Phù hợp nhất cho: Tài sản di động và ứng dụng băng thông cao.

• Ưu điểm: Phạm vi không giới hạn, băng thông cao (đặc biệt 5G), đáng tin cậy
• Nhược điểm: Năng lượng cao, chi phí data định kỳ, chi phí module
• Sử dụng điển hình: Theo dõi đội xe, xe kết nối, giám sát video

NB-IoT (Narrowband IoT)

Phù hợp nhất cho: Cảm biến cố định cần phủ sóng cellular với năng lượng thấp.

• Ưu điểm: Phủ sóng sâu trong nhà, tiết kiệm năng lượng, độ tin cậy cấp nhà mạng
• Nhược điểm: Băng thông thấp (250Kbps), độ trễ cao hơn LTE, hỗ trợ di động hạn chế
• Sử dụng điển hình: Đo lường thông minh, giám sát tiện ích, theo dõi tài sản

Tổng Quan Giao Thức Truyền Thông

Khi thiết bị có kết nối, nó cần một giao thức để cấu trúc thông điệp. Đây là so sánh các giao thức IoT chính:

MQTT — Tiêu Chuẩn IoT

MQTT (Message Queuing Telemetry Transport) là giao thức IoT được sử dụng rộng rãi nhất. Nó sử dụng mô hình publish-subscribe trong đó thiết bị publish thông điệp đến topics và subscribers nhận chúng thông qua một broker.

import mqtt from "mqtt";
 
// Kết nối đến MQTT broker
const client = mqtt.connect("mqtt://broker.hivemq.com:1883");
 
// Publish dữ liệu cảm biến đến một topic
client.on("connect", () => {
  setInterval(() => {
    const payload = JSON.stringify({
      temperature: 22.5 + Math.random() * 5,
      humidity: 60 + Math.random() * 20,
      timestamp: Date.now(),
    });
 
    // Cấu trúc topic: {org}/{location}/{device-type}/{device-id}
    client.publish(
      "acme/greenhouse-1/sensors/temp-042",
      payload,
      { qos: 1 } // Giao hàng ít nhất một lần
    );
  }, 10000); // Mỗi 10 giây
});

// Subscribe dữ liệu cảm biến ở phía cloud
const subscriber = mqtt.connect("mqtt://broker.hivemq.com:1883");
 
subscriber.on("connect", () => {
  // Wildcard '+' khớp bất kỳ một level nào
  subscriber.subscribe("acme/greenhouse-1/sensors/+");
});
 
subscriber.on("message", (topic, message) => {
  const data = JSON.parse(message.toString());
  console.log(`[${topic}] Nhiệt độ: ${data.temperature}°C`);
 
  // Cảnh báo nếu nhiệt độ vượt ngưỡng
  if (data.temperature > 35) {
    subscriber.publish("acme/greenhouse-1/alerts", JSON.stringify({
      type: "highTemperature",
      value: data.temperature,
      deviceTopic: topic,
      timestamp: Date.now(),
    }));
  }
});

CoAP — REST cho Thiết Bị Hạn Chế

CoAP (Constrained Application Protocol) mang mô hình REST quen thuộc (GET, PUT, POST, DELETE) đến các thiết bị không thể chịu overhead TCP. Nó chạy trên UDP.

# CoAP GET request để đọc giá trị cảm biến
from coapthon.client.helperclient import HelperClient
 
client = HelperClient(server=("coap://sensor-042.local", 5683))
 
# GET /temperature — giống HTTP nhưng qua UDP
response = client.get("temperature")
print(f"Nhiệt độ: {response.payload}")  # "23.5"
 
# PUT /actuator/fan — điều khiển thiết bị
client.put("actuator/fan", payload="on")
 
# OBSERVE /temperature — giống WebSocket nhưng cho CoAP
# Server đẩy cập nhật khi giá trị thay đổi
def callback(response):
    print(f"Cập nhật: {response.payload}")
 
client.observe("temperature", callback)

Khi Nào Dùng Giao Thức Nào

Message Patterns

Hệ thống IoT sử dụng bốn message patterns cơ bản. Hiểu khi nào dùng mỗi pattern là rất quan trọng:

Publish-Subscribe (Pub/Sub)

Pattern IoT thống trị. Thiết bị publish đến topics; consumers quan tâm subscribe. Broker xử lý routing.

Khi nào dùng: Báo cáo dữ liệu cảm biến, telemetry, phân phối sự kiện — bất kỳ tình huống nào nhiều consumers có thể cần cùng dữ liệu.

Request-Response

Mô hình HTTP quen thuộc. Client gửi request, server gửi response. Sử dụng trong CoAP và HTTP-based IoT.

Khi nào dùng: Cấu hình thiết bị, kiểm tra trạng thái theo yêu cầu, lệnh actuator cần xác nhận.

Fire-and-Forget

Thiết bị gửi thông điệp và không chờ xác nhận. Đây là MQTT QoS 0 — nhanh nhất nhưng ít đáng tin cậy nhất.

Khi nào dùng: Telemetry tần suất cao nơi mất dữ liệu thỉnh thoảng là chấp nhận được (ví dụ: gửi tọa độ GPS mỗi giây — mất một bản đọc không sao).

Store-and-Forward

Thiết bị lưu trữ thông điệp cục bộ khi kết nối không khả dụng và chuyển tiếp khi kết nối được khôi phục. Rất quan trọng cho triển khai IoT với mạng không đáng tin cậy.

// Store-and-forward pattern cho kết nối không đáng tin cậy
class StoreAndForwardClient {
  private queue: SensorReading[] = [];
  private isConnected = false;
 
  constructor(private mqttClient: mqtt.MqttClient) {
    mqttClient.on("connect", () => {
      this.isConnected = true;
      this.flush(); // Gửi thông điệp đã xếp hàng
    });
    mqttClient.on("offline", () => {
      this.isConnected = false;
    });
  }
 
  publish(reading: SensorReading): void {
    if (this.isConnected) {
      this.mqttClient.publish(
        `sensors/${reading.deviceId}`,
        JSON.stringify(reading),
        { qos: 1 }
      );
    } else {
      // Lưu cục bộ khi offline
      this.queue.push(reading);
      console.log(`Đã xếp hàng thông điệp (${this.queue.length} đang chờ)`);
    }
  }
 
  private flush(): void {
    console.log(`Đang gửi ${this.queue.length} thông điệp đã xếp hàng...`);
    while (this.queue.length > 0) {
      const reading = this.queue.shift()!;
      this.mqttClient.publish(
        `sensors/${reading.deviceId}`,
        JSON.stringify(reading),
        { qos: 1 }
      );
    }
  }
}

Hướng Dẫn Chọn Pattern

Giao Tiếp Thiết Bị Đến Cloud

Thiết bị kết nối đến cloud qua ba đường chính:

Đường 1: Kết Nối Trực Tiếp

Thiết bị kết nối trực tiếp đến cloud broker hoặc API. Kiến trúc đơn giản nhất, nhưng yêu cầu thiết bị phải có kết nối internet (WiFi, Cellular).

Ưu điểm: Đơn giản, độ trễ thấp đến cloud Nhược điểm: Cần internet luôn bật, không xử lý cục bộ, mỗi thiết bị cần thông tin đăng nhập cloud

Đường 2: Qua Gateway

Thiết bị hạn chế (BLE sensors, Zigbee nodes) kết nối đến gateway cục bộ làm cầu nối đến cloud. Gateway xử lý chuyển đổi giao thức.

// Gateway: cầu nối BLE sensors đến MQTT cloud
import mqtt from "mqtt";
 
const cloudClient = mqtt.connect("mqtts://iot.cloud-provider.com", {
  clientId: "gateway-01",
  username: "gateway-01",
  password: process.env.GATEWAY_TOKEN,
});
 
// Mô phỏng dữ liệu cảm biến BLE nhận bởi gateway
function onBLESensorData(sensorId: string, data: Buffer) {
  const reading = parseBLEPayload(data); // Giải mã BLE advertisement
 
  // Dịch và chuyển tiếp đến cloud qua MQTT
  cloudClient.publish(
    `devices/${sensorId}/telemetry`,
    JSON.stringify({
      ...reading,
      gatewayId: "gateway-01",
      receivedAt: Date.now(),
    }),
    { qos: 1 }
  );
}
 
function parseBLEPayload(data: Buffer): Record<string, number> {
  // BLE payloads là binary nhỏ gọn — giải mã thành JSON
  return {
    temperature: data.readInt16LE(0) / 100,
    humidity: data.readUInt8(2),
    battery: data.readUInt8(3),
  };
}

Ưu điểm: Hỗ trợ thiết bị hạn chế, chuyển đổi giao thức cục bộ, thông tin đăng nhập tập trung Nhược điểm: Gateway là điểm lỗi đơn, thêm phức tạp

Đường 3: Qua Edge Node

Đường phức tạp nhất. Edge node (máy chủ nhỏ, industrial PC) xử lý dữ liệu cục bộ trước khi gửi tóm tắt đến cloud. Điều này giảm băng thông, độ trễ, và chi phí cloud.

Ưu điểm: Xử lý cục bộ, khả năng chịu offline, giảm chi phí cloud Nhược điểm: Phức tạp nhất, cần quản lý hạ tầng edge

Digital Twins

Digital twin là đại diện ảo của thiết bị vật lý, được duy trì trên cloud. Nó phản chiếu trạng thái hiện tại và cấu hình mong muốn của thiết bị.

Ý tưởng chính: ứng dụng tương tác với twin, không phải thiết bị. Nếu thiết bị offline, twin vẫn giữ trạng thái biết cuối cùng, và mọi thay đổi cấu hình được xếp hàng cho đến khi thiết bị kết nối lại.

// Digital twin: device shadow pattern
interface DeviceTwin {
  deviceId: string;
  // Trạng thái báo cáo: những gì thiết bị nói nó ĐANG LÀ
  reported: {
    temperature: number;
    humidity: number;
    fanSpeed: "off" | "low" | "high";
    firmwareVersion: string;
    lastSeen: number;
  };
  // Trạng thái mong muốn: những gì ứng dụng MUỐN nó là
  desired: {
    fanSpeed: "off" | "low" | "high";
    reportingInterval: number; // giây
    firmwareVersion: string;   // cho cập nhật OTA
  };
  // Metadata
  metadata: {
    lastReportedUpdate: number;
    lastDesiredUpdate: number;
  };
}
 
// Ứng dụng đặt trạng thái mong muốn
function setFanSpeed(twin: DeviceTwin, speed: "off" | "low" | "high") {
  twin.desired.fanSpeed = speed;
  twin.metadata.lastDesiredUpdate = Date.now();
  // Nền tảng giao trạng thái này cho thiết bị khi nó online
}
 
// Thiết bị báo cáo trạng thái hiện tại
function onDeviceReport(twin: DeviceTwin, report: Partial<DeviceTwin["reported"]>) {
  Object.assign(twin.reported, report);
  twin.metadata.lastReportedUpdate = Date.now();
 
  // Kiểm tra thiết bị đã áp dụng trạng thái mong muốn chưa
  if (twin.reported.fanSpeed !== twin.desired.fanSpeed) {
    console.log("Thiết bị chưa áp dụng tốc độ quạt mong muốn");
  }
}

Trường Hợp Sử Dụng Digital Twin

• Smart home: Đặt nhiệt độ bộ điều nhiệt mong muốn; thiết bị áp dụng khi thức dậy
• Quản lý đội xe: Theo dõi vị trí GPS biết cuối cùng ngay cả khi xe trong đường hầm
• Công nghiệp: Giám sát trạng thái máy, xếp hàng lệnh bảo trì cho cửa sổ dịch vụ tiếp theo
• Cập nhật OTA: Đặt phiên bản firmware mong muốn; thiết bị tải xuống khi thuận tiện

AWS IoT Core gọi đây là "Device Shadow." Azure IoT Hub gọi là "Device Twin." Pattern là giống nhau.

IoT vs IIoT (Industrial IoT)

Mặc dù kiến trúc tương tự, Industrial IoT có yêu cầu riêng:

Điểm chính: IIoT thêm yêu cầu nghiêm ngặt về an toàn, độ tin cậy, và điều khiển thời gian thực mà IoT consumer hiếm khi cần. Nếu bạn đang xây dựng cho nhà máy hoặc tiện ích, hãy nghiên cứu OPC-UA và tiêu chuẩn an toàn công nghiệp.

Kết Hợp Tất Cả: Nhà Kính Thông Minh

Hãy áp dụng mọi thứ chúng ta đã học để thiết kế hệ thống IoT cho nhà kính thông minh:

Yêu Cầu

• Giám sát nhiệt độ, độ ẩm, độ ẩm đất, và mức ánh sáng
• Tự động điều khiển quạt, tưới tiêu, và màn che nắng
• Gửi cảnh báo khi điều kiện ngoài phạm vi
• Hoạt động ngay cả khi kết nối internet không ổn định
• Hỗ trợ 50 node cảm biến trên nhà kính 2,000m²

Quyết Định Kiến Trúc

Quyết Định Đã Chọn

// Edge node: rules engine cục bộ cho nhà kính
interface GreenhouseState {
  zones: Map<string, ZoneState>;
}
 
interface ZoneState {
  temperature: number;
  humidity: number;
  soilMoisture: number;
  light: number;
  fanSpeed: "off" | "low" | "high";
  irrigating: boolean;
}
 
function evaluateRules(zone: ZoneState): Action[] {
  const actions: Action[] = [];
 
  // Quy tắc 1: Điều khiển nhiệt độ
  if (zone.temperature > 30) {
    actions.push({ type: "setFan", value: "high" });
  } else if (zone.temperature > 26) {
    actions.push({ type: "setFan", value: "low" });
  } else {
    actions.push({ type: "setFan", value: "off" });
  }
 
  // Quy tắc 2: Điều khiển tưới tiêu
  if (zone.soilMoisture < 30 && !zone.irrigating) {
    actions.push({ type: "startIrrigation", durationMinutes: 15 });
  }
 
  return actions;
}
 
type Action =
  | { type: "setFan"; value: "off" | "low" | "high" }
  | { type: "startIrrigation"; durationMinutes: number };

Lỗi Thường Gặp của Người Mới

Lỗi 1: Dùng HTTP cho Mọi Thứ

// ❌ SAI: Polling HTTP mỗi 5 giây từ 1,000 thiết bị
setInterval(async () => {
  const response = await fetch("https://api.example.com/telemetry", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(sensorData),
  });
  // Mỗi request: TCP handshake + TLS + headers = ~1KB overhead
  // 1,000 thiết bị × 12 requests/phút = 12,000 HTTP requests/phút
}, 5000);

// ✅ ĐÚNG: Dùng MQTT với persistent connection
const client = mqtt.connect("mqtt://broker.example.com");
// Một TCP connection, giữ kết nối. Publish overhead: ~2 bytes
client.publish("sensors/temp-042", JSON.stringify(sensorData), { qos: 1 });
// 1,000 thiết bị × 1 persistent connection = 1,000 TCP connections

HTTP tạo kết nối mới cho mỗi request (hoặc giữ một nhưng thêm overhead header lớn). MQTT duy trì một persistent connection với header tối thiểu 2 bytes.

Lỗi 2: Gửi Full JSON Khi Bytes Quan Trọng

// ❌ SAI: JSON payload dài dòng (180 bytes)
{
  "deviceIdentifier": "greenhouse-sensor-042",
  "readingType": "temperature",
  "readingValue": 23.5,
  "readingUnit": "celsius",
  "readingTimestamp": "2026-02-14T10:30:00.000Z"
}

// ✅ ĐÚNG: Payload nhỏ gọn (28 bytes) cho thiết bị hạn chế
{
  "id": "s042",
  "t": 23.5,
  "ts": 1739520600
}
// Hoặc tốt hơn nữa: binary protocol như CBOR hoặc Protobuf

Trên LoRaWAN với giới hạn payload 51 bytes, JSON dài dòng đơn giản không vừa. Dùng key ngắn, Unix timestamps, và cân nhắc định dạng binary.

Lỗi 3: Không Có Chiến Lược Offline

// ❌ SAI: Mất dữ liệu khi offline
function publishReading(data: SensorReading) {
  if (!client.connected) {
    console.log("Offline, bỏ bản đọc");
    return; // Dữ liệu mất vĩnh viễn!
  }
  client.publish(`sensors/${data.deviceId}`, JSON.stringify(data));
}

// ✅ ĐÚNG: Xếp hàng và thử lại với store-and-forward
function publishReading(data: SensorReading) {
  if (!client.connected) {
    offlineQueue.push(data);
    return;
  }
  client.publish(`sensors/${data.deviceId}`, JSON.stringify(data), { qos: 1 });
}
 
client.on("connect", () => {
  while (offlineQueue.length > 0) {
    const data = offlineQueue.shift()!;
    client.publish(`sensors/${data.deviceId}`, JSON.stringify(data), { qos: 1 });
  }
});

Thiết bị IoT thường xuyên mất kết nối. Luôn thiết kế cho kết nối gián đoạn.

Lỗi 4: Cùng Kiến Trúc cho Mọi Loại Thiết Bị

// ❌ SAI: Đối xử cảm biến pin đồng xu như cloud server
// Đừng bắt thiết bị hạn chế làm TLS handshakes mỗi 10 giây
// Đừng yêu cầu JSON parsing trên thiết bị 64KB RAM
// Đừng mong đợi kết nối đáng tin cậy từ cảm biến LoRaWAN ngoài trời
 
// ✅ ĐÚNG: Khớp kiến trúc với khả năng thiết bị
// Hạn chế → CoAP/UDP, binary payloads, hỗ trợ qua gateway
// Trung bình → MQTT, JSON, kết nối trực tiếp
// Mạnh → HTTPS, rich JSON, xử lý cục bộ

Tóm Tắt và Điểm Chính

✅ Kiến trúc IoT bốn tầng (Cảm Nhận, Mạng, Xử Lý, Ứng Dụng) áp dụng cho mọi hệ thống IoT
✅ Thiết kế cho thiết bị hạn chế nhất trong hệ thống — không phải thiết bị mạnh nhất
✅ MQTT là giao thức mặc định cho hầu hết use cases IoT — nhẹ, pub/sub, các mức QoS
✅ Lựa chọn kết nối phụ thuộc phạm vi, năng lượng và băng thông — WiFi trong nhà, LoRaWAN ngoài trời, Cellular cho di động
✅ Store-and-forward là thiết yếu — Thiết bị IoT thường xuyên mất kết nối, không bao giờ mất dữ liệu im lặng
✅ Digital twins tách rời ứng dụng khỏi thiết bị — luôn đọc/ghi twin, không phải thiết bị trực tiếp
✅ Edge processing giảm độ trễ và chi phí cloud — lọc và tổng hợp dữ liệu trước khi gửi lên cloud
✅ IIoT thêm yêu cầu an toàn và thời gian thực mà IoT consumer hiếm khi cần
✅ Chọn payload nhỏ gọn cho thiết bị hạn chế — key ngắn, định dạng binary, Unix timestamps

Tiếp Theo

Bây giờ bạn đã hiểu kiến trúc và nền tảng IoT, đã đến lúc đi sâu hơn vào các giao thức cung cấp năng lượng cho giao tiếp thiết bị.

Tiếp theo: IOT-3: Giao Thức Truyền Thông IoT (MQTT, CoAP, AMQP, WebSocket) — Đi sâu vào từng giao thức với thiết lập thực hành, cấu hình, và ví dụ thực tế sử dụng Mosquitto, RabbitMQ, và HiveMQ.

Bài Viết Liên Quan

• Lộ Trình IoT Patterns & Strategies — Tổng quan series 12 bài và lộ trình học tập
• Hướng Dẫn Toàn Diện HTTP Protocol — Hiểu giao thức HTTP mà IoT thường thay thế bằng MQTT
• Giải Thích Kiến Trúc Server-Client — Nền tảng để hiểu IoT patterns dựa trên broker
• Lộ Trình Docker & Kubernetes — Nền tảng container cho triển khai edge và gateway

Đây là Phần 2 của series IoT Patterns & Strategies. Bắt đầu từ đầu hoặc nhảy đến bất kỳ chủ đề nào bạn quan tâm.