پرش به محتوای اصلی
مدیریت دانشبهسازان ملت
دانش فنی و تخصصیراهنمای تخصصیمنتشرشدهداخلی

معماری مرجع میکروسرویس‌ها در سامانه‌های پرداخت

مالک دانش
مهسا کریمی
تاریخ انتشار
۱۰ اسفند ۱۴۰۴
آخرین به‌روزرسانی
۱۵ مهر ۱۴۰۵
زمان مطالعه
۱۸ دقیقه
بازدید
۱٬۹۶۰
پیشنهاد اصلاح

خلاصه مدیریتی

الگوی مرجع تفکیک سرویس‌ها، ارتباط رویدادمحور، مدیریت تراکنش‌های توزیع‌شده با الگوی Saga و الزامات مشاهده‌پذیری برای سامانه‌های پرداخت پرتراکنش.

هدف و دامنه کاربرد

ارائه الگوی مشترک برای طراحی و تفکیک سرویس‌های پرداخت تا تیم‌ها تصمیمات معماری یکسان و قابل دفاع بگیرند.

دامنه کاربرد

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

پیش‌نیازها

  • مطالعه راهنمای استاندارد طراحی API
  • آشنایی با مفاهیم طراحی دامنه‌محور
  • آشنایی مقدماتی با Kafka

شرح دانش

اصول تفکیک سرویس‌ها

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

  • یک سرویس، یک تیم مالک و یک پایگاه داده
  • ارتباط هم‌زمان فقط برای استعلام‌های کوتاه
  • ارتباط رویدادمحور برای اعلام تغییر وضعیت

تراکنش‌های توزیع‌شده با الگوی Saga

در انتقال وجه که چند سرویس درگیرند، از الگوی Saga با هماهنگ‌کننده مرکزی استفاده می‌شود. هر گام یک عملیات جبرانی دارد که در صورت شکست گام‌های بعدی اجرا می‌شود و وضعیت نهایی همیشه قابل ردیابی است.

مراحل اجرا

  1. ۱

    شناسایی قابلیت‌های دامنه

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

  2. ۲

    تعیین قراردادها

    قرارداد API و شمای رویدادهای هر سرویس را پیش از توسعه ثبت کنید.

  3. ۳

    طراحی Saga و عملیات جبرانی

    برای هر فرایند چندسرویسی، گام‌ها، عملیات جبرانی و وضعیت‌های میانی را مستند کنید.

  4. ۴

    افزودن مشاهده‌پذیری

    ردیابی توزیع‌شده، شاخص‌های کلیدی و لاگ ساختاریافته را از نخستین نسخه فعال کنید.

تصاویر و نمودارها

جریان انتقال وجه در معماری رویدادمحور
  1. ۱سرویس انتقالآغاز Saga
  2. ۲Kafkaگذرگاه رویداد
  3. ۳سرویس حساببرداشت و واریز
  4. ۴سرویس تسویهثبت نهایی
شکل ۱: هماهنگ‌کننده Saga گام‌های انتقال وجه را از طریق رویدادهای Kafka پیش می‌برد.

نکات تخصصی

پیش از شکستن یک سامانه یکپارچه، شاخص‌های کارایی فعلی را ثبت کنید تا اثر معماری جدید قابل سنجش باشد.

رویدادها را با شمای نسخه‌دار و رجیستری شِما منتشر کنید تا مصرف‌کنندگان با تغییرات غافلگیر نشوند.

خطاهای رایج و راهکارها

راهکار:اگر دو سرویس همیشه با هم تغییر می‌کنند، احتمالاً باید یک سرویس باشند.

مستندات و منابع مرتبط

  • نمودار مرجع معماری پرداخت

    PDF · ۱٫۸ مگابایت

    پیوست
  • راهنمای استاندارد طراحی API در سامانه‌های بانکی

    صفحه دانش

    مشاهده

آیا این محتوا مفید بود؟

۱۳۳ همکار این دانش را مفید دانسته‌اند.

پیشنهاد اصلاح محتوا

اطلاعاتی نادرست، قدیمی یا ناقص دیدید؟ به مالک دانش اطلاع دهید.

نظرات و بازخورد همکاران۲

    • رضا احمدیمدیر فنی پروژه بانکداری شرکتی· ۱۲ آبان ۱۴۰۵

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

    • مهسا کریمیکارشناس ارشد معماری نرم‌افزار· ۱۲ آبان ۱۴۰۵

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