پرش به محتوای اصلی
لوگوی نوین وبنوین وبWEBNOVO
همه‌ی نمونه‌کارها
بک‌اند و تحلیلزیرساخت آماده بهره‌برداری

پلتفرم تحلیل رفرال صرافی با بک‌اند FastAPI و کش Redis

خواندن امن داده‌های صرافی، نرمال‌سازی و کش‌گذاری آن‌ها، و نمایش در داشبوردی که برای سه نوع کاربر متفاوت — انسان، ربات و API — طراحی شده است.

داشبورد تحلیل رفرال صرافی با نمودار رشد و کارت‌های شاخص

مسئله — چه چیزی درست کار نمی‌کرد؟

  • خواندن مستقیم داده از API صرافی برای هر بار باز شدن داشبورد، کند بود و با محدودیت نرخ درخواست برخورد می‌کرد.
  • امضای دیجیتال درخواست‌ها برای هر دو روش HMAC و RSA باید پشتیبانی می‌شد، و مدیریت کلید خصوصی نقطه حساسی بود.
  • سه نوع مصرف‌کننده متفاوت — کاربر انسانی، ربات تلگرام و سرویس خارجی — باید با سطوح دسترسی متفاوت به یک داده دسترسی می‌داشتند.
  • استقرار و بازتولید محیط روی سرور جدید نباید به دانش ضمنی وابسته می‌بود.

راه‌حل — چه ساختیم؟

  • بک‌اند ماژولار FastAPI با تفکیک لایه‌ها: تنظیمات، امنیت، رمزنگاری، پایگاه داده، سرویس‌ها و ماژول‌های کسب‌وکاری.
  • امضای دیجیتال درخواست‌ها با HMAC-SHA256 و پشتیبانی کامل از امضای RSA شامل بازسازی قالب‌های مختلف کلید خصوصی.
  • تلاش مجدد هوشمند برای خطای شبکه و محدودیت نرخ، نرمال‌سازی داده‌های خام و ذخیره‌سازی آن‌ها.
  • کش Redis روی اندپوینت‌های پرمصرف، با قابلیت ابطال گروهی کلیدها بر اساس پیشوند پس از هر همگام‌سازی.
  • احراز هویت دوگانه: توکن JWT برای کاربران انسانی با دو نقش مدیر و بیننده، و کلید API اختصاصی برای ربات.
  • ربات تلگرام فقط از مسیر API و با کلید مخصوص خودش داده می‌گیرد و هیچ دسترسی مستقیمی به پایگاه داده ندارد.
  • فرانت‌اند Next.js با معماری App Router و TypeScript، همراه با Ant Design و Recharts برای نمودار رشد، کارت‌های شاخص، جدول کدهای رفرال و تابلوی تیم.
  • استقرار کامل با Docker Compose شامل PostgreSQL، Redis، بک‌اند، داشبورد و ربات.

به زبان ساده

خواندن مستقیم اطلاعات از صرافی مثل این است که هر بار برای دیدن قیمت، به انبار مرکزی زنگ بزنید: هم کند است، هم اگر زیاد زنگ بزنید خط را قطع می‌کنند. این سامانه یک انبار کوچک و دم‌دستی می‌سازد؛ اطلاعات را یک‌بار می‌گیرد، مرتب می‌کند و نگه می‌دارد، و داشبورد از همان انبار سریع جواب می‌گیرد. دسترسی هم مثل کارت پرسنلی تفکیک شده است: کارمند، ربات و سرویس بیرونی هرکدام کارت مخصوص خودشان را دارند و فقط به همان چیزی می‌رسند که لازم دارند. ربات هیچ‌وقت مستقیم سراغ انبار اصلی نمی‌رود. نتیجه برای شما: داشبورد سریع باز می‌شود، به قطعی لحظه‌ای صرافی وابسته نیست و همیشه مشخص است چه کسی چه چیزی را دیده است.

قبل و بعد

همان فرآیند، در دو وضعیت: پیش از پیاده‌سازی و پس از آن.

قبل

هر بار باز شدن داشبورد یعنی چند درخواست مستقیم به صرافی و ریسک برخورد با محدودیت نرخ.

بعد

داده‌ها نرمال‌سازی و کش می‌شوند؛ پاسخ‌دهی اندپوینت‌های پرمصرف از کش انجام می‌شود و به وضعیت لحظه‌ای صرافی وابسته نیست.

قبل

هر ابزار با کلید و سطح دسترسی خودش، بدون مرز مشخص.

بعد

یک درگاه یکپارچه با توکن برای انسان، کلید برای ربات و اعمال کنترل دسترسی نقش‌محور در لایه API.

قبل

راه‌اندازی مجدد روی سرور جدید نیازمند دانش ضمنی و مراحل دستی بود.

بعد

یک فایل Docker Compose کل مجموعه را بالا می‌آورد: پایگاه داده، کش، بک‌اند، داشبورد و ربات.

عدد و اندازه

این اعداد از روی کد همین پروژه شمرده شده‌اند، نه تخمین زده.

۳٬۴۴۳خط کد پایتون
۵سرویس در Docker Compose
۲روش امضای درخواست
۳نوع مصرف‌کننده
۱۶نسخه PostgreSQL
۰دسترسی مستقیم ربات به دیتابیس

لایه‌های معماری

بک‌اندFastAPI ماژولار با تفکیک core، db، api، services و modules
امنیتJWT برای انسان، کلید API برای ربات، کنترل دسترسی در لایه وابستگی‌ها
صرافیدرخواست‌های امضاشده، تلاش مجدد و نرمال‌سازی داده
کشRedis برای اندپوینت‌های پرمصرف با ابطال گروهی
رابطNext.js با Ant Design و Recharts

پشته فناوری

PythonFastAPISQLAlchemyPostgreSQL 16Redis 7AlembicJWTNext.js 14TypeScriptAnt DesignRechartsDocker Compose

مرز امنیتی شفاف بین انسان و ربات

ربات هیچ دسترسی مستقیمی به پایگاه داده ندارد. هرچه می‌خواهد از همان درگاه API می‌گذرد، با کلید مخصوص خودش و نقش مشخص — همان مسیری که برای کاربر انسانی هم اعمال می‌شود.

پروژه مشابهی دارید؟

در یک جلسه ۱۵ دقیقه‌ای رایگان بررسی می‌کنیم این الگو برای فرآیند شما هم جواب می‌دهد یا نه.

رزرو مشاوره رایگان