یک درخواست HTTP ده ثانیهای در شبکههای 3G روستایی تقریباً همیشه به شکست و بسته شدن برنامه منجر میشود. برای حل این بحران، تیم Smart Tech Devs یک خط لوله پردازش تصویر ناهمگام را برای پلتفرم KhedutBandhu (ખેડૂત બંધુ) طراحی کرد. این سیستم قدرتبخش ابزار «دکتر تشخیص بیماری گیاهان» (AI પાક નિદાન) است که به کشاورزان اجازه میدهد با گرفتن عکس از برگهای در حال پوسیدگی، عفونتهای قارچی یا حملات آفات را شناسایی کنند.
پردازش تصاویر با کیفیت بالا توسط یک شبکه عصبی پیچشی (CNN) — شبیه نقشه پیچیدهای از مترو که سیگنالها را برای رسیدن به جواب جابهجا میکند — از نظر محاسباتی بسیار سنگین است. طبق گزارش منتشر شده در dev.to، در یک ساختار استاندارد، اپلیکیشن موبایل منتظر میماند تا استنتاج (Inference) در بکاند تمام شود و سپس پاسخ را دریافت کند. برای کشاورزانی که تصاویر ۴ مگابایتی آپلود میکنند، این تأخیر تبدیل به یک نقطه شکست بحرانی میشود. اگر یک کنترلر لاراول منتظر بماند تا یک میکروسرویس پایتون ماتریس تصویر را پردازش کند، این درخواست میتواند بین ۵ تا ۱۰ ثانیه طول بکشد که منجر به Timeout و از دست رفتن اعتماد کاربر میشود. این فشار محاسباتی نه تنها بر تجربه کاربری، بلکه بر سختافزار سرورها نیز اثرگذار است؛ چنانکه تحلیلهای زیرساختی نشان میدهد درخواستهای سنگین مدلهای AI تأثیر مستقیمی بر سیستمهای خنککننده مراکز داده دارند.
زمینه معماری
برای محافظت از تجربه کاربری (UX) در موبایل، تیم توسعه عملیات آپلود را از عملیات استنتاج جدا کرد. آنها مدل ارتباطی را از درخواستهای مستقیم و همگام HTTP POST به یک «خط لوله پردازش تصویر رویدادمحور و ناهمگام» تغییر دادند. این معماری از صفهای کاری (Job Queues) در لاراول ۱۱ (Laravel 11) و ترکیبی از وبساکتها و Polling استفاده میکند تا برنامه فارغ از نوسانات شدید شبکه، پاسخگو باقی بماند.
بر اساس مستندات فنی این پروژه، تیم توسعه به یک معماری جداسازی شده در سه فاز منتقل شده است:
فاز ۱: دریافت سریع (Fast Ingestion)
هدف اصلی API لاراول در این مرحله این است که تصویر را در سریعترین زمان ممکن روی سرور قرار داده و اتصال HTTP را در سریعترین حالت فیزیکی ممکن ببندد. هنگامی که کاربر عکسی از برگ گیاه آپلود میکند، سیستم مراحل زیر را طی میکند:
- اعتبارسنجی فایل برای اطمینان از اینکه فایل واقعاً یک تصویر است و حجم آن از ۵ مگابایت بیشتر نیست.
- تولید یک شناسه UUID منحصربهفرد برای ردیابی دقیق هر اسکن.
- ذخیرهسازی سریع تصویر خام در یک S3 bucket (یا فضای ذخیرهسازی محلی).
- ایجاد یک رکورد در پایگاهداده با وضعیت «در حال پردازش» (processing).
- ارسال عملیات سنگین استنتاج AI به یک صف پسزمینه Redis.
- بازگرداندن وضعیت 202 Accepted در کمتر از ۲۰۰ میلیثانیه، که باعث میشود اتصال شبکه موبایل فوراً آزاد شود.
فاز ۲: استنتاج در پسزمینه (Background Inference)
در حالی که اپلیکیشن فلاتر یک انیمیشن نرم با متن «در حال تحلیل...» را نمایش میدهد، یک Worker لاراول کارهای سنگین را در پسزمینه مدیریت میکند. مکانیسم کار به این صورت است:
- Worker آدرس امن S3 را به یک میکروسرویس داخلی بینایی ماشین (Computer Vision) که با پایتون نوشته شده ارسال میکند.
- میکروسرویس AI تصویر را طبقهبندی میکند (به عنوان مثال، شناسایی «ویروس پیچیدگی برگ» یا leaf_curl_virus).
- سیستم سپس درمانهای محلی را از پایگاه دانش ادمین استخراج میکند؛ این درمانها شامل ترجمه روشهای ارگانیک و شیمیایی به زبان بومی کشاورز است.
- رکورد اسکن در پایگاهداده به وضعیت «تکمیل شده» (completed) تغییر مییابد و بیماری شناسایی شده و درمانها در آن ثبت میشوند.
- در نهایت، یک رویداد با نام
CropScanCompletedشلیک میشود تا کلاینت موبایل مطلع گردد.
فاز ۳: حلوفصل مقاوم (Resilient Resolution)
از آنجایی که KhedutBandhu به کشاورزان در مناطق روستایی با شبکههای ناپایدار خدمات میدهد، تیم یک مکانیسم جایگزین (Fallback) مقاوم در اپلیکیشن فلاتر پیاده کرد:
- مسیر اصلی: اپلیکیشن تلاش میکند نتیجه را بهصورت آنی و از طریق وبساکتها با استفاده از Pusher یا Laravel Reverb دریافت کند.
- مسیر جایگزین: اگر اتصال ساکت قطع شود، اپلیکیشن بهطور خودکار به حالت Short Polling تغییر وضعیت میدهد. در این حالت، برنامه بهصورت بیصدا هر ۳ ثانیه یکبار نقطه انتهایی
/api/scans/{scan_id}/statusرا فراخوانی میکند تا زمانی که وضعیت از «در حال پردازش» به «تکمیل شده» تغییر کند.
این تغییر در معماری، فرض بنیادین مبنی بر اینکه «پاسخهای AI باید فوری باشند» را تغییر میدهد. با تبدیل استنتاج به یک رویداد پسزمینه به جای یک چرخه درخواست-پاسخ (Request-Response)، توسعهدهندگان میتوانند مدلهای بینایی ماشین خود را مقیاسبندی کرده یا آنها را بدون نیاز به حتی یک بهروزرسانی در اپلیکیشن موبایل، جایگزین کنند.
برای کاربر نهایی، این تغییر تفاوت بین یک صفحه منجمد شده و یک ابزار صیقلخورده و قابل اعتماد است که درمانهای کشاورزی را فارغ از قدرت سیگنال شبکه تحویل میدهد. توسعهدهندگانی که قصد پیادهسازی الگوهای مشابه را دارند، باید ارزیابی کنند که آیا نقاط انتهایی AI فعلی آنها در حال مسدود کردن Thread اصلی هستند یا خیر و انتقال به گردش کار 202 Accepted را مد نظر قرار دهند.
گام بعدی شما
- بررسی کنید آیا نقاط انتهایی (Endpoints) هوش مصنوعی شما در حال مسدود کردن Thread اصلی هستند یا خیر.
- برای عملیاتهای با تأخیر بالا، گردش کار 202 Accepted را جایگزین پاسخهای همگام کنید.
- برای محیطهای با شبکه ضعیف، ترکیبی از WebSockets و Polling را برای بهروزرسانی وضعیت پیاده کنید.
اما مدیریت هزینههای این زیرساخت در مقیاس بالا چالش بعدی است — به تحلیل ما درباره بهینهسازی هزینههای استنتاج در محیطهای ابری مراجعه کنید.
گفتگو