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

ربات اعتبارسنجی UID کاربران با معماری افزونه‌محور

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

ربات تلگرام اعتبارسنجی UID با پشتیبانی از چند صرافی

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

  • ثبت و بررسی UID کاربران به‌صورت دستی انجام می‌شد و خطا در آن مستقیماً به از دست رفتن کاربر منجر می‌شد.
  • هر صرافی API و قواعد متفاوت خودش را داشت و اضافه کردن صرافی جدید یعنی دست بردن در دل ربات.
  • موجودی اسپات و فیوچرز و حجم معاملات کاربران باید در پس‌زمینه به‌روز می‌ماند، بدون اینکه ربات سنگین شود.
  • قطع دسترسی VIP بعد از پایان دوره ۳۰ روزه فراموش می‌شد و لینک‌های دعوت قدیمی همچنان قابل استفاده می‌ماندند.

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

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

به زبان ساده

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

قبل و بعد

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

قبل

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

بعد

صرافی جدید فقط یک پکیج است که در رجیستری ثبت می‌شود؛ هسته ربات دست‌نخورده باقی می‌ماند.

قبل

قطع دسترسی VIP در پایان دوره، کاری دستی و فراموش‌شدنی بود و لینک‌های دعوت قدیمی باز می‌ماندند.

بعد

چرخه انقضا لینک دعوت را صریحاً باطل و کاربر را خارج می‌کند، و وضعیت پاک‌سازی جلوی هر پردازش تکراری را می‌گیرد.

قبل

تغییر یک متن ساده در ربات نیازمند ویرایش کد و استقرار دوباره بود.

بعد

متن‌ها از پنل مدیریت ویرایش می‌شوند، بدون استقرار مجدد.

عدد و اندازه

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

۹٬۳۹۶خط کد پایتون
۴۰فایل پایتون
۲صرافی روی یک هسته
۳تلاش مجدد در فراخوانی
۶بخش جداگانه هر صرافی
۱قالب آماده برای توسعه

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

هستهکلاس پایه صرافی، رجیستری مرکزی و انواع قرارداد داده
افزونه‌هاهر صرافی با شش بخش: کلاینت، تنظیمات، هندلر، کیبورد، متن و کار پس‌زمینه
رباتمسیریابی یکپارچه با حفظ سازگاری کامل با دکمه‌های قدیمی
پس‌زمینهبه‌روزرسانی دوره‌ای داده‌ها و چرخه انقضای دسترسی VIP
مدیریتپنل Flask با توکن یکبارمصرف و ویرایش متن بدون استقرار مجدد

پشته فناوری

PythonAiogram 3FlaskSQLAlchemySQLiteParamikoDockerNginx

هسته، صرافی‌ها را نمی‌شناسد

ربات به‌جای اتصال مستقیم به هر صرافی، آن‌ها را از رجیستری می‌خواند. نتیجه: افزودن یک صرافی جدید تغییری در هسته ایجاد نمی‌کند و رفتار صرافی‌های موجود دست‌نخورده می‌ماند.

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

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

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