بله، میشه سیستمهایی مثل Odoo که بر اساس این مدل طراحی نشدهاند رو هم با طراحی مناسب به معماری محاسبات لبه (Edge Computing) تبدیل کرد، هرچند این کار نیازمند بازنگری در معماری و نحوه تعامل اجزای سیستم است. البته این یه کار ساده نیست و نیازمند زمان و هزینه بالایی است. ما در تیم اودوونیکس این کار رو انجام دادیم و در یک مدل کوچک آزمایش کردیم.
مدل محاسبات لبه که در تیم اودوونیسک روی اودوو پیاده سازی شده، محاسبات رو بین یک سرور و یک لبه که در دو مرکز داده در دو کشور متفاوت هستن تقسیم کرده. این کار باعش شده کارها با سرعت بالایی انجام بشه و حتی کاربرها حس نکردن که سیستم مبتنی بر وب هست.
در ادامه توضیح میدهم چگونه این تبدیل ممکن است و چه نکاتی باید در نظر گرفته شود:
آیا Odoo قابل تبدیل به معماری Edge است؟
Odoo یک ERP ماژولار و تحت وب هست که معمولاً بهصورت متمرکز و یک پارچه اجرا میشه. هدفش هم این بوده که بتونه تمام نرم افزارهای یک سازمان رو به صورت یکپارچه پیاده سازی کنه. اما با توجه به ساختار باز و انعطافپذیر آن، میتوان بخشهایی از آن را به لبه منتقل کرد، بهویژه در سناریوهایی که:
- تاخیر کشنده است (مثلاً در خطوط تولید یا انبارهای دورافتاده)
- دادهها باید سریع پردازش شوند (مثل ثبت ورود کالا یا کنترل کیفیت)
- اتصال به اینترنت ناپایدار یا محدود است
فرض کنید که یک محموله باری به انبار رسیده و شما میخواهید آنها را تخله و در انبار قرار دهید. در همین هین اینترنت قطع میشه. راننده کامیون ناراحت هست و نمیتونه حتی یک ساعت هم صبر کنه. زمان برای یک انباردار در این شرایط خیلی سخت می گذره.
راهکارهای تبدیل Odoo به معماری Edge
1. شناسایی ماژولهای حساس به تأخیر
- ماژولهایی مثل انبار، تولید، فروش حضوری یا کنترل کیفیت را میتوان به لبه منتقل کرد.
- این ماژولها میتوانند بهصورت محلی اجرا شوند و دادهها را بهصورت دورهای با سرور مرکزی همگام کنند.
2. استقرار نسخههای سبک Odoo در لبه
- نصب Odoo روی سختافزارهای سبک مثل Raspberry Pi یا مینیPC با استفاده از Docker.
- اجرای فقط ماژولهای موردنیاز در لبه برای کاهش مصرف منابع.
یه نکته باید اضافه کنم. اگر شما به اودوو مسلط باشید متوجه می شید که نیازی نیست که دادههایی که در لبه پردازش میشه و نتایجی که نمایش داده میشه دقیقا همونهایی باشه که در مرکز داده ذخیره میشه.
مثلا فرض کنید که برای تیم حسابداری شناسایی هزینهها و تفکیک آنها در ثبت فروش بسیار مهم باشه. اما در فروشگاههایی که دارید و عمل فروش در آنجا انجام میشه اصلا این موضوع مهم نیست. برای همین بدون در نظرگرفتن محاسبات حسابداری و شناسایی هزینهها در لبه تنها فروش رو به صورت معمولی ثبت میکنید. زمانی که مرکز داده با لبهها همزمان سازی می شود اطلاعات فروش انتقال داده میشه و اینجا است که اطلاعات مربوط به شناسایی هزینهها اضافه میشه.
اینکه زمان فروش ساعت ۸ صبح بوده یا ۹:۴۵ در حسابداری مهم نیست، اما مهم این هست که شناسایی هزینه ثبت بشه. دقیقا برعکس در فروش مهم این هست که در حضور مشتری در کمترین زمان ثبت انجام بشه.
3. طراحی مکانیزم همگامسازی دادهها
4. استفاده از معماری Microservices یا کانتینری
- تقسیم Odoo به سرویسهای مستقل (مثلاً سرویس فروش، سرویس انبار) و اجرای آنها در گرههای لبه.
- استفاده از ابزارهایی مثل KubeEdge یا EdgeX Foundry برای مدیریت سرویسها.
- استفاده از داکر برای ایجاد اپلیکشنهای آماده به کار لبه
5. افزودن قابلیت آفلاین و بازیابی
- گرههای لبه باید بتوانند در حالت آفلاین کار کنند و پس از اتصال، دادهها را منتقل کنند.
- این قابلیت برای مکانهایی با اتصال ضعیف حیاتی است.
مثال عملی
در یک کارخانه، یک نسخه سبک Odoo روی رزبریپای نصب میشود تا ورود کالاها و تولید را ثبت کند. این دادهها بهصورت دورهای به سرور مرکزی منتقل میشوند تا در گزارشهای مدیریتی لحاظ شوند. در صورت قطع اینترنت، سیستم همچنان بهصورت محلی کار میکند.
اگر بخوای دقیقتر بدونی برای کدوم ماژولها یا سناریوها این تبدیل بهصرفهتره، یا چطور Docker و همگامسازی رو پیادهسازی کنیم، خوشحال میشیم که با تیم اودوونیکس تماس بگیری تا شما رو راهنماییات کنم.