در قسمت اول، نقش بروکر در دریافت و توزیع پیام‌ها را بررسی کردیم. اکنون پرسش این است که برای یک پروژه واقعی، چگونه می‌توانیم بروکر خودمان را داشته باشیم؟ آیا به یک سرور قدرتمند نیاز داریم؟ آیا کامپیوتر داخل شرکت کافی است؟ آیا می‌توان نرم‌افزار بروکر را روی همان هاستی نصب کرد که وب‌سایت شرکت روی آن قرار دارد؟
راه‌اندازی بروکر معمولاً به معنی نصب و تنظیم یک نرم‌افزار آماده روی بستری مناسب است. این بستر می‌تواند یک رایانه محلی، رزبری‌پای، رایانه صنعتی یا سرور اجاره‌ای باشد. همچنین می‌توان سرویسی تهیه کرد که نرم‌افزار بروکر از قبل روی آن نصب شده باشد.
انتخاب میان این روش‌ها به تعداد دستگاه‌ها، میزان تبادل پیام، نیاز به ارتباط اینترنتی، اهمیت پایداری و توان فنی مجموعه برای نگهداری سرویس بستگی دارد.
۱. داشتن بروکر اختصاصی دقیقاً به چه معناست؟
تفاوت اختصاصی‌بودن سرویس با اختصاصی‌بودن سخت‌افزار
وقتی گفته می‌شود «بروکر اختصاصی»، لازم است روشن کنیم چه چیزی اختصاصی است. ممکن است یک نمونه مستقل از نرم‌افزار بروکر برای پروژه ما اجرا شود، در حالی که سخت‌افزار میزبان آن با کاربران دیگر مشترک باشد.
برای مثال، روی یک سرور فیزیکی می‌توان چند سرور مجازی ایجاد کرد. اگر یکی از این سرورهای مجازی را اجاره و بروکر خودمان را روی آن نصب کنیم، نرم‌افزار، کاربران و تنظیمات بروکر را جداگانه مدیریت می‌کنیم؛ اما لزوماً مالک یا استفاده‌کننده انحصاری تمام سخت‌افزار نیستیم.
در مقابل، در سرور فیزیکی اختصاصی، کل یک دستگاه سرور در اختیار مشتری قرار می‌گیرد. این روش معمولاً اختیار و منابع بیشتری فراهم می‌کند، اما برای بسیاری از پروژه‌های کوچک و متوسط ضروری نیست.
سه مفهوم را باید از یکدیگر جدا کرد:
| نوع اختصاصی‌بودن | منظور چیست؟ |
| حساب و دسترسی خصوصی | کاربران و مجوزهای پروژه از دیگر مشتریان جدا هستند؛ ممکن است خود بروکر مشترک باشد. |
| نمونه مستقل بروکر | یک نمونه جدا از نرم‌افزار بروکر برای پروژه اجرا می‌شود. |
| سخت‌افزار اختصاصی | کل سرور فیزیکی به یک مشتری اختصاص دارد. |
بنابراین، داشتن حساب خصوصی در یک بروکر مشترک، به‌تنهایی به معنی داشتن یک نمونه مستقل بروکر نیست.
تفاوت بروکر خودمیزبان و بروکر مدیریت‌شده
در روش خودمیزبان، مسئولیت نصب، تنظیم و اداره بروکر بر عهده خودمان است. محل نصب می‌تواند داخل شرکت یا روی سرور اجاره‌ای باشد؛ خودمیزبان‌بودن الزاماً به معنی محلی‌بودن نیست.
در روش مدیریت‌شده، ارائه‌دهنده بخشی از امور اجرایی مانند نصب، پایش، به‌روزرسانی یا بازیابی سرویس را بر عهده می‌گیرد. حدود این مسئولیت باید در مشخصات خدمت روشن باشد.
حتی می‌توان بروکر را روی زیرساخت ابری متعلق به حساب مشتری اجرا کرد، اما مدیریت آن را به شرکت متخصص سپرد. سرویس ای‌ام‌کیوایکس در زیرساخت ابری مشتری، نمونه‌ای از این مدل است.
شکل ۱ ـ تفاوت حساب خصوصی، نمونه مستقل بروکر و سخت‌افزار اختصاصی
۲. نصب نرم‌افزار بروکر یا نوشتن بروکر از ابتدا؟
روش معمول راه‌اندازی با نرم‌افزارهای آماده
برای داشتن بروکر، معمولاً نیازی به برنامه‌نویسی آن نداریم. نرم‌افزارهای آماده، وظایفی مانند پذیرش اتصال‌ها، مدیریت اشتراک‌ها، توزیع پیام و نگهداری وضعیت ارتباط را پیاده‌سازی کرده‌اند.
در این روش، مراحل اصلی عبارت‌اند از:
۱. انتخاب نرم‌افزار مناسب؛
۲. نصب روی سیستم‌عامل یا محیط اجرای سازگار؛
۳. تنظیم شبکه و درگاه‌های ارتباطی؛
۴. تعریف کاربران و مجوزها؛
۵. آزمایش و آماده‌سازی برای کار دائم.
برای مثال، نرم‌افزار مسکویتو همراه با ابزارهای ارسال و دریافت پیام و ابزارهای مدیریتی ارائه می‌شود. این ابزارها امکان آزمایش بروکر را بدون نوشتن یک برنامه اختصاصی فراهم می‌کنند.
Eclipse Mosquitto
الزامات و دشواری‌های توسعه یک بروکر جدید
نوشتن بروکر از ابتدا، یک پروژه توسعه نرم‌افزار مستقل است. دریافت چند پیام و ارسال آن‌ها به چند گیرنده، فقط بخش ابتدایی این کار محسوب می‌شود.
یک بروکر قابل اتکا باید اتصال‌های هم‌زمان، پیام‌های ناقص، قطع ناگهانی شبکه، محدودیت حافظه، صف پیام‌ها و رفتار کلاینت‌های مختلف را مدیریت کند. امنیت، ذخیره پایدار و سازگاری با استاندارد نیز به طراحی و آزمون نیاز دارند.
برای نمونه، ممکن است دریافت‌کننده‌ای بسیار کند باشد، در حالی که فرستنده با سرعت زیاد پیام منتشر می‌کند. بروکر باید سیاست روشنی برای مدیریت صف و جلوگیری از مصرف نامحدود حافظه داشته باشد.
توسعه بروکر جدید زمانی توجیه بیشتری دارد که هدف، ساخت خودِ محصول بروکر یا تأمین یک نیاز ویژه باشد. برای بیشتر پروژه‌های پایش و کنترل صنعتی، استفاده از نرم‌افزار آماده، حجم توسعه و آزمون مورد نیاز را کاهش می‌دهد.
۳. نیازمندی‌های فنی راه‌اندازی بروکر
پردازنده، حافظه و فضای ذخیره‌سازی
نیاز سخت‌افزاری بروکر به نرم‌افزار و بار کاری وابسته است. نمی‌توان صرفاً با دانستن تعداد دستگاه‌ها، مقدار حافظه یا تعداد هسته پردازنده را قطعی تعیین کرد.
پردازنده، عملیات مربوط به ارتباط‌ها، توزیع پیام و رمزگذاری را انجام می‌دهد. حافظه برای اتصال‌ها، اشتراک‌ها و صف‌های پیام مصرف می‌شود. فضای ذخیره‌سازی نیز برای تنظیمات، گزارش‌ها و داده‌های پایدار مورد نیاز است.
برای یک آزمایش کوچک، ممکن است یک رایانه تک‌بردی کافی باشد. مسکویتو به‌عنوان بروکری سبک، برای طیفی از رایانه‌های کم‌مصرف تا سرورها معرفی شده است. این موضوع به معنی تضمین ظرفیت مشخص روی هر سخت‌افزار نیست.
اگر پایگاه داده، داشبورد یا نرم‌افزار تحلیل نیز روی همان دستگاه نصب شود، منابع لازم برای آن‌ها باید جداگانه محاسبه شود.
سیستم‌عامل و روش نصب
سیستم‌عامل باید با نرم‌افزار انتخابی سازگار باشد. برای نمونه، مسکویتو روش‌های دریافت و نصب برای ویندوز و توزیع‌های مختلف لینوکس دارد.
دو روش رایج استقرار عبارت‌اند از:
• نصب مستقیم: نرم‌افزار روی سیستم‌عامل نصب و به‌صورت سرویس اجرا می‌شود.
• نصب در کانتینر: نرم‌افزار در محیط اجرایی جداگانه‌ای اجرا می‌شود که استقرار و انتقال آن را منظم‌تر می‌کند.
در روش کانتینری، باید محل تنظیمات و داده‌های پایدار مشخص باشد. نگهداری اطلاعات فقط داخل فضای موقت کانتینر می‌تواند هنگام حذف یا بازسازی آن مشکل ایجاد کند.
در هر دو روش، اجرای خودکار پس از روشن‌شدن سیستم و راه‌اندازی مجدد پس از توقف برنامه اهمیت دارد.
شبکه، اینترنت، دامنه و آدرس قابل دسترس
برای بروکری که فقط در شبکه داخلی استفاده می‌شود، اینترنت و آدرس عمومی الزامی نیست. کافی است دستگاه‌ها بتوانند در همان شبکه به آن دسترسی پیدا کنند.
اگر قرار است دستگاه‌های خارج از مجموعه نیز متصل شوند، باید مسیر دسترسی مناسب وجود داشته باشد؛ مانند سرور دارای آدرس عمومی یا شبکه خصوصی مجازی.
دامنه، نشانی قابل‌فهم و قابل‌مدیریتی برای بروکر فراهم می‌کند. برای نمونه، می‌توان یک زیردامنه از دامنه شرکت را به آن اختصاص داد:
mqtt.example.com
داشتن دامنه به معنی نیاز به ساخت وب‌سایت نیست. این نام فقط می‌تواند نشانی سرویس بروکر باشد.
همچنین، هر دستگاه متصل‌شونده الزاماً به آدرس عمومی نیاز ندارد. وقتی دستگاه اتصال خروجی را به بروکر قابل دسترس برقرار می‌کند، معمولاً نیازی به بازکردن مسیر ورودی جداگانه روی مودم آن دستگاه نیست.
گواهی امنیتی، دیواره آتش و پشتیبان‌گیری
برای ارتباط رمزگذاری‌شده، باید تنظیمات امنیتی متناسب با نرم‌افزار و دستگاه‌ها انجام شود. در روش متداول مبتنی بر گواهی، کلاینت باید بتواند اعتبار گواهی و هویت سرور را بررسی کند.
دیواره آتش نیز باید فقط دسترسی‌های مورد نیاز را مجاز کند. بازبودن سرویس بروکر برای دستگاه‌ها، به معنی ضرورت بازبودن پنل مدیریت آن برای تمام اینترنت نیست.
نسخه پشتیبان باید تنظیمات، اطلاعات دسترسی و داده‌های پایدار مورد نیاز را پوشش دهد. جزئیات ذخیره‌سازی و امنیت در مستندات هر بروکر مشخص می‌شود.
عوامل مؤثر بر ظرفیت و تعداد اتصال‌ها
علاوه بر تعداد اتصال‌ها، این عوامل بر ظرفیت اثر دارند:
• تعداد پیام‌های ارسالی در ثانیه؛
• اندازه هر پیام؛
• تعداد دریافت‌کنندگان هر پیام؛
• میزان استفاده از رمزگذاری و ذخیره پایدار؛
• تعداد و طول صف‌های پیام؛
• اتصال مجدد هم‌زمان دستگاه‌ها.
برای یک مثال فرضی، هزار دستگاه را در نظر بگیریم که هر ده ثانیه یک پیام می‌فرستند. میانگین ورودی بروکر حدود صد پیام در ثانیه خواهد بود. اگر هر پیام پنج دریافت‌کننده داشته باشد، حدود پانصد تحویل خروجی در ثانیه نیز ایجاد می‌شود.
این محاسبه، سربار ارتباط و تأییدها را شامل نمی‌شود. هدف آن نشان‌دادن این نکته است که هزار اتصال کم‌کار با هزار اتصال پرترافیک، نیاز سخت‌افزاری یکسانی ندارند.
شکل ۲ ـ نیازمندی‌های فنی راه‌اندازی بروکر
۴. روش اول: نصب روی تجهیزات محلی خودمان
کامپیوتر شخصی و سرور داخل شرکت
برای آموزش، توسعه و آزمایش اولیه، می‌توان بروکر را روی یک کامپیوتر موجود نصب کرد. این روش هزینه شروع کمی دارد و دسترسی به تنظیمات و گزارش‌ها آسان است.
اما کامپیوتری که برای کارهای روزمره استفاده می‌شود، ممکن است خاموش شود، به حالت خواب برود یا به علت به‌روزرسانی راه‌اندازی مجدد شود. بنابراین، مناسب‌بودن آن برای آزمایش به معنی مناسب‌بودن برای سرویس دائم نیست.
برای کار پیوسته، یک مینی‌کامپیوتر یا سرور مشخص با تنظیمات پایدار، انتخاب قابل‌بررسی‌تری است.
رزبری‌پای و رایانه تک‌بردی
رایانه‌های تک‌بردی می‌توانند میزبان بروکر سبک در پروژه‌های کوچک باشند. ابعاد کم و مصرف برق پایین، آن‌ها را برای نصب داخل مجموعه جذاب می‌کند.
در چنین استقراری، کیفیت منبع تغذیه، ذخیره‌ساز و تهویه اهمیت دارد. اگر گزارش‌ها یا داده‌های پایدار مرتب نوشته شوند، دوام و قابلیت بازیابی ذخیره‌ساز نیز باید در طراحی لحاظ شود.
برای نمونه، یک رزبری‌پای می‌تواند بروکر محلی یک آزمایشگاه یا گلخانه کوچک باشد؛ به شرط آنکه بار واقعی و رفتار سیستم در قطعی برق آزمایش شده باشد.
رایانه صنعتی و گیت‌وی لبه
در محیط صنعتی، عواملی مانند دمای کار، کیفیت تغذیه، نصب داخل تابلو و امکان کار مداوم اهمیت بیشتری پیدا می‌کنند. رایانه صنعتی یا گیت‌وی دارای قابلیت اجرای نرم‌افزار، می‌تواند میزبان بروکر باشد.
«بروکر لبه» به بروکری گفته می‌شود که نزدیک تجهیزات و در محل جمع‌آوری داده اجرا می‌شود. لبه، جایگاه بروکر در معماری سامانه است؛ الزاماً نام یک دستگاه خاص نیست.
نانوام‌کیو نمونه‌ای از بروکرهای متمرکز بر کاربردهای لبه است. نسخه تجاری مرتبط با آن نیز با نام ای‌ام‌کیوایکس اج عرضه می‌شود.
NanoMQ
EMQX Edge
البته هر گیت‌وی دارای ارتباط ام‌کیوتی‌تی، بروکر نیست. بسیاری از گیت‌وی‌ها فقط کلاینت هستند و برای تبادل پیام باید به بروکر دیگری متصل شوند.
کاربرد بروکر محلی در گلخانه، کارخانه و ساختمان
در گلخانه، بروکر محلی می‌تواند ارتباط گیت‌وی، نمایشگر و نرم‌افزار کنترل را برقرار کند. در کارخانه، می‌تواند پیام‌های تجهیزات یک خط را میان برنامه‌های پایش و ثبت اطلاعات توزیع کند. در ساختمان نیز می‌تواند نقطه ارتباط مشترک میان کنترلرها و نرم‌افزار مدیریت باشد.
مزیت این ساختار، نزدیک‌بودن سرویس به تجهیزات و امکان تبادل اطلاعات در شبکه محلی است.
مزایا، محدودیت‌ها و امکان کار بدون اینترنت
اگر بروکر، دستگاه‌ها و نرم‌افزارهای مورد نیاز همگی در شبکه محلی باشند، تبادل محلی پیام می‌تواند بدون اینترنت ادامه یابد. البته برق، شبکه داخلی و خود برنامه‌ها باید فعال بمانند.
محدودیت اصلی این روش، مسئولیت نگهداری در محل است. خرابی سخت‌افزار، قطع برق یا توقف بروکر باید توسط مجموعه مدیریت شود. دسترسی از راه دور نیز به طراحی جداگانه شبکه نیاز دارد.
همچنین محلی‌بودن بروکر، به‌تنهایی تضمین نمی‌کند که کل سامانه مستقل از اینترنت باشد؛ ممکن است برنامه کنترل، احراز هویت یا بخش دیگری همچنان به سرویس خارجی وابسته باشد.
۵. روش دوم: نصب روی سرور اجاره‌ای
تفاوت هاست اشتراکی وب، سرور مجازی و سرور اختصاصی
در این روش، زیرساخت را از شرکت میزبان اجاره و نرم‌افزار بروکر را روی آن نصب می‌کنیم. پیش از خرید، باید نوع سرویس مشخص باشد.
| نوع میزبانی | ویژگی اصلی | وضعیت برای نصب بروکر |
| هاست اشتراکی وب | محیط از پیش تنظیم‌شده برای میزبانی وب‌سایت | معمولاً محدود؛ نیازمند تأیید امکانات لازم |
| سرور مجازی | سیستم‌عامل جدا با منابع و دسترسی مدیریتی مشخص | مناسب برای بررسی و نصب بروکر |
| سرور فیزیکی اختصاصی | کل یک سرور در اختیار مشتری | قابل استفاده برای نیازهای بزرگ‌تر یا خاص |
عنوان «ابری» به‌تنهایی این تفاوت‌ها را مشخص نمی‌کند. هاست وب ابری همچنان ممکن است محدودیت‌های هاست وب را داشته باشد.
چرا هر هاست وب برای نصب بروکر مناسب نیست؟
بروکر باید به‌صورت یک برنامه دائماً فعال اجرا شود و ارتباط‌های طولانی‌مدت را بپذیرد. هاست اشتراکی وب ممکن است اجازه اجرای چنین برنامه‌ای، نصب نرم‌افزار دلخواه یا استفاده از درگاه لازم را ندهد.
بنابراین، داشتن هاست وردپرس یا فضای میزبانی سایت شرکت، به معنی فراهم‌بودن بستر نصب بروکر نیست.
اگر یک سرویس میزبانی برنامه یا کانتینر انتخاب می‌شود، باید پشتیبانی از نوع اتصال مورد نیاز دستگاه‌ها بررسی شود. سرویسی که فقط ترافیک معمول وب را عبور می‌دهد، الزاماً برای اتصال مستقیم همه کلاینت‌های ام‌کیوتی‌تی مناسب نیست.
نمونه ارائه‌دهندگان ایرانی و معیار انتخاب آن‌ها
پارس‌پک، آروان‌کلاد و لیارا از نمونه‌های ایرانی ارائه‌دهنده زیرساخت سرور ابری هستند. برای این کاربرد باید محصول سرور و امکانات همان طرح بررسی شود؛ این معرفی به معنی ارائه بروکر آماده در تمام خدمات آن‌ها نیست.
معیارهای مهم انتخاب عبارت‌اند از:
• دسترسی مدیریتی و امکان نصب نرم‌افزار؛
• منابع پردازشی و حافظه؛
• فضای ذخیره‌سازی پایدار و امکانات پشتیبان؛
• آدرس قابل دسترس و قواعد شبکه؛
• هزینه ترافیک و امکان افزایش منابع؛
• کیفیت پشتیبانی و دسترسی از شبکه دستگاه‌های واقعی.
برای تجهیزات متصل با سیم‌کارت، بهتر است کیفیت ارتباط از همان اپراتور و محل نصب نیز آزمایش شود.
مراحل کلی نصب و دسترسی از بیرون شبکه
ابتدا سرور با سیستم‌عامل سازگار ایجاد می‌شود. سپس بروکر نصب، کاربران تعریف و درگاه ارتباطی تنظیم می‌شود. در ادامه، دامنه و گواهی در صورت نیاز پیکربندی و قواعد دیواره آتش اعمال می‌شوند.
آزمایش نهایی باید از شبکه‌ای خارج از سرور انجام شود. موفقیت اتصال روی خود سرور، به‌تنهایی نشان نمی‌دهد که دستگاه داخل گلخانه هم می‌تواند به آن دسترسی پیدا کند.
در سرویس خودمدیریت، شرکت میزبان زیرساخت را فراهم می‌کند؛ اما تنظیم کاربران بروکر، به‌روزرسانی نرم‌افزار و بازیابی تنظیمات همچنان مسئولیت مدیر پروژه است.
۶. روش سوم: تهیه سرور یا سرویس اختصاصی با نصب آماده
تصویر آماده، نصب یک‌کلیکی و سرویس مدیریت‌شده
در این روش، تمام مراحل نصب اولیه را دستی انجام نمی‌دهیم. ارائه‌دهنده می‌تواند نرم‌افزار را به یکی از شکل‌های زیر آماده کند:
تصویر آماده: یک قالب از پیش آماده برای ایجاد سرور یا محیط اجرا که بروکر یا پیش‌نیازهای آن را دارد.
نصب یک‌کلیکی: فرایندی خودکار که با انتخاب نرم‌افزار، عملیات استقرار اولیه را انجام می‌دهد.
سرویس مدیریت‌شده: خدمتی که علاوه بر استقرار، مسئولیت‌های مشخصی از اداره و نگهداری را نیز بر عهده می‌گیرد.
نصب آماده و مدیریت کامل یکسان نیستند. ممکن است نرم‌افزار در چند دقیقه نصب شود، اما به‌روزرسانی و پشتیبان‌گیری همچنان بر عهده مشتری باقی بماند.
نمونه خدمات ایرانی و خارجی
در ایران، چابکان و رانفلر صفحه مشخصی برای سرویس یا میزبانی مسکویتو دارند و نمونه‌هایی برای بررسی روش استقرار آماده هستند. میزان جداسازی نمونه، منابع، دسترسی به تنظیمات و تعهدات نگهداری باید از مشخصات همان طرح روشن شود.
در نمونه‌های خارجی، مستندات هایوام‌کیو روش‌های استقرار روی ارائه‌دهندگان ابری را معرفی می‌کند. این مسیر باید از اجاره یک بروکر کاملاً مدیریت‌شده تفکیک شود؛ استفاده از راهکار استقرار آماده لزوماً مدیریت روزمره را به فروشنده منتقل نمی‌کند.
HiveMQ
نمونه دیگر، اجرای ای‌ام‌کیوایکس در زیرساخت ابری خود مشتری همراه با مدیریت توسط تیم ارائه‌دهنده است. این مدل میان اختیار بر زیرساخت و دریافت خدمات تخصصی مدیریت قرار می‌گیرد.
EMQX BYOC
مسئولیت ارائه‌دهنده و مسئولیت مشتری در هر روش
| روش | مسئولیت معمول ارائه‌دهنده | مسئولیت معمول مشتری |
| سرور خام | زیرساخت و امکانات قراردادی سرور | نصب و اداره سیستم‌عامل و بروکر |
| نصب آماده | زیرساخت و استقرار اولیه نرم‌افزار | تنظیمات کاربردی و نگهداری خارج از قرارداد |
| بروکر مدیریت‌شده | اداره بروکر در حدود تعهد خدمت | کاربران، مجوزها، دستگاه‌ها و طراحی کاربرد |
پیش از انتخاب، باید روشن شود چه کسی گواهی را تمدید می‌کند، چه کسی نسخه پشتیبان می‌گیرد و در صورت خرابی چه کسی مسئول بازیابی است.
همچنین لازم است بدانیم آیا مشتری نمونه مستقل بروکر دارد یا فقط حسابی خصوصی در یک سرویس مشترک دریافت می‌کند. نام تجاری «اختصاصی» باید با مشخصات فنی خدمت تطبیق داده شود.
شکل ۳ ـ مقایسه سه روش استقرار بروکر اختصاصی
۷. نرم‌افزارهای رایگان و تجاری بروکر
معرفی نمونه‌های شناخته‌شده
مسکویتو
بروکری متن‌باز و سبک است که برای استقرارهای محلی و مستقل قابل بررسی است. نصب نسبتاً ساده و وجود ابزارهای همراه، آن را برای شروع کار نیز مناسب می‌کند. امکانات آن را نباید با نسخه‌های تجاری دارای مدیریت یا پایداری افزوده یکسان فرض کرد.
Eclipse Mosquitto
هایوام‌کیو نسخه جامعه
یک بروکر متن‌باز مبتنی بر جاوا است. انتخاب آن مستلزم توجه به محیط اجرای جاوا و منابع متناسب با بار پروژه است. نسخه جامعه و محصول تجاری هایوام‌کیو باید به‌صورت جداگانه مقایسه شوند.
HiveMQ Community Edition
ای‌ام‌کیوایکس
از نسخه ۵٫۹ به بعد، تحت مجوز «کد در دسترس» عرضه شده است. طبق توضیح رسمی، استفاده عملیاتی تک‌گرهی در شرایط تعیین‌شده می‌تواند رایگان باشد، اما خوشه‌بندی یا ارائه خود نرم‌افزار به‌صورت سرویس میزبانی‌شده یا محصول تعبیه‌شده برای دیگران، به مجوز تجاری نیاز دارد.
بنابراین، برای شرکتی که می‌خواهد بروکر را همراه یک محصول یا خدمت به مشتریان عرضه کند، بررسی مجوز همان نسخه اهمیت ویژه دارد.
EMQX
نسخه حرفه‌ای مسکویتو
محصول تجاری شرکت سدالو است و امکانات سازمانی، مدیریتی و پشتیبانی را پیرامون بروکر ارائه می‌کند. هنگام مقایسه، باید امکانات موجود در بسته انتخابی مشخص شود.
Pro Mosquitto
نانوام‌کیو
بروکری سبک با تمرکز بر محیط‌های لبه و سامانه‌های نزدیک تجهیزات است. برای استفاده روی سخت‌افزارهای محدود، باید سازگاری معماری پردازنده و قابلیت‌های مورد نیاز پروژه بررسی شود.
NanoMQ
تفاوت نسخه متن‌باز، رایگان و تجاری
این سه اصطلاح مترادف نیستند.
متن‌بازبودن به حقوقی مربوط است که مجوز برای استفاده، بررسی، تغییر و توزیع نرم‌افزار فراهم می‌کند.
رایگان‌بودن ممکن است فقط به نبود هزینه مجوز در یک محدوده مشخص اشاره کند؛ مثلاً برای آزمایش یا استقرار با شرایط معین.
تجاری‌بودن نیز می‌تواند به فروش مجوز، امکانات افزوده یا خدمات پشتیبانی مربوط باشد. نرم‌افزار متن‌باز هم ممکن است خدمات تجاری پیرامون خود داشته باشد.
همچنین صرف دسترسی به کد، به معنی متن‌بازبودن بدون محدودیت کاربرد نیست. در انتخاب محصول باید مجوز همان نسخه و نوع استفاده واقعی پروژه بررسی شود.
مقایسه امکانات، مجوز استفاده و نیاز سخت‌افزاری
| گزینه | محور اصلی بررسی | نکته اجرایی |
| مسکویتو | بروکر سبک و مستقل | امکانات مدیریتی مورد نیاز را جدا بررسی کنید. |
| هایوام‌کیو نسخه جامعه | بروکر متن‌باز مبتنی بر جاوا | محیط اجرا و منابع با بار واقعی تطبیق داده شود. |
| ای‌ام‌کیوایکس | امکانات مدیریت و توسعه استقرار | مجوز نسخه و شرایط خوشه‌بندی بررسی شود. |
| نسخه حرفه‌ای مسکویتو | امکانات و پشتیبانی سازمانی | قابلیت‌های بسته تجاری مشخص شود. |
| نانوام‌کیو | اجرای بروکر در لبه | سازگاری سخت‌افزار و نیازهای پروژه بررسی شود. |
برای مقایسه منابع، اجرای یک آزمایش یکسان روی گزینه‌ها مفیدتر از تکیه بر عبارت‌هایی مانند «پشتیبانی از میلیون‌ها دستگاه» است. اندازه پیام، تعداد گیرندگان و تنظیمات ذخیره‌سازی باید در آزمایش مشابه باشند.
همچنین رایگان‌بودن نرم‌افزار، هزینه برق، سرور، نیروی نگهداری و توقف سرویس را حذف نمی‌کند.
۸. از نصب تا بهره‌برداری
ساخت کاربر و تعریف دسترسی
پس از نصب، نخستین کار تعیین هویت‌ها و مجوزهاست. برای دستگاه‌ها و برنامه‌ها باید دسترسی متناسب با وظیفه آن‌ها تعریف شود.
در مثال گلخانه، گیت‌وی سالن اول باید بتواند داده‌های خودش را منتشر و فرمان‌های مجاز همان سالن را دریافت کند. کاربر ناظر ممکن است فقط اجازه مشاهده داشته باشد، در حالی که کاربر مسئول کنترل، مجوز ارسال فرمان نیز دارد.
بهتر است دسترسی‌ها از ابتدا محدود و مشخص باشند؛ استفاده از یک حساب مشترک با اختیار کامل برای تمام تجهیزات، مدیریت خطا و قطع دسترسی را دشوار می‌کند.
اتصال نخستین دستگاه
مشخصات اتصال در دستگاه یا نرم‌افزار وارد می‌شود: نشانی بروکر، درگاه، شناسه کلاینت، اطلاعات احراز هویت و تنظیمات امنیتی.
ابتدا باید اتصال یک کلاینت آزمایشی بررسی شود و سپس گیت‌وی یا دستگاه واقعی متصل گردد. این ترتیب کمک می‌کند مشکلات سمت سرور از مشکلات تنظیمات دستگاه تفکیک شوند.
شناسه کلاینت‌ها نیز باید درست مدیریت شود تا استفاده هم‌زمان دستگاه‌ها از یک شناسه، موجب اختلال ارتباط نشود.
آزمایش انتشار و دریافت پیام
برای آزمایش پایه، یک کلاینت پیام منتشر می‌کند و کلاینت دیگر دریافت آن را بررسی می‌کند. سپس مسیر برعکس نیز آزمایش می‌شود.
در پروژه کنترلی، آزمون باید تا خود تجهیز ادامه یابد: برنامه فرمان می‌دهد، گیت‌وی آن را دریافت می‌کند، خروجی تغییر می‌کند و نتیجه به برنامه برمی‌گردد.
این آزمون، فقط صحت بروکر را نمی‌سنجد؛ سازگاری موضوع‌ها، محتوای پیام و منطق دستگاه‌ها را نیز مشخص می‌کند.
همچنین باید بررسی شود که حساب فاقد مجوز، نتواند پیام‌های محدودشده را دریافت یا فرمان غیرمجاز منتشر کند.
آماده‌سازی برای استفاده واقعی
پیش از تحویل، این موارد باید تعیین و آزمایش شوند:
۱. اجرای خودکار بروکر پس از روشن‌شدن سرور؛
۲. رفتار دستگاه‌ها پس از قطع و وصل شبکه؛
۳. بقای اطلاعات مورد نیاز پس از راه‌اندازی مجدد؛
۴. مدیریت فضای دیسک و حجم گزارش‌ها؛
۵. تهیه نسخه پشتیبان و آزمایش بازیابی؛
۶. پایش سرویس و مشخص‌بودن مسئول رسیدگی به خرابی؛
۷. امکان تغییر آدرس یا انتقال بروکر در آینده.
شکل ۴ ـ مراحل نصب تا بهره‌برداری
راه‌اندازی زمانی کامل می‌شود که سرویس علاوه بر کارکرد عادی، رفتار مشخصی در برابر قطعی و خرابی داشته باشد. برای یک پروژه صنعتی، ارسال موفق یک پیام آغاز آزمون است؛ معیار تحویل، کارکرد قابل اتکای کل مسیر ارتباطی خواهد بود.
در قسمت سوم، روش اجاره بروکر ابری، تفاوت آن با پلتفرم اینترنت اشیا و چالش‌های انتخاب و نگهداری سرویس را بررسی می‌کنیم.
دیدگاه خود را بنویسید