NET Microservices: : مقیاس بندی با Pub/Sub

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

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

NCache یک ذخیره‌سازی داده‌های توزیع‌شده در حافظه برای دات‌نت است و pub/sub با ویژگی‌های غنی و درون حافظه را برای ارتباطات مبتنی بر رویداد فراهم می‌کند. از این رو، NCache می تواند به راحتی به عنوان یک واسطه پیام برای ارتباطات ناهمزمان بین میکروسرویس ها با استفاده از مدل Pub/Sub پیکربندی شود.

 

استفاده از NCache In-Memory Pub/Sub برای Microservices
Pub/Sub در NCache با تعریف موضوعی فعال می شود که در آن میکروسرویس ها (ساخته شده در .NET/.NET Core) می توانند رویدادها را منتشر کنند و همچنین در آنها مشترک شوند. رویدادها خارج از میکروسرویس، به واسطه پیام NCache منتشر می شوند. هر میکروسرویس مشترک حاوی یک کنترل کننده رویداد است تا پس از انتشار میکروسرویس ناشر، رویداد مناسب را مدیریت کند. 

 

استفاده از NCache In-Memory Pub/Sub برای Microservices
Pub/Sub در NCache با تعریف موضوعی فعال می شود که در آن میکروسرویس ها (ساخته شده در .NET/.NET Core) می توانند رویدادها را منتشر کنند و همچنین در آنها مشترک شوند. رویدادها خارج از میکروسرویس، به واسطه پیام NCache منتشر می شوند. هر میکروسرویس مشترک حاوی یک کنترل کننده رویداد است تا پس از انتشار میکروسرویس ناشر، رویداد مناسب را مدیریت کند. 

 

مثال سریع استفاده از NCache In-Memory Pub/Sub
با استفاده از برنامه eShopOnContainers، NCache به عنوان یک واسطه پیام در چندین سناریو عمل می کند. یکی از سناریوهایی که در اینجا برجسته شده است، رویداد تسویه حساب کاربر است که در آن جزئیات سبد در گذرگاه رویداد NCache منتشر می شود و برنامه سفارش ممکن است برای پردازش سفارش در سبدهای ورودی در پرداخت کاربر مشترک شده باشد.

• انتشار: این قطعه کد ساده شده بخشی از منطق پرداخت سبد را در میکروسرویس Basket.API نشان می دهد که در آن شناسه کاربر و تمام جزئیات سبد مانند آدرس، شماره کارت و موارد دیگر به عنوان بار پیام اضافه شده و در اتوبوس رویداد منتشر می شود. کد Basket.API را می توان در کلاس BasketController.cs در GitHub یافت.

[Route("checkout")]

[HttpPost]

public async Task<ActionResult> CheckoutAsync([FromBody]BasketCheckout basketCheckout, [FromHeader(Name = "x-requestid")] string requestId)

{

    var userId = GetUserIdentity();

    basketCheckout.RequestId = GetRequestID();

    var basket = await GetBasketAsync(userId);

    var userName = User.FindFirst(x => x.Type == "unique_name").Value;

    var eventMessage = new UserCheckoutAcceptedIntegrationEvent(userId, userName,

    basketCheckout.Address, basketCheckout.CardNumber, basketCheckout.RequestId, basket);

 

    // This message is published to the NCache Pub/Sub store

    eventBus.Publish(eventMessage);

}

• اشتراک: قطعه کد زیر از میکروسرویس Ordering.API است که کد آن در GitHub آپلود شده است. این شامل یک اشتراک در رویداد UserCheckout است که در آن هنگامی که کاربر سبد خرید را بررسی کرد، یک رویداد به عنوان یک پیام منتشر می‌شود و کنترل‌کننده از مشترک برای پردازش بیشتر سفارش فراخوانده می‌شود.

var eventBus = app.ApplicationServices.GetRequiredService<IEventBus>();

 

eventBus.Subscribe<UserCheckoutAcceptedEvent,

                   IIntegrationEventHandler<UserCheckoutAcceptedEvent>>();

 

دوام پیام Pub/Sub با اشتراک های بادوام
از آنجایی که میکروسرویس‌ها به‌طور ضعیفی جفت می‌شوند، به این معنی است که میکروسرویس‌ها ممکن است در هر زمانی به برنامه ملحق شوند یا از آن خارج شوند. علاوه بر این، اگر در حین ارسال پیام با ترافیک بالا با مشکلی در شبکه مواجه شوید، چه؟ این بدان معنی است که اتصال میکروسرویس با گذرگاه رویداد باید به اندازه کافی انعطاف پذیر باشد، بنابراین پیام ها از بین نمی روند حتی اگر شبکه به طور موقت قطع شده باشد.

NCache دو نوع اشتراک بادوام را برای تطبیق دوام پیام شما در میان ریزسرویس‌های NET/.NET Core ارائه می‌دهد:

1. اشتراک های بادوام مشترک: چند مشترک می توانند مشترک یک اشتراک شوند. روش Round Robin برای ارسال پیام به چندین مشترک استفاده می شود. حتی اگر مشترکین شبکه را ترک کنند، پیام ها بین مشترکین فعال همچنان توزیع می شود.
2. اشتراک های بادوام انحصاری: یک اشتراک هر بار فقط یک مشترک فعال دارد. هیچ درخواست مشترک جدیدی در همان اشتراک پذیرفته نمی شود تا زمانی که اتصال فعال باشد.

 

قابلیت اطمینان ارتباط با تلاش های مجدد اتصال

از آنجایی که ریزسرویس‌ها برای ارتباط به شبکه متکی هستند، ممکن است خرابی‌های غیرمنتظره‌ای در شبکه وجود داشته باشد که مستلزم داشتن مکانیزم برقراری ارتباط است. بنابراین، NCache یک پلت فرم ارتباطی قابل اعتماد را با تلاش های مجدد اتصال و ویژگی های زنده نگه می دارد تا مطمئن شود که سرویس های NET/.NET Core شما به طور خودکار سعی می کنند در صورت خرابی شبکه به حافظه پنهان متصل شوند. این امر نیاز به سیاست های امتحان مجدد توسط هر کتابخانه شخص ثالثی مانند Polly را از بین می برد.

 

چرا NCache؟
از آنجایی که سازمان‌ها اکنون معماری میکروسرویس را بر روی برنامه‌های یکپارچه می‌پذیرند، NCache تبدیل به ذخیره‌گاه داده‌های توزیع‌شده درون حافظه شما می‌شود تا به‌عنوان واسطه‌ای برای برنامه‌های میکروسرویس هسته دات‌نت/.NET شما استفاده شود.

• بسیار سریع و مقیاس‌پذیر خطی: NCache به دلیل حافظه داخلی، ارتباط سریع‌تری را نسبت به سایر راه‌حل‌های Pub/Sub فراهم می‌کند. علاوه بر این، توزیع به NCache این امکان را می دهد که به شما اجازه دهد در حین حرکت، با اضافه کردن سرورهای بیشتری به خوشه Message Broker برای مدیریت بارهای بیشتر، مقیاس کنید.
• در دسترس بودن بالا: NCache یک معماری خوشه‌ای همتا به همتا پویا و خود ترمیم‌شونده ارائه می‌کند که هیچ نقطه‌ای از شکست را تضمین نمی‌کند. علاوه بر این، NCache به طور هوشمندانه پیام‌ها را تکرار می‌کند و همچنین اشتراک‌های بادوام را فراهم می‌کند، بنابراین در صورت از کار افتادن سرور کش، پیامی از دست نمی‌رود و دسترسی بالا به میکروسرویس‌های شما را برای ارتباط تضمین می‌کند. NCache همچنین در مواقعی که نیاز به افزایش تعداد سرورها در کلاستر دارید، با اجازه دادن به شما در اضافه کردن این سرورها در زمان اجرا بدون توقف خوشه، دسترسی بالایی را فراهم می کند.
• Native .NET Core: برای میکروسرویس های ساخته شده در .NET/.NET Core، NCache یک پشته اصلی .NET / .NET 100% برای ادغام یکپارچه در پشته برنامه شما فراهم می کند.

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

 

مقیاس گذاری ارتباطات میکروسرویس دات نت با NCache Pub/Sub

NCache یک راه حل ذخیره سازی ذخیره سازی منبع باز 100% بومی .NET / .NET Core از Alachisoft است که می تواند به افزایش عملکرد و مقیاس پذیری برنامه شما با جهش و مرز کمک کند. این یک حافظه پنهان توزیع شده سریع در حافظه است که می تواند به صورت خطی مقیاس بندی کند و ویژگی های همگام سازی کش قوی را ارائه می دهد. می توانید سرورهای بیشتری را در صورت نیاز اضافه کنید تا بتوانید مقیاس خطی را انجام دهید. این مقاله بحثی را در مورد اینکه چگونه می‌توانیم از NCache PubSub برای مقیاس‌بندی میکروسرویس‌ها استفاده کنیم، ارائه می‌کند.
 
این مقاله به نکات زیر می پردازد

• مقیاس پذیری چیست؟
• مدل ناشر – مشترک چیست؟
• مقیاس پذیری چیست؟
• میکروسرویس چیست؟
• Pub/Sub Model چیست؟
• NCache به عنوان In-Memory Pub/Sub برای Microservices
• برنامه نویسی: انتشار و اشتراک پیام به/از یک موضوع

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

• Visual Studio 2019
• .NET. Core 3.0

 
مقیاس پذیری چیست؟
 
اصطلاح مقیاس پذیری یک برنامه کاربردی به عنوان توانایی آن برای پاسخگویی به بارهای تراکنش افزایش یافته بدون کاهش سرعت تعریف می شود. به عبارت دیگر، مقیاس پذیری یک برنامه، توانایی آن برای ادامه کار به همان سرعت است، حتی زمانی که حجم کاری اضافی برای برآورده کردن خواسته های کاربر اضافه می شود. یک برنامه مقیاس پذیر برنامه ای است که با تقاضاهای رو به رشد (کاربران همزمان بیشتر، تراکنش های بیشتر در ثانیه و غیره) در طول زمان سازگار باشد. مقیاس پذیری برنامه های کاربردی مبتنی بر میکروسرویس، توانایی آن در مدیریت افزایش ترافیک و در نتیجه تقاضای منابع در طول زمان است. توجه داشته باشید که توانایی مقیاس پذیری آسان یکی از مزایای کلیدی معماری میکروسرویس ها است.
 
توجه داشته باشید که حتی اگر اصطلاحات مقیاس پذیری و کشش هر دو به افزایش توانایی برنامه در حفظ حجم کاری مربوط می شوند، تفاوت های ظریفی بین این دو وجود دارد. در حالی که مقیاس پذیری به توانایی یک برنامه کاربردی برای حفظ حجم کار اضافی با استفاده از منابع سخت افزاری فعلی یا موجود مربوط می شود، کشش به توانایی برنامه برای حفظ تقاضا برای حجم کار اضافی با استفاده از منابع سخت افزاری فعلی و اضافی که در صورت تقاضا اضافه می شوند، مربوط می شود.
 
میکروسرویس چیست؟ 
 
مارتین فاولر می گوید: "به طور خلاصه، سبک معماری میکروسرویس رویکردی برای توسعه یک برنامه کاربردی واحد به عنوان مجموعه ای از سرویس های کوچک است که هر کدام در فرآیند خاص خود اجرا می شوند و با مکانیسم های سبک وزن، اغلب یک API منبع HTTP ارتباط برقرار می کنند. این سرویس ها بر اساس ساخته شده اند. قابلیت های تجاری و به طور مستقل توسط ماشین آلات استقرار کاملاً خودکار قابل استقرار است." 

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

 

مدل ناشر-مشترک چیست؟
 
پیام انتشار/اشتراک، نوعی پیام رسانی ناهمزمان یا نوعی سرویس ناهمزمان برای ارتباطات سرویس است. این نوع پیام‌رسانی معمولاً در معماری‌های محاسباتی بدون سرور و میکروسرویس‌ها استفاده می‌شود. در یک مدل معمولی public-subscribe (که معمولاً به عنوان pub-sub شناخته می‌شود)، ناشر رویداد اعلان‌ها یا پیام‌های رویداد را به مشترکین ارسال می‌کند. مدل پیام‌رسانی pub-sub اعلان‌های رویداد را برای برنامه‌های کاربردی توزیع شده تسهیل می‌کند - روشی را که ناشران و مشترکین می‌توانند به طور ناهمزمان با یکدیگر متصل شده و با یکدیگر ارتباط برقرار کنند، توضیح می‌دهد.
 
مدل ناشر-مشترک مزایای زیر را ارائه می دهد:

• اتصال سست
• امنیت بهتر
• تست پذیری بهبود یافته
• عملکرد بهبود یافته است

  سه جزء در یک الگوی معمولی ناشر-مشترک وجود دارد. این موارد شامل موارد زیر است،

• ناشر - این مؤلفه ای است که پیام ها را به یک زیرساخت ارتباطی منتشر می کند
• مشترک - این مؤلفه ای است که در یک یا چند پیام منتشر شده مشترک می شود
• زیرساخت ارتباطی - این زیرساخت از کانال‌هایی تشکیل شده است و مسئول فراهم کردن زیرساخت‌های لازم برای برقراری ارتباط موثر است.

چرا Pub/Sub در معماری Microservices؟
 
مدل pub-sub ارتباط سرویس به سرویس ناهمزمان را در برنامه های کاربردی مبتنی بر میکروسرویس تسهیل می کند. در یک سیستم پیام‌رسانی میخانه/فرعی، پیام‌ها با استفاده از یک کانال واسطه که به عنوان موضوع شناخته می‌شود، بین چندین برنامه رد و بدل می‌شود، بدون هر گونه دانشی از برنامه‌های ارسال یا دریافت. مدل pub/sub عمدتاً به دلیل ماهیت ناهمزمان و رویداد محور آن در معماری میکروسرویس مناسب است - شما می توانید از مزیت مدل pub-sub برای ساخت معماری های میکروسرویس با کارایی بالا، قابل اعتماد و مقیاس پذیر استفاده کنید.
 
انواع اشتراک Pub/Sub در NCache
 
هنگام کار با برنامه‌های مبتنی بر میکروسرویس، انعطاف‌پذیری از اهمیت بالایی برخوردار است - تضمین می‌کند که یک یا چند میکروسرویس می‌توانند از خرابی‌ها بازیابی شوند و شکست یک قسمت از برنامه، کل برنامه را از بین نخواهد برد.
 
NCache از چندین اشتراک میخانه/اشتراک بین ناشران و مشترکین پشتیبانی می کند. دو نوع اشتراک پشتیبانی می شود - این موارد شامل موارد زیر است (برای جزئیات به اسناد NCache مراجعه کنید)،

• اشتراک مبتنی بر الگو
• اشتراک بادوام و غیر بادوام

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

 

مدل‌های Pub-Sub مبتنی بر موضوع و محتوا
 
در مدل انتشار-اشتراک، پیام‌ها با استفاده از یکی از این دو روش انتخاب می‌شوند: سیستم‌های مبتنی بر موضوع و سیستم‌های مبتنی بر محتوا. توجه داشته باشید که در یک سیستم مبتنی بر موضوع معمولی، پیام‌هایی که برای یک موضوع منتشر می‌شوند، در واقع توسط همه مشترکین موضوع بلافاصله دریافت می‌شوند. در یک سیستم مبتنی بر محتوا، پیام‌ها تنها در صورتی تحویل داده می‌شوند که محدودیت‌ها و معیارهای مشخصی که توسط مشترک تعریف شده است، برآورده شوند.
 
توجه داشته باشید که در یک صف یک پیام تنها به یک مشترک می رسد. برعکس در یک موضوع پیامی به تک تک مشترکین می رسد. در حالی که موضوعات برای مدل ناشر-مشترک مناسب هستند، صف ها انتخاب خوبی برای نقطه به نقطه هستند.
 
در اکثر سیستم‌های میخانه/زیر، ناشران پیام‌ها را در یک واسطه پیام میانی یا یک اتوبوس رویداد ارسال می‌کنند. کارگزار پیام‌ها را از ناشران به مشترکان هدایت می‌کند و همچنین ممکن است به صورت اختیاری پیام‌ها را قبل از مسیریابی اولویت‌بندی کند.
 
NCache به عنوان In-Memory Pub/Sub برای Microservices
 
مدل پیام‌رسانی ناشر/مشترک معمولاً در برنامه‌های کاربردی توزیع‌شده به‌عنوان راهی برای مبادله پیام‌ها بین چندین برنامه به‌صورت جداشده استفاده می‌شود - بدون اینکه این برنامه‌ها نیازی به دانستن مبدع پیام از کجا دارند. اتفاقاً، این پیام‌ها سپس با استفاده از یک کانال واسطه رد و بدل می‌شوند - که به عنوان موضوع شناخته می‌شود.

 
NCache برای ارتباطات مبتنی بر رویداد در برنامه‌های مبتنی بر میکروسرویس برای میخانه/زیر حافظه در حافظه مناسب است. می‌توانید با تعریف موضوعی که سرویس‌ها می‌توانند از آن برای انتشار رویدادها یا اشتراک در آن استفاده کنند، ویژگی pub-sub را در NCache فعال کنید. ناشر یک جزء (یا یک میکروسرویس) است که پیامی را به موضوع NCache منتشر می کند. رویدادها برای کارگزار پیام NCache منتشر می شوند. هر میکروسرویس مشترک از یک کنترل کننده رویداد استفاده می کند تا به محض اینکه یک میکروسرویس ناشر پیامی را برای کارگزار پیام NCache منتشر کرد، رویداد مناسب را مدیریت کند.

قطعه کد ساده شده ارائه شده در زیر نشان می دهد که چگونه پیام ها می توانند در گذرگاه رویداد NCache منتشر شوند.

1. [Route("CheckoutItems")]  
2. [HttpPost]  
3. public async Task < ActionResult > CheckoutItemsAsync([FromBody] Item item) {  
4.     var items = _itemService.GetItemAsync(item.Id);  
5.     //Write your code to build the message here.  
6.     //Assume that the message instance is named eventMessage.  
7.     try {  
8.         _eventBus.Publish(eventMessage);  
9.     } catch (Exception ex) {  
10.         _logger.LogError(ex, "Error publishing event");  
11.         throw;  
12.     }  
13.     return Ok(items);  
14. }  

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

1. try {  
2.     string topicName = "demoTopic";  
3.     ITopic demoTopic = cache.MessagingService.GetTopic(topicName);  
4.     if (demoTopic != null) {  
5.         //Write code here to build the message instance  
6.         demoTopic.Publish(demoMessage, DeliveryOption.All, true);  
7.     } else {  
8.         //There is no topic in the name specified.  
9.     }  
10. } catch (Exception ex) {  
11.     //Write your error handling code here  
12. }  

برای حذف یک موضوع، می توانید از کد کد زیر استفاده کنید:

1. try {  
2.     string topicName = "demoTopic";  
3.     cache.MessagingService.DeleteTopic(topicName);  
4. } catch (Exception ex) {  
5.     //Write code error handling code here  
6. }  

با فرض اتصال برنامه به حافظه نهان، قطعه کد زیر نشان می دهد که چگونه می توانید در یک اشتراک غیر بادوام مشترک شوید.

1. try {  
2.     string topicName = "demoTopic";  
3.     ITopic demoTopic = cache.MessagingService.GetTopic(topicName);  
4.     if (orderTopic != null) {  
5.         ITopicSubscription demoSubscriber = demoTopic.CreateSubscription(MessageReceived);  
6.     } else {  
7.         //There is no topic in the name specified.  
8.     }  
9. } catch (Exception ex) {  
10.     //Write your error handling code here  
11. }  
12. private void MessageReceived(object sender, MessageEventArgs args) {  
13.     if (args.Message.Payload is Item item) {  
14.         //Write your code to perform some operation here  
15.     } else {  
16.         // Error occurred  
17.     }  
18. }  

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

 

خلاصه
 
معماری Microservices شامل مجموعه‌ای از ماژول‌هایی است که به‌طور آزاد به هم متصل شده‌اند که می‌توانند از طریق APIهای ساده با یکدیگر ارتباط برقرار کنند. مدل Pub/sub روشی زیبا برای ارتباط سرویس‌ها در یک برنامه کاربردی مبتنی بر میکروسرویس‌های معمولی است.
 
شما می توانید از NCache به عنوان یک واسطه پیام رسانی برای ارتباطات ناهمزمان بین میکروسرویس ها با استفاده از مدل Pub/Sub استفاده کنید. این مقاله بحثی را در مورد اینکه چگونه می‌توانیم با مدل pub-sub با استفاده از NCache برای بهبود مقیاس‌پذیری برنامه‌های مبتنی بر میکروسرویس کار کنیم، ارائه کردیم.

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

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

• لایه نمایشی
• لایه کسب و کار
• لایه پایگاه داده

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

• پیاده سازی ساده در فناوری واحد

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

• راه اندازی و راه اندازی اولیه بسیار آسان است

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

• ارتباط مستقیم

ارتباط بین اجزای یکپارچه در داخل مرزهای یک برنامه اتفاق می افتد. هیچ استراتژی اضافی برای حفظ این مورد نیاز نیست.

• اشکال زدایی و تست آسان

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

• استقرار آسان

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

معایب

• توسعه آهسته زمانی که بزرگ و پیچیده است

هنگامی که ویژگی ها همچنان در حال افزایش هستند و تیم در حال افزودن/تغییر کد است، بارها و بارها، پیچیدگی افزایش می یابد و در نهایت سرعت توسعه کاهش می یابد.

• مقیاس بندی توسط اجزا یا ماژول های جداگانه امکان پذیر نیست

به دلیل یک بسته نرم افزاری در طبیعت، مقیاس بندی توسط جزء یا ماژول امکان پذیر نیست. اگر نیاز به افزایش مقیاس دارید، کل برنامه باید بزرگ شود، حتی زمانی که فقط یک یا چند مؤلفه باید بزرگ شوند.

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

احتمال زیادی وجود دارد که کل برنامه در صورت بروز یک باگ از کار بیفتد. به عنوان مثال. اگر باگ منجر به از بین بردن دامنه برنامه شما شود، مطمئناً کل برنامه از بین خواهد رفت.

• تغییرات کوچک می تواند منجر به کل آزمایش شود

در حین ایجاد هرگونه تغییر در برنامه Monolithic، ماژول های دیگر احتمالاً تحت تأثیر قرار می گیرند و از این رو نیاز دارند که کل برنامه با چرخه های آزمایش کامل انجام شود. این می تواند زمان زیادی را صرف کند.

• استقرار مداوم سخت است

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

• کل برنامه در هنگام تغییر کوچک مستقر می شود

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

• پذیرش فناوری جدید یک کابوس است

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

معماری میکروسرویس
 
همانطور که از نام آن پیداست، این معماری مبتنی بر خدمات است. این معماری بیشتر از معماری SOA است. خدمات معمولاً با قابلیت های تجاری یا زیر دامنه از هم جدا می شوند. هنگامی که ماژول ها / مؤلفه ها تعریف می شوند، می توان آنها را از طریق مجموعه ای متفاوت از تیم ها پیاده سازی کرد. این تیم ها تیم های پشته فناوری یکسان یا متفاوت خواهند بود. به این ترتیب، اجزای جداگانه را می‌توان در صورت نیاز بزرگ‌تر کرد و پس از پایان نیاز، به سرعت آن‌ها را کوچک کرد. 

 

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

• یک تیم کوچک می تواند درگیر شود و مالک شود

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

• کد و منطق قابل درک آسان

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

• چابکی آسان است

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

• معرفی تاب آوری

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

• تسریع زمان ورود به بازار

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

• تحویل مستمر امکان پذیر است

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

• توسعه پذیری ساده است

هر زمان که یک ویژگی جدید مورد نیاز است، به سادگی سرویس جدید را به معماری برنامه موجود اضافه کنید. بدون نیاز به بازگشت به کد موجود، ساخت ویژگی های جدید، و سپس یک ویژگی جدید می تواند نسبتاً سریعتر اضافه شود، زیرا این امر مستلزم معرفی سرویس جدید است و بر پایه کد موجود تأثیری نخواهد گذاشت.

• قابلیت تعویض در هر زمان

در صورت نیاز، خدمات موجود را می توان به جای نگهداری طولانی مدت، با هم جایگزین کرد. این همچنین ما را مجبور می‌کند تا کیفیت کد را حفظ کنیم، نه اینکه کد موجود را بارها و بارها با تعداد زیادی وصله تغییر دهیم.

آیا واقعاً به میکروسرویس نیاز دارید؟
 
اکنون در مورد مزایای Microservices صحبت کردیم، اما این بدان معنا نیست که معماری تک برنامه ها باید در Microservices ترسیم شود. قبل از استفاده از معماری Microservice از خود بپرسید "آیا واقعاً به یک برنامه کاربردی مبتنی بر Microservice نیاز دارید؟" قبل از اینکه Microservices را ادامه دهید، تصمیم خود را با پرسیدن یک مجموعه ساده از سوالات قضاوت کنید.

• آیا نیاز فعلی برنامه شما به اندازه کافی بزرگ است که به چندین دامنه تقسیم شود؟ (یعنی میکروسرویس ها؟) اگر نه، احتمالاً به این رویکرد نیاز ندارید.
• آیا برنامه شما واقعاً نیاز به مقیاس بندی ماژول ها یا مؤلفه ها به صورت جداگانه دارد؟ اگر نه، شما خوب هستید که با Monolithic بروید. به عنوان مثال. یک برنامه تجارت الکترونیک باید ماژول سفارش خود را در طول دوره فروش مقیاس بندی کند و ماژول های دیگر مانند کاربر، محصول و غیره در حین بزرگ شدن مورد نیاز نیستند.
• هزینه/مدت پروژه کمتر است؟ خدمات میکرو به دلیل پیاده سازی، امنیت، نظارت، زیرساخت و غیره مطمئناً برای برنامه های کوچک پرهزینه خواهد بود. همه اینها باید به همه ذینفعان اطلاع داده شود، سپس تصمیمات مشترک اتخاذ می شود.
• آیا برای تست ادغام پیچیده آماده هستید؟ توسعه برنامه های پیچیده می تواند در دراز مدت با استفاده از Microservices آسان باشد، اما تست یکپارچه سازی همه سرویس ها مطمئناً انجام نخواهد شد. اطمینان حاصل کنید که ابزار، تکنیک ها و اعضای کافی برای مدیریت وضعیت دارید.
• آیا توسعه دهندگان Full-stack دارید؟ آنها نیاز اساسی هستند. اگر اعضای آماده ای در یک تیم ندارید، قبل از ورود به معماری Microservice باید آنها را داشته باشید.
• آیا Dev-Ops آماده هستید؟ بدون خط لوله یکپارچه سازی مداوم/تحویل مستمر/ استقرار مداوم (CI/CD/CD)، فرهنگ Dev-Ops نمی تواند راه اندازی شود که به تولید سریعتر نیاز دارد. اگر این فرهنگ را نداشته باشید، تمام هدف شکست خواهد خورد.
• آیا سیستم نظارت قوی دارید؟ معماری میکروسرویس شبکه ای از خدمات است و اگر هر یک از آنها از بین برود، باید به زودی بازیابی یا تکرار شوند. بدون یک سیستم نظارت قوی و فرآیند تحمل خطا خوب، این امکان پذیر نخواهد بود و شما تجارت را از دست خواهید داد.

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

• ذخیره سازی داده ها

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

• ارتباطات خدماتی

ارتباط با سرویس ها را می توان با استفاده از API Gateway انجام داد. API Gateway دروازه مرکزی است که از آنجا می توان تمام درخواست ها را ترجمه کرد و خدمات مناسب را فراخوانی کرد. ارتباط بین سرویس ها را می توان با استفاده از درخواست/پاسخ همزمان و ناهمزمان با استفاده از صف های پیام رسانی به دست آورد.

• امنیت

برخلاف سیستم یکپارچه، فرآیند مجوز و احراز هویت در معماری Microservices متفاوت است. برنامه Monolithic به راحتی از session استفاده می کند در حالی که Microservices از احراز هویت مبتنی بر توکن استفاده می کند.

• آزمایش کردن

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

• گسترش

هر میکروسرویس باید به گونه ای مستقر شود که دیگر منابع سرویس را مسدود نکند و به همین دلیل است که استقرار مستقل توصیه می شود. برای ایجاد یک استقرار کارآمدتر، باید کانتینرسازی دنبال شود. Independent Deploy, Update, Replace, Scale (DURS) زیبایی میکروسرویس است و باید مورد استفاده قرار گیرد.

 

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

Fanout Async Messaging Design در Microservices با استفاده از RabbitMQ

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

 
الگوی پیام رسانی "Fanout" چیست؟
 
Fanout یک طرح پیام رسانی است که در آن پیام منتشر شده از یک ناشر خاص توسط چندین مشترک مختلف به طور مستقل و همزمان مصرف می شود. هدف این است که همان پیام منتشر شده توسط مصرف کنندگان مختلف مصرف شود و به روش های مختلف پردازش شود.
 
در یک واسطه پیام مانند RabbitMQ، ناشر پیامی را منتشر می کند که از طریق نوع خاصی از تبادل به نام "Fanout Exchange" در صف های مختلف قرار می گیرد.
 
مصرف‌کنندگانی که به این صف‌ها گوش می‌دهند، همان پیامی را دریافت می‌کنند که باید مصرف شود.
 
نمودار زیر یک نمایش نموداری از الگوی پیام رسانی "Fanout" را نشان می دهد.
 
Fanout Async Messaging Design در Microservices با استفاده از RabbitMQ

 
چه زمانی از الگوی Fanout استفاده کنیم؟
 
مورد استفاده از الگوی fanout در مکان‌هایی که ناشر نیاز دارد به طور ناهمزمان با چندین مصرف‌کننده در یک حجم کاری واحد ارتباط برقرار کند، قابل استفاده است.
یک مثال می تواند این باشد: فرض کنید در یک سیستم کتابخانه آنلاین، یک میکروسرویس مسئول ارائه درخواست امانت برای یک کتاب است - سرویس اجاره کتاب. در اینجا، هنگامی که یک کتاب با موفقیت به یک مشتری اجاره شد، این سرویس می تواند به عنوان یک ناشر عمل کند و پیامی را برای سایر خدماتی که مسئول (i) حذف آن از "لیست آرزوهای" مشتری، (ii) کاهش تعداد در دسترس بودن هستند، تولید کند. برای این کتاب در قفسه کتابخانه آنلاین، (iii) به روز رسانی "قفسه در حال مطالعه" مشتری. این سرویس‌های مصرف‌کننده پیام یکسان را در صف‌های مختلف گوش می‌دهند و می‌توانند به طور مستقل روی این اعلان کار کنند، بدون اینکه فرآیند اجاره را منتظر بمانند. در اینجا ناشر، پیام را در صف‌های متفاوتی که مصرف‌کنندگان علاقه‌مند برای مصرف پیام به آن متصل می‌شوند، «طرفدار» می‌کند. ناشر در اینجا، سرویس اجاره کتاب، نیازی به صبر کردن ندارد تا خدمات دیگر بر اساس پیام به پایان برسد و می تواند به طور یکپارچه و مستقل کتاب را برای مشتری صادر کند و درخواست های اجاره بیشتری را انجام دهد تا آن را برای کاربران در دسترس قرار دهد.

 
Refresher در "Exchanges"، "Bindings"، "Routing Keys" در RabbitMQ
 
به‌عنوان تجدیدنظر یا محاسبه‌کننده سریع، جنبه‌های مختلف کلیدی واسطه پیام RabbitMQ را که در نمونه اولیه استفاده می‌کنیم، مشخص می‌کنم. با این حال، من شما را تشویق می‌کنم که برای درک عمیق این موضوعات به مطالعه‌های بیشتر بروید.

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

 

• مستقیم
• Fanout
• موضوع
• سرصفحه ها

 

اتصالات
 
Binding یک صف را به یک صرافی پیوند می دهد.

 

کلیدهای مسیریابی
 
Routing Key یکی از ویژگی‌هایی است که صرافی‌ها هنگام تصمیم‌گیری در مورد اینکه پیام به کدام صف ارسال شود، به دنبال آن هستند. با این حال، در مورد نوع مبادله "Fanout" این کلید هیچ اهمیتی ندارد و نادیده گرفته می شود.
 

نمونه اولیه
 
در مقاله قبلی ام نحوه چرخش و ارتباط با یک ظرف RabbitMQ را نشان داده بودم. این دمو بر اساس همین زیرساخت خواهد بود.
 
برای شروع، (الف) من یک تبادل از نوع "Fanout" در نمونه در حال اجرا RabbitMQ ایجاد می کنم. پس از آن (B) من سه صف مختلف را برای اتصال به این صرافی اعلام می کنم. پس از آماده شدن، (C) من پیامی را از طریق سرویس اجاره به صرافی منتشر خواهم کرد.
 
قطعه کد زیر این مراحل را نشان می دهد،

1. private const string FANOUT_EXCHANGE = "fanout.exchange";
2. private const string WISHLIST_QUEUE = "wishListQueue";  
3. private const string LIBRARY_SHELF_QUEUE = "libraryShelfQueue";  
4. private const string READING_SHELF = "readingShelfQueue";

 

1. var factory = new ConnectionFactory()  
2.             {  
3.                 Uri = new Uri("amqp://guest:guest@localhost:5672")  
4.             };  
5.   
6.             using (var connection = factory.CreateConnection())  
7.             using (var channel = connection.CreateModel())  
8.             {  
9.                 // declare exchange of type "Fanout"  
10.                 channel.ExchangeDeclare(exchange:FANOUT_EXCHANGE, type: ExchangeType.Fanout);  
11.   
12.                 // declare queue : Wishlist Queue  
13.                 channel.QueueDeclare(queue: WISHLIST_QUEUE,  
14.                                      durable: false,  
15.                                      exclusive: false,  
16.                                      autoDelete: false,  
17.                                      arguments: null);  
18.                 // bindind the wishlist queue to the "Fanout" exchange  
19.                 channel.QueueBind(queue: WISHLIST_QUEUE, exchange: FANOUT_EXCHANGE, routingKey:"");  
20.   
21.                 // declare queue : Library Shelf Queue  
22.                 channel.QueueDeclare(queue: LIBRARY_SHELF_QUEUE,  
23.                                      durable: false,  
24.                                      exclusive: false,  
25.                                      autoDelete: false,  
26.                                      arguments: null);  
27.                 // bindind the Library Shelf Queue to the "Fanout" exchange  
28.                 channel.QueueBind(queue: LIBRARY_SHELF_QUEUE, exchange: FANOUT_EXCHANGE, routingKey: "");  
29.   
30.                 // declare queue : Reading Shelf Queue  
31.                 channel.QueueDeclare(queue: READING_SHELF,  
32.                                      durable: false,  
33.                                      exclusive: false,  
34.                                      autoDelete: false,  
35.                                      arguments: null);  
36.                 // bindind the Reading Shelf to the "Fanout" exchange  
37.                 channel.QueueBind(queue: READING_SHELF, exchange: FANOUT_EXCHANGE, routingKey: "");  
38.   
39.   
40.   
41.   
42.                 // publish message  
43.                 string message = "ID of the Book which is Rented out: " + id;  
44.                 var body = Encoding.UTF8.GetBytes(message);  
45.   
46.                 channel.BasicPublish(exchange: FANOUT_EXCHANGE,  
47.                                     routingKey: "",  
48.                                     basicProperties: null,  
49.                                     body: body);  
50.   
51.             }  

اکنون اجازه دهید مشتریان خود را که برای گوش دادن به این سه صف مختلف پیکربندی شده اند، بچرخانیم. یک کد نمونه از یکی از مصرف کنندگان - WishListService - که در آن پیام ها را از صف مربوطه مصرف می کند: wishListQueue

1. //establish connection  
2.             var factory = new ConnectionFactory()  
3.             {  
4.                 Uri = new Uri("amqp://guest:guest@localhost:5672")  
5.             };  
6.             var rabbitMqConnection = factory.CreateConnection();  
7.             var rabbitMqChannel = rabbitMqConnection.CreateModel();  
8.   
9.             rabbitMqChannel.BasicQos(prefetchSize: 0, prefetchCount: 1, global: false);  
10.   
11.             //consume the message received  
12.             var consumer = new EventingBasicConsumer(rabbitMqChannel);  
13.             consumer.Received += (model, args) =>  
14.             {  
15.                 var body = args.Body;  
16.                 var message = Encoding.UTF8.GetString(body.ToArray());  
17.                 Console.WriteLine("Book ID To be removed from Wishlist: " + message);  
18.                 rabbitMqChannel.BasicAck(deliveryTag: args.DeliveryTag, multiple: true);  
19.                 Thread.Sleep(1000);  
20.             };  
21.             rabbitMqChannel.BasicConsume(queue: WISHLIST_QUEUE,  
22.                                          autoAck: false,  
23.                                          consumer: consumer);  
24.             Console.ReadLine();  

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

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

میکروسرویس ها یکی از معماری های نرم افزاری ضروری هستند که در حال حاضر مورد استفاده قرار می گیرند. در این معماری، یک برنامه کاربردی به عنوان ادغام سرویس‌های متصل به هم تنظیم می‌شود. هر میکروسرویس مستقل است و یک رابط واضح برای مدیریت عملکردهای تجاری ارائه می دهد.

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

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

 

میکروسرویس چیست؟
میکروسرویس ها که به عنوان معماری میکروسرویس نیز شناخته می شوند، یک سبک ساختاری بسیار مقیاس پذیر است که برای توسعه سیستم های نرم افزاری استفاده می شود. چنین معماری عمدتاً توسط مؤسسات خیریه، مدارس، دولت ها، مشاغل و موارد دیگر برای توسعه برنامه های کاربردی سازمانی استفاده می شود.

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

 

ابزارهای میکروسرویس چیست؟
ابزارهای میکروسرویس چیزی جز مجموعه ای از فناوری ها و ابزارهای مختلف نیستند که دارای مجموعه ای از عملکردها هستند. این ابزارها عمدتاً در مراحل مختلف توسعه یک برنامه کاربردی استفاده می شوند. آنها همچنین به توسعه دهندگان کمک می کنند تا بدون هیچ زحمتی کار کنند.

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

 

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

 

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

لینوکس

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

 

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

اکسیر

با Elixir، اکنون می توانید به طور یکپارچه کارنامه برنامه نویسی خود را گسترش دهید. این ابزار کاربردی و همزمان است. به طور کلی برای هر زبان برنامه نویسی ساخته شده است. و همراه با بایت کدی که در BEAM دیده می شود کار می کند که به Erlang VM نیز معروف است.

چکمه بهاره

چارچوب های Spring Boot به شما این امکان را می دهد که توسعه میکروسرویس های مبتنی بر REST را تنها با چند خط کدنویسی ساده کنید. برای شروع آسان و سریع، می توانید از Spring Initializr یا یکی از نمونه های موجود Spring Boot استفاده کنید.

 

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

 

قلعه API

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

 

پستچی
Postman یک مجموعه توسعه API است که برای تیم ها و توسعه دهندگان فردی است. این به شما امکان می دهد بدون زحمت تست های API را که مبتنی بر UI هستند اجرا کنید. از آنجایی که Postman یک کلاینت مهم HTTP است، کاوش API RESTful را بسیار آسان می کند. کاربران می‌توانند به سرعت درخواست‌های HTTP پیچیده و ساده را برای آزمایش، توسعه و همچنین مستندسازی APIها در کمترین زمان جمع کنند.

 

تایک

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

 

ابزارهای پیام رسانی
در اینجا لیستی از ابزارهای پیام رسانی قابل استفاده آمده است:

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

 

سرویس صف ساده آمازون (SQS)
Amazon SQS اینجاست تا ارتباطات میکروسرویس انعطاف پذیر، قوی و قابل اعتماد را ارائه دهد. این ابزار هنگام انتخاب یک مدل ارتباطی انتشار-اشتراک از یک میکروسرویس به حل مشکلات مختلفی برای یک توسعه دهنده کمک می کند. در کنار امنیت ایده‌آل، صف‌ها با ارائه یک مکان قابل اعتماد برای ذخیره همه پیام‌های معلق به عملکرد و ارسال پیام کمک می‌کنند.

 

آپاچی کافکا

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

 

Google Cloud Pub/Sub
این یک سرویس پیام رسانی بی درنگ کاملاً مدیریت شده است که به شما امکان می دهد پیام ها را بین میکروسرویس ها ارسال و همچنین دریافت کنید. با ادغام برنامه با Google Cloud Pub/Sub، می‌توانید تمام درخواست‌های ناهمزمان را که دریافت خواهید کرد، رسیدگی کنید. همچنین، می توانید مدت زمانی را که کاربران در انتظار پاسخ سرمایه گذاری می کنند، کاهش دهید.

 

5.جعبه ابزار
ابزارهایی که می‌توانید برای میکروسرویس‌های Toolkits استفاده کنید، در زیر نشان داده شده است:

 

پارچه 8

fabric8 یک ابزار منبع باز پلتفرم به عنوان یک سرویس است که با ارائه سیستم های مدیریت پیکربندی از طریق git به توسعه دهندگان کمک می کند. همچنین پیچیدگی های ناشی از آدرس های IP و نگاشت پورت ها را کنترل می کند. همراه با آن، این ابزار می تواند توازن بار را به سرویس ها انجام دهد و بارگذاری کند. از این ابزار می توانید دسترسی و مقیاس پذیری بالایی کسب کنید.

 

سنکا

از طریق Seneca، اکنون می توانید فرآیندهای میکروسرویس مبتنی بر پیام را ایجاد کنید. این جعبه ابزار میکروسرویس به طور خاص برای Node.js طراحی شده است. با در دست داشتن این کد، اکنون می توانید کدهای سازماندهی شده، تمیز بنویسید و منطق برنامه کسب و کار خود را بدون زحمت سیستماتیک کنید.

 

توابع Google Cloud

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

 

چارچوب های معماری
در اینجا بهترین ابزار چارچوب های معماری وجود دارد:

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

 

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

 

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

رهبر ارکستر

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

 

ابزارهای نظارت
در اینجا برخی از بهترین ابزارهای نظارتی که می توانید استفاده کنید آورده شده است:

 

لاگستاش

Logstash یکی از ابزارهای نظارتی عالی است که می توانید برای میکروسرویس مستقر خود و نظارت بر آن استفاده کنید. این یک پلت فرم منبع باز است که می توانید به راحتی داده های خود را متمرکز، ذخیره و تغییر دهید.

گری لاگ

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

 

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

سوالات مصاحبه میکروسرویس

اگر به دنبال سوالات مصاحبه Microservices برای افراد با تجربه یا تازه کار هستید، در جای مناسبی هستید. فرصت های زیادی برای بسیاری از شرکت های معتبر در جهان وجود دارد.

پرسش و پاسخ مصاحبه میکروسرویس

Q1) Spring Cloud در حوزه Microservices چیست؟
این نوعی ویژگی در حوزه Microservices است که یکپارچگی با سیستم های بیرونی را فراهم می کند. همچنین به عنوان یک فریم ورک میکروسرویس کوتاه مدت شناخته می شود که توانایی ساخت برنامه های کاربردی را به سرعت دارد. علاوه بر این، عملکرد مهمی در میکروسرویس ها ایفا می کند زیرا با مقادیر محدودی از پردازش داده ها مرتبط است.

 

Q2) معماری Microservices را روشن کنید؟
این نوع معماری است که اجتناب از اجرای برنامه های کاربردی بزرگ را برای یک سیستم بزرگ تسهیل می کند. این با مشیت اتصال شل که بین رویه های مختلف مشارکتی اتفاق می افتد مرتبط است. از طرف دیگر، این قابلیت را دارد که به صورت مستقل تحت شرایط مختلف اجرا شود.

 

Q3) روشی را که از طریق آن می توانید کشف سرویس را راه اندازی کنید، شرح دهید؟
اگرچه راه‌های زیادی برای راه‌اندازی کشف سرویس وجود دارد، اما باید از Eureka ایجاد شده توسط Netflix استفاده کنید. این معمولاً یک فرآیند بسیار بدون دردسر است که برای برنامه سنگین نیست. همچنین، می تواند برای برنامه های مختلف مناسب باشد که بسیار خوب است.

 

Q4) منظور شما از Eureka در حوزه Microservices چیست؟
Eureka همچنین به عنوان Netflix Service Discovery Server شناخته می شود. این از Spring Cloud استفاده می کند و اغلب به عنوان پرکاربردترین تنظیمات برای شروع کشف سرویس شناخته می شود. همچنین روی فرآیند توسعه اپلیکیشن چندان سنگین نیست. به همین دلیل است که در بین توسعه دهندگان امروزی بسیار محبوب است.

 

Q5) راه‌هایی را که از طریق آنها می‌توانید به میکروسرویس‌های RESTful دسترسی پیدا کنید، روشن کنید؟
اینها راه های زیر هستند که با کمک آنها می توانید از یک میکروسرویس RESTful استفاده کنید.

با استفاده از الگوی استراحت متعادل بار
با استفاده از چندین Microservice می توانید به راحتی از یک قالب RESTful استفاده کنید
اگر تعداد زیادی الگوی RESTful به شما داده شده است، همیشه مطمئن شوید که از الگوی مناسب استفاده می کنید

 

Q6) فرآیندی را شرح دهید که توسط آن می توانید بار سمت سرور را با استفاده از Spring Cloud متعادل کنید؟
جالب است بدانید که عمل متعادل کننده در مورد دستیابی به بار سمت سرور را می توان با استفاده از Netflix Zuul به دست آورد. Zuul همچنین به عنوان یک روتر مبتنی بر JVM شناخته می شود. همچنین به عنوان یک متعادل کننده بار توسط نتفلیکس در نظر گرفته می شود. به همین دلیل است که همیشه یک موجودیت واحد را به سیستم تسهیل می کند.

 

Q7) آیا می توانید Zuul را با انواع دیگر پروژه ها ادغام کنید؟
بله، Zuul را می توان با انواع دیگر خدمات نتفلیکس که به عنوان Hystrix شناخته می شوند، ادغام کرد. به ویژه برای تحمل انواع مختلف گسل هایی که معمولاً در اورکا وجود دارند، در نظر گرفته شده است. با تحمل انواع مختلف خطاها، کشف خدمات در حوزه میکروسرویس ها آسان تر می شود. همچنین می توان از آن برای مدیریت جداول مسیریابی و متعادل سازی موثر بار در سراسر سیستم استفاده کرد.

 

Q8) نیاز اساسی میکروسرویس ها را در زمینه توسعه برنامه امروزی روشن کنید؟
میکروسرویس ها به عنوان یک الگوی جدید در حوزه توسعه نرم افزار نیز شناخته می شوند. از آنجایی که توانایی افزایش سرعت و کارایی را دارد اهمیت پیدا کرده است. همچنین می تواند راه حل های نرم افزاری را به شیوه ای موثر مدیریت کند. برخی نیز آن را رویکردی به فرآیند و فرهنگ می نامند که ارزش کسب و کار را به شیوه ای افزایش یافته ارائه می دهد. در زمینه توسعه برنامه امروزی، نقش بسیار مهمی ایفا می کند زیرا می تواند در فرآیند توسعه یک برنامه یکپارچه به شیوه ای کارآمد به کار گرفته شود.

 

Q9) شرایطی را توضیح دهید که تحت آن از Netflix Hystrix استفاده می کنید؟
این یک واقعیت پذیرفته شده است که Hystrix همچنین به عنوان یک کتابخانه تحمل خطا و تأخیر شناخته می شود. هدف اصلی Hystrix اطمینان از جداسازی نقاط دسترسی است. از طرفی با کمک این اکسس پوینت ها می توان به راحتی به سیستم های راه دور دسترسی پیدا کرد. همچنین اطمینان حاصل می کند که استفاده گسترده از کتابخانه های شخص ثالث و همچنین خدمات را محدود می کند. به این ترتیب، تضمین می کند که یک برنامه به شیوه ای کارآمد اجرا می شود. همچنین در ممانعت از شکستی که اغلب در سیستم های توزیع شده ای که ماهیت بسیار پیچیده ای دارند، بسیار موثر است.

 

Q10) فرآیندی را که توسط آن می توانید تعریف کنید

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

 

Q14) در مورد YAML در حوزه Microservices چه می دانید؟
همیشه باید توجه داشته باشید که YAML به عنوان یک زبان خوانا فردی نیز شناخته می شود. بسیاری از کارشناسان همچنین آن را زبانی می نامند که می تواند منجر به عقیم سازی داده ها شود. از این رو، اساساً نشان می دهد که می توان از آن برای پاک کردن داده ها استفاده کرد. این مزیت بزرگی در شبکه Microservices دارد. در مقایسه با سایر فایل‌های دارای ویژگی‌های مختلف، گفته می‌شود که فایل YAML از نظر سازمان‌دهی بیشتر است. از سوی دیگر، کمتر گیج کننده است و از این رو دسترسی آسان را برای انواع توسعه دهندگان وب فراهم می کند. با این حال، توجه به این نکته نیز ضروری است که YAML دارای شکل سلسله مراتبی داده است که نقش اساسی در توسعه سریع برنامه های مختلف داشته است.

 

Q15) جنبه های مختلف استفاده از نمایه های فنری را روشن کنید؟
در زمینه میکروسرویس ها، نمایه های فنری نقش اساسی دارند. این به این دلیل است که به کاربران اجازه می دهد تا در فرآیند ثبت انواع لوبیا باشند. با این حال، روند ثبت لوبیا همیشه به روش های مختلفی که برنامه توسط آنها اجرا شده است بستگی دارد. از این رو، اگر برنامه را در حالت DEVELOPMENT اجرا می کنید، شاهد خواهید بود که تعداد معینی از آیتم ها را می توان به روشی آسان تحت فشار قرار داد. از طرفی در طول زمان تولید، سایر اقلام نیز قابل بارگیری هستند. با استفاده گسترده از Spring Boot، اطمینان از اینکه همه پروفایل ها می توانند به راحتی بوت شوند، نسبتاً آسان شده است. این اطمینان حاصل می کند که برنامه توسعه یافته بدون خطا اجرا می شود و در رابط کاربری سبک است.

 

Q16) کش را با توجه به محیطی که میکروسرویس ها در آن کار می کنند تعریف کنید؟
این یک واقعیت است که معمولاً مشاهده می شود که حافظه نهان نوعی ناحیه در حافظه محلی است که توانایی نگهداری یک کپی از داده های اغلب تحقیق شده را دارد. به عبارت دیگر، اگر حافظه نهان در برنامه انباشته شده باشد، سرعت برنامه به طرز خارق العاده ای افزایش می یابد. از طرف دیگر، می‌توانید از تابع Cast نیز برای کنترل مقدار حافظه پنهان مورد نظر خود استفاده کنید.

 

Q17) آیا شما اغلب از چارچوب مربوط به ادغام با چارچوب Spring Boot استفاده می کنید؟
در پاسخ به این سوال همیشه می توان گفت که از Apache Camel استفاده کرده اید و تجربه یکپارچه سازی با تابع Spring Boot را دارید. همچنین می توان گفت در محیط Microservices از Apache Camel Boot starter استفاده کرده اید.

 

Q18) AOP را روشن کنید و همچنین نحوه استفاده از آن را با Microservices شرح دهید؟
در زمان پاسخ به این سوال، همیشه باید روی نگرانی های مقطعی تمرکز کنید. نگرانی های مقطعی راه هایی هستند که جاده های متعدد یک کاربرد خاص را گسترش می دهند. در این زمینه، جالب است بدانید که نگرانی های مقطعی معمولاً از منطق تجاری یک برنامه خاص در نوسان است. به همین دلیل است که جداسازی نگرانی های مربوط به ماهیت مقطعی همیشه یک گام اولیه است که باید در فرآیند توسعه برنامه برداشته شود. AOP همچنین به عنوان برنامه نویسی مشخصه گرا شناخته می شود که در حصول اطمینان از اینکه منطق کسب و کار به درستی برای برنامه های کاربردی مبتنی بر سازمان اعمال می شود، بسیار کمک می کند.

 

Q19) فرآیندی را تعریف کنید که با کمک آن می توانید مدیریت استثنا را در حوزه Microservices مستقر کنید؟
مهم است که توجه داشته باشید که میکروسرویس ها و فنر معمولاً روش منحصر به فردی را ارائه می دهند که در آن می توانید مشاوره کنترلر را کنترل کنید. می توانید بگویید که تجربه استقرار یک کلاس از Controller Advice را با کمک استثناهایی که توسط کلاس کنترلرها استفاده می شود را دارید.

 

Q20) مزایای Microservices چیست؟
استفاده از میکروسرویس ها مزایای مختلفی دارد. آنها به شرح زیر است:

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

 

Q21) انواع مختلف ویژگی های فناوری اطلاعات موجود در Microservices را روشن کنید؟

با کمک Microservices، کسب و کار شما می تواند به ارتفاعات جدیدی برسد زیرا برنامه ریزی فناوری اطلاعات و اجرای پروژه ها را یکپارچه می کند. در اینجا لیستی از ویژگی های مهم فناوری اطلاعات موجود در Microservices آمده است.

• برنامه ریزی انواع پروژه های فناوری اطلاعات
• مدیریت امکانات
• اجرای چندین نوع تمرین چابک
• تخصیص خدمات مشترک
• مدیریت پرونده های تجاری
• حفظ شفافیت در جنبه های مختلف هزینه همراه با برنامه ریزی مدیریت فناوری اطلاعات

 

Q22) گزارشات و داشبوردها در محیط میکروسرویس چه کاربردهایی دارند؟
توجه به این نکته برای شما حیاتی است که Microservices دارای انبوهی از ویژگی های انتشار است. این شامل انواع نمودارها، پی دی اف ها و داشبوردها می شود. با کمک داشبوردها و گزارش ها در میکروسرویس می توانید به راحتی سناریوها را تحلیل کنید و انواع بسته های اجرایی را تسهیل کنید.

 

 

Cloud Native Microservices

این مقاله در مورد Cloud Native Microservices به ارائه یک درک عمیق از آنچه که Cloud Native Microservices هستند اختصاص داده شده است و همچنین اطلاعاتی در مورد چگونگی استفاده از مزایای معماری جدید ارائه می دهد.

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

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

 

Cloud Native Microservices چیست؟
میکروسرویس یک فرآیند معماری است که در آن برای توسعه یک برنامه کاربردی با جمع آوری خدمات کوچک استفاده می شود. هر یک از خدمات با قابلیت های تجاری مرتبط است، جایی که آنها به فرآیند خاص خود مجهز هستند. تمام ارتباطات از طریق HTTP API یا ویژگی های پیام رسانی انجام می شود.

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

اکنون که متوجه شدیم میکروسرویس چیست، بیایید بر درک آنچه نیاز است کسب و کار یا سازمان از معماری سنتی خود به معماری میکروسرویس بومی ابری حرکت کند، تمرکز کنیم:

بسیاری از سازمان ها از یک فرآیند استاندارد پیروی می کنند که در آن تنها یک واحد استقرار دارند که همه ویژگی های برنامه را دارد. به این نوع معماری معماری یکپارچه می گویند.

 

مثلا:

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

برخی از خطرات موجود در معماری یکپارچه به شرح زیر است:

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

• نگهداری از پایگاه عظیم کد آسان نیست و مدیریت آن برای توسعه دهندگان نسبتاً دشوار است.
• اگر اندازه استقرار بزرگ باشد، قطعاً سرور را بیش از حد بارگذاری می کند و منجر به خرابی ناگهانی می شود.
• مقیاس پذیری اجزای جداگانه دشوار است.
• زمان توقف قابل توجهی برای استقرار تولید ضروری است و بر عملیات تجاری تأثیر می گذارد.

 

بنابراین با توجه به نکات فوق، قطعا تغییر فرآیند از معماری یکپارچه به معماری میکروسرویس منطقی است.

بنابراین، چه چیزی برای کسب و کارها یا سازمان ها لازم است تا از معماری یکپارچه به معماری میکروسرویس تغییر کنند؟

اکثر محدودیت‌هایی که در بالا با معماری یکپارچه ذکر کرده‌ایم را می‌توان با استفاده از معماری میکروسرویس اصلاح کرد.

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

طبق مثالی که در بالا در نظر گرفتیم، یعنی برنامه HealthCare، ماژول هایی مانند پذیرش، فاکتورها، داروخانه همه اجزای مستقلی خواهند بود و به عنوان یک واحد واحد مستقر می شوند.

بیایید بگوییم که افزایشی در استفاده از ماژول پذیرش وجود دارد، سپس توسعه دهندگان این گزینه را دارند که فقط مؤلفه مربوط به پذیرش را مقیاس کنند و بر بقیه رفتار برنامه تأثیری نگذارند. برعکس، این مسئله در محیط یکپارچه بزرگتر است.

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

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

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

 

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

 

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

در این دو رویکرد، آنها چند چالش هستند که مشاغل باید از آن عبور کنند.

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

 

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

آیا Microservices بهترین هستند؟
در مقایسه با معماری یکپارچه استاندارد، مزایای بسیاری وجود دارد که یک معماری میکروسرویس ارائه می کند:

• اول از همه، برنامه کاملاً منعطف است و مقیاس پذیر است.
• ارتقاء سیستم یا ارتقاء کد، کل استفاده از برنامه را مختل نمی کند.
• معماری میکروسرویس‌ها انعطاف‌پذیر است و فرآیند توسعه چابک در واقع چرخه‌های توسعه کوتاه‌تر را ارتقا می‌دهد و منجر به زمان سریع‌تر برای استقرار می‌شود.
• با فرآیند یکپارچه سازی مداوم و استقرار مداوم، زمان صرف شده برای استقرار در مقایسه با فرآیند استاندارد کمتر است.
• جداسازی مشکل آسان است. از آنجایی که پایه کد ماژولار است، اشکالات یا نقص‌ها تأثیری بر سایر بخش‌های برنامه نخواهد داشت.
• مفهوم قابلیت استفاده مجدد نیز در این ساختار در مقایسه با معماری استاندارد یکپارچه بالا است.
• با در نظر گرفتن همه این مزایا، قطعا بهترین تناسب خواهد بود. با توجه به نیاز سازمان و نیازهای برنامه، معماری میکروسرویس ها قابل پیاده سازی است.

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

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

جنبه های فوق باید به دقت بررسی شوند تا بهترین معماری میکروسرویس در دسترس باشد.

 

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

• برای استقرار و همچنین عدم استقرار میکروسرویس به طور مستقل باید انعطاف پذیر باشد.
• باید به گونه ای طراحی شود که یک جزء میکروسرویس بدون هیچ محدودیتی مقیاس پذیر باشد.
• خطای یکی از میکروسرویس ها نباید روی بقیه میکروسرویس ها تاثیر بگذارد.
• از نظر ساخت و استقرار سریع میکروسرویس ها باید سریع باشد.

نکات فوق حیاتی هستند تا میکروسرویس ها به طور موثر مستقر شوند.

 

با استفاده از ابزارهای منبع باز مانند Docker و Kubernetes، معماری میکروسرویس ها را می توان مستقر کرد.

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

این یکی از بهترین راه ها برای استقرار یک برنامه معماری میکروسرویس است. مراحل زیر برای کامل کردن اجرای کامل ضروری است:

• هر میکروسرویس باید به عنوان یک تصویر ظرف Docker بسته بندی شود
• هر نمونه سرویس یک ظرف است
• با افزایش نمونه های کانتینر، میکروسرویس می تواند مقیاس شود.
• از آنجایی که ما از کانتینرهای Docker استفاده می کنیم، ساخت و استقرار میکروسرویس ها در مقایسه با VM سنتی سریعتر است

Kubernetes یکی دیگر از پلتفرم‌هایی است که می‌توانیم با استفاده از Docker از آن استفاده کنیم و ارزش بیشتری به استقرار آن اضافه کنیم.

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

 

استراتژی های مهاجرت برای خدمات خرد
وقتی صحبت از استراتژی‌های مهاجرت برای میکروسرویس‌ها می‌شود، رویکردهای کمی وجود دارد که در دسترس هستند. استفاده از یک رویکرد بر اساس شرایط متفاوت است و تیم درون سازمان برای اتخاذ تصمیم مناسب، اولتیماتوم خواهد داشت.

سطح بالایی از استراتژی‌های مهاجرتی که سازمان‌ها تمایل به استفاده از آنها دارند در زیر بیان شده‌اند:

• طراحی مجدد موازی
• میکروسرویس های استاندارد
• سیستم های خودکفا

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

مزایای این نوع رویکرد عبارتند از:

• برنامه موجود، یعنی در برنامه یکپارچه، به هیچ وجه مختل نمی شود.
• اپلیکیشن جدید را می توان با توجه به نیاز طراحی کرد.

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

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

2. میکروسرویس های استاندارد
در این رویکرد، ابتدا ماژول‌های مستقل شناسایی می‌شوند و با توجه به ساختار میکروسرویس، دوباره طراحی و توسعه می‌یابند. در این فرآیند، کل رابط کاربری و باطن برنامه مجدداً طراحی می‌شوند تا با معماری میکروسرویس مطابقت داشته باشد.

مزایای مرتبط با این نوع رویکرد عبارتند از:

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

معایب این روش عبارتند از:

• کد UI فقط یکپارچه خواهد بود.
• تغییرات زیادی در طول این پیاده سازی انتظار می رود.

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

مزایای مرتبط با این رویکرد در زیر آورده شده است.

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

• با افزایش تعداد ماژول ها، پیچیدگی ارتباط درون ماژول ها نیز افزایش می یابد.
• شاید شاهد یک تضاد در چارچوب های UI باشیم.

بهترین روش ها برای مهاجرت:

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

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

 

Hybrid Cloud گامی برای Microservices است
ابر هیبریدی چیزی نیست جز یک راه اندازی یا محیط رایانش ابری که در درجه اول از ترکیبی از ابرهای خصوصی و ابرهای داخلی در ارتباط با خدمات ابری عمومی استفاده می کند.

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

اکنون، بیایید درک کنیم که چگونه راه‌اندازی محیط ابری ترکیبی به پیاده‌سازی Microservices کمک می‌کند:

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

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

یکی از بهترین نمونه ها ظروف است. مفهوم کانتینر به طور گسترده در معماری میکروسرویس استفاده می شود. هر زمان که نیاز باشد، می توان کانتینرها را به صورت خودکار ایجاد یا از بین برد

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

از طرف دیگر، اگر تقاضای کاهشی برای بار روی برنامه وجود داشته باشد، کانتینرهای مربوطه از بین می روند تا همیشه استفاده موثر از منابع حفظ شود.

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

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

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

نگاشت لایه ها به بارهای کاری Cloud-Native
طبق استانداردها، یک برنامه بومی ابری بر اساس عملکرد و استقرار بر روی لایه های منطقی مختلف ساخته شده است. هر لایه دارای میکروسرویس هایی است که در نهایت وظایف خود را انجام می دهند.

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

لایه های مختلف موجود و موارد استفاده از آنها در زیر لیست شده است:

• لایه مقیاس پذیر
• لایه بادوام
• لایه قابل موازی سازی
• لایه رویداد محور
• لایه میراث

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

2. لایه بادوام
در این لایه، هر سرویس یک پایگاه داده ایده آل را انتخاب می کند که در آن داده های ساخت یافته ذخیره می شود. به این نوع سرویس ها سرویس های حالت دار گفته می شود که در آن API های سطح بالا در معرض دید قرار می گیرند.

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

4. لایه رویداد محور
در لایه رویداد محور، کد به شکل کانتینر بسته بندی نمی شود. بنابراین، به جای استفاده از کانتینرها، توابع در زبان های برنامه نویسی مانند Python و Node.Js نوشته می شوند. هنگامی که این توابع در زبان های برنامه نویسی ذکر شده در بالا نوشته می شوند، مستقیماً مستقر می شوند.

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

5. لایه میراث
اکثر برنامه های یکپارچه مبتنی بر لایه های قدیمی هستند. به عنوان مثال، تمام برنامه های مدیریت ارتباط با مشتری (CRM)، برنامه ریزی منابع سازمانی (ERP)، مدیریت زنجیره تامین (SCM) و منابع انسانی (HR)

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

 

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

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

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

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

 

نتیجه:

در این مقاله Cloud Native Microservices، چندین مفهوم از مؤلفه‌های معماری میکروسرویس‌ها را مرور کرده‌ایم که در آن روش‌های توسعه و استقرار برنامه‌های کاربردی سنتی را تغییر می‌دهند. بر اساس پایداری برنامه و الزامات ad-hoc، تیم می تواند تصمیم سازنده ای برای حرکت از معماری یکپارچه به معماری میکروسرویس بگیرد. با استفاده از استراتژی های مهاجرت، می توان بهترین رویکرد را انتخاب کرد و برای تکمیل کار کرد.

میکروسرویس با Spring Boot

Microservices سیستم ما را به اجزای کوچک مستقل تقسیم می کند. بوت فنری دارای ویژگی هایی است که برای ساخت سریع میکروسرویس ها مفید است. از طریق فنر بوت، می‌توانیم میکروسرویس‌ها را به سرعت پیکربندی کنیم. در این مقاله Microservices With Spring Boot، نحوه ساخت یک Microservices با Spring Boot و Eureka Server را با جزئیات به شما نشان خواهیم داد.

 

میکروسرویس با SpringBoot
  در ادامه به موضوعاتی می پردازیم که در این مقاله به آنها خواهیم پرداخت

• میکروسرویس چیست؟
• اصول میکروسرویس ها
• معماری میکروسرویس ها
• چرا چکمه بهاره
• ساخت میکروسرویس با چکمه فنری
•  

MicroServices چیست؟
Microservices یک رویکرد ساختاری است که برنامه را به عنوان گروهی از خدمات مستقل که در مورد یک دامنه سازمانی تشکیل شده است، می سازد. معماری میکروسرویس ها میکروسرویس ها را برای ایجاد یک سرویس بزرگ ترکیب می کند.

 

برای اطلاعات بیشتر: میکروسرویس ها و انواع میکروسرویس ها چیست؟

اصول میکروسرویس ها
1. مدل سازی شده در اطراف دامنه کسب و کار

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

2. استقرار مستقل

میکروسرویس ها مستقل از پلتفرم هستند. ما می توانیم آنها را بدون تأثیرگذاری بر سایر خدمات مستقر و طراحی کنیم.

3. شکست منفرد

هر برنامه بزرگی می‌تواند بدون تاثیر در طول شکست یک ماژول باقی بماند. ما باید شکست را به سرعت تشخیص دهیم زیرا یک سرویس در هر زمان ممکن است خراب شود.

4. اصل مسئولیت واحد

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

5. اتوماسیون زیرساخت

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

 

معماری میکروسرویس ها
در زیر نکات ضروری معماری میکروسرویس آورده شده است:

• هر میکروسرویس یک پایگاه داده جداگانه خواهد داشت.
• Client API به خدمات دسترسی نخواهد داشت. فقط می تواند با دروازه API ارتباط برقرار کند.
• ما هر سرویسی را در سرور کشف ثبت خواهیم کرد. سرور کشف حاوی اطلاعات هر میکروسرویسی است که در سیستم وجود دارد.
• سرور پیکربندی تمامی تنظیمات میکروسرویس ها را ذخیره می کند و این سرور برای دریافت اطلاعات پیکربندی مانند URL، نام میزبان و غیره برای کاربران مفید است.

 

چرا چکمه بهاره
Spring Boot امکان توسعه برنامه های آماده تولید را فراهم می کند و ویژگی های غیر کاربردی زیر را ارائه می دهد:

• به کنترل چندین مؤلفه کمک می کند.
• به تنظیم صریح اجزا کمک می کند.
• این سرورهای جاسازی شده را ارائه می دهد که پیاده سازی آنها با کانتینرها ساده است.

 

بنابراین، بیایید ببینیم که چالش های معماری Microservices چیست

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

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

 

بنابراین، برای جلوگیری از چالش‌های فوق، ما میکروسرویس‌ها را با Spring Boot می‌سازیم. بوت فنری دارای ویژگی هایی برای ساخت Microservices با حداقل تنظیمات است.

ساخت اپلیکیشن میکروسرویس با استفاده از فنر بوت
1. سرور Eureka

Eureka یک سرویس رجیستری یا سرور نامگذاری است. سرور Eureka نام هر سرویسی را می دهد. این یک خدمات بسیار مهم است زیرا:

• در سرور eureka، نیازی به کدگذاری سخت آدرس های IP میکروسرویس ها نیست.
• زمانی مفید است که سرویس‌ها از آدرس‌های IP پویا، به عنوان مثال، مقیاس‌پذیری خودکار استفاده می‌کنند.

 

بنابراین، هر سرویس باید در سرور Eureka ثبت شود و به سرور Eureka اطلاع دهد که فعال است. اگر eureka هیچ اطلاعیه ای از یک سرویس دریافت نکرد، آن سرویس در سرور eureka ثبت نشده است.

برای توسعه سرور Eureka به ابزارهای زیر نیاز داریم:

• ابزار فنری
• جاوا 8
• Eclipse IDE

 

پس از نصب ابزارهای فوق، می توانیم سرور Eureka را توسعه دهیم.

Microservices with Spring Boot: ایجاد سرور Eureka

برای ایجاد سرور Eureka، ابتدا باید پروژه "EurekaServer" را در Eclipse IDE ایجاد کنیم. برای ایجاد پروژه "Eureka Server"، "Spring Starter Project" را فشار می دهیم و پس از آن باید "Next" را فشار دهیم. می توانیم پروژه Spring Starter را با هر نامی نام گذاری کنیم.

2. سرویس تصویر

Eureka Client Service یک سرویس مستقل در معماری میکروسرویس است. سرویس مشتری می تواند حساب، پرداخت، تأیید اعتبار، اعلان، پیکربندی و غیره باشد. سرویس تصویر یک منبع داده برای تصاویر است و هر تصویر دارای عنوان، شناسه، URL و غیره است. 

3. خدمات گالری

سرویس Eureka Client همچنین به عنوان REST Client شناخته می شود که خدمات REST API (سایر خدمات) را در برنامه میکروسرویس فراخوانی می کند. بنابراین، به عنوان مثال، سرویس گالری، سرویس تصویر را برای دریافت گروهی از تصاویر، یا فقط تصاویری که در یک سال خاص تولید می کنیم، فراخوانی می کند.

4. سرویس احراز هویت (Auth).

گردش کار احراز هویت به شرح زیر است:

• مشتری اعتبار خود را برای درخواست توکن ارسال می کند.
• سرور اعتبارنامه ها را تأیید می کند و یک توکن برمی گرداند.
• برای هر درخواست، کاربر یک نشانه ارائه می کند و سرور آن توکن را تأیید می کند.

 

برای تایید اعتبار کاربری و صدور توکن ها، سرویس جدیدی به نام “Auth Service” راه اندازی می کنیم. Gateway از سرویس auth برای اعتبار سنجی توکن ها استفاده می کند.

 

نتیجه
ساخت میکروسرویس با بوت فنری به کاربران کمک می کند تا از میکروسرویس ها به نحو احسن استفاده کنند. بوت فنری باعث می شود که میکروسرویس ها با حداقل پیکربندی با هم کار کنند. امیدوارم این مقاله اطلاعات مورد نیاز در مورد توسعه Microservices با Spring Boot را در اختیار شما قرار دهد.

 

امنیت در میکروسرویس ها

میکروسرویس ها آینده برنامه های توسعه یافته برای ابر هستند. غول تحقیقاتی IDC پیش‌بینی می‌کند که تقریباً 90 درصد از برنامه‌های جدید که تا سال 2022 مستقر شده‌اند، دارای معماری‌های مبتنی بر میکروسرویس‌ها خواهند بود. مزایای اصلی میکروسرویس ها، بهبود توانایی طراحی، اشکال زدایی، به روز رسانی و استفاده از کدهای شخص ثالث است.

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

 

امنیت میکروسرویس ها
این مقاله امنیت در میکروسرویس ها بهترین الگوهای امنیتی و بهترین روش ها برای تضمین امنیت در میکروسرویس ها را فهرست می کند.

  در ادامه به موضوعاتی می پردازیم که در این مقاله به آنها خواهیم پرداخت

• میکروسرویس چیست؟
• امنیت در میکروسرویس ها
• بهترین شیوه ها و الگوهای امنیت در معماری میکروسرویس ها

 

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

میکروسرویس چیست؟
Microservices یا Microservices Architecture یک سبک معماری است که یک مدل یکپارچه سنتی را به سرویس‌های مستقل و توزیع‌شده تقسیم می‌کند که می‌توانند به صورت جداگانه استقرار و مقیاس شوند. هر سرویس در سراسر قابلیت های تجاری سازماندهی شده و به صورت جداگانه توسط ماشین آلات استقرار کاملاً خودکار قابل استقرار است.

 

امنیت در میکروسرویس ها
رویکرد Microservices توسعه یک برنامه واحد به عنوان مجموعه‌ای از سرویس‌ها است که هر کدام فرآیند خاص خود را اجرا می‌کنند و با مکانیسم‌های سبک، که به طور منظم یک API منبع HTTP است، تعامل دارند. برنامه های کاربردی ساخته شده بر اساس معماری مبتنی بر میکروسرویس ها پیچیده هستند و به دلیل ماهیت ماژولار خود دارای چندین آسیب پذیری منحصر به فرد هستند. آنها نسبت به مدل های کاربردی سنتی مساحت سطح حمله بسیار بیشتری دارند.

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

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

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

 

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

 

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

#1. با طراحی ایمن باشید
اولین قدم برای ایمن سازی یک راه حل مبتنی بر میکروسرویس، اطمینان از گنجاندن امنیت در طراحی است. Secure by design به معنای ایجاد امنیت در طراحی نرم افزار شما از طراحی است.

برخی از اصول اساسی برای همه طرح ها عبارتند از:

• همه درخواست های دسترسی را تأیید اعتبار کنید
• رمزگذاری تمام ارتباطات (با استفاده از امنیت لایه انتقال یا HTTPS)
• از ابزار DevSecOps برای اسکن کدها در معماری های میکروسرویس استفاده کنید
• از گواهی کدهای سخت، رمز عبور یا هر نوع محرمانه ای در کد خودداری کنید
• API ها را تعریف کنید

اقدامات امنیتی نیاز به این نوع اقدامات احتیاطی در سطح طراحی دارند.

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

ردیابی وابستگی های شخص ثالث برای ردیابی و اصلاح آسیب پذیری های امنیتی در اسرع وقت بسیار مهم است.

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

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

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

مزیت دیگر استفاده از دروازه‌های API، مدیریت خدمات فراخوانی فرامین خارجی است که سرویس‌های Fail-over و سایر خدمات متعادل کننده بار را ارائه می‌دهد. همچنین گزارش‌گیری را فراهم می‌کند و یک سرویس اطلاعات امنیتی و مدیریت رویداد/مرکز عملیات امنیتی (SIEM/SOC) را قادر می‌سازد تا برنامه‌ها را نظارت کند و رفتارهای غیرمنتظره را پیدا کند.

#4. انزوا
جداسازی اصل کلیدی میکروسرویس ها است. هر سرویس باید یک قطعه مستقل از برنامه کلی باشد. یک میکروسرویس بدون تأثیر بر سایر سرویس‌های اطراف خود، مستقر، مدیریت و مقیاس می‌شود.

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

#5. نشانه های دسترسی و هویت کاربر
اکثر برنامه های کاربردی امروزه برخی از سطوح کنترل دسترسی و مدیریت مجوز را انجام می دهند. کارشناسان صنعت OAuth/OAuth2 را به عنوان استاندارد مجوز کاربر پیشنهاد می کنند. هنگام استفاده از این، برنامه از کاربران می‌خواهد تا برنامه‌های شخص ثالث را مجاز کنند، از اطلاعات مورد نیاز استفاده کنند و یک توکن برای آن ایجاد کنند. به طور کلی، یک کد مجوز برای درخواست رمز استفاده می شود تا اطمینان حاصل شود که URL بازگشت به تماس کاربر به سرقت نرود.

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

#6. از دفاع در رویکرد عمقی استفاده کنید
یکی از حیاتی ترین استراتژی هایی که باید اتخاذ شود، رویکرد دفاعی در عمق است. باور داشتن یک دیوار آتش در محیط شبکه شما از نرم افزار شما محافظت می کند یک تصور اشتباه بزرگ است. رویکرد دفاع در عمق به عنوان یک مفهوم تضمین اطلاعات تعریف می شود که در آن کنترل های امنیتی لایه های مختلف از طریق سیستم های نرم افزاری سازمان اضافه می شود. در زمینه میکروسرویس‌ها، سرویس‌هایی که حساس‌ترین داده‌ها را دارند، خدماتی هستند که به لایه‌های حفاظتی متعددی نیاز دارند. مهاجم نمی تواند با یک بار تلاش امنیت را بشکند و باید به جلو برود و تمام مکانیسم دفاعی لایه را بشکند.

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

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

برخی از آنها DAST (تست امنیت برنامه کاربردی پویا)، SAST (تست امنیت برنامه استاتیک)، SCA (ابزار تجزیه و تحلیل ترکیب نرم افزار) و RASP (محافظت از خود برنامه در زمان اجرا) در خطوط لوله DevSecOps شما هستند.

#8. امنیت کانتینر
امنیت کانتینر در محیط‌های بومی ابری که میکروسرویس‌ها در آن قرار دارند بسیار مهم است. خطرات امنیتی کانتینر می تواند تصاویر کانتینر، رجیستری ها، ارکستراسیون، سیستم عامل میزبان و موارد دیگر را در معرض خطر قرار دهد.

1.تصاویر
در محیط کانتینر، تصاویر برنامه آسیب پذیرترین مناطق هستند. آنها شامل تصاویر قدیمی، برنامه های دارای اشکال، تصاویر با پیکربندی ضعیف و نسخه های نرم افزار ناامن هستند. شما باید ظروف شخص ثالثی را که استفاده می‌کنید گسترش دهید که دارای خط‌مشی‌های مناسب باشند تا مطمئن شوید که تصاویر را به‌طور مرتب بازخوانی و بازبینی می‌کنند.

2.تنظیم و ارکستراسیون
حفظ تصاویری که استفاده می کنید و نحوه ارتباط آنها بسیار مهم است. بنابراین، برای مدیریت کنترل دسترسی، روش‌های احراز هویت مؤثر مانند احراز هویت چند عاملی را بر روی حساب‌های مدیریتی در کلستر پیاده‌سازی کنید.

3.ثبت
رجیستری بخش کلیدی کشف سرویس است. رجیستری باید تحت نظارت مستمر قرار گیرد تا اطمینان حاصل شود که تمام تصاویر قدیمی که خطرات را دارند واضح هستند.

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

 

جمع بندی:

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

 

آموزش قدم به قدم میکروسرویس ها

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

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

• معماری یکپارچه
• چالش های معماری یکپارچه
• میکروسرویس چیست؟
• اصول میکروسرویس ها
• معماری یکپارچه در مقابل میکروسرویس
• انواع میکروسرویس ها
• مزایا و معایب میکروسرویس ها
• چارچوب های میکروسرویس جاوا
• ابزارهای میکروسرویس
• بهترین شیوه های میکروسرویس ها

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

 

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

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

 

مدل سرور مشتری

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

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

 

همچنین، چندین چالش دیگر با معماری یکپارچه وجود دارد. حالا یک به یک آنها را بررسی می کنیم:

چالش های معماری یکپارچه (معایب)

• چابکی - معماری یکپارچه می تواند تغییرات جدید برنامه را با چابکی کمتر در خود جای دهد. توسعه دهندگان باید برای هر تغییر جزئی همه چیز را بسازند.
• مقیاس ناپذیر - مقیاس پذیری چیزی نیست جز قابلیت یک سیستم/برنامه برای مدیریت بهتر رشد کار. بیایید فرض کنیم که یک برنامه تجارت الکترونیک در حال جذب مشتری زیادی است و می‌خواهد برنامه را مقیاس‌بندی کند تا مشتریان جدید بیشتری به دست آورد.
• توسعه دهندگان نمی توانند برنامه را به طور همزمان مقیاس کنند. هر زمان که یک ویژگی جدید باید اضافه یا به روز شود، آنها باید نمونه های جدیدی از برنامه را ایجاد کنند. همچنین، ماژول های مختلف نیازهای منابع متناقضی دارند.
• تحمل خطا - یک اشکال در هر ماژول به طور بالقوه می تواند کل فرآیند را از بین ببرد. بر در دسترس بودن برنامه ها تأثیر می گذارد.
• فن آوری های ترکیبی - برنامه های کاربردی یکپارچه مانعی برای پذیرش فناوری های جدید دارند. از آنجایی که تغییرات در فریمورک ها یا برنامه نویسی کل برنامه را تحت تاثیر قرار می دهد، هزینه بالایی دارد.
• بلوک های توسعه مداوم - همه ویژگی های برنامه را نمی توان به طور همزمان ساخته و اجرا کرد.
• توسعه آهسته - توسعه در برنامه های یکپارچه کند است زیرا هر ویژگی باید یکی پس از دیگری ساخته شود.

 

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

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

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

 

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

• معماری میکروسرویس‌ها شامل سرویس‌های کوچک و مستقلی است که هر کدام مستقل هستند و یک قابلیت تجاری واحد را پیاده‌سازی می‌کنند. همه این سرویس‌ها دارای محیط‌های اجرایی و متعادل‌کننده‌های بار برای انجام عملکردهای مختلف و گرفتن داده‌هایشان هستند. آنها از طریق گذرگاه HTTP REST/Message برای انجام اتوماسیون و قابلیت های نظارت با یکدیگر ارتباط برقرار می کنند. دروازه API به عنوان یک ارتباط دهنده برای انتقال درخواست مشتری به معماری داخلی عمل می کند.
• بیایید عملکردهای این اجزا را یک به یک درک کنیم:
• مشتریان - کاربران مختلف درخواست ها را از دستگاه های مختلف ارسال می کنند.
• Identity Providers - درخواست های مشتری توسط ارائه دهندگان هویت احراز هویت می شوند و سپس به API Gateway ارسال می شوند.
• API Gateway - درخواست های مشتری را مدیریت می کند.
• فرمت های پیام - آنها از طریق دو نوع پیام همزمان و ناهمزمان ارتباط برقرار می کنند.
• مدیریت داده ها - هر میکروسرویس دارای یک پایگاه داده خصوصی برای گرفتن داده های خود و اجرای عملکردهای تجاری مربوطه است. همچنین پایگاه داده های Microservices فقط از طریق سرویس API خود به روز می شوند.
• محتوای ثابت - تمام محتوای سیستم را در خود جای می دهد.
• مدیریت - این مؤلفه مسئول متعادل کردن سرویس ها در گره ها و شناسایی خرابی ها است.
• کشف سرویس - این جزء به عنوان یک راهنما برای یافتن مسیر ارتباط بین میکروسرویس ها عمل می کند.
• شبکه های تحویل محتوا - محتوا را به کاربران نهایی توزیع شده ارائه می دهد.
• سرویس از راه دور - روشی پویا، مستقل از حمل و نقل و مدولار برای نمایش ریزسرویس ها ارائه می دهد.

 

نمونه معماری میکروسرویس ها
برنامه تجارت الکترونیک با معماری Microservices

در معماری یکپارچه، همه اجزا در یک ماژول ادغام می شوند. اما، در معماری Microservices، آنها به ماژول های فردی (microservice) گسترش می یابند.

در اینجا، هر ویژگی (پیشنهاد، جدید، سبد خرید، خدمات مشتری و غیره) با یک میکروسرویس متفاوت تخصیص داده می‌شود، داده‌های آن‌ها را مدیریت می‌کند و سایر عملکردها را انجام می‌دهد. هر میکروسرویس روی یک قابلیت تجاری متمرکز است. از طریق آن، می‌توانیم هر زمان که نیاز باشد ویژگی‌های فردی را بدون تأثیر بر عملکرد کل برنامه، مستقر کنیم.

این واحدهای منفرد قابل استقرار از طریق یک رابط کاملاً تعریف شده به نام REST یا گذرگاه پیام با یکدیگر ارتباط برقرار می کنند.

 

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

• اصل مسئولیت واحد - بیان می کند که هر کلاس یا ماژول در میکروسرویس ها باید یک مسئولیت واحد داشته باشد. داشتن مسئولیت های متعدد منجر به اتصال محکم می شود و منجر به طرح های شکننده می شود که به سختی تکامل می یابند و می توانند با تغییر به راه های غیرمنتظره تبدیل شوند.
• اتصال شل - وابستگی بین سرویس ها از طریق اتصال شل به حداقل می رسد.
• تحمل خطا - میکروسرویس ها لزوماً مقاوم به خطا ساخته می شوند تا خرابی در سمت سرویس های همکار آن تأثیر کمتری بر SLA خود داشته باشد.
• اتوماسیون زیرساخت - در رویکرد میکروسرویس، هر سرویس با تعبیه همه وابستگی ها و اجرا به صورت مستقل ساخته می شود.
• استقرار - میکروسرویس ها پلتفرم آگنوستیک هستند. این بدان معناست که سرویس ها به طور مستقل بدون تأثیرگذاری بر دیگران طراحی و اجرا می شوند.

 

انواع میکروسرویس ها
میکروسرویس ها دو نوع هستند:

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

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

این در مورد انواع میکروسرویس ها است. از آنجایی که هر الگوی معماری مزایا و معایب خود را دارد، اکنون لازم است قبل از اتخاذ آن، مزایا و معایب Microservice را بدانید.

 

مزایا و معایب میکروسرویس ها
مزایای میکروسرویس ها
مزایای Microservices به اندازه کافی قوی است که برخی از بازیکنان بزرگ مانند Netflix، eBay و غیره را متقاعد کند که این روش را اتخاذ کنند. بیایید یک به یک آنها را مورد بحث قرار دهیم:

1. میکروسرویس ها به راحتی مقیاس پذیر هستند.

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

2. میکروسرویس ها از طریق جداسازی خطا، زمان خرابی را کاهش می دهند.

برنامه‌های بزرگ می‌توانند برای خرابی یک ماژول بی‌تأثیر باقی بمانند.

3. استقرار کوچکتر و سریعتر

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

4. سهولت درک

با سادگی بیشتر، توسعه دهندگان می توانند به راحتی عملکرد یک سرویس را درک کنند.

 

معایب میکروسرویس ها
میکروسرویس ها چند معایب دارند. برخی از آنها به شرح زیر است:

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

چارچوب های میکروسرویس جاوا
چندین فریمورک میکروسرویس وجود دارد که می توانید برای توسعه جاوا از آنها استفاده کنید. برخی از محبوب ترین آنها در زیر ذکر شده است:

1. چکمه فنری
Spring Boot فریم ورک پیشرو برای ساخت اپلیکیشن های میکروسرویس در جاوا است. این برنامه در بالای زبان ها برای وارونگی کنترل، برنامه نویسی جنبه گرا و غیره کار می کند. Spring Boot یک چارچوب بالغ، منبع باز و غنی از ویژگی ها با مستندات عالی و یک جامعه گسترده است. پروژه های بوت بهار شامل پلتفرم IO، Cloud، Framework، Security، Batch، Data، REST Docs و غیره است.

2. Dropwizard
Dropwizard یک چارچوب منبع باز محبوب است که برای توسعه سریع خدمات وب RESTful استفاده می شود. این چارچوب کتابخانه‌های جاوا بالغ و پایدار را در یک پلتفرم کاملاً کاربردی ادغام می‌کند: Jersey برای REST، Jetty برای HTTP، و Jackson برای JSON، FreeMarker، Mustache و غیره.

ما می توانیم Dropwizard را با استفاده از Maven با افزودن آخرین نسخه به POM راه اندازی کنیم.

علاوه بر این، برای توسعه برنامه های کاربردی میکروسرویس دارای عملکرد بالا و دوستی عملیات است. برنامه‌های Dropwizard مانند Spring Boot در فایل‌های JAR با سرور برنامه Jetty قرار می‌گیرند.

3. جرسی
Jersey یک چارچوب منبع باز است که برای توسعه خدمات وب RESTful در جاوا استفاده می شود که از پیاده سازی API های JAX-RS پشتیبانی می کند. بهترین چیز در مورد جرسی این است که مستندات استثنایی همراه با مثال دارد.

4. میکرونورد
این یک فریم ورک میکروسرویس مدرن و مبتنی بر JVM است که برای ساخت برنامه‌های میکروسرویس ماژولار به راحتی قابل آزمایش است. تمام ابزارهای مورد نیاز برای ساخت اپلیکیشن های میکروسرویس با امکانات کامل را فراهم می کند. از Kubernetes، کشف سرویس، ردیابی توزیع شده و توابع بدون سرور پشتیبانی می کند.

5. AxonIQ
این یک چارچوب میکروسرویس جاوا است که برای ساخت معماری میکروسرویس ها مطابق با اصول طراحی دامنه محور (DDD) استفاده می شود. همچنین به شما امکان می دهد الگوهای میکروسرویس مانند معماری رویداد محور و Command-Query-Responsibility-Segregation (CQRS) را پیاده سازی کنید.

در حال حاضر، شما با فریمورک های میکروسرویس جاوا که اغلب استفاده می شود آشنا شده اید. در مرحله بعد، اجازه دهید به جلو برویم و در مورد ابزارهای مختلف مورد استفاده در هنگام توسعه برنامه های کاربردی در معماری Microservices بیاموزیم.

 

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

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

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

3. AWS Lambda
این ابزار AWS Lamda از سرورهای بدون زیرساخت برای ساخت‌های میکروسرویس‌ها و کاربرانی که با نرخ پرداخت به ازای استفاده دریافت می‌کنند، پشتیبانی می‌کند. بیشتر، ما از این ابزار برای میزبانی خدمات REST یا API در ترکیب با دروازه API AWS استفاده می کنیم.

4. پرومتئوس
Prometheus یک ابزار نظارتی است که برای شناسایی الگوهای عجیب و غریب Microservices استفاده می شود.

5. Logstash
Logstash یک ابزار منبع باز است که برای بررسی گزارش ها استفاده می شود. این به شما امکان می دهد داده های میکروسرویس ها را ذخیره، متمرکز و تبدیل کنید.

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

7. آپاچی کافکا
آپاچی کافکا یک پلت فرم پردازش جریان توزیع شده است که برای پردازش داده یا تماس های API استفاده می شود.

 

در نهایت، در این مقاله آموزشی Microservices، بهترین روش‌ها برای طراحی میکروسرویس‌ها را مورد بحث قرار می‌دهیم.

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

در اینجا بهترین روش ها برای طراحی معماری میکروسرویس ها آمده است:

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

نتیجه

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

امیدواریم مقاله مفید و آموزنده بوده باشد.