MQTT tròn 25 tuổi
(andypiper.co.uk)- MQTT đã lan rộng từ một giao thức nhẹ dành cho thiết bị nhỏ và mạng không ổn định sang các lĩnh vực công nghiệp, gia đình và ứng dụng trong suốt 25 năm kể từ khi đặc tả đầu tiên được công bố vào tháng 10/1999
- Cấu trúc publish/subscribe đơn giản, được thiết kế với giả định về nguồn điện hạn chế và kết nối gián đoạn, vẫn là điểm mạnh ngay cả sau khi môi trường mạng và thiết bị edge đã thay đổi
- MQTT, vốn được dùng quanh IBM, bắt đầu lan rộng mạnh trong cộng đồng vào giai đoạn 2009~2011; thông qua Mosquitto và Eclipse Paho, nó mở rộng thành một hệ sinh thái giao thức mở bên ngoài IBM
- Hiện nay MQTT xuất hiện cả ở những nơi người dùng không nhận ra, như xử lý thông điệp trên Raspberry Pi dựa trên Node-RED, máy lọc không khí Dyson và ứng dụng, điều khiển máy in 3D, thông báo trong nhà, nhà máy sản xuất
- Nhân dịp 25 năm, cộng đồng đã chuyển từ tài khoản dự án cũ trên X sang @mqtt@fosstodon.org trên Mastodon, đồng thời đăng thông điệp đầu tiên lên Fediverse dựa trên ActivityPub
Nhắn tin nhẹ bắt đầu từ môi trường hạn chế
- Tháng 10/2024 đánh dấu 25 năm kể từ khi tài liệu dẫn tới đặc tả đầu tiên của MQTT được công bố
- MQTT là một giao thức mạng được thiết kế cho các thiết bị nhỏ, hạn chế và các mạng nhẹ hoặc không ổn định vào cuối thập niên 1990
- Trọng tâm của nó là gửi dữ liệu cảm biến tới các hệ thống lớn hơn trong những tình huống kết nối gián đoạn và nguồn điện hạn chế, chẳng hạn như thiết bị giám sát môi trường ở xa
- Các thiết bị như vậy cần tiết kiệm điện năng, băng thông và độ sẵn sàng của mạng
- MQTT rất phù hợp với cách phát hành, thu thập và nhận dữ liệu ở định dạng nhỏ nhưng hữu ích
- Dù mạng đã trở nên nhanh hơn và ổn định hơn, còn edge, tự động hóa gia đình và thiết bị di động ngày càng phổ biến, tính đơn giản của giao thức vẫn là sức mạnh cốt lõi của MQTT
Từ quanh IBM lan rộng thành hệ sinh thái mở
- Sau khi gia nhập IBM vào năm 2001, tác giả thực hiện các dự án khách hàng liên quan đến IBM MQ, tích hợp kinh doanh, message queuing, kết nối ứng dụng và middleware
- IBM Hursley Lab là nền tảng của MQ, đồng thời là nơi hoạt động của Andy Stanford-Clark, đồng sáng tạo MQTT; các thử nghiệm MQTT bắt đầu quanh môi trường này
- Khi đó MQTT đã được công bố ra bên ngoài như một giao thức, nhưng bên ngoài IBM thì chưa được biết đến nhiều hoặc triển khai rộng rãi
- Khoảng giai đoạn 2009~2011, các hoạt động đưa MQTT ra khỏi phạm vi triển khai nhỏ của IBM đã có bước tiến
- Lựa chọn broker khi đó gồm IBM WebSphere Message Broker dành cho doanh nghiệp và đắt đỏ, microbroker mã nguồn đóng, và Really Small Message Broker mã nguồn đóng nhưng miễn phí
- Mosquitto mã nguồn mở do Roger Light tạo ra hiện vẫn là một trong những triển khai miễn phí được dùng rộng rãi
- Roger Light tạo ra Mosquitto sau khi nghe bài trình bày về smart home được kết nối của Andy Stanford-Clark tại OggCamp đầu tiên năm 2009, tức 10 năm sau ngày tạo đặc tả
Eclipse Paho và tiêu chuẩn hóa chính thức
- Năm 2011, phần triển khai MQTT của IBM được đóng góp cho cộng đồng Eclipse, khởi đầu dự án Eclipse Paho
- Sau khi rời IBM vào năm 2012, mối liên hệ với dự án Paho vẫn tiếp tục, và tác giả cũng đảm nhiệm vai trò trong thời gian làm việc tại Cloud Foundry
- Sau khi gia nhập Twitter vào năm 2014, tác giả rút khỏi sự tham gia chính thức
- Trong giai đoạn đó, MQTT đã trải qua quy trình tiêu chuẩn hóa chính thức tại OASIS và ISO/IEC
MQTT ở những nơi vô hình ngày nay
- MQTT đã vượt ra ngoài ranh giới của IBM và trở thành một câu chuyện thành công của giao thức mở; 25 năm sau, nó hiện diện trong nhiều sản phẩm và địa điểm mà người dùng không nhận ra
- Các trường hợp sử dụng tiêu biểu gồm:
- Dự án của lập trình viên hobbyist và maker
- Máy lọc không khí Dyson và các ứng dụng liên quan
- Hệ thống điều khiển máy in 3D
- Hệ thống thông báo trong nhà
- Công nghiệp và nhà máy sản xuất
- Ngay cả trong không gian làm việc cá nhân, MQTT cũng được dùng theo nhiều cách
- Máy in 3D Bambu Lab X1C dùng MQTT cho giao tiếp nội bộ
- Các thiết bị kết nối trên tường phản hồi thông báo MQTT để hiển thị dữ liệu hoặc bật đèn
- Node-RED chạy trên Raspberry Pi xử lý thông điệp MQTT
- Rất có khả năng ít nhất một ứng dụng trên điện thoại hiện tại của bạn cũng dùng MQTT ở đâu đó trong stack
25 năm và sự dịch chuyển của cộng đồng
- Tài khoản cộng đồng MQTT đã chuyển sang Mastodon thay cho tài khoản dự án cũ trên X
- Có thể theo dõi tài khoản mới tại @mqtt@fosstodon.org
- Để kỷ niệm 25 năm, MQTT đã đăng thông điệp đầu tiên lên Fediverse thông qua ActivityPub và gia nhập open social web
- Andy Stanford-Clark đã tham gia một fireside chat với HiveMQ, và podcast The Unstructured Message của HiveMQ cũng được giới thiệu như một nơi để xem thêm nội dung liên quan đến MQTT
1 bình luận
Ý kiến trên Hacker News
Dự án đầu tiên vẫn còn đang vận hành và được dùng hằng ngày của tôi là lấy bản đồ SVG hệ thống nước gồm đường ống/bơm/van cho tạo tuyết và chữa cháy của một khu nghỉ dưỡng trượt tuyết lớn, rồi biến nó thành một website hiển thị trạng thái
Tôi tạo MQTT topic cho từng bơm, van và đoạn ống, gắn các trạng thái như hướng dòng nước, bật/tắt bơm/van, áp suất, rồi dùng mqtt.js và jQuery để cập nhật màu và phần tô của SVG
Một MQTT broker chạy bằng container trên hosting tĩnh đã hoạt động gần 10 năm mà hầu như không phải đụng tới; mqtt.js chạy trên WebSocket nên khi trạng thái thay đổi, mọi người đều tự động thấy cập nhật
Gần đây tôi đã thử dùng MQTT trong một dự án, nhưng không thật sự thích lắm
Giao thức có nhiều tùy chọn, và không dễ biết ngay từng tùy chọn làm gì, vì sao nó quan trọng, phải dùng tổ hợp nào để hoạt động đúng như mong muốn; tài liệu cũng không giải thích tốt những điểm đó
Một phần có thể là do Eclipse Mosquitto Python client mà tôi dùng: trên hệ thống chậm, xảy ra race condition khiến việc subscribe topic bị âm thầm bỏ qua và callback bị hỏng; tôi mất vài ngày mới tìm ra
Dù đã làm theo tài liệu 100%, nó vẫn như vậy, và với một giao thức không quá mới thì đây là một trong những trải nghiệm lộn xộn nhất tôi từng gặp
Trải nghiệm của tôi với các client Eclipse, chẳng hạn Paho trong Python và C++, cũng tương tự: quá phức tạp, cảm giác quá low-level, và do cấu trúc nên cũng có một số bug
Có lẽ vì gần như chỉ được một người bảo trì nên theo thời gian đã thành ra như vậy. Client C++ trong 6 tháng gần đây cũng chỉ có một người đóng góp, và 3 tháng gần đây thì không có ai đóng góp
Một PR đơn giản sửa bug rõ ràng, chỉ ở mức đổi một từ, cũng mất 2 năm để được review và merge. Tôi không có ý chỉ trích, mà muốn nói rằng có vẻ có quá nhiều thư viện, bug và việc phải làm, trong khi chỉ một nhóm nhỏ người quá tải xử lý
Khi chuyển sang client khác, trải nghiệm trong Python, Rust, C# và C++ tốt hơn nhiều; phần lớn có kết hợp API high-level/low-level tốt, nên nếu chỉ muốn gửi message tới topic thì không cần bận tâm đến ack hay retry
Ngược lại, nếu cần kiểm soát thì cũng có thể kiểm soát. Tôi lo rằng việc để paho và các thư viện tương tự tồn tại trong trạng thái hiện nay lại có thể gây hại. Nếu nó chính thức chết thì ít nhất vấn đề sẽ buộc phải lộ ra, còn hiện tại người dùng có những trải nghiệm như thế này rồi bỏ MQTT hoặc nghĩ rằng mình đang làm sai
Từ thiết kế API, tài liệu nghèo nàn, cho đến cách làm có vẻ không theo convention của Python, tất cả đều gây khó chịu
Lúc mới bắt đầu thì có vẻ dễ, nhưng phạm vi của giao thức và phần triển khai dần dần trở thành điểm cản trở. Có thời, cách đáng tin cậy để kiểm tra xem đã kết nối thành công tới server hay chưa là thử subscribe cùng một topic hai lần và bắt một mã lỗi cụ thể trong message
on_connect. Khi đó mã này trong tài liệu lại được ghi là mã thành côngTôi biết nghe thật vô lý, và dù có cách tốt hơn thì cũng không dễ tìm ra. Dù vậy, phàn nàn thì dễ; tôi vẫn biết ơn rất nhiều người đã tạo ra thư viện này. Không có họ thì tôi đã không thể tạo được những thứ hiện có, và tôi tôn trọng những người đảm nhận các dự án khổng lồ như vậy
Khi có thể, tôi chọn để
mosquitto_subvàmosquitto_pubxử lý giao thức, còn mình chỉ đọc/ghi qua stdin/stdoutKhông chỉ vì bug, mà vì việc giao phó quản lý kết nối broker cho một chương trình đã được viết và kiểm thử sẵn dễ hơn
Tuy nhiên, với will message thì cách này không dùng hiệu quả được, và cũng không phù hợp với các microcontroller không chạy những thứ như Linux
Về cơ bản, nó tạo ra một hệ thống pipe *nix qua mạng có xác thực, hướng tới cách đơn giản nhất để gửi và nhận sự kiện
Với use case của tôi, hàng đợi vô hạn là điều quan trọng, nhưng MQTT không cung cấp điều đó; nếu tôi vẫn phải tự quản lý message ID để MQTT theo dõi message ID riêng của nó rồi gửi tới broker, thì chẳng có lý do gì phải dùng nó
Nếu không phải tích hợp với một dự án đã được thiết kế quanh MQTT, tôi không thật sự rõ trường hợp sử dụng tối ưu của nó là gì
Trong vài năm gần đây, MQTT được dùng nhiều hơn hẳn để chia sẻ dữ liệu giữa các máy móc trong nhà máy.
Về mặt lịch sử, nó từng được dùng cho SCADA trong ngành Oil & Gas để lấy dữ liệu từ các địa điểm giếng dầu từ xa.
Hơn 10 năm trước, tôi đã thêm MQTT vào Kepware (OPC server) để stream giá trị tag lên “đám mây”; sau buổi trình bày, Arlen Nipper, một trong những người tạo ra MQTT, đến nói rằng tôi “làm khá ổn”, khiến tôi thấy khiêm tốn hẳn.
Giờ tôi ở một công ty mới tên HighByte, mô hình hóa dữ liệu nhà máy ở edge rồi gửi qua MQTT, SparkplugB (một giao thức trên MQTT), S3, Azure Blob, v.v.
Tóm lại, MQTT là một động lực lớn của Industry 4.0, và thật tuyệt khi sau ngần ấy thời gian nó vẫn được dùng nhiều như vậy.
Nó hơi thô và có nhiều bước xử lý hơn mong muốn. Vì Kepware tính phí license lặp lại hằng năm cho plugin IoT, nên giờ chúng tôi đang rời khỏi giải pháp đó và chuyển sang để telegraf đọc trực tiếp dữ liệu OPC-UA từ Kepware.
Tôi tò mò không biết bạn đã từng làm hoặc đang làm ở Kepware không.
Giá mà họ cứ dùng Sparkplug B rồi triển khai một đặc tả về ngữ nghĩa ở trên đó thì tốt.
Hơn nữa, phần việc bất đồng bộ hiện nay cũng bị thiết kế quá mức và rất tệ. Tôi đã tham gia các cuộc họp một thời gian; dù đặc tả MQTT chưa đến 50 trang và dễ đọc, họ vẫn chưa từng đọc, cũng không hiểu header dùng để làm gì. Ví dụ, họ thực sự định đưa vào header những thứ lẽ ra phải nằm trong payload.
Một người phía Microsoft còn khó chịu trước đề xuất rằng trước hết nên xem các đối thủ đang làm gì với MQTT. Lý do là họ muốn tự tạo mới hơn là sao chép.
Theo đề xuất của tôi, công ty chúng tôi sẽ chỉ xử lý OPC UA ở sát edge nhất, và cô lập nó khỏi công nghệ của chúng tôi càng nhiều càng tốt.
Tuy vậy, gần đây tôi cũng thấy Kafka và RabbitMQ đang lấn sâu hơn vào phần thị trường của MQTT.
Khoảng 15 năm trước, khi các thiết bị IoT biết tweet còn chưa phổ biến, ngôi nhà của Andy Stanford Clark từng trở thành đề tài trên tin tức.
https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
Giao thức cốt lõi được nghĩ ra vào thời mà truyền 1 byte qua liên kết vệ tinh tốn 1 đô la, nên nó hiệu quả đến khó tin và cũng đơn giản để triển khai.
Trước đây có lần cổng duy nhất dùng được qua firewall của một khách hàng là MQTT 1883.
Lý do là họ đang nhận dữ liệu cảm biến theo cách đó; dù có yêu cầu thế nào họ cũng không mở cổng khác, nên chúng tôi đã lách bằng cách tạo một wrapper TCP thời gian thực chạy trên MQTT.
Một daemon TCP đa luồng cục bộ lắng nghe các yêu cầu đi ra trên một cổng nhất định, bọc chúng trong MQTT rồi publish lên một topic duy nhất; daemon phía server phát hiện topic đó, giải bọc rồi chuyển tiếp đến tiến trình server.
Từ góc nhìn của máy client, nó trông như đang thiết lập kết nối TCP thời gian thực tới server của chúng tôi, nhưng ở giữa lại có một wrapper MQTT kỳ quặc vô hình.
Khi chạy được rồi thì khá thanh lịch, nhưng debug thì thật sự khổ sở, và mất vài tháng đi qua nhiều ngõ cụt mới ghép toàn bộ cho đúng.
Giờ thì tình huống không làm được gì ngoài ngồi không được gọi là “để quy trình vận hành”.
Một chi tiết thú vị là Boost, thư viện C++ nổi tiếng nhất, đúng thời điểm này cũng đang review việc đưa bản triển khai
async-mqtt5(https://github.com/mireo/async-mqtt5) vào dưới tên Boost.MQTT: https://lists.boost.org/Archives/boost/2024/10/index.phpTheo trải nghiệm cá nhân thì phần lớn việc đưa vào dùng diễn ra trong thập niên 2000 và giai đoạn rất đầu thập niên 2010, tức trước khi mọi người bắt buộc C++0x/C++11; còn ngày nay thì hiếm khi thấy.
boost.org giống như du hành về quá khứ. Nó vẫn y như tôi nhớ khoảng năm 2008, kể cả nút “Get Boost” ghép lên nút dừng khẩn cấp.
MQTT là một giao thức nhỏ thực sự ổn; nó không chỉ “đủ nhỏ” để dùng cho dự án sở thích, mà còn mở rộng được tới mức dùng trong những thứ như Facebook Messenger.
[1]: https://engineering.fb.com/2011/08/12/android/building-faceb...
Việc quảng bá kiểu MQTT nhẹ và hiệu quả không thật sự thuyết phục
Rốt cuộc cũng chỉ dùng TCP/IP, và theo tiêu chuẩn thời đó thì có thể tương đối đặc biệt, nhưng ngoài những lời tự hào lặp đi lặp lại, tôi chưa từng thấy bằng chứng thực tế nào củng cố cho tuyên bố đó
Việc nó là tiêu chuẩn nên có thể kết nối với các thiết bị có sẵn được hỗ trợ là điểm tốt. Dù vậy, tôi cho rằng vẫn có những lựa chọn tốt hơn cho publish/subscribe hoặc hàng đợi thông điệp, đặc biệt là khi phía consumer cần cơ chế failover
Điểm hay của MQTT, và cũng là điểm mà gần như mọi triển khai publish/subscribe khác tôi từng thấy đều làm sai, là cấu trúc dữ liệu cốt lõi của MQTT không phải hàng đợi hay topic, mà là client đã đăng ký
Vì vậy có thể ánh xạ một không gian địa chỉ lớn tùy ý vào cây topic. Cây topic có thể có hàng nghìn tỷ endpoint, và nếu muốn thì ngay cả trên server nhúng cũng có thể đặt một endpoint cho từng địa chỉ IPv6
Vì cây topic phong phú nên có thể tạo subscription chọn lọc đến mức cần thiết, và server vẫn có thể chạy nhanh với mức sử dụng tài nguyên nhỏ
Tôi đã dùng MQTT trong các lớp IoT suốt vài năm, và nó đã chứng minh là một công cụ rất đa năng
Việc nó cũng được hỗ trợ qua WebSocket cũng rất tiện
Gần đây tôi dùng MQTT làm hệ thống nhắn tin liên tiến trình trong một dự án hệ thống nhúng, khá thú vị
Broker và client chạy trên cùng một máy
Khi cần sniff hoặc debug thứ gì đó, chỉ cần đưa thiết bị lên mạng rồi dùng MQTT Explorer để ghi lại hoặc chèn thông điệp, nên rất dễ
Cũng có thể mở port ra ngoài LAN để đồng nghiệp làm việc từ xa thao tác với hệ thống
Điều tôi lo nhất khi dùng làm thành phần hệ thống là đảm bảo độ bền dữ liệu, và tôi không mấy tin rằng triển khai broker sẽ không làm mất dữ liệu