"> توسعه میکروسرویس ها با NET Core 2.1. و RabbitMQ - بخش اول | ام اس پی سافت

توسعه میکروسرویس ها با NET Core 2.1. و RabbitMQ – بخش اول

توسعه میکروسرویس

در این مقاله میخواهیم راجب توسعه میکروسرویس ها با NET Core 2.1, RabbitMQ, SignalR, EF Core 2.1 and Angular 6. صحبت کنیم. تا پایان این مقاله همراه ما باشید.

مونولیت: عارضه ای زمین شناختی است که از یک توده ی منفرد سنگ یا صخره ای تشکیل شده است که مانند برخی کوه ها یا تکه های منفرد صخره ای که به شکل یک یاد بود یا ساختمان شکل گرفته است. فرسایش اغلب اوقات باعث رخنمون سازند های زمین شناسی مقاوم میگردد که سبب تشکیل تک سنگ میشود.

همانطور که اکثر طرفداران داستان های علمی تخیلی می دانند؛ اصطلاح مونولیت در سال ۱۹۶۸ از طریق فیلم ساخته استنلی کوبریک (۲۰۰۱) به نام: یک ادیسه فضایی به نمایش گذاشته شده است.

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

اما چرا این منولیت سیاه در این فیلم نمایش داده شد.

در لحظه ای والا، به نظر میرسد که مونولیت سیاه ابتدا از انسان های گذشته الهام گرفته شده است تا فناوری را کشف کرده و به کمک آن به ستاره ها نگاه کنند.

وقتی میمون ها در ابتدا مونولیت سیاه را می بینند ، لحظه ای کاملاً انسانی و والا را تجربه می کنند.

احساس همزمان حسرت ، تعجب و وحشت هنگام نگاه کردن به چیزی با شکوه و مرموز که به نظر می رسد عقل و ادراکات حسی آنها را تحت الشعاع قرار می دهد.

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

نرم افزار مونولیت

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

معمولا یک اپلیکیشن یکپارچه شامل سه بخش می‌شود:

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

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

برنامه های onolithic یک روش طبیعی برای تکامل یک برنامه هستند.

بیشتر برنامه ها با یک هدف واحد شروع می شوند. با گذشت زمان ، ویژگی هایی برای پشتیبانی از نیازهای تجاری به برنامه اضافه می شود.

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

نمونه های خوبی از سیستم های مونولیت را می توان در دولت فدرال، موسسات بزرگ بیمه و همینطور در بانک ها یافت.

بسیاری از این مؤسسات متکی به سیستم های ناکارآمد ، پرهزینه ، شکننده و قدیمی هستند که بیش از ۷۵ درصد از کل بودجه IT به آن ها اختصاص داده شده است.

برخی آژانس ها با اندکی موفقیت و یا ناکامی سعی در مدرن سازی این سیستم های عظیم دارند.

البته در اینجا متوقف نمی شود. از طریق گسترش اینترنت ، برنامه های کاربردی به طور فزاینده ای برای شبکه جهانی وب نوشته شده اند.

متأسفانه ، فن آوری های مورد استفاده برای توسعه برنامه های وب در طی سال ها ، اصول مهندسی نرم افزار شناخته شده را در سیستم های قدیمی که از گذشته باقی مانده است را نقض کرده اند.

اکنون ما برنامه های وب بزرگی داریم که حاوی کوه هایی با spaghetti code هستند که در طی پانزده سال گذشته توسعه یافته اند. نوسازی این سیستم ها چالشی برانگیز خواهد بود .

معماری میکروسرویس

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

به عبارت دیگر، میکروسرویس یک معماری توسعه نرم‌افزار به اصطلاح Distributed است.

هر میکروسرویس یک برنامه کوچک است که معماری خاص خود را دارد که می تواند بدون اینکه روی سایر قسمت های برنامه تأثیر بگذارد ، بصورت جداگانه توسعه داده ، آزمایش و مستقر شود.

طراحی و برنامه ریزی میکروسرویس

یک معماری میکروسرویس (MSA) اغلب فرآیندی است که برای دستیابی به یک هدف با استفاده از پروتکل های آگونیستیک می باشد که از طریق شبکه HTTP ارتباط برقرار می کند.

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

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

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

Sample Application

توسعه میکروسرویس

ساده ترین کاربرد این مقاله یک برنامه کوچک ERP است که از چندین میکروسرویس بک اند و سرویس های متعدد بک اند صف پیام که یک کاربرد فرانت اند Angular 6 ارایه میدهند.
میکروسرویس های زیر کاربرد نمونه را تشکیل میدهند

  •  مدیریت حساب Web API Microservice
  •  مدیریت موجودی Web API Microservice
  •  مدیریت فروش سفارش Web API Microservice
  • مدیریت خریداری سفارش Web API Microservice

علاوه بر این ، خدمات ارسال پیام زیر نیز در برنامه نمونه گنجانده شده است:

  •  تنظیم مدیریت پیام موجودی سرویس
  •  مدیریت سفارش فروش
  •  مدیریت دستور خرید سرویس با تنظسم ارسال پیام
  •  مدیریت ورود به سیستم سرویس با تنظیم ارسال پیام

میکروسرویس های برنامه نمونه

جدا کردن یک سری قابلیت ها از مونولیت کار سختی است.

تصمیم گیری در مورد قابلیت جابجایی در یک میکروسرویس یکی از چالش های معماری در مورد تجزیه یک برنامه مونولیت در ecosystem of microservices است.

یکی از متداول ترین سؤالات مربوط به اجرای معماری میکروسرویس در مورد اندازه و granularity است: در صورت کوچک بودن میکروسرویس ها ، باید یک قطعه نرم افزار به چندین میکروسرویس تقسیم شود یا به صورت تک ساخته شود.

در طراحی میکروسرویس برای مدیریت فروش سفارش ، عملکرد هر دو، یعنی حفظ مشتری وارد شده به سیستم و همینطور وارد شده به فروش، ادغام شده است.

به نظر می رسد این دو، عملکردی به هم مرتبط دارند. می توان ادعا کرد که حفظ مشتری باید از ورود سفارشات فروش جداگانه باشد.
یافتن مرزهای دامنه در یک legacy monolith هم یک هنر و هم یک علم است.

در یک طرح بزرگ، شما باید از هر معماری با یک grain of salt استفاده کنید و طرحی را ایجاد کنید که برای شما کاربردی باشد.

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

میکروسرویس های ارتباطات بین فرآینده

تا زمانی که یک مونولیت ساخته اید ، نیازی به تفکر بیش از اندازه در مورد ارتباط ماژول هایتان با یکدیگر ندارید.

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

چندین راهکار وجود دارد، برنامه مبتنی بر میکروسرویس یک سیستم توزیع شده است که بر روی چندین فرآیند یا خدمت اجرا می شود ، معمولاً حتی در چندین سرور هم اجرا میشود هر نمونه سرویس معمولاً یک فرآیند است. بنابراین ، خدمات باید بسته به ماهیت هر سرویس ، با استفاده از یک پروتکل ارتباطی بین فرآیندی مانند HTTP ، AMQP یا یک پروتکل باینری مانند TCP ، ارتباط برقرار کنند.

پیام دهی بین سرویس های ارائه شده با تنظیم پیام

اکثر مردم فکر می کنند که میکروسرویس ها ساختار مبتنی بر همان اصل REST با یک سرویس وب JSON است.

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

به عنوان مثال ، اگر سرویس فراخوان خراب شده و قادر به پاسخگویی نباشد چه؟

سرویس کلاینت شما مجبور است نوعی اتصال مجدد را پیاده سازی کند یا به دلایل منطقی شکست بخورد ، در غیر این صورت ، شما خطر از دست دادن درخواست ها و بخش هایی از اطلاعات را دارید.

یک cloud architecture باید انعطاف پذیر باشد و با کمال آرامش بعد شکست ها بازیابی کند.

یک جایگزین و مکمل درخواست های HTTP برای صف های پیام وجود دارد.

استفاده از صف ارسال پیام در واقع یک راه حل نسبتاً قدیمی (مانند فناوری پیام رسانی پیام مایکروسافت (MSMQ)) هنگام مواجه با چندین سرویس ارتباطی مورد استفاده قرار می گردد.

صف ارسال روشی است که با استفاده از آن یک فرآیند می تواند داده ها را با استفاده از یک رابط به صف مدیریت پیام ها انتقال دهد.

یک صف پیغام را می توان با یک فرآیند ایجاد کرد و توسط چندین پردازش که پیام را از صف می خوانند و یا می نویسند استفاده می شود.

تنظیم پیام شامل بسیاری از مؤلفه ها زیر از قبیل:

  •  پیام: بسته ای برای اطلاعات ، که معمولاً از دو بخش تشکیل شده است. headers ، حاوی متادیتا و بدنه ای که یک بسته باینری دارد که حاوی پیام واقعی است.
  •  تهیه کننده: هر کسی که پیامی را ایجاد و ارسال می کند
  •  مصرف کننده: هر کسی که پیامی را دریافت و می خواند
  •  صف: یک کانال ارتباطی است که برای بازیابی های بعدی توسط یک یا چند مصرف کننده پیام هایی را بررسی می کند.
  •  Exchange : یک جمع کننده صف است که بر اساس برخی منطق های از پیش تعریف شده ، پیام ها را به صف می بندد.

با استفاده از صف های پیام ، می توانید پیامها را بین هر یک از اجزای برنامه ارسال کنید ، ذخیره کنید و دریافت کنید ، بدون اینکه پیام ها را از دست بدهید و یا نیاز به سرویس های دیگر همیشه در دسترس داشته باشید.

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

با گسترش cloud technology چندین تصمیم گیری در مورد طراحی و معماری وجود دارد.

به عنوان مثال ، مایکروسافت Azure Service Bus خود را برای پیام رسانی cloudبسیار مطمئن بین برنامه ها و خدمات ارائه می دهد.

علاوه بر این ، اخیراً آمازون سرویس جدیدی به نام Amazon MQ ، یک سرویس کارگزار پیام مدیریت شده برای Apache ActiveMQ راه‌اندازی کرد.

یک کارگزار پیام رسان منبع باز ، سازگار با اکثر پروتکل های استاندارد صنعتی است.

آمازون ActiveMQ را انتخاب کرد زیرا از اکثر پروتکل های استاندارد صنعت را پشتیبانی می کند.

پیام ها و اهداف تصمیم گیری معماری

پس از تحقیقات زیاد ، برای طراحی نمونه از طرح میکروسرویس زیر استفاده میشود:

  •  برنامه جلویی فرانت-وب، یک برنامه Angular 6 را با هر module lazy به عنوان modulesزاویه دار جداگانه بارگذاری می کند. هنگام تصمیم گیری برای توسعه مقابل خود؛ یک رویکرد فرانت جداگانه برای هر سرویس دارد.
  •  هر میکروسرویس دارای پایگاه داده اختصاصی SQL Server است که خود همراه با یک متن، پایگاه داده و هسته اصلی Entity Framework Core خواهد بود.
  •  هر میکرو سرویس به خودی خود محدود می شود و از مرزها عبور نمی کند و یا تماس های راه دور را به سایر خدمات میکروسرویسی انجام نمی دهد.
  •  هر پایگاه داده میکروسرویس، کپی جداگانه ای از جداول بانک اطلاعاتی را که در آن به داده های مشترک در میکروسرویس نیاز است ، حفظ می کند.
  • هر تراکنش میکروسرویس الگوی طراحی واحد کار را با بانک اطلاعاتی ACID (اتمی ، جداسازی قوام ، دوام) پشتیبانی می کند و هر معامله پشتیبان را در محدوده یک پایگاه داده، دنبال می کند.
  •  هر میکروسرویس معامله ورودی و خروجی را در داخل هر تراکنش ثبت می کند و در هر پایگاه داده message queue را ارسال و در جداول تراکنش های ورودی و خروجی ذخیره میکند.
  •  هر میکروسرویس یک روند بک گراند جداگانه برای ارسال ، دریافت و پردازش پیام های در صف دارد.
  • هر پیام صف ارسال پیام‘queue massage” ، یک شناسه تراکنش منحصر به فرد خواهد داشت تا بتواند هر پیام را بطور منحصر به فرد شناسایی و از پردازش همان پیام بیش از یک بار جلوگیری کند.
  •  هر تراکنش به ترتیب پیاپی ایجاد (شناسه تراکنش) پردازش می کند تا به حفظ یکپارچگی داده ها کمک کند .بسته به ماهیت معاملات برنامه شما ، ممکن است این یک الزام نباشد.
  • هر سرویس صف ارسال پیام در یک برنامه کنسول چند رشته ای جداگانه اجرا می شود و به طور مستقیم با RabbitMQ تعامل خواهد داشت.
  • RabbitMQ : با اجزای API Web کاملاً همراه خواهد بود و در هر فرآیند API وب پیاده سازی نخواهد شد.
  •  سرویس صف ارسال پیام، پیام و بانک اطلاعاتی ورود به سیستم را اجرا میکنند. کلیه پیامهای صف ارسال شده و دریافت شده از طریق RabbitMQ در یک پایگاه داده ورود به سیستم مرکزی برای ورود به سیستم ، نظارت، تأیید و ذخیره می شوند.
  •  از خدمات درج پیام ورود به سیستم این است که ، پیام های تأیید ورود به صفحات میکروسرویس بازگردانده می شوند تا نشان داده شود که که پیام ها با موفقیت پردازش شدند.
  •  هر میکروسرویس پیام های تصدیق پس از دریافت را پردازش می کند. هر دو پیام ورودی و خروجی در جداول تاریخ صف پیام، در هر پایگاه داده اختصاصی میکرو بایگانی می شوند.
  • صف های پیام پایدار خواهند بود. در هنگام راه اندازی مجدد کارگزار پیام ، پیام ها از بین نمی روند.
  •  SignalR : برای پردازش پیام در زمان واقعی بین سرویس صف برگشت پیام و برنامه API وب استفاده خواهد شد.

اکنون که همه اینها را خواهیم داشت می توانیم برخی از کد های نمونه برنامه ERP را بررسی کنیم.

مدیریت حساب ورود به برنامه API وب

هر میکرو سرویس برای برنامه نمونه با استفاده از نشانه وب JSON امن و محافظت می شود.

یک نشانه وب JSON JWTیک استاندارد باز (RFC 7419) است که روشی جمع و جور و خودکار را برای انتقال ایمن اطلاعات بین طرفین به عنوان یکObject JSON تعریف می کند.

این اطلاعات قابل تأیید و اعتماد است زیرا به صورت دیجیتالی امضا شده است.

JWT را می توان با استفاده از (الگوریتم HMAC) یا با یک جفت کلید عمومی یا خصوصی با استفاده از RSA یا ECDSA امضا کرد.

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

یعنی یک برنامه ممکن است روی سیستم عامل linux باشد اما شما که یک سرور ویندوزی دارید، می‌توانید از API آن به سادگی استفاده کنید.

SOAP و REST دو گروه معروف از API های تحت وب هستند که دومی ساده ‌تر و استفاده از آن آسان‌تر است.

JSON Web Token یا به اختصار JWT استانداردی که می‌تواند به منزله روشی برای ردوبدل کردن دیتا مابین دو سیستم در قالب جیسونی که دارای یک به اصطلاح Digital Sign (امضای دیجیتال) است مورد استفاده قرار گیرد.

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

با ورود نشانه وب JSON در قسمت هدرهای درخواست مشتری HTTP ساخته شده و به هر نقطه انتهایی Web API از برنامه نمونه درج خواهد شد.


 

  • پسورد: www.mspsoft.com
زهره سلطانیان

نوشته‌های مرتبط

دیدگاه‌ها

*
*

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

کدیشن ! مارکت پروژه های برنامه نویسی راه اندازی شدیه توکه پا بریم ببینم