Hướng dẫn thực hành Azure Event Grid MQTT Broker: Kết nối thiết bị IoT không cần viết code

Trong bài viết này, chúng ta sẽ tìm hiểu về cách triển khai broker MQTT của Azure Event Grid. Đầu tiên, chúng ta sẽ xem xét nguyên lý hoạt động của giao thức MQTT và cách mà Azure Event Grid tối ưu hóa quy trình này để xử lý thông điệp một cách hiệu quả. Điều này bao gồm việc đảm bảo tính nhất quán và độ tin cậy trong quá trình truyền tải thông tin giữa các thiết bị.

Chúng ta cũng sẽ hướng dẫn bạn từng bước để cấu hình broker một cách thủ công qua cổng thông tin và sử dụng các lệnh bash. Bạn sẽ biết cách tạo và cấu hình broker MQTT cùng với hai khách hàng—một thiết bị IoT và một bộ điều khiển.

Ngoài ra, có thể đề cập đến những thành phần quan trọng như QoS (Quality of Service) trong giao thức MQTT, giúp cải thiện trải nghiệm người dùng bằng cách đảm bảo rằng thông điệp được gửi đi một cách đáng tin cậy hơn. Cuối cùng, chúng ta cũng sẽ khám phá những ứng dụng thực tế mà dịch vụ này hỗ trợ trong lĩnh vực Internet vạn vật (IoT), từ đó giúp bạn dễ dàng hình dung hơn về khả năng của Azure Event Grid trong việc kết nối các thiết bị.

Khi bắt đầu tạo một tài nguyên mới, bạn có thể tìm kiếm không gian tên Event Grid. Không gian tên Event Grid trên Azure là một công cụ quản lý được thiết kế để bao gồm nhiều loại tài nguyên và phần con khác nhau, như các chủ đề của không gian tên, không gian chủ đề, khách hàng, nhóm khách hàng, chứng chỉ CA và các ràng buộc quyền truy cập. Tôi sẽ giải thích tất cả những thuật ngữ này sau. Giống như nhiều tài nguyên khác trên Azure, nó cung cấp một tên miền duy nhất để truy cập và nhận diện; vì vậy, cái tên phải là duy nhất trong từng khu vực. Các không gian tên trong Event Grid rất linh hoạt với hai điểm cuối: một điểm cuối HTTP cho việc truyền thông điệp chung qua các chủ đề của không gian tên và một điểm cuối MQTT được thiết kế riêng cho việc nhắn tin IoT hoặc cho các ứng dụng sử dụng giao thức MQTT.

Event Grid đóng vai trò quan trọng trong việc quản lý sự kiện bằng cách đảm bảo rằng mọi sự kiện được chuyển tiếp đến đúng đích mà bạn đã chỉ định. Bên cạnh đó, nó cũng hỗ trợ tích hợp dễ dàng với nhiều dịch vụ khác của Azure như Azure Functions hay Logic Apps, giúp tăng cường khả năng mở rộng và tính linh hoạt của hệ thống trong môi trường IoT. Bạn cũng có thể tùy chỉnh chính sách bảo mật cùng với quyền truy cập phù hợp để điều chỉnh mức độ phân phối tài nguyên theo nhu cầu cụ thể của mình.

Hãy lưu ý rằng không phải tất cả các vùng của Azure đều hỗ trợ việc tạo một Tên miền Event Grid. Bạn có thể tham khảo trang web này để biết thêm thông tin về các vùng được hỗ trợ. Một tên miền Event Grid cho phép bạn mở rộng quy mô thông qua Các Đơn vị Thông lượng (Throughput Units - TU). Mỗi tên miền có thể thiết lập tối đa 40 TU, và tất cả các khả năng khác phụ thuộc vào số lượng TU mà bạn có. Ví dụ, bạn có thể có tới 10.000 phiên MQTT trên mỗi TU hoặc 1.000 thông điệp được công bố trên mỗi TU. Điều tương tự cũng áp dụng cho băng thông và yêu cầu kết nối. Để biết thêm chi tiết, hãy tham khảo tài liệu này. Nếu bạn triển khai tại một vùng có khu vực sẵn có (availability zone), bạn cũng nên đánh dấu tùy chọn để cải thiện tính khả dụng của dịch vụ.

Giống như các tài nguyên Azure khác, bạn có thể thiết lập quy tắc truy cập mạng, phân quyền danh tính và gán nhãn. Việc phân quyền danh tính rất quan trọng nếu bạn cần khả năng chuyển tiếp tin nhắn tới một chủ đề sự kiện tùy chỉnh. Chúng ta sẽ xem cách gán vai trò "Người gửi dữ liệu EventGrid" cho một chủ đề tùy chỉnh sau trong bài viết này. Bước đầu tiên của quá trình triển khai thủ công là tạo không gian tên Event Grid. Trong tab bảo mật, hãy kích hoạt danh tính được gán tự động. Bạn có thể bắt đầu cấu hình ngay khi hoàn tất việc tạo tài nguyên. Đầu tiên, bạn cần kích hoạt Broker MQTT để tiến hành các bước tiếp theo trong quá trình thiết lập này.

Một trong những cách để tùy chỉnh cài đặt của broker MQTT cho không gian tên Event Grid của bạn là điều chỉnh thời gian hết hạn phiên. Tham số này xác định khoảng thời gian mà broker giữ cho một phiên của khách hàng hoạt động sau khi khách hàng ngắt kết nối. Nếu khách hàng kết nối lại trước khi phiên hết hạn, họ có thể tiếp tục giao tiếp mà không mất bất kỳ tin nhắn hoặc đăng ký nào. Đối với các khách hàng sử dụng MQTT v3.1.1, thời gian hết hạn phiên được cố định và áp dụng cho tất cả các phiên lưu trữ. Trong khi đó, với các khách hàng MQTT v5, khoảng thời gian hết hạn phiên có thể được chỉ định bởi chính khách hàng trong gói CONNECT, nhưng không được vượt quá giới hạn do broker quy định.

Thời gian hết hạn phiên có thể ảnh hưởng đến hiệu suất và độ tin cậy của ứng dụng MQTT của bạn. Việc thiết lập một khoảng thời gian hết hạn dài hơn cho phép các thiết bị duy trì kết nối lâu hơn mà không cần phải tái thiết lập kết nối. Điều này rất hữu ích nếu các thiết bị gặp phải tình trạng mạng không ổn định hoặc cần bảo tồn trạng thái phiên của chúng. Tuy nhiên, việc kéo dài thời gian hết hạn cũng đồng nghĩa với việc broker tiêu tốn nhiều tài nguyên hơn để lưu trữ dữ liệu phiên và xử lý các kết nối nhàn rỗi. Ngược lại, việc cài đặt một khoảng thời gian ngắn hơn giúp giảm mức tiêu thụ tài nguyên trên broker và đảm bảo rằng những khách hàng không hoạt động sẽ bị ngắt kết nối sớm hơn, từ đó tiết kiệm TUs và chi phí.

Do đó, bạn nên lựa chọn một khoảng thời gian hết hạn phù hợp với yêu cầu và sự đánh đổi trong ứng dụng của mình. Giá trị mặc định cho khoảng thời gian này trên không gian tên Event Grid là 1 giờ nhưng bạn có thể thay đổi tối đa lên tới 8 giờ.

Cách khác để tùy chỉnh cài đặt broker MQTT cho không gian tên Event Grid là điều chỉnh số lượng tối đa các phiên đồng thời từ cùng một khách hàng. Tham số này xác định số lượng kết nối hoạt động mà broker cho phép từ một khách hàng sử dụng cùng một ID khách hàng (client ID). Nếu một khách hàng cố gắng kết nối bằng ID đã tồn tại đạt đến giới hạn tối đa thì broker sẽ từ chối yêu cầu kết nối đó.

Số lượng tối đa các phiên đồng thời có thể ảnh hưởng đến tính linh hoạt và khả năng phục hồi của ứng dụng MQTT của bạn. Bằng cách tăng số lượng tối đa này lên cao hơn, bạn có thể cho phép các thiết bị kết nối vào Không Gian Tên Event Grid với nhiều phiên hoạt động đồng thời khác nhau; điều này rất hữu ích nếu như chúng cần giao tiếp qua nhiều chủ đề hoặc cấp độ chất lượng dịch vụ khác nhau hay nếu bạn muốn triển khai cơ chế cân bằng tải hoặc dự phòng cho các thiết bị.

Tuy nhiên, việc tăng giới hạn cũng dẫn đến việc broker tiêu tốn thêm tài nguyên để xử lý nhiều kết nối cùng lúc và bạn phải quản lý sự đồng bộ hóa cũng như nhất quán dữ liệu giữa các phiến bản khác nhau ấy. Trái lại, nếu giảm số lượng tối đa xuống thấp hơn sẽ giúp giảm thiểu mức tiêu thụ tài nguyên trên broker cũng như đảm bảo rằng chỉ một phiến bản mỗi client được phép truy cập; điều này đơn giản hóa logic quản lý trạng thái ở phía client nhằm tránh xung đột hay trùng lặp.

Vì vậy, hãy lựa chọn con số phù hợp nhất với yêu cầu và sự đánh đổi trong ứng dụng của bạn.

Một phương pháp nữa để tùy chỉnh cài đặt Broker MQTT dành riêng cho không gian tên Event Grid là điều chỉnh phương thức xác thực đối tượng client thay thế (alternative method for client authentication). Tùy chọn này cho phép xác định trường chứng nhận nào sẽ chứa tên xác thực của client nếu nó chưa được cung cấp trong trường username thuộc gói connect; dịch vụ sẽ so khớp tên xác thực lấy từ chứng thư TLS với thông tin metadata liên quan đến client để kiểm tra tính hợp lệ.

Trước khi tạo hai clients mới, hãy chuẩn bị nền tảng giao tiếp giữa chúng!

Mẫu chủ đề (topic templates) trong chức năng Broker MQTT thuộc Azure Event Grid là giải pháp tinh vi nhằm quản lý đường truyền thông tin cũng như quyền truy cập giữa các clients MQTT dễ dàng hơn rất nhiều so với việc chỉ dùng bộ lọc chủ đề cơ bản; nó mở rộng khả năng lọc topic bằng cách bổ sung biến & ký tự đại diện đại diện cho phần riêng biệt theo từng client bên trong chuỗi topic MQTT.

Từ góc độ phân quyền (authorization), mẫu chủ đề giúp đơn giản hóa đáng kể quá trình quản lý vì bạn có thể nhóm những topic chung lại thành từng nhóm lớn (topic spaces) rồi áp dụng quyền truy cập tập trung thay vì từng cái riêng lẻ; điều này đặc biệt tiện lợi khi làm việc với nhiều topics chia sẻ nhu cầu truy cập tương tự nhau.

Chẳng hạn như mẫu **telemetry/+/#** sẽ khớp với những topics kiểu **telemetry/device123/temperature** hay **telemetry/device456/humidity**, giả sử 'device123' và 'device456' là tên xác thực tương ứng của clients đó; nó giúp mỗi thiết bị gửi đi thông tin nhiệt độ hoặc dữ liệu cảm biến độc nhất về từng topic nằm trong namespace telemetry còn người nhận thì đọc tất cả dữ liệu nhiệt độ hay cảm biến từ mọi thiết bị kia cùng lúc!

Về mặt đăng ký từ phía device subscription thì cấu hình mẫu có vẻ giống như **configuration/${client.authenticationName}/settings**, thứ sẽ khớp tốt với những topics dạng **configuration/device123/settings**; cấu hình ngoại tại đảm bảo mỗi thiết bị chỉ nhận được thông tin cấu hình hướng tới chính nó mà thôi – đây chính là điểm then chốt nhằm kiểm soát quyền truy cập ở mức chi tiết."

Lý do sử dụng các mẫu chủ đề bắt nguồn từ cả hai yếu tố bảo mật và khả năng mở rộng. Bằng cách tận dụng các biến tương ứng với thuộc tính của khách hàng hoặc tên xác thực, trình môi giới MQTT của Azure Event Grid có thể tự động giải quyết các chuỗi chủ đề cho từng khách hàng, tạo ra những kênh giao tiếp cá nhân hóa. Phương pháp này cũng giúp giảm bớt công việc quản lý việc cấp quyền khi số lượng khách hàng tăng lên, làm cho nó trở thành một giải pháp hiệu quả cho các tình huống IoT với nhiều thiết bị.

Tuy nhiên, vấn đề ở đây là không cho phép một bộ điều khiển gửi thông tin trên chủ đề này vì nó yêu cầu khách hàng phải có tên xác thực. Để khắc phục điều này, chúng ta có thể thêm mẫu: **configuration/+/settings** vào chủ đề để cho phép xuất bản từ tất cả các bộ điều khiển. Nhờ vậy, chúng ta có thể phát hành thông tin từ bất kỳ bộ điều khiển nào đến tất cả các thiết bị; nhưng đồng thời cũng cho phép bất kỳ thiết bị nào đăng ký và nhận cài đặt từ tất cả các thiết bị khác. Nếu không muốn như vậy, chúng ta có thể tách riêng các chủ đề cấu hình thành hai loại: Một dành riêng cho mỗi thiết bị với mẫu cụ thể của nó và một dành cho các bộ điều khiển với mẫu chung.

Chúng tôi đã tạo ra hai không gian chủ đề: một để thiết bị gửi (xuất bản) dữ liệu telemetry và một để bộ điều khiển (dịch vụ đám mây) cấu hình lại thiết bị. Chúng tôi cần xây dựng nhóm khách hàng để kết nối mỗi chủ đề với những khách hàng cụ thể nhất định.

Bảng điều khiển sự kiện IoT phân loại các khách hàng vào các nhóm theo tiêu chí mà chúng ta đã thiết lập. Tiêu chí này là một truy vấn dựa trên thuộc tính của khách hàng, và đây là cài đặt mà chúng ta cần cung cấp khi gán một khách hàng cho Bảng điều khiển MQTT của sự kiện. Như bạn có thể thấy, các liên kết quyền hạn gắn nhóm khách hàng với một không gian chủ đề cụ thể cùng với quyền hạn xác định. Điều này cho phép các bộ điều khiển có khả năng gửi yêu cầu cập nhật cài đặt, trong khi các thiết bị được phép nhận yêu cầu cài đặt cũng như gửi dữ liệu cảm biến (telemetry).

Tiếp theo, chúng ta sẽ tiến hành tạo ra các khách hàng. Trong ví dụ này, tôi sẽ tạo ra một thiết bị IoT và một bộ điều khiển. Để thực hiện việc này, trước tiên chúng ta cần tạo chứng chỉ cho cả hai loại khách hàng. Có nhiều công cụ khác nhau có thể giúp bạn tạo chứng chỉ tự ký, nhưng ở đây tôi sẽ sử dụng OpenSSL chạy trên WSL để thực hiện việc đó.

Khi nói đến giao thức MQTT (Message Queuing Telemetry Transport), nó hoạt động bằng cách chia sẻ thông tin giữa các thiết bị qua một hệ thống chủ đề (topics) và thông điệp (messages). Ví dụ trong môi trường IoT, bạn có thể gặp những cảm biến nhiệt độ hay độ ẩm nào đó - mỗi thiết bị đều có thể đăng ký vào những chủ đề mà nó quan tâm để nhận hoặc gửi dữ liệu phù hợp với nhu cầu của mình.

Việc cấu hình chính xác cho từng loại thiết bị sao cho dễ dàng kết nối với bảng điều khiển rất quan trọng và ảnh hưởng đến toàn bộ quy trình truyền tải dữ liệu trong mạng lưới IoT.

Nếu bạn chưa cài đặt OpenSSL, hãy làm điều đó trước: ### > sudo apt-get update && sudo apt-get install openssl Bây giờ chúng ta cần tạo chứng chỉ gốc; chúng ta sẽ sử dụng nó để tự ký chứng chỉ trung gian, mà sau đó sẽ được dùng để ký các chứng chỉ của khách hàng (thiết bị và bộ điều khiển). ### > openssl genrsa -out rootCA.key 4096 ### > openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 2000 -out rootCA.pem -subj "/C=IL/ST=Haifa/L=Binyamina/O=Fliess/OU=Home/[email protected]/CN=fliess.org" Hãy thay đổi thông tin trong phần chủ thể cho phù hợp với danh tính của chứng chỉ bạn. Tiếp theo, chúng ta sẽ tạo một chứng chỉ trung gian. Mặc dù không bắt buộc phải có chứng chỉ trung gian, nhưng việc này được coi là một thực tiễn tốt. Các CA trung gian được cấp quyền phát hành chứng chỉ bởi CA gốc. Việc phân lớp này giúp bảo vệ khóa bí mật của CA gốc bằng cách giới hạn khả năng tiếp xúc và sử dụng của nó. ### > openssl genrsa -out intermidiateCA.key 4096 ### > openssl req -new -key intermidiateCA.key -out intermidiateCA.csr -subj "/C=IL/ST=Haifa/L=Binyamina/O=Fliess/OU=Home/[email protected]/CN=intermidiateCA" ### > openssl x509 -req -in intermidiateCA.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out intermidiateCA.pem -days 2000 -sha256 Việc tạo ra một chứng chỉ gốc và một chứng chỉ trung gian là những thao tác diễn ra một lần duy nhất. Bạn cần lưu trữ các khóa riêng tư để có thể sử dụng chúng khi cần tạo thêm các chứng chỉ cho khách hàng bất cứ lúc nào hoặc khi cần làm mới lại các chứng chỉ đó. Sau này, tôi sẽ hướng dẫn bạn cách lưu trữ và lấy lại chúng bằng Azure KeyVault.

Bây giờ, chúng ta sẽ tạo chứng chỉ cho thiết bị IoT:
### > openssl genrsa -out deviceCert.key 4096
### > openssl req -new -key deviceCert.key -out deviceCert.csr -subj "/C=IL/ST=Haifa/L=Binyamina/O=Fliess/OU=Home/[email protected]/CN=my-device"
### > openssl x509 -req -in deviceCert.csr -CA intermidiateCA.pem -CAkey intermidiateCA.key -CAcreateserial -out deviceCert.pem -days 2000 -sha256

Tiếp theo là chứng chỉ cho bộ điều khiển:
### > openssl genrsa -out controllerCert.key 4096
### > openssl req -new -key controllerCert.key -out controllerCert.csr -subj "/C=IL/ST=Haifa/L=Binyamina/O=Fliess/OU=Home/[email protected]/CN=my-controller"
### > openssl x509 -req -in controllerCert.csr -CA intermidiateCA.pem -CAkey intermidiateCA.key -CAcreateserial -out controllerCert.pem -days 2000 –sha256

Giờ là lúc tạo các khách hàng trong Broker MQTT của Event Grid. Chúng ta cần xác thực khách hàng dựa trên dấu vân tay của nó, có nghĩa là giá trị hash của chứng chỉ. Tốt nhất nên sử dụng hash SHA256 vì lý do bảo mật rõ ràng; tuy nhiên, những thiết bị cũ có thể không hỗ trợ SHA256, vì vậy bạn có thể sử dụng SHA1. Dưới đây là cách lấy khóa hash dấu vân tay từ chứng chỉ:

### > openssl x509 –in "deviceCert.pem" –noout –fingerprint **-sha1** | sed 's/SHA1 Fingerprint=//;s/://g'
Kết quả: ACB4E3E1E200FE3877A63C88C54743BFA961CCA2

### > openssl x509 –in "controllerCert.pem" –noout –fingerprint **-sha256** | sed 's/SHA256 Fingerprint=//;s/://g'
Kết quả:
### 92951446650D94CCCF5B2276A2381A2AAD577746D4E48CBAEFC27A1B72784352

Với điều đó, hãy thêm thiết bị: Tôi sử dụng dấu vân tay Sha256 và thuộc tính loại được đặt thành 'device'. Với điều này, thiết bị của chúng ta nhận được quyền truy cập để gửi telemetry và nhận cấu hình.

Chúng ta có thể kết nối các khách hàng với Azure Event Grid MQTT Broker.

## Khám phá MQTT mà không cần mã

Nếu bạn muốn thử nghiệm và khám phá các tính năng MQTT của namespace Event Grid mà không cần viết mã, bạn có thể sử dụng một số công cụ bên thứ ba hỗ trợ giao thức MQTT. Một trong số đó là MQTTX, một ứng dụng máy tính để bàn đa nền tảng cho phép kết nối, đăng ký, xuất bản và theo dõi các chủ đề MQTT với giao diện đơn giản và trực quan. Để chơi với MQTTX mà không phải viết bất kỳ mã nào, hãy làm theo các bước sau:

- Tải xuống và cài đặt MQTTX từ [https://mqttx.app/].
- Mở ứng dụng lên và tạo một kết nối mới bằng cách nhấp vào nút + ở góc trên bên trái.
- Nhập tên cho kết nối và chọn MQTT làm giao thức.
- Nhập hostname và cổng của namespace Event Grid của bạn. Bạn có thể tìm thấy chúng trong phần tổng quan của namespace trong cổng Azure.
- Kiểm tra hộp SSL/TLS và chọn phiên bản TLS cũng như bộ mật mã phù hợp.
- Kiểm tra hộp chứng chỉ tự ký và duyệt đến vị trí chứa tập tin chứng chỉ khách hàng cùng với khóa riêng tư.
- Nhập ID khách hàng (client ID) và tên người dùng (username) cho khách hàng MQTT của bạn.
- Nhấn Kết nối để thiết lập kết nối với namespace Event Grid của bạn.

Bạn có thể nhấp chuột phải vào kết nối rồi nhân đôi nó. Sau đó chỉnh sửa lại: Bạn cần xem hai khách hàng mới (trong trường hợp tôi đã có một cái nên sẽ là ba):

Chúng đều màu xanh lá cây, tức là đã được kết nối. Chúng ta có thể thấy rằng chúng tôi đã thiết lập liên lạc.

## Gửi gói tin

Để giao tiếp, chúng ta cần đăng ký chủ đề và xuất bản tin nhắn. Để đăng ký một chủ đề, hãy nhấp vào nút + bên cạnh nhãn Các Chủ Đề Đã Đăng Ký (Subscribed Topics) rồi nhập tên chủ đề cùng cấp độ dịch vụ chất lượng (quality of service level). Bạn cũng có thể sử dụng dấu đại diện (+ và #) để đăng ký nhiều chủ đề cùng lúc.

Giờ đây chúng ta có thể xuất bản telemetry:

Và xem controller nhận nó:

Tương tự như vậy, việc xuất bản một thông điệp để cập nhật cấu hình:

Bạn cũng có thể theo dõi nhật ký sự kiện từ Azure MQTT Broker tại [https://learn.microsoft.com/en-us/azure/event-grid/monitor-namespaces].

## Lộ trình thông điệp Event Grid

Có nhiều cách để giao tiếp giữa đám mây với các thiết bị. Chúng ta có thể viết ứng dụng kết nối tới Event Grid MQTT Broker dưới dạng controller, gửi lệnh hoặc nhận telemetry như đã thấy trước đó; hoặc chúng ta có thể chuyển hướng thông điệp bằng tùy chọn định tuyến thông điệp của Event Grid. Điều này tương tự như định tuyến thông điệp Azure IoT Hub nhưng cung cấp khả năng làm phong phú thêm thông điệp giống như IoT Hub; tuy nhiên định tuyến thông điệp hoạt động bằng cách phát hành một sự kiện của Event Grid cho mỗi tin nhắn MQTT.

Để định tuyến thông điệp, bạn cần tạo một chủ đề tùy chỉnh và thêm phân quyền cho danh tính Namespace Event Grid nhằm cho phép gửi dữ liệu event grid tới chủ đề đó. Bạn cũng cần tạo một đăng ký cho chủ đề này. Vì bài viết này yêu cầu không được phép viết mã 😊 , nên chúng tôi sẽ thực hiện việc đăng ký bằng Service Bus queue rồi xem các tin nhắn từ cổng.

Trong màn hình Routing (Định Tuyến), bật định tuyến lên, chọn "Create topic" (Tạo chủ đề) rồi tạo ra chủ đề tùy chỉnh cho việc định tuyến telemetry messages:

Bây giờ hãy tạo Service Bus namespace cùng queue nhận sự kiện:

Hãy thêm rồi đăng ký Service Bus Queue tới telemetry topic; đến telemetry topic rồi thêm một sự kiện subscription:

Chọn Service Bus Queue rồi nhấn "Configure an endpoint":

Hãy chắc chắn rằng bạn chọn cùng schema sự kiện.

Giờ thì lại chơi với MQTTX lần nữa nhé - gửi tin nhắn telemetry từ "Device":

Lần này thì tất cả năm tin nhắn đã đến tay Service Bus Queue;

Chọn Service Bus Explorer rồi "Peek next messages":

Dữ liệu ở dạng base64; chúng ta có thể giải mã nó:
### data_base64":"eyJzZW5zb3JBIiA6IDMxLjUgfQ==

Như vậy qua bài viết này, chúng ta đã chứng kiến hoạt động của Azure Event Grid MQTT Broker mà không phải viết bất kỳ đoạn mã nào. Chúng ta đã học cách tận dụng Azure Event Grid MQTT Broker để kích hoạt giao tiếp dựa trên sự kiện giữa các thiết bị với controller. Ngoài ra còn thấy cách sử dụng portal Azure cùng CLI để tạo quản lý tài nguyên phục vụ tình huống này.

Ở phần tiếp theo, mình sẽ tự động hóa quá trình tạo dựng Azure Event Grid MQTT Broker đồng thời cả clients sử dụng công cụ DevOps cũng như thực tiễn tốt nhất trong ngành. Mình sẽ dùng Bicep - ngôn ngữ chuyên biệt dành riêng cho triển khai tài nguyên trên Azure - cùng Bash scripts nhằm xây dựng hạ tầng dưới dạng code rõ ràng hơn nữa!