Files
Backend/Backend.txt
T
2026-03-20 23:16:53 +03:30

163 lines
7.2 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
## Backend Architecture CropLogic Platform
پلتفرم **CropLogic** از سه سرویس کاملاً مستقل تشکیل شده است تا مقیاس‌پذیری، پایداری و امنیت داده‌ها در سطح بالایی حفظ شود. این سرویس‌ها عبارت‌اند از:
- Backend Service
- AI Service
- SensorHub Service
جدا بودن این سرویس‌ها باعث می‌شود هر بخش بتواند به‌صورت مستقل توسعه داده شود، در صورت افزایش بار به‌صورت جداگانه مقیاس‌پذیر باشد و در صورت بروز مشکل در یک سرویس، سایر سرویس‌ها دچار اختلال نشوند.
---
## 1. Backend Service
سرویس **Backend** هسته‌ی اصلی منطق سیستم محسوب می‌شود و نقش **Gateway** بین کلاینت و سایر سرویس‌های داخلی را ایفا می‌کند.
### وظایف اصلی
- دریافت درخواست‌ها از سمت کلاینت
- ارتباط با سرویس‌های **AI** و **SensorHub**
- پردازش و مدیریت خروجی سرویس‌ها
- آماده‌سازی و ارسال پاسخ نهایی به کلاینت
به عبارت دیگر، Backend لایه‌ی هماهنگ‌کننده بین بخش‌های مختلف سیستم است و تمام ارتباطات خارجی از طریق این سرویس انجام می‌شود.
### تکنولوژی‌ها
- **Framework:** Django
- **Database:** MySQL
پروژه با استفاده از **Clean Architecture** طراحی شده است؛ بنابراین لایه‌ی دیتابیس از منطق اصلی جدا بوده و در صورت نیاز امکان تغییر دیتابیس در آینده به‌سادگی وجود دارد.
---
## 2. AI Service
سرویس **AI** به دلیل حجم بالای محاسبات و احتمال ایجاد بار سنگین روی سیستم، به‌صورت کاملاً جدا از Backend پیاده‌سازی شده است. این سرویس مسئول انجام تمام پردازش‌های مرتبط با **هوش مصنوعی و تحلیل داده‌ها** است.
### بخش‌های اصلی این سرویس
#### 2.1 سیستم RAG (Retrieval-Augmented Generation)
این سیستم با استفاده از **Embedding مدل‌های LLM** پیاده‌سازی شده و نقش ساخت **دستیار هوشمند مزرعه** را بر عهده دارد.
از این دستیار برای:
- پاسخ به سوالات کشاورزان
- ارائه راهنمایی‌های تخصصی کشاورزی
- تحلیل شرایط مزرعه
استفاده می‌شود.
---
#### 2.2 دریافت اطلاعات خاک بر اساس مختصات جغرافیایی
برای دریافت داده‌های علمی مربوط به خاک از API زیر استفاده می‌شود:
`https://rest.isric.org/soilgrids`
این سرویس اطلاعات خاک را بر اساس مختصات جغرافیایی ارائه می‌دهد.
پارامترهای اصلی دریافت شده شامل موارد زیر است:
- depth_label
- bdod
- cec
- cfvo
- clay
- nitrogen
- ocd
- ocs
- phh2o
- sand
- silt
- soc
- wv0010
- wv0033
- wv1500
علاوه بر این، اطلاعات خاک برای عمق‌های مختلف نیز دریافت می‌شود، از جمله:
- 05 سانتی‌متر
- 510 سانتی‌متر
- 10–15 سانتی‌متر
این تفکیک عمق خاک اهمیت زیادی دارد، زیرا برخی گیاهان نسبت به ویژگی‌های خاک در عمق‌های خاص حساس‌تر هستند.
---
#### 2.3 ترکیب داده‌های خاک با داده‌های سنسور
اطلاعات دریافتی از SoilGrids با داده‌های **سنسورهای مزرعه** ترکیب می‌شوند.
هدف از این مرحله:
- تکمیل داده‌های ناقص سنسورها
- افزایش دقت مدل‌های تحلیلی
- ایجاد یک دیتاست کامل از شرایط واقعی مزرعه
---
#### 2.4 محاسبات تکمیلی ژئوفیزیک و خاک
در این مرحله، داده‌هایی که نه از طریق سنسورها و نه از طریق APIهای خارجی قابل دریافت نیستند، با استفاده از **فرمول‌های علمی ژئوفیزیک و خاک‌شناسی کشاورزی** محاسبه می‌شوند.
این کار باعث می‌شود مدل‌های تحلیلی تصویر کامل‌تری از شرایط مزرعه داشته باشند.
---
#### 2.5 تحلیل و مدل‌های هوش مصنوعی
در مرحله نهایی، داده‌های جمع‌آوری‌شده و پردازش‌شده وارد سیستم‌های تحلیلی می‌شوند که شامل موارد زیر است:
- استفاده از **سیستم RAG** برای تحلیل و تولید پاسخ
- استفاده از **Machine Learning** در سناریوهای تخصصی‌تر
- استفاده از **مدل‌های از پیش آموزش‌دیده (Pretrained Models)**
خروجی این تحلیل‌ها شامل مواردی مانند:
- توصیه زمان و میزان **آبیاری**
- توصیه **کوددهی**
- تحلیل وضعیت خاک و رشد گیاه
- پیشنهاد اقدامات بهینه برای مدیریت مزرعه
### دیتابیس
- **MySQL**
---
## 3. SensorHub Service
سرویس **SensorHub** مسئول دریافت، ذخیره و مدیریت داده‌های سنسورهای مزرعه است.
به دلیل حساسیت بالای این داده‌ها و اهمیت **عدم از دست رفتن اطلاعات سنسورها**، این سرویس به‌صورت مستقل از سایر بخش‌ها پیاده‌سازی شده است.
### ویژگی‌های این سرویس
- دریافت داده‌های سنسورها در زمان واقعی
- ذخیره‌سازی امن و پایدار داده‌ها
- ارائه داده‌ها به سرویس Backend برای تحلیل
### دیتابیس
برای این سرویس از **Apache Cassandra** استفاده شده است.
دلایل انتخاب Cassandra:
- دیتابیس **Distributed** و مناسب برای داده‌های حجیم
- **Fault Tolerance بالا**
- جلوگیری از از دست رفتن داده‌ها
- مناسب برای **Time-Series Data** مانند داده‌های سنسورها
---
## جمع‌بندی معماری
معماری CropLogic بر پایه **Microservice Architecture** طراحی شده است که مزایای زیر را فراهم می‌کند:
- مقیاس‌پذیری مستقل هر سرویس
- افزایش پایداری سیستم
- جداسازی مسئولیت‌ها
- مدیریت بهتر بار پردازشی
- امنیت بیشتر برای داده‌های حساس
این معماری باعث می‌شود پلتفرم بتواند در مقیاس‌های بزرگ مزرعه و تعداد زیاد سنسورها نیز عملکرد پایدار و قابل اعتمادی داشته باشد.
:::