بررسی معماری میکروسرویس در صنعت بانکداری(بانکداری دیجیتال)

مقدمه:

از آن‌جایی که سازمان‌های بیشتری رایانش ابری را در قالب استراتژی تحول دیجیتال خود قرار می‌دهند. مهم است که معماری‌ها و روش‌های توسعه مناسب را برای بهره‌گیری از مزایای کامل ابر اتخاذ کنند. رقابت امروز در بازار بانکداری دیجیتال به همان اندازه شدید است که قبلا هرگز نبوده‌است.

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

نحوه کمک معماری میکروسرویس در موضوعی چون customer-first بودن و ارائه خدمات customaize شده است كه اين خود مستلزم ارتقاي مداوم فناوري‌ها و عملكرد محصول است. اينكه معماری ميكروسرويس به بانكداری ديجيتال كمك مي‌كند كه مدام عملكرد بهبود يافته، نوآوری ايجاد شود و ويژگی‌های سريع و جديد و كارآمد پياده‌سازی شود.

ايده استفاده از معماری ميكروسرويس از تقسيم برنامه‌ها به چندين خدمت به جهت افزايش كيفيت و سرعت تحويل بوده و به همين دليل امكان نوآوری و توسعه مداوم برنامه‌های نرم‌افزاری پيچيده در مقياس بزرگ را فراهم می‌كند. از لحاظ عملی نيز ، معمار ی به تيم توسعه اجازه می‌دهد تا پروژه‌های توسعه و آزمايش بسياری را به طور همزمان انجام دهد تا تمام اجزای برنامه را به صورت يكپارچه فعال كند.

در نهايت امروزه مشتريان بر اساس تجربه خود تصميمات بانكی خود را در مورد بانكی كه می‌توانند به آن اعتماد

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

و بهبود خدمات خود را تسريع بخشند .

میکروسرویس ها در مقابل SOA

در SOA، سرویس‌ها نیازی ندارند که با داده‌ها و رابط کاربری همراه باشند. پایگاه داده SOA هیچ تمرکزی بر واحدهای استقرار مستقل و پیامدهای مرتبط ندارد، و این مورد به سادگی رویکردی برای ارتباط بین کسب و کار است. ایده SOA فعال کردن برنامه‌نویسی در سطح کسب‌وکار از طریق موتورهای پردازش تجاری و زبان‌هایی مانند WS-BPEL و BPMN بود که بر پایه ادبیات گسترده مدل‌سازی کسب‌وکار ساخته شده‌اند. علاوه بر این، تأکید همه بر ترکیب خدمات بیشتر نسبت به توسعه و استقرار خدمات بود.

اصول معماری میکروسرویس:

هر معماری میکروسرویس مبتنی بر سه اصل اساسی است که در ادامه به توضیح آن پرداخته خواهد شد:

1. اصل Bounded Context: یکی از ویژگی‌های میکروسرویس ، تمرکز بر روی قابلیت‌های تجاری است. عملکردهای مرتبط در یک واحد ترکیب می‌شوند و بعدا بعنوان یک سرویس پیاده می‌شود.
2. اصل Independency: هر سرویس در میکروسرویس، مستقل از سایرین از نظر عملیاتی است و دارای اتصال سست در عین انسجام بالاست.
3. سایز Size: اندازه یک مفهوم حیاتی برای میکروسرویس ها است و مزایای عمده ای را از نظر قابلیت نگهداری و گسترش سرویس به ارمغان می آورد. استفاده اصطلاحی از معماری میکروسرویس‌ها نشان می‌دهد که اگر یک سرویس بیش از حد بزرگ است، باید به دو یا چند سرویس تبدیل شود، بنابراین جزئیات حفظ می‌شود و تمرکز بر ارائه تنها یک قابلیت تجاری واحد حفظ می‌شود.

دلایل استفاده از معماری میکروسرویس در بانکداری:

• کار کردن ساده با میکروسرویس
• عدم دور ریختن زیرساخت‌های موجود
• مدیریت تغییرات و کاهش زمان خرابی و هزینه
• مدیریت جنبه‌های امنیتی بانکداری در اولویت
• تقسیم برنامه به خدمات مستقل در شرکت‌ها

هدف هر دو معماری SOA و MSA (میکروسرویس) تبدیل معماری‌های قدیمی غیرقابل انعطاف به معماری‌های مبتنی بر خدمات است که برای توسعه راه‌حل‌های دیجیتال نوآورانه انعطاف‌پذیر و چابک‌تر است.

در سازمان‌های پیچیده مثل بانک‌های سنتی، بلوغ SOA کلید غلبه بر سیستم‌های قدیمی بعنوان بازدارنده تحول بانکداری دیجیتال است. در حالی که SOA یک عامل کلیدی برای چابکی راه‌حل‌های داخلی در حضور سیستم‌های قدیمی یکپارچه است. این معماری به خوبی در فضای ابر که پیاده‌سازی‌های یکپارچه غیرعملی است، صورت نمی‌گیرد. بنابراین MSA اکنون یک عامل کلیدی برای چابکی‌ راه‌حل‌های مبتنی بر ابر است. با شرط اینکه میکروسرویس‌ها در سطح مناسب کپسوله‌سازی یا Bounded Context طراحی شده باشد.

معماری لایه‌ای میکروسرویس:

1- یک میکروسرویس اتمی، یک سرویس ریز دانه است که عملکرد و داده های یک واحد تجاری واحد مانند محصول را در بر می گیرد. بعنوان مثال، سرویس محصول مالک داده‌های محصول است، یعنی؛ اگر هر سرویس دیگری به داده های محصول نیاز دارد، باید از طریق رابط سرویس محصول به آن دسترسی داشته باشد. سرویس محصول عملکردها یا عملیات‌هایی را از طریق رابط کاربری خود نشان می‌دهد، مانند: داده‌های محصول را دریافت کنید، داده‌های محصول جدید را ارسال کنید (ایجاد کنید)، داده‌های محصول موجود را قرار دهید (به‌روزرسانی کنید)، و داده‌های محصول را حذف کنید. میکروسرویس‌های اتمی کوچک‌ترین ماژول‌های نرم‌افزاری قابل استفاده مجدد را نشان می‌دهند که نمی‌توان آن‌ها را به‌طور مفید بیشتر تقسیم یا تجزیه کرد.

2- یک میکروسرویس ترکیبی ، یک سرویس دوره ای است که عملکرد یک فعالیت تجاری واحد، مانند انتقال سرمایه را در بر می گیرد. در این مثال، سرویس انتقال وجه یک فرآیند end-to-end را با فراخوانی عملیات چندین میکروسرویس اتمی در یک توالی که فعالیت تجاری را انجام می‌دهد، هماهنگ می‌کند. میکروسرویس‌های مرکب همچنین می‌توانند مدیریت تراکنش (به عنوان مثال commit یا rollback) را در سراسر ارکستراسیون انجام دهند.

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

ارتباط بین میکروسرویس‌ها مبتنی بر رویداد است که در این صورت منطق فرایند end-to-end بین میکروسرویس‌ها توزیع می‌شود.

فازهای مهاجرت از معماری مونولیتک به میکروسرویس:

با استخراج از مقالات ، یک رویکرد مرحله‌ای برای مهاجرت از یک معماری یکپارچه به یک معماری میکروسرویس مبتنی بر ابر ارائه می‌شود. مراحل مهاجرت ارائه شده در اینجا بر اساس یک مهاجرت سیستم بانکی اصلی است که در یک محیط آکادمیک تحت پروژه ای به نام SMU tBank انجام شده است، که به موجب آن یک سیستم بانکداری خرده‌فروشی Oracle Flexcube به طور مستقیم با بیش از 200 میکروسرویس جایگزین شد.

مراحل مهاجرت شامل موارد زیر است:

1- جداسازی یکپارچه: یک رویکرد متداول برای جدا کردن لایه presentation جلویی از لایه منطق کسب و کار انتهای بانک، معرفی یک لایه نما (Facade) بین رابط کاربر و یکپارچه است، تا برای انتقال نهایی به دور از معماری مونولیتیک آماده شود.

2- توسعه میکروسرویس های محلی: مونولیتیک را به میکروسرویسهای جداگانه تجزیه کنید. این امر ممکن است شامل مهندسی معکوس مونولیتیک به منظور شناسایی ریزسرویس‌های کاندید باشد، همانطور که در شکل بالا نشان داده شده است. شناسایی خدمات هم خسته‌کننده‌ترین مرحله و هم حیاتی‌ترین مرحله در کل فرآیند مهاجرت است. درک سطح بهینه انسجام و اتصال سست برای هر میکروسرویس مهم است.

3- اجرای میکروسرویس های محلی : هنگامی که میکروسرویس ها توسعه یافتند، واحد موردنظر، مورد آزمایش قرار گرفته و به صورت محلی به عنوان مثال در محل مستقر می‌شود.

4- استقرار Microservices در Cloud

5- اجرای Microservices در Cloud

6- منحل کردن مونولیتیک: مزایای بعد از مهاجرت نیز شامل بهبود میانگین زمان پاسخ از 200 میلی ثانیه به 40 میلی ثانیه در مثال فوق بوده ، همچنین برای قابلیت چابکی و استفاده مجدد و همکاری جهت استفاده از میکروسرویس‌های روی ابر در جاهای دیگر است.
چالش های استفاده از میکروسرویس ها:

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

میکروسرویس‌های وابسته به هم بر روی سیستم‌های میزبان مختلف در سراسر شبکه WAN، وجود داشته باشد بنابراین همین امر باعث افزایش ترافیک شبکه خواهد شد.

تکنولوژی‌های مکانیسم e-banking در معماری میکروسرویس:

این تکنولوژی‌های پرکاربرد بیشتر شامل داکر، loggly و API metrics می‌باشد. همچنین ابزارهایی نظیر کوبرنتیکس نیز در معماری میکروسرویس بسیار پرکاربرد است.

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

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

مونزو ( بانکی است که هدف آن افرادی است که زمان زیادی را با تلفن های هوشمند خود می گذرانند و برای کسانی که دوست دارند کارها را با یک کلیک انجام دهند و نیازی به شعبه ها و دسته چک نمی بینند.) اکنون یک معماری فناوری اطلاعات کاملاً توزیع شده در فضای ابری دارد و بر اساس اصول مرکز دادهActive اجرا می‌شود تا از هرگونه خرابی یا خرابی برنامه حیاتی خود جلوگیری کند. برای مطابقت با الزامات قانونی، به امنیت AWS، رمزگذاری و ویژگی‌های قابل ممیزی متکی است.

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

در قلب کسب و کار Monzo، معماری فناوری زیربنایی آن است که باز، آگنوستیک، مقیاس پذیر، ایمن و دارای پلتفرم سوم است. به عنوان محصول جانبی زیرساخت فناوری اطلاعات آماده دیجیتال، برای Monzo آسان بود که فرآیندهای جدیدتری مانند DevOps را برای پیشبرد مزیت رقابتی خود اتخاذ کند.

نتیجه‌گیری:

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

برنامه های کاربردی یکپارچه قدیمی ممکن است از نظر عملیاتی به صورت روزانه قابل قبول باشند، اما این برنامه ها برای ساخت خدمات دیجیتال مناسب نیستند. معماری سنتی یکپارچه و روش‌های توسعه نرم‌افزار همچنان یک مانع برای ایجاد تحول دیجیتال است. به منظور هدایت موثر تحول دیجیتال، سازمان‌ها در حال بررسی یک روش و معماری جدید توسعه نرم‌افزار هستند، «معماری میکروسرویس‌های مبتنی بر ابر»، که به موجب آن راه‌حل‌های فناوری اطلاعات را می‌توان حول قابلیت‌های کسب‌وکار دانه‌ای سازمان‌دهی کرد که می‌تواند به سرعت برای ایجاد تجربه دیجیتالی جدید مبتنی بر ابر جمع‌آوری شود. برنامه های کاربردی. معماری «microservices» سبک و روشی برای توسعه برنامه‌های نرم‌افزاری سریع‌تر با ساخت آن‌ها به‌عنوان مجموعه‌ای از خدمات مستقل، کوچک و ماژولار است.

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

منابع:

•Poniszewska-Marańda, A., Vesely, P., Urikova, O., & Ivanochko, I. (2019, September). Building Microservices Architecture for Smart Banking. In International Conference on Intelligent Networking and Collaborative Systems (pp. 534-543). Springer, Cham

•Megargel, A., MADJELISI, A., & SHANKARARAMAN, V. (2020). Digital banking accelerator: A Service-Oriented Architecture starter kit for banks. IEEE Software.

• Megargel, A., Shankararaman, V., & Walker, D. K. (2020). Migrating from monoliths to cloud-based microservices: A banking industry example. In Software Engineering in the Era of Cloud Computing (pp. 85-108). Springer, Cham.

• Mazzara, M., Bucchiarone, A., Dragoni, N., & Rivera, V. (2020). Size matters: Microservices research and applications. In Microservices (pp. 29-42). Springer, Cham.

• https://www.qulix.com/about/microservice-architecture-in-digital-banking/

• https://d0.awsstatic.com/analyst-reports/EMEA41642116%20Web.pdf

https://d0.awsstatic.com/analyst-reports/EMEA41642116%20Web.pdf

• https://bian.org/wp-content/uploads/2020/07/Coreless-Bank-July-14th-2020.pdf

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.