نوشته های Ehsan

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

Ehsan — Sun, 12 Feb 2023 15:03:57 +0330

اولین گام برای استفاده از گذرگاه رویداد، اشتراک میکروسرویس ها برای رویدادهایی است که می خواهند دریافت کنند. این عملکرد باید در میکروسرویس های گیرنده انجام شود.کد ساده زیر نشان می‌دهد که هر میکروسرویس گیرنده باید چه چیزی را هنگام راه‌اندازی سرویس (یعنی در کلاس Startup) پیاده‌سازی کند تا در رویدادهایی که نیاز دارد مشترک شود. در این مورد، میکروسرویس basket-api باید در ProductPriceChangedIntegrationEvent و پیام‌های OrderStartedIntegrationEvent مشترک شود.به عنوان مثال، هنگام اشتراک در رویداد ProductPriceChangedIntegrationEvent، میکروسرویس سبد را از هرگونه تغییر در قیمت محصول آگاه می‌کند و به کاربر اجازه می‌دهد در صورت وجود آن محصول در سبد کاربر، درباره تغییر هشدار دهد.var eventBus = app.ApplicationServices.GetRequiredService();eventBus.Subscribe();eventBus.Subscribe();پس از اجرای این کد، میکروسرویس مشترک از طریق کانال های RabbitMQ گوش می دهد. هنگامی که هر پیامی از نوع ProductPriceChangedIntegrationEvent می رسد، کد کنترل کننده رویداد را که به آن ارسال می شود فراخوانی می کند و رویداد را پردازش می کند.انتشار رویدادها از طریق اتوبوس رویداددر نهایت، فرستنده پیام (میکروسرویس مبدا) رویدادهای یکپارچه سازی را با کدی شبیه به مثال زیر منتشر می کند. (این رویکرد یک مثال ساده شده است که اتمی را در نظر نمی گیرد.) هر زمان که یک رویداد باید در چندین میکروسرویس منتشر شود، معمولاً بلافاصله پس از انجام داده ها یا تراکنش ها از میکروسرویس مبدا، کد مشابهی را پیاده سازی می کنید.ابتدا، شی پیاده سازی گذرگاه رویداد (بر اساس RabbitMQ یا بر اساس یک گذرگاه سرویس) مانند کد زیر به سازنده کنترلر تزریق می شود:[Route("api/v1/[controller]")]public class CatalogController : ControllerBase{ private readonly CatalogContext _context; private readonly IOptionsSnapshot _settings; private readonly IEventBus _eventBus; public CatalogController(CatalogContext context, IOptionsSnapshot settings, IEventBus eventBus) { _context = context; _settings = settings; _eventBus = eventBus; } // ...}سپس آن را از روش های کنترلر خود استفاده می کنید، مانند روش UpdateProduct:[Route("items")][HttpPost]public async Task UpdateProduct([FromBody]CatalogItem product){ var item = await _context.CatalogItems.SingleOrDefaultAsync( i => i.Id == product.Id); // ... if (item.Price != product.Price) { var oldPrice = item.Price; item.Price = product.Price; _context.CatalogItems.Update(item); var @event = new ProductPriceChangedIntegrationEvent(item.Id, item.Price, oldPrice); // Commit changes in original transaction await _context.SaveChangesAsync(); // Publish integration event to the event bus // (RabbitMQ or a service bus underneath) _eventBus.Publish(@event); // ... } // ...}در این مورد، از آنجایی که میکروسرویس مبدا یک میکروسرویس ساده CRUD است، آن کد مستقیماً در یک کنترلر Web API قرار می گیرد.در میکروسرویس های پیشرفته تر، مانند زمانی که از رویکردهای CQRS استفاده می شود، می توان آن را در کلاس CommandHandler، در متد Handle() پیاده سازی کرد.طراحی اتمی و انعطاف پذیری هنگام انتشار در اتوبوس رویدادهنگامی که رویدادهای یکپارچه سازی را از طریق یک سیستم پیام رسانی توزیع شده مانند گذرگاه رویداد خود منتشر می کنید، با مشکل به روز رسانی اتمی پایگاه داده اصلی و انتشار یک رویداد مواجه می شوید (یعنی یا هر دو عملیات کامل می شوند یا هیچ کدام از آنها انجام نمی شود). به عنوان مثال، در مثال ساده‌شده‌ای، زمانی که قیمت محصول تغییر می‌کند، کد داده‌ها را به پایگاه داده ارسال می‌کند و سپس پیام ProductPriceChangedIntegrationEvent را منتشر می‌کند. در ابتدا، ممکن است ضروری به نظر برسد که این دو عملیات به صورت اتمی انجام شوند. با این حال، اگر از یک تراکنش توزیع‌شده شامل پایگاه داده و کارگزار پیام استفاده می‌کنید، همانطور که در سیستم‌های قدیمی‌تر مانند صف‌بندی پیام‌های مایکروسافت (MSMQ) انجام می‌دهید، این رویکرد به دلایلی که در قضیه CAP توضیح داده شده است، توصیه نمی‌شود.اساسا، شما از میکروسرویس ها برای ساختن سیستم های مقیاس پذیر و بسیار در دسترس استفاده می کنید. تا حدودی ساده تر، قضیه CAP می گوید که شما نمی توانید یک پایگاه داده (توزیع شده) (یا یک میکروسرویس که مدل آن را در اختیار دارد) بسازید که به طور مداوم در دسترس، به شدت سازگار و قابل تحمل برای هر پارتیشنی باشد. شما باید دو مورد از این سه ملک را انتخاب کنید.در معماری‌های مبتنی بر ریزسرویس‌ها، شما باید در دسترس بودن و تحمل را انتخاب کنید و باید بر ثبات قوی بی‌تأکید کنید. بنابراین، در اکثر برنامه‌های کاربردی مبتنی بر میکروسرویس مدرن، معمولاً نمی‌خواهید از تراکنش‌های توزیع‌شده در پیام‌رسانی استفاده کنید، مانند زمانی که تراکنش‌های توزیع‌شده را بر اساس هماهنگ‌کننده تراکنش توزیع‌شده ویندوز (DTC) با MSMQ پیاده‌سازی می‌کنید.به موضوع اولیه و مثال آن برگردیم. اگر سرویس پس از به‌روزرسانی پایگاه داده از کار بیفتد (در این مورد، درست بعد از خط کد با _context.SaveChangesAsync())، اما قبل از انتشار رویداد یکپارچه‌سازی، سیستم کلی ممکن است ناسازگار شود. این رویکرد بسته به عملیات تجاری خاصی که با آن سروکار دارید، ممکن است برای کسب و کار حیاتی باشد.همانطور که قبلا در بخش معماری ذکر شد، می توانید چندین رویکرد برای مقابله با این موضوع داشته باشید:با استفاده از الگوی کامل رویداد منبع یابی.استفاده از استخراج لاگ تراکنشبا استفاده از الگوی صندوق خروجی این یک جدول تراکنشی برای ذخیره رویدادهای ادغام (توسعه تراکنش محلی) است.برای این سناریو، استفاده از الگوی کامل رویداد منبع یابی (ES) یکی از بهترین رویکردها است، اگر بهترین نباشد. با این حال، در بسیاری از سناریوهای برنامه، ممکن است نتوانید یک سیستم کامل ES را پیاده سازی کنید. ES به این معنی است که به جای ذخیره داده های وضعیت فعلی، فقط رویدادهای دامنه را در پایگاه داده تراکنشی خود ذخیره کنید. ذخیره فقط رویدادهای دامنه می تواند مزایای بزرگی داشته باشد، مانند داشتن تاریخچه سیستم شما و توانایی تعیین وضعیت سیستم خود در هر لحظه از گذشته. با این حال، پیاده سازی یک سیستم کامل ES مستلزم آن است که بیشتر سیستم خود را مجدداً معماری کنید و بسیاری از پیچیدگی ها و الزامات دیگر را معرفی کنید. به عنوان مثال، می‌خواهید از پایگاه داده‌ای که به‌طور خاص برای منبع‌یابی رویدادها ساخته شده است، مانند فروشگاه رویداد، یا پایگاه‌داده‌ای سند محور مانند Azure Cosmos DB، MongoDB، Cassandra، CouchDB یا RavenDB استفاده کنید. ES یک روش عالی برای این مشکل است، اما ساده ترین راه حل نیست، مگر اینکه قبلاً با منبع یابی رویداد آشنا باشید.گزینه استفاده از استخراج گزارش تراکنش در ابتدا شفاف به نظر می رسد. با این حال، برای استفاده از این رویکرد، میکروسرویس باید با گزارش تراکنش RDBMS شما، مانند گزارش تراکنش SQL Server، کوپل شود. این رویکرد احتمالاً مطلوب نیست. اشکال دیگر این است که به‌روزرسانی‌های سطح پایین ثبت‌شده در گزارش تراکنش ممکن است در سطح رویدادهای یکپارچه‌سازی سطح بالا شما نباشند. اگر چنین است، فرآیند مهندسی معکوس آن عملیات گزارش تراکنش می تواند دشوار باشد.یک رویکرد متعادل ترکیبی از جدول پایگاه داده تراکنشی و یک الگوی ES ساده شده است. می‌توانید از حالتی مانند «آماده برای انتشار رویداد» استفاده کنید که در رویداد اصلی وقتی آن را به جدول رویدادهای یکپارچه‌سازی متعهد می‌کنید، تنظیم می‌کنید. سپس سعی کنید رویداد را در اتوبوس رویداد منتشر کنید. اگر اقدام انتشار-رویداد با موفقیت انجام شود، تراکنش دیگری را در سرویس مبدا شروع می‌کنید و وضعیت را از «آماده برای انتشار رویداد» به «رویداد قبلاً منتشر شده» منتقل می‌کنید.اگر اقدام انتشار-رویداد در گذرگاه رویداد ناموفق باشد، داده‌ها همچنان در ریزسرویس مبدا متناقض نخواهند بود - همچنان به‌عنوان «آماده برای انتشار رویداد» علامت‌گذاری می‌شود و با توجه به بقیه سرویس‌ها، در نهایت انجام می‌شود. مقاوم باش. همیشه می توانید کارهای پس زمینه ای داشته باشید که وضعیت تراکنش ها یا رویدادهای یکپارچه سازی را بررسی می کنند. اگر شغل رویدادی را در وضعیت «آماده انتشار رویداد» بیابد، می‌تواند سعی کند آن رویداد را در اتوبوس رویداد منتشر کند.اگر اقدام انتشار-رویداد در گذرگاه رویداد ناموفق باشد، داده‌ها همچنان در ریزسرویس مبدا متناقض نخواهند بود - همچنان به‌عنوان «آماده برای انتشار رویداد» علامت‌گذاری می‌شود و با توجه به بقیه سرویس‌ها، در نهایت انجام می‌شود. مقاوم باش. همیشه می توانید کارهای پس زمینه ای داشته باشید که وضعیت تراکنش ها یا رویدادهای یکپارچه سازی را بررسی می کنند. اگر شغل رویدادی را در وضعیت «آماده انتشار رویداد» بیابد، می‌تواند سعی کند آن رویداد را در اتوبوس رویداد منتشر کند.توجه داشته باشید که با این رویکرد، شما فقط رویدادهای یکپارچه‌سازی را برای هر میکروسرویس مبدا ادامه می‌دهید، و فقط رویدادهایی را که می‌خواهید با سایر ریزسرویس‌ها یا سیستم‌های خارجی ارتباط برقرار کنید. در مقابل، در یک سیستم کامل ES، شما تمام رویدادهای دامنه را نیز ذخیره می کنید.بنابراین، این رویکرد متعادل یک سیستم ES ساده شده است. شما به فهرستی از رویدادهای ادغام با وضعیت فعلی آنها نیاز دارید ("آماده برای انتشار" در مقابل "منتشر شده"). اما شما فقط باید این حالت ها را برای رویدادهای ادغام اجرا کنید. و در این رویکرد، مانند یک سیستم ES کامل، نیازی به ذخیره تمام داده های دامنه خود به عنوان رویداد در پایگاه داده تراکنش ندارید.اگر قبلاً از یک پایگاه داده رابطه‌ای استفاده می‌کنید، می‌توانید از جدول تراکنشی برای ذخیره رویدادهای ادغام استفاده کنید. برای دستیابی به اتمی در برنامه خود، از یک فرآیند دو مرحله ای مبتنی بر تراکنش های محلی استفاده می کنید. اساسا، شما یک جدول IntegrationEvent در همان پایگاه داده ای که موجودیت های دامنه خود را دارید دارید. آن جدول به عنوان بیمه ای برای دستیابی به اتمی عمل می کند، به طوری که شما رویدادهای یکپارچه سازی مداوم را در همان تراکنش هایی که داده های دامنه شما را متعهد می کنند، قرار دهید.مرحله به مرحله، روند به این صورت پیش می رود:برنامه یک تراکنش پایگاه داده محلی را آغاز می کند.سپس وضعیت موجودیت های دامنه شما را به روز می کند و یک رویداد را در جدول رویداد یکپارچه سازی درج می کند.در نهایت، تراکنش را انجام می دهد، بنابراین شما اتمی مورد نظر را دریافت می کنید و سپسشما رویداد را به نحوی منتشر می کنید.هنگام اجرای مراحل انتشار رویدادها، این انتخاب ها را دارید:رویداد ادغام را بلافاصله پس از انجام تراکنش منتشر کنید و از تراکنش محلی دیگری برای علامت گذاری رویدادها در جدول به عنوان منتشر شده استفاده کنید. سپس، از جدول فقط به عنوان یک مصنوع برای ردیابی رویدادهای یکپارچه سازی در صورت بروز مشکلات در میکروسرویس های راه دور استفاده کنید و اقدامات جبرانی را بر اساس رویدادهای یکپارچه سازی ذخیره شده انجام دهید.از جدول به عنوان نوعی صف استفاده کنید. یک رشته یا فرآیند برنامه جداگانه جدول رویداد ادغام را پرس و جو می کند، رویدادها را در گذرگاه رویداد منتشر می کند و سپس از یک تراکنش محلی برای علامت گذاری رویدادها به عنوان منتشر شده استفاده می کند.برای سادگی، نمونه eShopOnContainers از رویکرد اول (بدون فرآیندهای اضافی یا ریزسرویس‌های جستجوگر) به همراه گذرگاه رویداد استفاده می‌کند. با این حال، نمونه eShopOnContainers همه موارد خرابی احتمالی را مدیریت نمی کند. در یک برنامه واقعی که در فضای ابری مستقر شده است، باید این واقعیت را بپذیرید که در نهایت مشکلاتی به وجود می آیند و باید منطق بررسی و ارسال مجدد را اجرا کنید. استفاده از جدول به عنوان یک صف می تواند موثرتر از رویکرد اول باشد، اگر آن جدول را به عنوان منبع واحد رویدادها در هنگام انتشار آنها (با کارگر) از طریق اتوبوس رویداد داشته باشید.پیاده سازی اتمی در هنگام انتشار رویدادهای یکپارچه سازی از طریق اتوبوس رویدادکد زیر نشان می دهد که چگونه می توانید یک تراکنش منفرد شامل چندین شیء DbContext ایجاد کنید - یک زمینه مربوط به داده های اصلی در حال به روز رسانی و زمینه دوم مربوط به جدول IntegrationEventLog است.اگر اتصالات به پایگاه داده در زمان اجرای کد مشکلی داشته باشند، تراکنش در کد مثال زیر انعطاف پذیر نخواهد بود. این می تواند در سیستم های مبتنی بر ابر مانند Azure SQL DB اتفاق بیفتد، که ممکن است پایگاه داده را در سرورها جابجا کند. برای وضوح، مثال زیر کل فرآیند را در یک قطعه کد نشان می دهد. با این حال، پیاده سازی eShopOnContainers مجدداً ساخته شده است و این منطق را به چندین کلاس تقسیم می کند تا نگهداری آن آسان تر باشد.// Update Product from the Catalog microservice//public async Task UpdateProduct([FromBody]CatalogItem productToUpdate){ var catalogItem = await _catalogContext.CatalogItems.SingleOrDefaultAsync(i => i.Id == productToUpdate.Id); if (catalogItem == null) return NotFound(); bool raiseProductPriceChangedEvent = false; IntegrationEvent priceChangedEvent = null; if (catalogItem.Price != productToUpdate.Price) raiseProductPriceChangedEvent = true; if (raiseProductPriceChangedEvent) // Create event if price has changed { var oldPrice = catalogItem.Price; priceChangedEvent = new ProductPriceChangedIntegrationEvent(catalogItem.Id, productToUpdate.Price, oldPrice); } // Update current product catalogItem = productToUpdate; // Just save the updated product if the Product's Price hasn't changed. if (!raiseProductPriceChangedEvent) { await _catalogContext.SaveChangesAsync(); } else // Publish to event bus only if product price changed { // Achieving atomicity between original DB and the IntegrationEventLog // with a local transaction using (var transaction = _catalogContext.Database.BeginTransaction()) { _catalogContext.CatalogItems.Update(catalogItem); await _catalogContext.SaveChangesAsync(); await _integrationEventLogService.SaveEventAsync(priceChangedEvent); transaction.Commit(); } // Publish the integration event through the event bus _eventBus.Publish(priceChangedEvent); _integrationEventLogService.MarkEventAsPublishedAsync( priceChangedEvent); } return Ok();}پس از ایجاد رویداد یکپارچه سازی ProductPriceChangedIntegrationEvent، تراکنشی که عملیات دامنه اصلی را ذخیره می کند (به روز رسانی مورد کاتالوگ) همچنین شامل ماندگاری رویداد در جدول EventLog می شود. این باعث می شود که یک تراکنش واحد باشد و شما همیشه می توانید بررسی کنید که آیا پیام های رویداد ارسال شده است یا خیر.جدول ثبت رویداد به صورت اتمی با عملیات پایگاه داده اصلی، با استفاده از یک تراکنش محلی در برابر همان پایگاه داده به روز می شود. اگر هر یک از عملیات شکست بخورد، یک استثنا ایجاد می‌شود و تراکنش هر عملیات تکمیل‌شده را به عقب برمی‌گرداند، بنابراین هماهنگی بین عملیات دامنه و پیام‌های رویداد ذخیره شده در جدول حفظ می‌شود.دریافت پیام از اشتراک‌ها: کنترل‌کننده‌های رویداد در میکروسرویس‌های گیرندهعلاوه بر منطق اشتراک رویداد، باید کد داخلی را برای کنترل‌کننده‌های رویداد ادغام پیاده‌سازی کنید (مانند یک روش برگشتی). کنترل کننده رویداد جایی است که شما تعیین می کنید که در آن پیام های رویداد از نوع خاصی دریافت و پردازش شوند.یک کنترل کننده رویداد ابتدا یک نمونه رویداد را از گذرگاه رویداد دریافت می کند. سپس مؤلفه‌ای را که باید پردازش شود مربوط به آن رویداد یکپارچه‌سازی را تعیین می‌کند و رویداد را به‌عنوان تغییر حالت در میکروسرویس گیرنده منتشر و ادامه می‌دهد. به عنوان مثال، اگر یک رویداد ProductPriceChanged از میکروسرویس کاتالوگ منشا گرفته شود، در میکروسرویس سبد مدیریت می شود و وضعیت را در این میکروسرویس سبد گیرنده نیز تغییر می دهد، همانطور که در کد زیر نشان داده شده است.namespace Microsoft.eShopOnContainers.Services.Basket.API.IntegrationEvents.EventHandling{ public class ProductPriceChangedIntegrationEventHandler : IIntegrationEventHandler { private readonly IBasketRepository _repository; public ProductPriceChangedIntegrationEventHandler( IBasketRepository repository) { _repository = repository; } public async Task Handle(ProductPriceChangedIntegrationEvent @event) { var userIds = await _repository.GetUsers(); foreach (var id in userIds) { var basket = await _repository.GetBasket(id); await UpdatePriceInBasketItems(@event.ProductId, @event.NewPrice, basket); } } private async Task UpdatePriceInBasketItems(int productId, decimal newPrice, CustomerBasket basket) { var itemsToUpdate = basket?.Items?.Where(x => int.Parse(x.ProductId) == productId).ToList(); if (itemsToUpdate != null) { foreach (var item in itemsToUpdate) { if(item.UnitPrice != newPrice) { var originalPrice = item.UnitPrice; item.UnitPrice = newPrice; item.OldUnitPrice = originalPrice; } } await _repository.UpdateBasket(basket); } } }}کنترل کننده رویداد باید بررسی کند که آیا محصول در هر یک از نمونه های سبد وجود دارد یا خیر. همچنین قیمت اقلام را برای هر خط سبد مرتبط به‌روزرسانی می‌کند.عدم توانایی در رویدادهای پیام به روز رسانییکی از جنبه های مهم رویدادهای پیام به روز رسانی این است که یک شکست در هر نقطه از ارتباط باید باعث شود که پیام دوباره امتحان شود. در غیر این صورت، یک کار پس‌زمینه ممکن است سعی کند رویدادی را منتشر کند که قبلاً منتشر شده است و شرایط مسابقه ایجاد می‌کند. اطمینان حاصل کنید که به‌روزرسانی‌ها یا فاقد قدرت هستند یا اطلاعات کافی را ارائه می‌دهند تا اطمینان حاصل شود که می‌توانید یک نسخه تکراری را شناسایی کنید، آن را دور بیندازید و تنها یک پاسخ را ارسال کنید.همانطور که قبلا ذکر شد، ناتوانی به این معنی است که یک عمل می تواند چندین بار بدون تغییر نتیجه انجام شود. در یک محیط پیام‌رسانی، مانند هنگام برقراری ارتباط رویدادها، یک رویداد در صورتی بی‌توان است که بتواند چندین بار بدون تغییر نتیجه برای میکروسرویس گیرنده تحویل داده شود. این ممکن است به دلیل ماهیت خود رویداد یا به دلیل نحوه مدیریت رویداد توسط سیستم ضروری باشد. ناتوانی پیام در هر برنامه‌ای که از پیام‌رسانی استفاده می‌کند مهم است، نه فقط در برنامه‌هایی که الگوی اتوبوس رویداد را پیاده‌سازی می‌کنند.نمونه ای از عملیات idempotent یک دستور SQL است که داده ها را تنها در صورتی وارد جدول می کند که آن داده ها قبلاً در جدول نباشد. مهم نیست که چند بار آن دستور SQL را اجرا کنید. نتیجه یکسان خواهد بود - جدول حاوی آن داده ها خواهد بود. اگر پیام‌ها به طور بالقوه می‌توانستند ارسال شوند و بنابراین بیش از یک بار پردازش شوند، چنین بی‌توانایی می‌تواند هنگام برخورد با پیام‌ها نیز ضروری باشد. به عنوان مثال، اگر منطق سعی مجدد باعث شود فرستنده دقیقاً همان پیام را بیش از یک بار ارسال کند، باید مطمئن شوید که آن پیام ضعیف است.مثال دیگر ممکن است یک رویداد تکمیل شده با سفارش باشد که به چندین مشترک منتشر می شود. برنامه باید مطمئن شود که اطلاعات سفارش در سیستم های دیگر فقط یک بار به روز می شود، حتی اگر رویدادهای پیام تکراری برای همان رویداد تکمیل شده سفارش وجود داشته باشد.مثال دیگر ممکن است یک رویداد تکمیل شده با سفارش باشد که به چندین مشترک منتشر می شود. برنامه باید مطمئن شود که اطلاعات سفارش در سیستم های دیگر فقط یک بار به روز می شود، حتی اگر رویدادهای پیام تکراری برای همان رویداد تکمیل شده سفارش وجود داشته باشد.داشتن نوعی هویت در هر رویداد راحت است تا بتوانید منطقی ایجاد کنید که هر رویداد را تنها یک بار در هر گیرنده پردازش کند.برخی از پردازش پیام‌ها ذاتاً بی‌توان هستند. برای مثال، اگر سیستمی تصاویر کوچک تصویر را تولید کند، ممکن است مهم نباشد که پیام مربوط به تصویر کوچک تولید شده چند بار پردازش می شود. نتیجه این است که ریز عکسها تولید می شوند و هر بار یکسان هستند. از سوی دیگر، عملیاتی مانند فراخوانی درگاه پرداخت برای شارژ کارت اعتباری ممکن است اصلاً بی تأثیر نباشد. در این موارد، باید اطمینان حاصل کنید که پردازش چندباره یک پیام، تأثیری را که انتظار دارید داشته باشد.کپی برداری از پیام های رویداد یکپارچه سازیمی توانید مطمئن شوید که رویدادهای پیام تنها یک بار برای هر مشترک در سطوح مختلف ارسال و پردازش می شوند. یکی از راه‌ها استفاده از ویژگی کپی‌برداری است که توسط زیرساخت پیام‌رسانی که استفاده می‌کنید ارائه می‌شود. دیگری این است که منطق سفارشی را در میکروسرویس مقصد خود پیاده سازی کنید. داشتن اعتبارسنجی هم در سطح حمل و نقل و هم در سطح برنامه بهترین گزینه است.کپی کردن رویدادهای پیام در سطح EventHandlerیک راه برای اطمینان از اینکه یک رویداد فقط یک بار توسط هر گیرنده پردازش می شود، اجرای منطق خاصی در هنگام پردازش رویدادهای پیام در کنترل کننده رویداد است. برای مثال، این رویکردی است که در برنامه eShopOnContainers استفاده می‌شود، همانطور که می‌توانید در کد منبع کلاس UserCheckoutAcceptedIntegrationEventHandler هنگام دریافت رویداد ادغام UserCheckoutAcceptedIntegrationEvent مشاهده کنید. (در این مورد، CreateOrderCommand با یک IdentifiedCommand، با استفاده از eventMsg.RequestId به عنوان شناسه، قبل از ارسال آن به کنترل کننده فرمان پیچیده می شود).کپی کردن پیام ها هنگام استفاده از RabbitMQهنگامی که خرابی های متناوب شبکه رخ می دهد، پیام ها می توانند تکرار شوند و گیرنده پیام باید آماده رسیدگی به این پیام های تکراری باشد. در صورت امکان، گیرنده‌ها باید پیام‌ها را به شیوه‌ای بی‌توان مدیریت کنند، که بهتر از مدیریت صریح آن‌ها با کپی‌برداری است.با توجه به مستندات RabbitMQ، "اگر پیامی به یک مصرف کننده تحویل داده شود و سپس درخواست داده شود (به عنوان مثال، به دلیل اینکه قبل از قطع اتصال مصرف کننده تایید نشده است) پس RabbitMQ پرچم تحویل مجدد را روی آن تنظیم می کند که دوباره تحویل داده شود (خواه به مصرف کننده مشابه یا مصرف کننده متفاوت).اگر پرچم "تحویل مجدد" تنظیم شده باشد، گیرنده باید آن را در نظر بگیرد، زیرا ممکن است پیام قبلا پردازش شده باشد. اما این تضمین شده نیست. ممکن است پیام پس از خروج از واسطه پیام هرگز به گیرنده نرسد، شاید به دلیل مشکلات شبکه. از سوی دیگر، اگر پرچم "تحویل مجدد" تنظیم نشود، تضمین می شود که پیام بیش از یک بار ارسال نشده است. بنابراین، گیرنده نیاز دارد پیام‌ها را کپی کند یا پیام‌ها را به روشی غیرقابل پردازش پردازش کند، تنها در صورتی که پرچم «تحویل مجدد» در پیام تنظیم شده باشد.

پیاده سازی گذرگاه رویداد میکروسرویس با RabbitMQ برای محیط توسعه یا آزمایش

Ehsan — Sun, 12 Feb 2023 13:45:15 +0330

e باید با گفتن این که اگر گذرگاه رویداد سفارشی خود را بر اساس RabbitMQ در حال اجرا در یک کانتینر ایجاد کنید، همانطور که برنامه eShopOnContainers انجام می دهد، باید فقط برای محیط های توسعه و آزمایش خود استفاده شود. از آن برای محیط تولید خود استفاده نکنید، مگر اینکه آن را به عنوان بخشی از اتوبوس خدمات آماده تولید بسازید، همانطور که در بخش منابع اضافی در زیر توضیح داده شده است. یک اتوبوس رویداد سفارشی ساده ممکن است بسیاری از ویژگی‌های حیاتی آماده تولید را که یک اتوبوس خدمات تجاری دارد، نداشته باشد.یکی از پیاده سازی های سفارشی گذرگاه رویداد در eShopOnContainers اساساً یک کتابخانه با استفاده از RabbitMQ API است. (یک پیاده سازی دیگر بر اساس Azure Service Bus وجود دارد.)پیاده سازی گذرگاه رویداد با RabbitMQ به میکروسرویس ها اجازه می دهد تا در رویدادها مشترک شوند، رویدادها را منتشر کنند و رویدادها را دریافت کنند، همانطور که در شکل 6-21 نشان داده شده است.RabbitMQ به عنوان یک واسطه بین ناشر پیام و مشترکین برای مدیریت توزیع عمل می کند. در کد، کلاس EventBusRabbitMQ رابط عمومی IEventBus را پیاده سازی می کند. این پیاده سازی مبتنی بر Dependency Injection است تا بتوانید از این نسخه توسعه دهنده/تست به نسخه تولیدی مبادله کنید.public class EventBusRabbitMQ : IEventBus, IDisposable{ // Implementation using RabbitMQ API //...}پیاده‌سازی RabbitMQ یک گذرگاه رویداد برنامه‌نویس/تست نمونه، کد boilerplate است. باید اتصال به سرور RabbitMQ را مدیریت کند و کدی را برای انتشار یک رویداد پیام در صف ها ارائه کند. همچنین باید فرهنگ لغت مجموعه‌ای از مدیریت‌کننده‌های رویداد یکپارچه‌سازی را برای هر نوع رویداد پیاده‌سازی کند. این نوع رویدادها می توانند برای هر میکروسرویس گیرنده یک نمونه متفاوت و اشتراک های متفاوت داشته باشند.پیاده سازی یک روش انتشار ساده با RabbitMQکد زیر یک نسخه ساده شده از پیاده سازی گذرگاه رویداد برای RabbitMQ است تا کل سناریو را به نمایش بگذارد. شما واقعاً ارتباط را اینگونه مدیریت نمی کنید. برای مشاهده اجرای کامل، کد واقعی را در مخزن dotnet-architecture/eShopOnContainers ببینید.public class EventBusRabbitMQ : IEventBus, IDisposable{ // Member objects and other methods ... // ... public void Publish(IntegrationEvent @event) { var eventName = @event.GetType().Name; var factory = new ConnectionFactory() { HostName = _connectionString }; using (var connection = factory.CreateConnection()) using (var channel = connection.CreateModel()) { channel.ExchangeDeclare(exchange: _brokerName, type: "direct"); string message = JsonConvert.SerializeObject(@event); var body = Encoding.UTF8.GetBytes(message); channel.BasicPublish(exchange: _brokerName, routingKey: eventName, basicProperties: null, body: body); } }}کد واقعی روش Publish در برنامه eShopOnContainers با استفاده از یک خط مشی امتحان مجدد Polly بهبود می یابد، که در صورت آماده نبودن ظرف RabbitMQ، این کار را چند بار تکرار می کند. این سناریو می تواند زمانی رخ دهد که docker-compose در حال راه اندازی کانتینرها است. برای مثال، محفظه RabbitMQ ممکن است کندتر از سایر کانتینرها شروع به کار کند.همانطور که قبلا ذکر شد، تنظیمات احتمالی زیادی در RabbitMQ وجود دارد، بنابراین این کد باید فقط برای محیط‌های dev/test استفاده شود.پیاده سازی کد اشتراک با RabbitMQ APIهمانند کد انتشار، کد زیر ساده‌سازی بخشی از اجرای اتوبوس رویداد برای RabbitMQ است. باز هم، معمولاً نیازی به تغییر آن ندارید، مگر اینکه در حال بهبود آن باشید.public class EventBusRabbitMQ : IEventBus, IDisposable{ // Member objects and other methods ... // ... public void Subscribe() where T : IntegrationEvent where TH : IIntegrationEventHandler { var eventName = _subsManager.GetEventKey(); var containsKey = _subsManager.HasSubscriptionsForEvent(eventName); if (!containsKey) { if (!_persistentConnection.IsConnected) { _persistentConnection.TryConnect(); } using (var channel = _persistentConnection.CreateModel()) { channel.QueueBind(queue: _queueName, exchange: BROKER_NAME, routingKey: eventName); } } _subsManager.AddSubscription(); }}هر نوع رویداد یک کانال مرتبط برای دریافت رویدادها از RabbitMQ دارد. سپس می توانید به تعداد مورد نیاز در هر کانال و نوع رویداد، کنترل کننده رویداد داشته باشید.متد Subscribe یک شی IIntegrationEventHandler را می‌پذیرد، که مانند یک روش بازگشت به تماس در میکروسرویس فعلی است، به علاوه شی IntegrationEvent مربوط به آن. سپس کد آن رویداد کنترل‌کننده را به فهرست کنترل‌کننده‌های رویداد اضافه می‌کند که هر نوع رویداد یکپارچه‌سازی می‌تواند در هر میکروسرویس مشتری داشته باشد. اگر کد مشتری قبلاً در رویداد مشترک نشده باشد، کد یک کانال برای نوع رویداد ایجاد می کند تا بتواند رویدادها را به سبک فشاری از RabbitMQ دریافت کند، زمانی که آن رویداد از هر سرویس دیگری منتشر می شود.همانطور که در بالا ذکر شد، اتوبوس رویداد پیاده‌سازی شده در eShopOnContainers فقط یک هدف آموزشی دارد، زیرا تنها سناریوهای اصلی را کنترل می‌کند، بنابراین برای تولید آماده نیست.

پیاده سازی ارتباطات مبتنی بر رویداد بین میکروسرویس ها (رویدادهای یکپارچه سازی)

Ehsan — Sun, 12 Feb 2023 11:04:26 +0330

همانطور که قبلا توضیح داده شد، هنگامی که از ارتباطات مبتنی بر رویداد استفاده می کنید، یک میکروسرویس زمانی که اتفاق قابل توجهی رخ می دهد، مانند زمانی که یک نهاد تجاری را به روز می کند، رویدادی را منتشر می کند. سایر ریزسرویس‌ها مشترک آن رویدادها هستند. هنگامی که یک میکروسرویس رویدادی را دریافت می کند، می تواند نهادهای تجاری خود را به روز کند، که ممکن است منجر به انتشار رویدادهای بیشتری شود. این جوهر مفهوم سازگاری نهایی است. این سیستم انتشار/اشتراک معمولاً با استفاده از پیاده‌سازی گذرگاه رویداد انجام می‌شود. اتوبوس رویداد را می توان به عنوان یک رابط با API مورد نیاز برای اشتراک و لغو اشتراک رویدادها و انتشار رویدادها طراحی کرد. همچنین می‌تواند یک یا چند پیاده‌سازی بر اساس هر ارتباط بین فرآیندی یا پیام‌رسانی، مانند صف پیام‌رسانی یا گذرگاه خدماتی که از ارتباط ناهمزمان و مدل انتشار/اشتراک پشتیبانی می‌کند، داشته باشد.می‌توانید از رویدادها برای پیاده‌سازی تراکنش‌های تجاری که چندین سرویس را در بر می‌گیرند، استفاده کنید، که به شما یکپارچگی نهایی بین آن خدمات را می‌دهد. یک تراکنش در نهایت سازگار شامل یک سری اقدامات توزیع شده است. در هر اقدام، میکروسرویس یک نهاد تجاری را به روز می کند و رویدادی را منتشر می کند که اقدام بعدی را آغاز می کند. این بخش توضیح می دهد که چگونه می توانید این نوع ارتباط را با دات نت با استفاده از یک رابط گذرگاه رویداد عمومی پیاده سازی کنید. چندین پیاده سازی بالقوه وجود دارد که هر کدام از فناوری یا زیرساخت متفاوتی مانند RabbitMQ، Azure Service Bus یا هر گذرگاه خدمات تجاری منبع باز یا شخص ثالث دیگری استفاده می کنند.استفاده از کارگزاران پیام و اتوبوس های خدمات برای سیستم های تولیدهمانطور که در بخش معماری اشاره شد، می‌توانید از میان چندین فناوری پیام‌رسانی برای پیاده‌سازی گذرگاه رویداد انتزاعی خود انتخاب کنید. اما این فناوری ها در سطوح مختلفی قرار دارند. به عنوان مثال، RabbitMQ، یک واسطه انتقال پیام، در سطح پایین تری نسبت به محصولات تجاری مانند Azure Service Bus، NServiceBus، MassTransit یا Brighter قرار دارد. اکثر این محصولات می‌توانند در بالای RabbitMQ یا Azure Service Bus کار کنند. انتخاب محصول شما به چند ویژگی و میزان مقیاس پذیری خارج از جعبه برای برنامه خود بستگی دارد.مانند نمونه eShopOnContainers، برای پیاده‌سازی یک گذرگاه رویداد اثبات مفهوم برای محیط توسعه‌تان، یک پیاده‌سازی ساده در بالای RabbitMQ که به‌عنوان یک کانتینر اجرا می‌شود، ممکن است کافی باشد. اما برای سیستم‌های تولیدی و حیاتی که نیاز به مقیاس‌پذیری بالایی دارند، ممکن است بخواهید Azure Service Bus را ارزیابی کرده و از آن استفاده کنید.اگر به انتزاع‌های سطح بالا و ویژگی‌های غنی‌تر مانند Sagas برای فرآیندهای طولانی‌مدت نیاز دارید که توسعه توزیع‌شده را آسان‌تر می‌کنند، سایر اتوبوس‌های خدمات تجاری و منبع باز مانند NServiceBus، MassTransit و Brighter ارزش ارزیابی دارند. در این مورد، انتزاع‌ها و APIهای مورد استفاده معمولاً مستقیماً همانهایی هستند که به‌جای انتزاع‌های خود شما توسط اتوبوس‌های خدمات سطح بالا ارائه می‌شوند (مانند انتزاع‌های اتوبوس رویداد ساده ارائه‌شده در eShopOnContainers). برای این موضوع، می توانید با استفاده از NServiceBus (نمونه مشتق شده اضافی که توسط نرم افزار خاص پیاده سازی شده است) در مورد eShopOnContainers فورک شده تحقیق کنید.البته، همیشه می‌توانید ویژگی‌های گذرگاه خدمات خود را بر روی فناوری‌های سطح پایین‌تر مانند RabbitMQ و Docker ایجاد کنید، اما کار مورد نیاز برای «اختراع مجدد چرخ» ممکن است برای یک برنامه سازمانی سفارشی بسیار پرهزینه باشد.تکرار: انتزاع‌ها و پیاده‌سازی گذرگاه رویداد نمونه که در نمونه eShopOnContainers به نمایش گذاشته شده‌اند، صرفاً به‌عنوان اثبات مفهوم مورد استفاده قرار می‌گیرند. هنگامی که تصمیم گرفتید که می خواهید ارتباط ناهمزمان و رویداد محور داشته باشید، همانطور که در بخش فعلی توضیح داده شد، باید محصول اتوبوس خدماتی را انتخاب کنید که به بهترین وجه با نیازهای شما برای تولید مطابقت دارد.رویدادهای ادغامرویدادهای یکپارچه سازی برای همگام سازی حالت دامنه در چندین میکروسرویس یا سیستم های خارجی استفاده می شود. این عملکرد با انتشار رویدادهای یکپارچه سازی خارج از میکروسرویس انجام می شود. هنگامی که یک رویداد برای میکروسرویس‌های گیرنده چندگانه منتشر می‌شود (به تعداد میکروسرویس‌هایی که در رویداد یکپارچه‌سازی مشترک شده‌اند)، کنترل‌کننده رویداد مناسب در هر میکروسرویس گیرنده، رویداد را مدیریت می‌کند.یک رویداد یکپارچه سازی اساساً یک کلاس نگهدارنده داده است، مانند مثال زیر:public class ProductPriceChangedIntegrationEvent : IntegrationEvent{ public int ProductId { get; private set; } public decimal NewPrice { get; private set; } public decimal OldPrice { get; private set; } public ProductPriceChangedIntegrationEvent(int productId, decimal newPrice, decimal oldPrice) { ProductId = productId; NewPrice = newPrice; OldPrice = oldPrice; }}رویدادهای یکپارچه‌سازی را می‌توان در سطح کاربرد هر میکروسرویس تعریف کرد، بنابراین آنها از سایر ریزسرویس‌ها جدا می‌شوند، به نحوی که قابل مقایسه با نحوه تعریف ViewModels در سرور و مشتری است. آنچه توصیه نمی شود اشتراک گذاری یک کتابخانه رویدادهای یکپارچه سازی مشترک در چندین میکروسرویس است. انجام این کار می تواند آن میکروسرویس ها را با یک کتابخانه داده با تعریف رویداد واحد پیوند دهد. شما نمی خواهید این کار را به همان دلایلی انجام دهید که نمی خواهید یک مدل دامنه مشترک را بین چندین میکروسرویس به اشتراک بگذارید: میکروسرویس ها باید کاملاً مستقل باشند. برای اطلاعات بیشتر، این پست وبلاگ را در مورد میزان داده هایی که باید در رویدادها قرار دهید، ببینید.فقط چند نوع کتابخانه وجود دارد که باید در میان میکروسرویس ها به اشتراک بگذارید. یکی کتابخانه هایی هستند که بلوک های برنامه نهایی هستند، مانند Event Bus مشتری API، مانند eShopOnContainers. دیگری کتابخانه‌هایی است که ابزارهایی را تشکیل می‌دهند که می‌توانند به‌عنوان اجزای NuGet به اشتراک گذاشته شوند، مانند سریال‌سازهای JSON.اتوبوس مراسمیک گذرگاه رویداد اجازه می دهد تا ارتباطی به سبک انتشار/اشتراک بین میکروسرویس ها بدون نیاز به آگاهی صریح اجزا از یکدیگر وجود داشته باشد.الگوی مشاهده گردر الگوی Observer، شی اصلی شما (معروف به Observable) سایر اشیاء علاقه مند (معروف به Observers) را با اطلاعات مرتبط (رویدادها) مطلع می کند.الگوی انتشار/اشتراک (Pub/Sub).هدف از الگوی Publish/Subscribe همانند الگوی Observer است: می‌خواهید در صورت وقوع رویدادهای خاصی به سایر سرویس‌ها اطلاع دهید. اما تفاوت مهمی بین الگوهای Observer و Pub/Sub وجود دارد. در الگوی مشاهده گر، پخش مستقیماً از مشاهده پذیر به ناظران انجام می شود، بنابراین آنها یکدیگر را می شناسند. اما هنگام استفاده از الگوی Pub/Sub، جزء سومی به نام بروکر یا واسطه پیام یا اتوبوس رویداد وجود دارد که هم توسط ناشر و هم مشترک شناخته می شود. بنابراین، هنگام استفاده از الگوی Pub/Sub، ناشر و مشترکین دقیقاً به لطف اتوبوس رویداد یا کارگزار پیام ذکر شده جدا می شوند.واسطه یا اتوبوس رویدادچگونه بین ناشر و مشترک به ناشناس بودن می رسید؟ یک راه آسان این است که اجازه دهید یک واسطه تمام ارتباطات را انجام دهد. اتوبوس رویداد یکی از این واسطه هاست.اتوبوس رویداد معمولاً از دو بخش تشکیل شده است:انتزاع یا رابط.یک یا چند پیاده سازیخوب است که گذرگاه رویداد از طریق یک رابط تعریف شود تا بتوان آن را با چندین فناوری مانند RabbitMQ، Azure Service bus یا موارد دیگر پیاده‌سازی کرد. با این حال، و همانطور که قبلا ذکر شد، استفاده از انتزاع‌های خود (رابط اتوبوس رویداد) تنها در صورتی خوب است که به ویژگی‌های گذرگاه رویداد اصلی که توسط انتزاع‌هایتان پشتیبانی می‌شوند، نیاز داشته باشید. اگر به ویژگی‌های گذرگاه خدمات غنی‌تری نیاز دارید، احتمالاً باید از API و انتزاع‌های ارائه‌شده توسط اتوبوس خدمات تجاری مورد علاقه‌تان به جای انتزاع‌های خود استفاده کنید.تعریف رابط اتوبوس رویدادبیایید با برخی از کدهای پیاده سازی برای رابط اتوبوس رویداد و پیاده سازی های ممکن برای اهداف اکتشافی شروع کنیم. رابط باید عمومی و ساده باشد، مانند رابط زیر.public interface IEventBus{ void Publish(IntegrationEvent @event); void Subscribe() where T : IntegrationEvent where TH : IIntegrationEventHandler; void SubscribeDynamic(string eventName) where TH : IDynamicIntegrationEventHandler; void UnsubscribeDynamic(string eventName) where TH : IDynamicIntegrationEventHandler; void Unsubscribe() where TH : IIntegrationEventHandler where T : IntegrationEvent;}روش انتشار ساده است. گذرگاه رویداد رویداد یکپارچه‌سازی ارسال شده به آن را برای هر میکروسرویس یا حتی یک برنامه خارجی مشترک در آن رویداد پخش می‌کند. این روش توسط میکروسرویسی که رویداد را منتشر می کند استفاده می شود.روش های Subscribe (بسته به آرگومان ها می توانید چندین پیاده سازی داشته باشید) توسط میکروسرویس هایی که می خواهند رویدادها را دریافت کنند استفاده می شود. این روش دو آرگومان دارد. اولین رویداد یکپارچه سازی برای اشتراک در (IntegrationEvent) است. آرگومان دوم، کنترل‌کننده رویداد یکپارچه‌سازی (یا روش برگشت به تماس)، با نام IIntegrationEventHandler است که زمانی اجرا می‌شود که میکروسرویس گیرنده پیام رویداد یکپارچه‌سازی را دریافت کند.

ایجاد یک میکروسرویس CRUD مبتنی بر داده قسمت دوم

Ehsan — Sun, 12 Feb 2023 10:23:22 +0330

رشته اتصال DB و متغیرهای محیطی که توسط کانتینرهای Docker استفاده می شودمی‌توانید از تنظیمات ASP.NET Core استفاده کنید و یک ویژگی ConnectionString به فایل settings.json خود اضافه کنید، همانطور که در مثال زیر نشان داده شده است:{ "ConnectionString": "Server=tcp:127.0.0.1,5433;Initial Catalog=Microsoft.eShopOnContainers.Services.CatalogDb;User Id=sa;Password=[PLACEHOLDER]", "ExternalCatalogBaseUrl": "http://host.docker.internal:5101", "Logging": { "IncludeScopes": false, "LogLevel": { "Default": "Debug", "System": "Information", "Microsoft": "Information" } }}فایل settings.json می‌تواند مقادیر پیش‌فرض برای ویژگی ConnectionString یا هر ویژگی دیگری داشته باشد. با این حال، این ویژگی‌ها با مقادیر متغیرهای محیطی که در فایل docker-compose.override.yml مشخص می‌کنید، هنگام استفاده از Docker لغو می‌شوند.از فایل‌های docker-compose.yml یا docker-compose.override.yml خود، می‌توانید آن متغیرهای محیطی را مقداردهی اولیه کنید تا Docker آنها را به عنوان متغیرهای محیط سیستم عامل برای شما تنظیم کند، همانطور که در فایل docker-compose.override.yml زیر نشان داده شده است. (رشته اتصال و خطوط دیگر در این مثال پیچیده می شود، اما در فایل خود شما قرار نمی گیرد).# docker-compose.override.yml#catalog-api: environment: - ConnectionString=Server=sqldata;Database=Microsoft.eShopOnContainers.Services.CatalogDb;User Id=sa;Password=[PLACEHOLDER] # Additional environment variables for this service ports: - "5101:80"فایل‌های docker-compose.yml در سطح راه‌حل نه تنها نسبت به فایل‌های پیکربندی در سطح پروژه یا میکروسرویس انعطاف‌پذیرتر هستند، بلکه اگر متغیرهای محیطی اعلام‌شده در فایل‌های docker-compose را با مقادیر تنظیم‌شده از ابزارهای استقرار خود لغو کنید، امنیت بیشتری نیز دارند. ، مانند وظایف استقرار Azure DevOps Services Docker.در نهایت، همانطور که در روش ConfigureServices در نمونه کد قبلی نشان داده شده است، می توانید با استفاده از Configuration["ConnectionString"] آن مقدار را از کد خود دریافت کنید.با این حال، برای محیط های تولید، ممکن است بخواهید راه های دیگری را در مورد نحوه ذخیره اسرار مانند رشته های اتصال کشف کنید. یک راه عالی برای مدیریت اسرار برنامه استفاده از Azure Key Vault است.Azure Key Vault به ذخیره و محافظت از کلیدهای رمزنگاری و اسرار مورد استفاده توسط برنامه‌ها و سرویس‌های ابری شما کمک می‌کند. یک راز هر چیزی است که می‌خواهید کنترل دقیقی روی آن داشته باشید، مانند کلیدهای API، رشته‌های اتصال، گذرواژه‌ها و غیره و کنترل دقیق شامل ثبت استفاده، تنظیم انقضا، مدیریت دسترسی و غیره است.Azure Key Vault اجازه می دهد تا سطح کنترل دقیق استفاده از اسرار برنامه را بدون نیاز به اطلاع دیگران از آنها انجام دهید. رازها حتی می توانند برای افزایش امنیت بدون ایجاد اختلال در توسعه یا عملیات چرخانده شوند.برنامه ها باید در اکتیو دایرکتوری سازمان ثبت شوند تا بتوانند از Key Vault استفاده کنند.پیاده سازی نسخه سازی در ASP.NET Web APIبا تغییر نیازهای کسب و کار، ممکن است مجموعه های جدیدی از منابع اضافه شود، روابط بین منابع ممکن است تغییر کند و ساختار داده ها در منابع ممکن است اصلاح شود. به روز رسانی Web API برای رسیدگی به نیازهای جدید یک فرآیند نسبتاً ساده است، اما باید تأثیراتی را که چنین تغییراتی بر برنامه های مشتری مصرف کننده Web API خواهند داشت، در نظر بگیرید. اگرچه توسعه‌دهنده‌ای که یک Web API را طراحی و اجرا می‌کند، کنترل کاملی بر آن API دارد، توسعه‌دهنده آن درجه از کنترل روی برنامه‌های کلاینت را ندارد که ممکن است توسط سازمان‌های شخص ثالث که از راه دور کار می‌کنند ساخته شوند.نسخه‌سازی Web API را قادر می‌سازد تا ویژگی‌ها و منابعی را که در معرض نمایش قرار می‌دهد را نشان دهد. سپس یک برنامه مشتری می تواند درخواست هایی را به نسخه خاصی از یک ویژگی یا منبع ارسال کند. چندین رویکرد برای پیاده سازی نسخه سازی وجود دارد:نسخه URIنسخه سازی رشته پرس و جونسخه هدررشته کوئری و نسخه‌سازی URI ساده‌ترین روش‌ها برای پیاده‌سازی هستند. نسخه نویسی هدر رویکرد خوبی است. با این حال، نسخه‌سازی هدر به اندازه نسخه‌سازی URI صریح و ساده نیست. از آنجا که نسخه‌سازی URL ساده‌ترین و واضح‌ترین است، برنامه نمونه eShopOnContainers از نسخه‌سازی URI استفاده می‌کند.با نسخه‌سازی URI، مانند برنامه نمونه eShopOnContainers، هر بار که Web API را تغییر می‌دهید یا طرح منابع را تغییر می‌دهید، برای هر منبع یک شماره نسخه به URI اضافه می‌کنید. URI های موجود باید مانند قبل به کار خود ادامه دهند و منابعی را برگردانند که با طرحی مطابق با نسخه درخواستی مطابقت دارند.همانطور که در مثال کد زیر نشان داده شده است، نسخه را می توان با استفاده از ویژگی Route در کنترلر Web API تنظیم کرد، که نسخه را در URI واضح می کند (در این مورد v1).[Route("api/v1/[controller]")]public class CatalogController : ControllerBase{ // Implementation ...این مکانیسم نسخه سازی ساده است و بستگی به این دارد که سرور درخواست را به نقطه پایانی مناسب هدایت کند. با این حال، برای نسخه‌سازی پیچیده‌تر و بهترین روش در هنگام استفاده از REST، باید از هایپر مدیا استفاده کنید و HATEOAS (فوق متن به عنوان موتور حالت برنامه) را پیاده‌سازی کنید.ایجاد ابرداده توضیحات Swagger از ASP.NET Core Web API Swagger یک چارچوب متن باز پر استفاده است که توسط اکوسیستم بزرگی از ابزارها پشتیبانی می شود که به شما کمک می کند API های RESTful خود را طراحی، ساخت، مستندسازی و مصرف کنید. این در حال تبدیل شدن به استانداردی برای دامنه فراداده توصیف APIها است. شما باید ابرداده توضیحات Swagger را با هر نوع میکروسرویس، اعم از میکروسرویس‌های مبتنی بر داده یا میکروسرویس‌های پیشرفته‌تر مبتنی بر دامنه اضافه کنید.قلب Swagger مشخصات Swagger است، که ابرداده توضیحات API در یک فایل JSON یا YAML است. این مشخصات قرارداد RESTful را برای API شما ایجاد می‌کند و تمام منابع و عملیات آن را در قالبی قابل خواندن توسط انسان و ماشین برای توسعه، کشف و ادغام آسان توضیح می‌دهد.این مشخصات اساس مشخصات OpenAPI (OAS) است و در یک جامعه باز، شفاف و مشارکتی برای استانداردسازی روش تعریف رابط های RESTful توسعه یافته است.چرا از Swagger استفاده کنیم؟دلایل اصلی برای ایجاد ابرداده Swagger برای API های شما موارد زیر است.توانایی سایر محصولات برای مصرف خودکار و ادغام API های شما. ده ها محصول و ابزار تجاری و بسیاری از کتابخانه ها و چارچوب ها از Swagger پشتیبانی می کنند. مایکروسافت محصولات و ابزارهای سطح بالایی دارد که می توانند به طور خودکار API های مبتنی بر Swagger را مصرف کنند، مانند موارد زیر:استراحت خودکار. می توانید به طور خودکار کلاس های کلاینت دات نت را برای فراخوانی Swagger ایجاد کنید. این ابزار را می توان از CLI استفاده کرد و همچنین برای استفاده آسان از طریق رابط کاربری گرافیکی با ویژوال استودیو ادغام می شود.مایکروسافت فلو. می‌توانید به‌طور خودکار از API خود استفاده کرده و در یک جریان کاری سطح بالا Microsoft Flow، بدون نیاز به مهارت‌های برنامه‌نویسی، ادغام کنید.Microsoft Power Apps. می‌توانید به‌طور خودکار API خود را از برنامه‌های تلفن همراه PowerApps که با PowerApps Studio ساخته شده‌اند، بدون نیاز به مهارت برنامه‌نویسی مصرف کنید.Azure App Service Logic Apps. می‌توانید بدون نیاز به مهارت برنامه‌نویسی، به‌طور خودکار از API خود در یک برنامه منطقی سرویس Azure App استفاده کرده و ادغام کنید.امکان تولید خودکار اسناد API. وقتی APIهای RESTful در مقیاس بزرگ ایجاد می‌کنید، مانند برنامه‌های کاربردی پیچیده مبتنی بر میکروسرویس، باید بسیاری از نقاط پایانی را با مدل‌های داده‌های مختلف مورد استفاده در بارهای درخواست و پاسخ مدیریت کنید. داشتن اسناد و مدارک مناسب و داشتن یک کاوشگر API قوی، همانطور که با Swagger دریافت می کنید، کلید موفقیت API شما و پذیرش توسط توسعه دهندگان است.ابرداده Swagger همان چیزی است که Microsoft Flow، PowerApps و Azure Logic Apps برای درک نحوه استفاده از APIها و اتصال به آنها استفاده می کنند.چندین گزینه برای خودکارسازی تولید ابرداده Swagger برای برنامه‌های ASP.NET Core REST API، در قالب صفحات راهنمای کاربردی API، بر اساس swagger-ui وجود دارد.احتمالاً بهترین دانش Swashbuckle است که در حال حاضر در eShopOnContainers استفاده می شود و ما در این راهنما به جزئیات خواهیم پرداخت، اما گزینه ای برای استفاده از NSwag نیز وجود دارد که می تواند کلاینت های Typescript و C# API و همچنین کنترلرهای C# را از یک مشخصات Swagger یا OpenAPI و حتی با اسکن .dll حاوی کنترلرها، با استفاده از NSwagStudio.چگونه با بسته Swashbuckle NuGet تولید ابرداده API Swagger را خودکار کنیمایجاد ابرداده Swagger به صورت دستی (در یک فایل JSON یا YAML) می تواند کار خسته کننده ای باشد. با این حال، می توانید با استفاده از بسته Swashbuckle NuGet برای تولید متاداده Swagger API به صورت پویا، کشف API سرویس های ASP.NET Web API را خودکار کنید.Swashbuckle به طور خودکار ابرداده Swagger را برای پروژه های ASP.NET Web API شما تولید می کند. این برنامه از پروژه های ASP.NET Core Web API و ASP.NET Web API سنتی و هر طعم دیگری مانند Azure API App، Azure Mobile App، میکروسرویس های Azure Service Fabric مبتنی بر ASP.NET پشتیبانی می کند. همچنین از Web API ساده مستقر در کانتینرها، مانند برنامه مرجع، پشتیبانی می کند.Swashbuckle API Explorer و Swagger یا swagger-ui را با هم ترکیب می‌کند تا تجربه‌ای غنی از کشف و مستندسازی را برای مصرف‌کنندگان API شما فراهم کند. Swashbuckle علاوه بر موتور مولد ابرداده Swagger، دارای یک نسخه جاسازی شده از swagger-ui نیز می باشد که پس از نصب Swashbuckle به طور خودکار به کار می رود.این بدان معناست که می‌توانید API خود را با یک رابط کاربری جدید برای کمک به توسعه‌دهندگان در استفاده از API خود تکمیل کنید. به مقدار کمی کد و نگهداری نیاز دارد زیرا به طور خودکار تولید می شود و به شما امکان می دهد بر روی ساخت API خود تمرکز کنید. نتیجه API Explorer مانند شکل 6-8 است.اسناد API Swagger UI ایجاد شده توسط Swashbuckle شامل تمام اقدامات منتشر شده است. کاوشگر API مهمترین چیز در اینجا نیست. هنگامی که یک Web API دارید که می تواند خود را در ابرداده Swagger توصیف کند، API شما می تواند به طور یکپارچه از ابزارهای مبتنی بر Swagger استفاده شود، از جمله تولیدکنندگان کد کلاس پروکسی مشتری که می توانند پلتفرم های زیادی را هدف قرار دهند. به عنوان مثال، همانطور که گفته شد، AutoRest به طور خودکار کلاس های کلاینت دات نت را تولید می کند. اما ابزارهای اضافی مانند swagger-codegen نیز در دسترس هستند که امکان تولید کد کتابخانه های سرویس گیرنده API، خرد سرور و مستندات را به صورت خودکار فراهم می کند.در حال حاضر، Swashbuckle از پنج بسته داخلی NuGet تحت متا بسته بندی سطح بالا Swashbuckle.AspNetCore برای برنامه های ASP.NET Core تشکیل شده است.بعد از اینکه این بسته های NuGet را در پروژه Web API خود نصب کردید، باید Swagger را در کلاس Startup پیکربندی کنید، مانند کد ساده شده زیر:public class Startup{ public IConfigurationRoot Configuration { get; } // Other startup code... public void ConfigureServices(IServiceCollection services) { // Other ConfigureServices() code... // Add framework services. services.AddSwaggerGen(options => { options.DescribeAllEnumsAsStrings(); options.SwaggerDoc("v1", new OpenApiInfo { Title = "eShopOnContainers - Catalog HTTP API", Version = "v1", Description = "The Catalog Microservice HTTP API. This is a Data-Driven/CRUD microservice sample" }); }); // Other ConfigureServices() code... } public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { // Other Configure() code... // ... app.UseSwagger() .UseSwaggerUI(c => { c.SwaggerEndpoint("/swagger/v1/swagger.json", "My API V1"); }); }}پس از انجام این کار، می توانید برنامه خود را راه اندازی کنید و با استفاده از URL هایی مانند این، نقاط پایانی Swagger JSON و UI زیر را مرور کنید:http:///swagger/v1/swagger.json http:///swagger/شما قبلاً رابط کاربری ایجاد شده توسط Swashbuckle را برای نشانی اینترنتی مانند http:///swagger مشاهده کرده‌اید. در شکل 6-9، همچنین می توانید ببینید که چگونه می توانید هر روش API را آزمایش کنید.جزئیات API UI Swagger نمونه ای از پاسخ را نشان می دهد و می توان از آن برای اجرای API واقعی استفاده کرد که برای کشف توسعه دهندگان عالی است. شکل 6-10 ابرداده JSON Swagger را نشان می‌دهد که از ریزسرویس eShopOnContainers (که ابزارها در زیر آن استفاده می‌کنند) هنگامی که شما http:///swagger/v1/swagger.json را با استفاده از Postman درخواست می‌کنید، نشان می‌دهد.به همین سادگی است. و از آنجایی که به طور خودکار تولید می شود، زمانی که عملکرد بیشتری به API خود اضافه کنید، ابرداده Swagger رشد خواهد کرد.

ایجاد یک میکروسرویس CRUD مبتنی بر داده قسمت اول

Ehsan — Sat, 11 Feb 2023 15:31:55 +0330

این بخش نحوه ایجاد یک میکروسرویس ساده را توضیح می دهد که عملیات ایجاد، خواندن، به روز رسانی و حذف (CRUD) را بر روی یک منبع داده انجام می دهد.طراحی یک میکروسرویس ساده CRUDاز نظر طراحی، این نوع میکروسرویس کانتینری بسیار ساده است. شاید مشکل برای حل ساده باشد، یا شاید پیاده سازی تنها یک اثبات مفهوم باشد.نمونه ای از این نوع سرویس داده درایو ساده، ریزسرویس کاتالوگ از برنامه نمونه eShopOnContainers است. این نوع سرویس تمام عملکردهای خود را در یک پروژه ASP.NET Core Web API که شامل کلاس هایی برای مدل داده، منطق تجاری و کد دسترسی به داده است، پیاده سازی می کند. همچنین داده های مرتبط خود را در یک پایگاه داده در حال اجرا در SQL Server (به عنوان یک محفظه دیگر برای اهداف توسعه/آزمایش) ذخیره می کند، می تواند هر میزبان معمولی SQL Server نیز باشد. وجود پایگاه داده در همان میزبان Docker ممکن است برای توسعه خوب باشد، اما برای تولید نه. هنگامی که در حال توسعه این نوع سرویس هستید، فقط به ASP.NET Core و یک API یا ORM دسترسی به داده مانند Entity Framework Core نیاز دارید. همچنین می‌توانید ابرداده Swagger را به‌طور خودکار از طریق Swashbuckle ایجاد کنید تا شرحی از آنچه خدمات شما ارائه می‌دهد، همانطور که در بخش بعدی توضیح داده شد، ارائه دهید.توجه داشته باشید که اجرای یک سرور پایگاه داده مانند SQL Server در یک ظرف Docker برای محیط های توسعه عالی است، زیرا می توانید تمام وابستگی های خود را بدون نیاز به ارائه پایگاه داده در فضای ابری یا درون محل اجرا کنید. این رویکرد هنگام اجرای تست های یکپارچه سازی راحت است. با این حال، برای محیط‌های تولید، اجرای یک سرور پایگاه داده در یک کانتینر توصیه نمی‌شود، زیرا معمولاً با این رویکرد دسترسی بالایی به دست نمی‌آورید. برای یک محیط تولید در Azure، توصیه می شود از Azure SQL DB یا هر فناوری پایگاه داده دیگری که می تواند دسترسی بالا و مقیاس پذیری بالا را ارائه دهد، استفاده کنید. به عنوان مثال، برای یک رویکرد NoSQL، ممکن است CosmosDB را انتخاب کنید.در نهایت، با ویرایش فایل‌های فراداده Dockerfile و docker-compose.yml، می‌توانید نحوه ایجاد تصویر این کانتینر را پیکربندی کنید - از چه تصویری پایه استفاده می‌کند، به علاوه تنظیمات طراحی مانند نام‌های داخلی و خارجی و پورت‌های TCP.پیاده سازی یک میکروسرویس ساده CRUD با ASP.NET Coreبرای پیاده سازی یک میکروسرویس ساده CRUD با استفاده از دات نت و ویژوال استودیو، با ایجاد یک پروژه ASP.NET Core Web API ساده (که بر روی دات نت اجرا می شود تا بتواند روی هاست لینوکس داکر اجرا شود) شروع می کنید.برای ایجاد یک پروژه ASP.NET Core Web API، ابتدا یک ASP.NET Core Web Application و سپس نوع API را انتخاب کنید. پس از ایجاد پروژه، می‌توانید کنترل‌کننده‌های MVC خود را مانند هر پروژه Web API دیگری با استفاده از Entity Framework API یا سایر API پیاده‌سازی کنید. در یک پروژه Web API جدید، می توانید ببینید که تنها وابستگی شما در آن میکروسرویس به خود ASP.NET Core است.پروژه API شامل ارجاعاتی به بسته Microsoft.AspNetCore.App NuGet است که شامل ارجاع به تمام بسته های ضروری است. این می تواند شامل برخی از بسته های دیگر نیز باشد.پیاده سازی خدمات CRUD Web API با Entity Framework CoreEntity Framework (EF) Core یک نسخه سبک، قابل توسعه و چند پلتفرمی از فناوری محبوب دسترسی به داده Entity Framework است. EF Core یک نگاشت شی-رابطه ای (ORM) است که به توسعه دهندگان دات نت امکان می دهد با استفاده از اشیاء دات نت با پایگاه داده کار کنند.میکروسرویس کاتالوگ از EF و ارائه دهنده SQL Server استفاده می کند زیرا پایگاه داده آن در یک ظرف با تصویر SQL Server برای Linux Docker اجرا می شود. با این حال، پایگاه داده می تواند در هر سرور SQL، مانند Windows on-premises یا Azure SQL DB مستقر شود. تنها چیزی که باید تغییر دهید رشته اتصال در میکروسرویس ASP.NET Web API است.مدل دادهبا EF Core، دسترسی به داده ها با استفاده از یک مدل انجام می شود. یک مدل از کلاس های موجودیت (مدل دامنه) و یک زمینه مشتق شده (DbContext) تشکیل شده است که یک جلسه با پایگاه داده را نشان می دهد و به شما امکان می دهد داده ها را پرس و جو کنید و ذخیره کنید. شما می توانید یک مدل از یک پایگاه داده موجود ایجاد کنید، به صورت دستی یک مدل را کدنویسی کنید تا با پایگاه داده خود مطابقت داشته باشد، یا از تکنیک مهاجرت EF برای ایجاد یک پایگاه داده از مدل خود، با استفاده از رویکرد کد اول استفاده کنید (که باعث می شود پایگاه داده به عنوان مدل شما تکامل یابد. در طول زمان تغییر می کند). برای میکروسرویس کاتالوگ از آخرین رویکرد استفاده شده است. می توانید نمونه ای از کلاس موجودیت CatalogItem را در مثال کد زیر مشاهده کنید، که یک کلاس موجودیت ساده Plain Old Class Object (POCO) است.public class CatalogItem{ public int Id { get; set; } public string Name { get; set; } public string Description { get; set; } public decimal Price { get; set; } public string PictureFileName { get; set; } public string PictureUri { get; set; } public int CatalogTypeId { get; set; } public CatalogType CatalogType { get; set; } public int CatalogBrandId { get; set; } public CatalogBrand CatalogBrand { get; set; } public int AvailableStock { get; set; } public int RestockThreshold { get; set; } public int MaxStockThreshold { get; set; } public bool OnReorder { get; set; } public CatalogItem() { } // Additional code ...}شما همچنین به یک DbContext نیاز دارید که یک جلسه با پایگاه داده را نشان دهد. برای میکروسرویس کاتالوگ، کلاس CatalogContext از کلاس پایه DbContext مشتق شده است، همانطور که در مثال زیر نشان داده شده است:public class CatalogContext : DbContext{ public CatalogContext(DbContextOptions options) : base(options) { } public DbSet CatalogItems { get; set; } public DbSet CatalogBrands { get; set; } public DbSet CatalogTypes { get; set; } // Additional code ...}می توانید پیاده سازی های اضافی DbContext داشته باشید. به عنوان مثال، در نمونه ریزسرویس Catalog.API، یک DbContext دوم به نام CatalogContextSeed وجود دارد که در اولین باری که سعی می کند به پایگاه داده دسترسی پیدا کند، به طور خودکار داده های نمونه را پر می کند. این روش برای داده های آزمایشی و برای سناریوهای آزمایش خودکار نیز مفید است.در DbContext، شما از روش OnModelCreating برای سفارشی کردن نگاشت های موجودیت شی/پایگاه داده و سایر نقاط توسعه پذیری EF استفاده می کنید.جستجوی داده ها از کنترلرهای Web APIنمونه‌های کلاس‌های موجودیت شما معمولاً از پایگاه داده با استفاده از زبان یکپارچه Query (LINQ) بازیابی می‌شوند، همانطور که در مثال زیر نشان داده شده است:[Route("api/v1/[controller]")]public class CatalogController : ControllerBase{ private readonly CatalogContext _catalogContext; private readonly CatalogSettings _settings; private readonly ICatalogIntegrationEventService _catalogIntegrationEventService; public CatalogController( CatalogContext context, IOptionsSnapshot settings, ICatalogIntegrationEventService catalogIntegrationEventService) { _catalogContext = context ?? throw new ArgumentNullException(nameof(context)); _catalogIntegrationEventService = catalogIntegrationEventService ?? throw new ArgumentNullException(nameof(catalogIntegrationEventService)); _settings = settings.Value; context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking; } // GET api/v1/[controller]/items[?pageSize=3&pageIndex=10] [HttpGet] [Route("items")] [ProducesResponseType(typeof(PaginatedItemsViewModel), (int)HttpStatusCode.OK)] [ProducesResponseType(typeof(IEnumerable), (int)HttpStatusCode.OK)] [ProducesResponseType((int)HttpStatusCode.BadRequest)] public async Task ItemsAsync( [FromQuery]int pageSize = 10, [FromQuery]int pageIndex = 0, string ids = null) { if (!string.IsNullOrEmpty(ids)) { var items = await GetItemsByIdsAsync(ids); if (!items.Any()) { return BadRequest("ids value invalid. Must be comma-separated list of numbers"); } return Ok(items); } var totalItems = await _catalogContext.CatalogItems .LongCountAsync(); var itemsOnPage = await _catalogContext.CatalogItems .OrderBy(c => c.Name) .Skip(pageSize * pageIndex) .Take(pageSize) .ToListAsync(); itemsOnPage = ChangeUriPlaceholder(itemsOnPage); var model = new PaginatedItemsViewModel( pageIndex, pageSize, totalItems, itemsOnPage); return Ok(model); } //...}ذخیره داده هاداده ها با استفاده از نمونه هایی از کلاس های موجودیت شما در پایگاه داده ایجاد، حذف و اصلاح می شوند. می‌توانید کدی مانند مثال سخت‌کد زیر (در این مورد داده‌های ساختگی) به کنترل‌کننده‌های Web API خود اضافه کنید.var catalogItem = new CatalogItem() {CatalogTypeId=2, CatalogBrandId=2, Name="Roslyn T-Shirt", Price = 12};_context.Catalog.Add(catalogItem);_context.SaveChanges();تزریق وابستگی در کنترلرهای ASP.NET Core و Web APIدر ASP.NET Core، می توانید از تزریق وابستگی (DI) خارج از جعبه استفاده کنید. شما نیازی به راه اندازی یک کانتینر وارونگی کنترل (IoC) شخص ثالث ندارید، اگرچه در صورت تمایل می توانید کانتینر IoC مورد نظر خود را به زیرساخت هسته ASP.NET وصل کنید. در این حالت، به این معنی است که می توانید مستقیماً EF DBContext یا مخازن اضافی مورد نیاز را از طریق سازنده کنترلر تزریق کنید.در کلاس CatalogController که قبلا ذکر شد، نوع CatalogContext (که از DbContext به ارث می رسد) همراه با سایر اشیاء مورد نیاز در سازنده(CatalogController) تزریق می شود.یک پیکربندی مهم برای راه اندازی در پروژه Web API ثبت کلاس DbContext در ظرف IoC سرویس است. شما معمولاً این کار را در کلاس Startup با فراخوانی سرویس ها انجام می دهید. متد AddDbContext() در داخل متد ConfigureServices()، همانطور که در مثال ساده شده زیر نشان داده شده است:public void ConfigureServices(IServiceCollection services){ // Additional code... services.AddDbContext(options => { options.UseSqlServer(Configuration["ConnectionString"], sqlServerOptionsAction: sqlOptions => { sqlOptions.MigrationsAssembly( typeof(Startup).GetTypeInfo().Assembly.GetName().Name); //Configuring Connection Resiliency: sqlOptions. EnableRetryOnFailure(maxRetryCount: 5, maxRetryDelay: TimeSpan.FromSeconds(30), errorNumbersToAdd: null); }); // Changing default behavior when client evaluation occurs to throw. // Default in EFCore would be to log warning when client evaluation is done. options.ConfigureWarnings(warnings => warnings.Throw( RelationalEventId.QueryClientEvaluationWarning)); }); //...}

یک برنامه کاربردی میکروسرویس گرا طراحی کنید قسمت دوم

Ehsan — Sat, 11 Feb 2023 15:17:58 +0330

مزایای یک راه حل مبتنی بر میکروسرویسراه حل مبتنی بر میکروسرویس مانند این مزایای بسیاری دارد:هر میکروسرویس نسبتاً کوچک است - مدیریت و تکامل آن آسان است. به طور مشخص:درک و شروع سریع با بهره وری خوب برای یک توسعه دهنده آسان است.کانتینرها سریع شروع می شوند، که باعث می شود توسعه دهندگان بهره وری بیشتری داشته باشند.یک IDE مانند ویژوال استودیو می تواند پروژه های کوچکتر را سریع بارگذاری کند و توسعه دهندگان را سازنده کند.هر میکروسرویس می‌تواند مستقل از سایر میکروسرویس‌ها طراحی، توسعه و استقرار شود، که چابکی را فراهم می‌کنند، زیرا استفاده مکرر نسخه‌های جدید میکروسرویس‌ها آسان‌تر است.این امکان وجود دارد که بخش های جداگانه برنامه را کوچک کنید. به عنوان مثال، خدمات کاتالوگ یا خدمات سبد خرید ممکن است نیاز به کوچک شدن داشته باشد، اما نه فرآیند سفارش. یک زیرساخت میکروسرویس با توجه به منابع مورد استفاده در هنگام مقیاس بندی بسیار کارآمدتر از یک معماری یکپارچه خواهد بود.می توانید کار توسعه را بین چندین تیم تقسیم کنید. هر سرویس می تواند متعلق به یک تیم توسعه باشد. هر تیم می‌تواند خدمات خود را مستقل از بقیه تیم‌ها مدیریت، توسعه، استقرار و مقیاس‌بندی کند.مسائل منزوی تر هستند. اگر مشکلی در یک سرویس وجود داشته باشد، در ابتدا فقط آن سرویس تحت تأثیر قرار می گیرد (به جز زمانی که از طراحی اشتباه استفاده می شود، با وابستگی مستقیم بین میکروسرویس ها)، و سایر سرویس ها می توانند به رسیدگی به درخواست ها ادامه دهند. در مقابل، یک جزء معیوب در یک معماری استقرار یکپارچه می‌تواند کل سیستم را خراب کند، به خصوص زمانی که شامل منابعی مانند نشت حافظه باشد. علاوه بر این، هنگامی که مشکلی در یک میکروسرویس حل می‌شود، می‌توانید فقط میکروسرویس آسیب‌دیده را بدون تأثیر بر بقیه برنامه‌ها مستقر کنید.می توانید از آخرین فناوری ها استفاده کنید. از آنجایی که می‌توانید به‌طور مستقل شروع به توسعه سرویس‌ها کنید و آنها را در کنار هم اجرا کنید (به لطف کانتینرها و دات‌نت)، می‌توانید به‌جای گیرکردن در یک پشته یا فریم‌ورک قدیمی‌تر برای کل برنامه، از جدیدترین فناوری‌ها و فریم‌ورک‌ها به‌درستی استفاده کنید.معایب یک راه حل مبتنی بر میکروسرویسراه حل مبتنی بر میکروسرویس مانند این نیز دارای معایبی است:برنامه توزیع شده توزیع برنامه پیچیدگی را برای توسعه دهندگان در هنگام طراحی و ساخت سرویس ها اضافه می کند. به عنوان مثال، توسعه دهندگان باید ارتباطات بین سرویسی را با استفاده از پروتکل هایی مانند HTTP یا AMPQ پیاده سازی کنند، که پیچیدگی آزمایش و مدیریت استثنا را اضافه می کند. همچنین تاخیر را به سیستم اضافه می کند.پیچیدگی استقرار برنامه‌ای که ده‌ها نوع میکروسرویس دارد و به مقیاس‌پذیری بالایی نیاز دارد (نیاز دارد بتواند نمونه‌های زیادی را در هر سرویس ایجاد کند و آن سرویس‌ها را در بسیاری از میزبان‌ها متعادل کند) به معنای درجه بالایی از پیچیدگی استقرار برای عملیات و مدیریت فناوری اطلاعات است. اگر از یک زیرساخت مبتنی بر میکروسرویس (مانند یک ارکستراتور و زمان‌بندی) استفاده نمی‌کنید، این پیچیدگی بیشتر می‌تواند به تلاش‌های توسعه بسیار بیشتری نسبت به خود برنامه تجاری نیاز داشته باشد.معاملات اتمی تراکنش اتمی بین چندین میکروسرویس معمولا امکان پذیر نیست. الزامات کسب و کار باید سازگاری نهایی بین ریزسرویس های متعدد را در بر گیرد.افزایش نیاز به منابع جهانی (کل حافظه، درایوها و منابع شبکه برای همه سرورها یا هاست ها). در بسیاری از موارد، هنگامی که یک برنامه یکپارچه را با رویکرد میکروسرویس جایگزین می‌کنید، مقدار منابع جهانی اولیه مورد نیاز برنامه جدید مبتنی بر میکروسرویس از نیازهای زیرساختی برنامه یکپارچه اصلی بیشتر خواهد بود. این رویکرد به این دلیل است که درجه بالاتری از جزئیات و خدمات توزیع شده به منابع جهانی بیشتری نیاز دارد. با این حال، با توجه به هزینه کم منابع به طور کلی و مزیت امکان کوچک کردن بخش‌های خاصی از برنامه در مقایسه با هزینه‌های بلندمدت هنگام توسعه برنامه‌های کاربردی یکپارچه، افزایش استفاده از منابع معمولاً یک معاوضه خوب برای بزرگ و طولانی مدت است. مشکلات مربوط به ارتباط مستقیم مشتری به سرویس میکرو. هنگامی که برنامه بزرگ است، با ده ها میکروسرویس، چالش ها و محدودیت هایی وجود دارد اگر برنامه به ارتباطات مستقیم مشتری به میکرو سرویس نیاز داشته باشد. یک مشکل عدم تطابق احتمالی بین نیازهای مشتری و APIهایی است که توسط هر یک از میکروسرویس ها در معرض دید قرار می گیرند. در موارد خاص، برنامه مشتری ممکن است نیاز به درخواست‌های جداگانه زیادی برای ایجاد رابط کاربری داشته باشد که می‌تواند در اینترنت ناکارآمد باشد و در شبکه تلفن همراه غیرعملی باشد. بنابراین، درخواست ها از برنامه مشتری به سیستم back-end باید به حداقل برسد.یکی دیگر از مشکلات ارتباط مستقیم مشتری به میکروسرویس این است که برخی از میکروسرویس ها ممکن است از پروتکل هایی استفاده کنند که وب پسند نیستند. یک سرویس ممکن است از یک پروتکل باینری استفاده کند، در حالی که سرویس دیگر ممکن است از پیام رسانی AMQP استفاده کند. این پروتکل ها فایروال پسند نیستند و بهتر است به صورت داخلی استفاده شوند. معمولاً یک برنامه باید از پروتکل هایی مانند HTTP و WebSockets برای ارتباط خارج از فایروال استفاده کند.با این حال، یکی دیگر از اشکالات این رویکرد مستقیم مشتری به سرویس این است که بازسازی قراردادها برای آن میکروسرویس ها را دشوار می کند. با گذشت زمان، توسعه دهندگان ممکن است بخواهند نحوه تقسیم سیستم به خدمات را تغییر دهند. برای مثال، ممکن است دو سرویس را ادغام کنند یا یک سرویس را به دو یا چند سرویس تقسیم کنند. با این حال، اگر کلاینت‌ها مستقیماً با سرویس‌ها ارتباط برقرار کنند، انجام این نوع بازسازی می‌تواند سازگاری با برنامه‌های مشتری را از بین ببرد.همانطور که در بخش معماری ذکر شد، هنگام طراحی و ساخت یک برنامه کاربردی پیچیده بر اساس ریزسرویس‌ها، ممکن است به جای رویکرد ساده‌تر ارتباط مشتری به میکروسرویس، از چندین دروازه API ریزدانه استفاده کنید.پارتیشن بندی میکروسرویس ها در نهایت، مهم نیست که چه رویکردی را برای معماری میکروسرویس خود در نظر می گیرید، چالش دیگر تصمیم گیری در مورد نحوه پارتیشن بندی یک برنامه پایان به انتها به چندین میکروسرویس است. همانطور که در بخش معماری راهنما اشاره شد، چندین تکنیک و رویکرد وجود دارد که می توانید از آنها استفاده کنید. اساساً، شما باید مناطقی از برنامه را شناسایی کنید که از مناطق دیگر جدا شده اند و تعداد کمی وابستگی سخت دارند. در بسیاری از موارد، این رویکرد با پارتیشن بندی سرویس ها با استفاده از case همسو می شود. به عنوان مثال، در اپلیکیشن فروشگاه الکترونیکی خود، یک سرویس سفارش داریم که مسئولیت تمامی منطق تجاری مربوط به فرآیند سفارش را بر عهده دارد. ما همچنین سرویس کاتالوگ و سبد خدمات را داریم که قابلیت های دیگر را پیاده سازی می کند. در حالت ایده آل، هر سرویس باید تنها مجموعه کوچکی از مسئولیت ها را داشته باشد. این رویکرد مشابه اصل مسئولیت واحد (SRP) است که برای کلاس ها اعمال می شود، که بیان می کند که یک کلاس باید تنها یک دلیل برای تغییر داشته باشد. اما در این مورد، در مورد میکروسرویس ها است، بنابراین دامنه از یک کلاس بزرگتر خواهد بود. بیشتر از همه، یک میکروسرویس باید مستقل باشد، از انتها به انتها، از جمله مسئولیت منابع داده خودش.الگوهای معماری و طراحی خارجی در مقابل داخلیمعماری خارجی، معماری میکروسرویس است که توسط چندین سرویس، با پیروی از اصول توضیح داده شده در بخش معماری این راهنما، تشکیل شده است. با این حال، بسته به ماهیت هر میکروسرویس، و مستقل از معماری میکروسرویس سطح بالایی که انتخاب می‌کنید، معمول است و گاهی اوقات توصیه می‌شود که معماری‌های داخلی متفاوتی داشته باشید که هرکدام بر اساس الگوهای متفاوتی برای میکروسرویس‌های مختلف هستند. میکروسرویس ها حتی می توانند از فناوری ها و زبان های برنامه نویسی مختلف استفاده کنند. به عنوان مثال، در نمونه eShopOnContainers ما، کاتالوگ، سبد، و ریزسرویس‌های نمایه کاربر ساده هستند (عموماً، زیرسیستم‌های CRUD). بنابراین، معماری داخلی و طراحی آنها ساده است. با این حال، ممکن است شما ریزسرویس‌های دیگری داشته باشید، مانند ریزسرویس سفارش، که پیچیده‌تر است و قوانین تجاری در حال تغییر را با درجه بالایی از پیچیدگی دامنه نشان می‌دهد. در مواردی مانند این، ممکن است بخواهید الگوهای پیشرفته‌تری را در یک میکروسرویس خاص پیاده‌سازی کنید، مانند آن‌هایی که با رویکردهای طراحی دامنه محور (DDD) تعریف شده‌اند، همانطور که در eShopOnContainers سفارش میکروسرویس انجام می‌دهیم. یکی دیگر از دلایل تکنولوژی متفاوت در هر میکروسرویس ممکن است ماهیت هر میکروسرویس باشد. به عنوان مثال، بهتر است به جای زبان برنامه نویسی شی گرا مانند سی شارپ، از یک زبان برنامه نویسی کاربردی مانند F# یا حتی زبانی مانند R اگر حوزه های هوش مصنوعی و یادگیری ماشین را هدف قرار می دهید، استفاده کنید.نکته اصلی این است که هر میکروسرویس می تواند معماری داخلی متفاوتی بر اساس الگوهای طراحی متفاوت داشته باشد. همه ریزسرویس ها نباید با استفاده از الگوهای پیشرفته DDD پیاده سازی شوند، زیرا این امر باعث مهندسی بیش از حد آنها می شود. به طور مشابه، میکروسرویس‌های پیچیده با منطق تجاری دائماً در حال تغییر نباید به عنوان اجزای CRUD پیاده‌سازی شوند، در غیر این صورت می‌توانید کدهای با کیفیت پایین را دریافت کنید.دنیای جدید: الگوهای معماری متعدد و ریزسرویس های چند زبانهالگوهای معماری زیادی توسط معماران و توسعه دهندگان نرم افزار استفاده می شود. موارد زیر به چند مورد (ترکیب سبک های معماری و الگوهای معماری) اشاره شده است:CRUD ساده، تک لایه، تک لایه.سنتی N-Layered.طراحی دامنه محور N-layered.معماری پاک (همانطور که با eShopOnWeb استفاده می شود)تفکیک مسئولیت فرمان و پرس و جو (CQRS).معماری رویداد محور (EDA).شما همچنین می‌توانید میکروسرویس‌ها را با فناوری‌ها و زبان‌های بسیاری مانند ASP.NET Core Web API، NancyFx، ASP.NET Core SignalR (در دسترس با .NET Core 2 یا جدیدتر)، F#، Node.js، Python، Java، C++، بسازید. GoLang، و بیشتر.نکته مهم این است که هیچ الگو یا سبک معماری خاصی و نه فناوری خاصی برای همه شرایط مناسب نیست. الگوی چند معماری و ریزسرویس‌های چند زبانه به این معنی است که می‌توانید زبان‌ها و فناوری‌ها را با نیازهای هر میکروسرویس ترکیب و مطابقت دهید و همچنان آن‌ها را مجبور کنید با یکدیگر صحبت کنند. در برنامه هایی که از ریزسرویس های زیادی تشکیل شده اند (زمینه های محدود در اصطلاحات طراحی دامنه محور، یا به سادگی "زیر سیستم ها" به عنوان ریزسرویس های مستقل)، ممکن است هر میکروسرویس را به روشی متفاوت پیاده سازی کنید. هر کدام ممکن است الگوی معماری متفاوتی داشته باشند و بسته به ماهیت برنامه، الزامات تجاری و اولویت‌ها از زبان‌ها و پایگاه‌های داده متفاوتی استفاده کنند. در برخی موارد، میکروسرویس ها ممکن است مشابه باشند. اما معمولاً اینطور نیست، زیرا مرزهای زمینه و الزامات هر زیرسیستم معمولاً متفاوت است.به عنوان مثال، برای یک برنامه ساده نگهداری CRUD، طراحی و پیاده سازی الگوهای DDD ممکن است منطقی نباشد. اما برای دامنه اصلی یا تجارت اصلی خود، ممکن است لازم باشد الگوهای پیشرفته تری را برای مقابله با پیچیدگی کسب و کار با قوانین تجاری در حال تغییر اعمال کنید.به خصوص هنگامی که با برنامه های کاربردی بزرگ ساخته شده توسط چندین زیرسیستم سروکار دارید، نباید یک معماری سطح بالا را بر اساس یک الگوی معماری واحد اعمال کنید. به عنوان مثال، CQRS نباید به عنوان یک معماری سطح بالا برای یک برنامه کاربردی استفاده شود، اما ممکن است برای مجموعه خاصی از خدمات مفید باشد.هیچ گلوله نقره ای یا الگوی معماری درستی برای هر مورد خاص وجود ندارد. شما نمی توانید "یک الگوی معماری برای حکومت بر همه آنها" داشته باشید. بسته به اولویت های هر میکروسرویس، باید روش متفاوتی را برای هر یک انتخاب کنید.

یک برنامه کاربردی میکروسرویس گرا طراحی کنید قسمت اول

Ehsan — Sat, 11 Feb 2023 15:05:44 +0330

مشخصات اپلیکیشنبرنامه فرضی درخواست ها را با اجرای منطق تجاری، دسترسی به پایگاه های داده و سپس برگرداندن پاسخ های HTML، JSON یا XML انجام می دهد. می گوییم که برنامه باید از کلاینت های مختلفی پشتیبانی کند، از جمله مرورگرهای دسکتاپ که دارای برنامه های کاربردی یک صفحه (SPAs)، برنامه های وب سنتی، برنامه های وب تلفن همراه و برنامه های موبایل بومی هستند. این برنامه همچنین ممکن است یک API را در معرض مصرف اشخاص ثالث قرار دهد. همچنین باید بتواند میکروسرویس ها یا برنامه های کاربردی خارجی خود را به صورت ناهمزمان ادغام کند، به طوری که این رویکرد به انعطاف پذیری میکروسرویس ها در صورت خرابی های جزئی کمک می کند.برنامه از این نوع اجزا تشکیل شده است:اجزای ارائه این مؤلفه ها مسئول مدیریت رابط کاربری و مصرف سرویس های راه دور هستند.منطق دامنه یا تجارت این جزء منطق دامنه برنامه است.منطق دسترسی به پایگاه داده این جزء شامل اجزای دسترسی به داده است که مسئول دسترسی به پایگاه های داده (SQL یا NoSQL) هستند.منطق یکپارچه سازی برنامه این جزء شامل یک کانال پیام رسانی است که بر اساس کارگزاران پیام است.این برنامه به مقیاس پذیری بالایی نیاز دارد، در حالی که به زیرسیستم های عمودی خود اجازه می دهد تا به طور مستقل مقیاس شوند، زیرا زیرسیستم های خاصی نسبت به سایرین به مقیاس پذیری بیشتری نیاز دارند.برنامه باید بتواند در محیط‌های زیرساختی متعدد (چندین ابر عمومی و در محل) مستقر شود و در حالت ایده‌آل باید بین پلتفرمی باشد و بتواند به راحتی از لینوکس به ویندوز (یا بالعکس) حرکت کند.زمینه تیم توسعهما همچنین موارد زیر را در مورد فرآیند توسعه برنامه فرض می کنیم:چندین تیم توسعه دهنده دارید که بر روی حوزه های مختلف تجاری برنامه تمرکز می کنند.اعضای تیم جدید باید به سرعت سازنده شوند و برنامه باید به راحتی قابل درک و اصلاح باشد.این برنامه یک تکامل طولانی مدت و قوانین تجاری دائماً در حال تغییر خواهد داشت.شما به قابلیت نگهداری طولانی مدت خوب نیاز دارید، به این معنی که هنگام اجرای تغییرات جدید در آینده چابکی داشته باشید و در عین حال قادر به به روز رسانی چندین زیرسیستم با حداقل تأثیر بر سایر زیرسیستم ها باشید.شما می خواهید یکپارچه سازی مداوم و استقرار مداوم برنامه را تمرین کنید.شما می خواهید از مزایای فناوری های نوظهور (فریم ورک ها، زبان های برنامه نویسی و غیره) در حین تکامل برنامه استفاده کنید. هنگام حرکت به سمت فناوری‌های جدید، نمی‌خواهید برنامه را به طور کامل تغییر دهید، زیرا این امر منجر به هزینه‌های بالا می‌شود و بر قابلیت پیش‌بینی و پایداری برنامه تأثیر می‌گذارد.انتخاب یک معماریمعماری استقرار برنامه چگونه باید باشد؟ مشخصات برنامه، همراه با زمینه توسعه، قویاً نشان می‌دهد که باید برنامه را با تجزیه آن به زیرسیستم‌های مستقل در قالب میکروسرویس‌ها و کانتینرهای مشترک، طراحی کنید، جایی که میکروسرویس یک کانتینر است.در این رویکرد، هر سرویس (کانتینر) مجموعه ای از توابع منسجم و مرتبط با هم را پیاده سازی می کند. به عنوان مثال، یک برنامه ممکن است از خدماتی مانند سرویس کاتالوگ، سرویس سفارش، خدمات سبد خرید، خدمات نمایه کاربر و غیره تشکیل شده باشد.میکروسرویس ها با استفاده از پروتکل هایی مانند HTTP (REST) و همچنین به صورت ناهمزمان (مثلاً با استفاده از AMQP) در صورت امکان ارتباط برقرار می کنند، به خصوص هنگام انتشار به روز رسانی با رویدادهای یکپارچه سازی.میکروسرویس ها به صورت کانتینر مستقل از یکدیگر توسعه یافته و مستقر می شوند. این رویکرد به این معنی است که یک تیم توسعه می‌تواند یک میکروسرویس خاص را بدون تأثیر بر سایر زیرسیستم‌ها توسعه و استقرار دهد.هر میکروسرویس پایگاه داده مخصوص به خود را دارد که به آن امکان جداسازی کامل از سایر میکروسرویس ها را می دهد. در صورت لزوم، سازگاری بین پایگاه‌های داده از میکروسرویس‌های مختلف با استفاده از رویدادهای یکپارچه‌سازی در سطح برنامه (از طریق یک گذرگاه رویداد منطقی)، همانطور که در Command and Query Responsibility Segregation (CQRS) انجام می‌شود، به دست می‌آید. به همین دلیل، محدودیت‌های تجاری باید سازگاری نهایی بین ریزسرویس‌های متعدد و پایگاه‌های داده مرتبط را در بر گیرند.eShopOnContainers: یک برنامه مرجع برای دات نت و میکروسرویس هایی که با استفاده از کانتینرها مستقر شده اند.برای اینکه بتوانید به جای فکر کردن در مورد یک دامنه تجاری فرضی که ممکن است ندانید، بر روی معماری و فناوری تمرکز کنید، ما یک دامنه تجاری شناخته شده را انتخاب کرده ایم - یعنی یک برنامه تجارت الکترونیکی ساده (فروشگاه الکترونیکی) که ارائه می کند. کاتالوگ محصولات، سفارشات مشتریان را می گیرد، موجودی را تأیید می کند و سایر وظایف تجاری را انجام می دهد. این کد منبع برنامه مبتنی بر کانتینر در مخزن eShopOnContainers GitHub موجود است.این برنامه از چندین زیرسیستم، از جمله چندین بخش جلویی رابط کاربری فروشگاه (یک برنامه وب و یک برنامه تلفن همراه بومی)، به همراه ریزسرویس‌های پشتیبان و کانتینرها برای تمام عملیات مورد نیاز سمت سرور با چندین دروازه API به عنوان نقاط ورودی تلفیقی تشکیل شده است. محیط میزبانی. در شکل 6-1، چندین کانتینر را می بینید که در یک میزبان Docker مستقر شده اند. این مورد در هنگام استقرار در یک میزبان Docker با دستور docker-compose up صدق می کند. با این حال، اگر از یک ارکستراتور یا کانتینر کلاستر استفاده می‌کنید، هر کانتینر می‌تواند در یک میزبان (گره) متفاوت اجرا شود، و هر گره می‌تواند هر تعداد کانتینر را اجرا کند، همانطور که قبلا در بخش معماری توضیح دادیم.معماری ارتباطات برنامه eShopOnContainers بسته به نوع عملکرد عملکردی (پرسش‌ها در مقابل به‌روزرسانی‌ها و تراکنش‌ها) از دو نوع ارتباط استفاده می‌کند:ارتباط مشتری به میکروسرویس Http از طریق دروازه های API. این رویکرد برای پرس و جوها و هنگام پذیرش دستورات به روز رسانی یا تراکنش از برنامه های مشتری استفاده می شود. روش استفاده از API Gateways در بخش های بعدی به تفصیل توضیح داده شده است.ارتباطات ناهمزمان مبتنی بر رویداد. این ارتباط از طریق یک گذرگاه رویداد برای انتشار به‌روزرسانی‌ها در میکروسرویس‌ها یا ادغام با برنامه‌های خارجی انجام می‌شود. گذرگاه رویداد را می توان با هر فناوری زیرساخت واسطه پیام رسانی مانند RabbitMQ یا با استفاده از اتوبوس های خدمات سطح بالاتر (سطح انتزاعی) مانند Azure Service Bus، NServiceBus، MassTransit یا Brighter پیاده سازی کرد.این برنامه به عنوان مجموعه ای از میکروسرویس ها در قالب کانتینرها مستقر شده است. برنامه های سرویس گیرنده می توانند با آن میکروسرویس هایی که به صورت کانتینر اجرا می شوند از طریق URL های عمومی منتشر شده توسط API Gateways ارتباط برقرار کنند.حاکمیت داده در هر میکروسرویسدر برنامه نمونه، هر میکروسرویس دارای پایگاه داده یا منبع داده خود است، اگرچه همه پایگاه های داده SQL Server به عنوان یک ظرف واحد مستقر شده اند. این تصمیم طراحی فقط به این دلیل گرفته شد که یک توسعه دهنده به راحتی کد را از GitHub دریافت کند، آن را شبیه سازی کند و آن را در Visual Studio یا Visual Studio Code باز کند. یا متناوبا، کامپایل کردن تصاویر Docker سفارشی را با استفاده از NET CLI و Docker CLI، و سپس استقرار و اجرای آنها در یک محیط توسعه Docker را آسان می کند. در هر صورت، استفاده از کانتینرها برای منابع داده به توسعه دهندگان این امکان را می دهد که در عرض چند دقیقه بدون نیاز به ارائه یک پایگاه داده خارجی یا هر منبع داده دیگری با وابستگی سخت به زیرساخت (ابر یا درون محل) بسازند و مستقر کنند.در یک محیط تولید واقعی، برای دسترسی بالا و مقیاس‌پذیری، پایگاه‌های داده باید بر اساس سرورهای پایگاه داده در فضای ابری یا درون محل باشند، اما نه در کانتینرها.بنابراین، واحدهای استقرار برای میکروسرویس ها (و حتی برای پایگاه های داده در این برنامه) کانتینرهای Docker هستند و برنامه مرجع یک برنامه کاربردی چند کانتینری است که اصول میکروسرویس ها را در بر می گیرد.

طراحی و توسعه اپلیکیشن های دات نت مبتنی بر چند کانتینر و میکروسرویس

Ehsan — Sat, 11 Feb 2023 14:36:01 +0330

توسعه برنامه های میکروسرویس کانتینری به این معنی است که شما در حال ساخت برنامه های چند کانتینری هستید. با این حال، یک برنامه چند کانتینری نیز می تواند ساده تر باشد - برای مثال، یک برنامه سه لایه - و ممکن است با استفاده از معماری میکروسرویس ساخته نشود.قبلاً این سؤال را مطرح کردیم که "آیا Docker هنگام ساخت یک معماری میکروسرویس ضروری است؟" پاسخ یک نه واضح است. Docker یک توانمندساز است و می تواند مزایای قابل توجهی ارائه دهد، اما کانتینرها و Docker نیاز سختی برای میکروسرویس ها نیستند. به عنوان مثال، می‌توانید هنگام استفاده از Azure Service Fabric یک برنامه مبتنی بر میکروسرویس با یا بدون Docker ایجاد کنید، که از میکروسرویس‌هایی که به‌عنوان فرآیندهای ساده یا به‌عنوان کانتینرهای Docker اجرا می‌شوند، پشتیبانی می‌کند.با این حال، اگر می‌دانید چگونه یک برنامه کاربردی مبتنی بر میکروسرویس‌ها را طراحی و توسعه دهید که بر پایه کانتینرهای Docker نیز باشد، می‌توانید هر مدل کاربردی ساده‌تری را طراحی و توسعه دهید. برای مثال، ممکن است یک برنامه کاربردی سه لایه طراحی کنید که به رویکرد چند کانتینری نیز نیاز دارد. به همین دلیل، و از آنجا که معماری‌های میکروسرویس یک روند مهم در دنیای کانتینر هستند، این بخش بر روی پیاده‌سازی معماری میکروسرویس با استفاده از کانتینرهای Docker تمرکز دارد.

میکروسرویس ها و برنامه های کاربردی چند کانتینری را برای مقیاس پذیری و در دسترس بودن بالا هماهنگ کنید

Ehsan — Sat, 11 Feb 2023 14:31:13 +0330

اگر برنامه شما بر اساس میکروسرویس ها باشد یا به سادگی در چندین کانتینر تقسیم شده باشد، آواز ارکسترها برای برنامه های آماده تولید ضروری است. همانطور که قبلاً معرفی شد، در یک رویکرد مبتنی بر میکروسرویس، هر میکروسرویس دارای مدل و داده‌های خود است تا از نقطه نظر توسعه و استقرار مستقل باشد. اما حتی اگر یک برنامه کاربردی سنتی تری داشته باشید که از چندین سرویس تشکیل شده است (مانند SOA)، چندین کانتینر یا سرویس نیز خواهید داشت که شامل یک برنامه تجاری واحد است که باید به عنوان یک سیستم توزیع شده مستقر شوند. این نوع سیستم ها برای بزرگ کردن و مدیریت پیچیده هستند. بنابراین، اگر می خواهید یک برنامه چند کانتینری آماده و مقیاس پذیر داشته باشید، کاملاً به یک ارکستراتور نیاز دارید.شما از یک کانتینر برای هر نمونه سرویس استفاده می کنید. کانتینرهای داکر «واحدهای استقرار» هستند و کانتینر نمونه‌ای از داکر است. میزبان بسیاری از کانتینرها را اداره می کند. به نظر یک رویکرد منطقی است. اما چگونه می‌توانید با متعادل‌سازی بار، مسیریابی و هماهنگ‌سازی این برنامه‌های کاربردی ترکیب‌شده برخورد کنید؟Docker Engine ساده در هاست‌های Docker تنها نیازهای مدیریت نمونه‌های تصویر واحد را در یک میزبان برآورده می‌کند، اما زمانی که صحبت از مدیریت چندین کانتینر مستقر در میزبان‌های متعدد برای برنامه‌های پیچیده‌تر توزیع‌شده به میان می‌آید، کوتاهی می‌کند. در بیشتر موارد، شما به یک پلتفرم مدیریتی نیاز دارید که به طور خودکار کانتینرها را راه اندازی کند، کانتینرهایی با چندین نمونه در هر تصویر را کاهش دهد، آنها را به حالت تعلیق درآورد یا در صورت نیاز آنها را خاموش کند، و در حالت ایده آل نیز نحوه دسترسی آنها به منابعی مانند شبکه و ذخیره داده را کنترل کند.برای فراتر رفتن از مدیریت کانتینرهای منفرد یا برنامه‌های ترکیبی ساده و حرکت به سمت برنامه‌های بزرگ‌تر سازمانی با میکروسرویس‌ها، باید به پلتفرم‌های هماهنگ‌سازی و خوشه‌بندی روی بیاورید.از نقطه نظر معماری و توسعه، اگر در حال ساخت یک شرکت بزرگ متشکل از برنامه های کاربردی مبتنی بر میکروسرویس هستید، درک پلتفرم ها و محصولات زیر که از سناریوهای پیشرفته پشتیبانی می کنند بسیار مهم است:خوشه ها و ارکسترها. هنگامی که شما نیاز دارید که برنامه‌ها را در بسیاری از میزبان‌های Docker مقیاس‌بندی کنید، مانند زمانی که یک برنامه بزرگ مبتنی بر میکروسرویس، بسیار مهم است که بتوانید همه آن میزبان‌ها را به عنوان یک خوشه واحد با انتزاع کردن پیچیدگی پلتفرم زیربنایی مدیریت کنید. این چیزی است که گروه های کانتینر و ارکستراتورها ارائه می دهند. Kubernetes نمونه ای از ارکستراست و در Azure از طریق Azure Kubernetes Service در دسترس است.برنامه ریزان. زمان‌بندی به این معنی است که یک مدیر این قابلیت را داشته باشد که کانتینرها را در یک خوشه راه‌اندازی کند تا آنها یک رابط کاربری نیز ارائه دهند. یک زمان‌بندی خوشه وظایف متعددی دارد: استفاده کارآمد از منابع خوشه، تنظیم محدودیت‌های ارائه‌شده توسط کاربر، بارگذاری کارآمد محفظه‌ها در گره‌ها یا میزبان‌ها، و مقاوم بودن در برابر خطاها و در عین حال در دسترس بودن بالا.مفاهیم خوشه و زمانبندی ارتباط نزدیکی با هم دارند، بنابراین محصولات ارائه شده توسط فروشندگان مختلف اغلب هر دو مجموعه از قابلیت ها را ارائه می دهند. لیست زیر مهم ترین پلتفرم ها و انتخاب های نرم افزاری را که برای خوشه ها و زمان بندی ها دارید نشان می دهد. این ارکسترها معمولاً در ابرهای عمومی مانند Azure ارائه می شوند.استفاده از ارکسترهای مبتنی بر کانتینر در Microsoft Azureچندین فروشنده ابری پشتیبانی از کانتینرهای Docker به علاوه خوشه‌های Docker و پشتیبانی هماهنگ‌سازی را ارائه می‌کنند، از جمله Microsoft Azure، Amazon EC2 Container Service و Google Container Engine. Microsoft Azure از طریق سرویس Azure Kubernetes (AKS) پشتیبانی از Docker Cluster و Orchestrator را فراهم می کند.با استفاده از سرویس Azure Kubernetesیک خوشه Kubernetes چندین میزبان Docker را جمع آوری می کند و آنها را به عنوان یک میزبان Docker مجازی نمایش می دهد، بنابراین شما می توانید چندین کانتینر را در خوشه مستقر کنید و با هر تعداد نمونه کانتینر آن را کوچک کنید. این خوشه تمام لوله‌کشی‌های مدیریتی پیچیده، مانند مقیاس‌پذیری، سلامت، و غیره را مدیریت می‌کند.AKS راهی برای ساده‌سازی ایجاد، پیکربندی و مدیریت مجموعه‌ای از ماشین‌های مجازی در Azure فراهم می‌کند که برای اجرای برنامه‌های کانتینری از پیش پیکربندی شده‌اند. با استفاده از یک پیکربندی بهینه از ابزارهای برنامه‌ریزی و هماهنگ‌سازی منبع باز محبوب، AKS شما را قادر می‌سازد تا از مهارت‌های موجود خود استفاده کنید یا از تخصص بزرگ و رو به رشد جامعه برای استقرار و مدیریت برنامه‌های کاربردی مبتنی بر کانتینر در Microsoft Azure استفاده کنید.سرویس Azure Kubernetes پیکربندی ابزارها و فناوری های منبع باز خوشه بندی محبوب Docker را به طور خاص برای Azure بهینه می کند. شما یک راه حل باز دریافت می کنید که قابلیت حمل هم برای کانتینرها و هم برای پیکربندی برنامه شما ارائه می دهد. شما اندازه، تعداد میزبان‌ها و ابزارهای ارکستراتور را انتخاب می‌کنید و AKS همه چیز را مدیریت می‌کند.محیط توسعه برای Kubernetesدر محیط توسعه، داکر در جولای 2018 اعلام کرد که Kubernetes می‌تواند با نصب Docker Desktop در یک ماشین توسعه (ویندوز 10 یا macOS) نیز اجرا شود. همانطور که در شکل 4-25 نشان داده شده است، می توانید بعداً برای آزمایش های ادغام بیشتر در فضای ابری (AKS) مستقر شوید.شروع به کار با سرویس Azure Kubernetes (AKS)برای شروع استفاده از AKS، یک خوشه AKS را از پورتال Azure یا با استفاده از CLI مستقر می کنید. برای اطلاعات بیشتر در مورد استقرار یک خوشه Kubernetes در Azure، به Deploy an Azure Kubernetes Service (AKS) خوشه مراجعه کنید.هیچ هزینه ای برای هیچ یک از نرم افزارهای نصب شده به طور پیش فرض به عنوان بخشی از AKS وجود ندارد. همه گزینه های پیش فرض با نرم افزار منبع باز پیاده سازی می شوند. AKS برای چندین ماشین مجازی در Azure در دسترس است. فقط برای نمونه‌های محاسباتی که انتخاب می‌کنید، و سایر منابع زیرساختی مصرف‌شده، مانند ذخیره‌سازی و شبکه، هزینه دریافت می‌کنید. هیچ هزینه افزایشی برای خود AKS وجود ندارد.گزینه پیش‌فرض استقرار تولید برای Kubernetes استفاده از نمودارهای Helm است که در بخش بعدی معرفی می‌شوند.با نمودار Helm در خوشه های Kubernetes مستقر کنیدهنگام استقرار یک برنامه در یک خوشه Kubernetes، می‌توانید از ابزار اصلی kubectl.exe CLI با استفاده از فایل‌های استقرار بر اساس فرمت اصلی (فایل‌هایyaml) استفاده کنید، همانطور که قبلاً در بخش قبل ذکر شد. با این حال، برای برنامه های پیچیده تر Kubernetes مانند هنگام استقرار برنامه های پیچیده مبتنی بر میکروسرویس، توصیه می شود از Helm استفاده کنید.Helm Charts به شما کمک می‌کند حتی پیچیده‌ترین برنامه Kubernetes را تعریف، نسخه، نصب، اشتراک‌گذاری، ارتقا یا عقب‌گردانی کنید.در ادامه، استفاده از Helm نیز توصیه می‌شود زیرا سایر محیط‌های Kubernetes در Azure، مانند Azure Dev Spaces نیز بر اساس نمودارهای Helm هستند.Helm توسط بنیاد محاسبات بومی ابری (CNCF) - با همکاری مایکروسافت، گوگل، بیتنامی و جامعه مشارکت کنندگان Helm نگهداری می شود.

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

Ehsan — Sat, 11 Feb 2023 13:48:23 +0330

مقابله با خرابی های غیرمنتظره یکی از سخت ترین مشکلات برای حل است، به ویژه در یک سیستم توزیع شده. بسیاری از کدهایی که توسعه دهندگان می نویسند شامل مدیریت استثناها می شود، و همچنین در اینجا بیشترین زمان صرف تست می شود. مشکل بیشتر از نوشتن کد برای رسیدگی به خرابی ها است. وقتی دستگاهی که میکروسرویس در آن کار می کند از کار بیفتد چه اتفاقی می افتد؟ نه تنها باید این خرابی میکروسرویس را تشخیص دهید (مشکلی سخت به خودی خود)، بلکه به چیزی برای راه اندازی مجدد میکروسرویس خود نیز نیاز دارید.یک میکروسرویس باید در برابر خرابی مقاوم باشد و بتواند اغلب در ماشین دیگری برای در دسترس بودن راه اندازی مجدد شود. این انعطاف‌پذیری همچنین به وضعیت ذخیره شده از طرف میکروسرویس مربوط می‌شود، جایی که میکروسرویس می‌تواند این حالت را از آن بازیابی کند، و اینکه آیا میکروسرویس می‌تواند با موفقیت دوباره راه‌اندازی شود. به عبارت دیگر، نیاز به انعطاف پذیری در قابلیت محاسباتی وجود دارد (فرایند می تواند در هر زمانی دوباره راه اندازی شود) و همچنین انعطاف پذیری در حالت یا داده ها (بدون از دست دادن داده ها، و داده ها ثابت می مانند).مشکلات انعطاف‌پذیری در سناریوهای دیگر، مانند زمانی که خرابی در حین ارتقاء برنامه رخ می‌دهد، ترکیب می‌شود. میکروسرویس که با سیستم استقرار کار می‌کند، باید تعیین کند که آیا می‌تواند به سمت نسخه جدیدتر حرکت کند یا در عوض به نسخه قبلی برگردد تا وضعیت ثابتی داشته باشد. سؤالاتی مانند اینکه آیا ماشین های کافی برای ادامه حرکت رو به جلو در دسترس هستند یا خیر و نحوه بازیابی نسخه های قبلی میکروسرویس باید در نظر گرفته شوند. این رویکرد به میکروسرویس نیاز دارد که اطلاعات بهداشتی را منتشر کند تا برنامه کلی و ارکستراتور بتوانند این تصمیمات را بگیرند.علاوه بر این، انعطاف پذیری با نحوه رفتار سیستم های مبتنی بر ابر مرتبط است. همانطور که گفته شد، یک سیستم مبتنی بر ابر باید شکست ها را بپذیرد و سعی کند به طور خودکار آنها را بازیابی کند. به عنوان مثال، در صورت خرابی شبکه یا کانتینر، برنامه های سرویس گیرنده یا سرویس های سرویس گیرنده باید استراتژی برای ارسال مجدد پیام ها یا تلاش مجدد درخواست ها داشته باشند، زیرا در بسیاری از موارد خرابی ها در ابر جزئی هستند. بخش پیاده‌سازی برنامه‌های انعطاف‌پذیر در این راهنما به نحوه رسیدگی به شکست جزئی می‌پردازد. با استفاده از کتابخانه‌هایی مانند Polly که طیف وسیعی از سیاست‌ها را برای رسیدگی به این موضوع ارائه می‌دهد، تکنیک‌هایی مانند تلاش‌های مجدد با عقب‌نشینی نمایی یا الگوی Circuit Breaker در دات‌نت را توصیف می‌کند.مدیریت سلامت و تشخیص در میکروسرویس هاممکن است بدیهی به نظر برسد، و اغلب نادیده گرفته می شود، اما یک میکروسرویس باید سلامت و تشخیص آن را گزارش کند. در غیر این صورت، بینش کمی از دیدگاه عملیات وجود دارد. مرتبط کردن رویدادهای تشخیصی در میان مجموعه‌ای از سرویس‌های مستقل و برخورد با انحرافات ساعت ماشین برای درک ترتیب رویداد، چالش برانگیز است. همانطور که با یک میکروسرویس از طریق پروتکل‌های توافق شده و قالب‌های داده تعامل می‌کنید، نیاز به استانداردسازی در نحوه ثبت رویدادهای سلامت و تشخیصی وجود دارد که در نهایت به فروشگاه رویداد برای جستجو و مشاهده ختم می‌شوند. در رویکرد میکروسرویس‌ها، مهم است که تیم‌های مختلف بر روی یک قالب گزارش واحد به توافق برسند. برای مشاهده رویدادهای تشخیصی در برنامه باید یک رویکرد ثابت وجود داشته باشد.بررسی های سلامتسلامتی با تشخیص متفاوت است. سلامتی در مورد میکروسرویس است که وضعیت فعلی خود را برای انجام اقدامات مناسب گزارش می دهد. یک مثال خوب کار با مکانیسم های ارتقا و استقرار برای حفظ در دسترس بودن است. اگرچه ممکن است یک سرویس در حال حاضر به دلیل خرابی فرآیند یا راه اندازی مجدد ماشین ناسالم باشد، اما ممکن است این سرویس همچنان عملیاتی باشد. آخرین چیزی که شما نیاز دارید این است که با انجام یک ارتقا، این وضعیت را بدتر کنید. بهترین روش این است که ابتدا یک بررسی انجام دهید یا زمانی را برای بهبودی میکروسرویس در نظر بگیرید. رویدادهای بهداشتی از یک میکروسرویس به ما کمک می کند تا تصمیمات آگاهانه بگیریم و در واقع به ایجاد خدمات خود درمانی کمک کنیم.شما همچنین می توانید از یک کتابخانه منبع باز عالی به نام AspNetCore.Diagnostics.HealthChecks استفاده کنید که در GitHub و به عنوان بسته NuGet موجود است. این کتابخانه همچنین چک های سلامتی را انجام می دهد، با یک چرخش، دو نوع بررسی را انجام می دهد:زنده بودن: بررسی می‌کند که آیا میکروسرویس زنده است یا خیر، یعنی می‌تواند درخواست‌ها را بپذیرد و پاسخ دهد.آمادگی: بررسی می کند که آیا وابستگی های میکروسرویس (پایگاه داده، خدمات صف و غیره) خود آماده هستند، بنابراین میکروسرویس می تواند کاری را که قرار است انجام دهد انجام دهد.با استفاده از تشخیص و گزارش جریان رویدادگزارش‌ها اطلاعاتی را درباره نحوه اجرای یک برنامه یا سرویس ارائه می‌دهند، از جمله استثناها، هشدارها و پیام‌های اطلاعاتی ساده. معمولاً، هر گزارش در قالب متنی با یک خط در هر رویداد است، اگرچه استثنائات نیز اغلب رد پشته را در چندین خط نشان می‌دهند.در برنامه های کاربردی مبتنی بر سرور یکپارچه، می توانید گزارش ها را روی یک فایل روی دیسک بنویسید (یک فایل لاگ) و سپس آن را با هر ابزاری تجزیه و تحلیل کنید. از آنجایی که اجرای برنامه محدود به یک سرور ثابت یا VM است، معمولاً تحلیل جریان رویدادها چندان پیچیده نیست. با این حال، در یک برنامه توزیع شده که در آن چندین سرویس در بسیاری از گره‌ها در یک خوشه ارکستراتور اجرا می‌شوند، توانایی مرتبط کردن رویدادهای توزیع شده یک چالش است.یک برنامه کاربردی مبتنی بر میکروسرویس نباید سعی کند جریان خروجی رویدادها یا فایل های گزارش را به تنهایی ذخیره کند و حتی سعی در مدیریت مسیریابی رویدادها به یک مکان مرکزی نداشته باشد. باید شفاف باشد، به این معنی که هر فرآیند فقط باید جریان رویداد خود را در یک خروجی استاندارد بنویسد که زیر آن توسط زیرساخت محیط اجرا که در آن اجرا می‌شود جمع‌آوری می‌شود. نمونه ای از این روترهای جریان رویداد Microsoft.Diagnostic.EventFlow است که جریان های رویداد را از چندین منبع جمع آوری می کند و آن را در سیستم های خروجی منتشر می کند. اینها می توانند شامل خروجی استاندارد ساده برای یک محیط توسعه یا سیستم های ابری مانند Azure Monitor و Azure Diagnostics باشند. همچنین پلتفرم‌ها و ابزارهای تجزیه و تحلیل لاگ شخص ثالث خوبی وجود دارد که می‌تواند گزارش‌ها را جستجو، هشدار، گزارش و نظارت کند، حتی در زمان واقعی، مانند Splunk.ارکسترهایی که اطلاعات سلامت و تشخیص را مدیریت می کنندهنگامی که یک برنامه کاربردی مبتنی بر میکروسرویس ایجاد می کنید، باید با پیچیدگی مقابله کنید. البته برخورد با یک میکروسرویس ساده است، اما ده ها یا صدها نوع و هزاران نمونه میکروسرویس مشکل پیچیده ای است. این فقط در مورد ساختن معماری میکروسرویس شما نیست - اگر می‌خواهید یک سیستم پایدار و منسجم داشته باشید، به دسترسی بالا، آدرس‌پذیری، انعطاف‌پذیری، سلامت و تشخیص نیاز دارید.تیم های توسعه باید بر حل مشکلات تجاری و ایجاد برنامه های کاربردی سفارشی با رویکردهای مبتنی بر میکروسرویس تمرکز کنند. آنها نباید بر حل مشکلات زیرساختی پیچیده تمرکز کنند. اگر این کار را انجام دهند، هزینه هر برنامه کاربردی مبتنی بر میکروسرویس بسیار زیاد خواهد بود. بنابراین، پلتفرم‌های میکروسرویس‌گرا وجود دارند که به آنها ارکستراتور یا خوشه‌های میکروسرویس گفته می‌شود، که سعی در حل مشکلات سخت ساخت و اجرای یک سرویس و استفاده بهینه از منابع زیرساختی دارند. این رویکرد پیچیدگی های ساخت برنامه هایی را که از رویکرد میکروسرویس استفاده می کنند، کاهش می دهد.ممکن است ارکسترهای مختلف شبیه هم به نظر برسند، اما بررسی‌های تشخیصی و سلامتی ارائه شده توسط هر یک از آنها در ویژگی‌ها و وضعیت بلوغ متفاوت است، که گاهی به پلتفرم سیستم‌عامل بستگی دارد.

ایجاد رابط کاربری ترکیبی بر اساس میکروسرویس ها

Ehsan — Sat, 11 Feb 2023 13:39:57 +0330

معماری میکروسرویس‌ها اغلب با مدیریت داده‌ها و منطق سمت سرور شروع می‌شود، اما در بسیاری از موارد، رابط کاربری همچنان به‌عنوان یکپارچه مدیریت می‌شود. با این حال، یک رویکرد پیشرفته تر، به نام micro frontends، طراحی رابط کاربری برنامه شما بر اساس میکروسرویس ها نیز هست. این به معنای داشتن یک رابط کاربری ترکیبی است که توسط میکروسرویس‌ها تولید می‌شود، به‌جای اینکه میکروسرویس‌ها روی سرور وجود داشته باشد و فقط یک برنامه مشتری یکپارچه که ریزسرویس‌ها را مصرف می‌کند. با این رویکرد، میکروسرویس هایی که می سازید می توانند هم با منطق و هم با نمایش بصری کامل شوند.در مقابل، یک رابط کاربری ترکیبی دقیقاً توسط خود میکروسرویس ها ایجاد و تشکیل می شود. برخی از میکروسرویس ها شکل بصری مناطق خاصی از رابط کاربری را هدایت می کنند. تفاوت اصلی این است که شما اجزای رابط کاربری مشتری (برای مثال کلاس‌های تایپ اسکریپت) بر اساس الگوها دارید، و ViewModel-shaping-UI برای آن الگوها از هر میکروسرویس می‌آید.در زمان راه اندازی برنامه مشتری، هر یک از مؤلفه های رابط کاربری مشتری (برای مثال کلاس های تایپ اسکریپت) خود را با یک میکروسرویس زیرساختی که قادر به ارائه ViewModels برای یک سناریوی معین است، ثبت می کند. اگر میکروسرویس شکل را تغییر دهد، رابط کاربری نیز تغییر می کند.هر یک از آن میکروسرویس‌های ترکیب رابط کاربری مشابه یک دروازه کوچک API خواهد بود. اما در این مورد، هر یک مسئول یک ناحیه کوچک UI هستند.یک رویکرد UI ترکیبی که توسط میکروسرویس ها هدایت می شود، بسته به اینکه از چه فناوری های رابط کاربری استفاده می کنید، می تواند چالش برانگیزتر یا کمتر باشد. به عنوان مثال، شما از تکنیک های مشابهی برای ساخت یک برنامه وب سنتی استفاده نمی کنید که برای ساختن یک SPA یا برای برنامه موبایل بومی استفاده می کنید (مانند توسعه برنامه های Xamarin، که می تواند برای این رویکرد چالش برانگیزتر باشد).برنامه نمونه eShopOnContainers به دلایل متعدد از رویکرد UI یکپارچه استفاده می کند. ابتدا، مقدمه ای بر میکروسرویس ها و ظروف است. یک رابط کاربری ترکیبی پیشرفته‌تر است، اما به پیچیدگی بیشتری در هنگام طراحی و توسعه UI نیاز دارد. دوم، eShopOnContainers همچنین یک برنامه تلفن همراه بومی مبتنی بر Xamarin ارائه می دهد که آن را در سمت C# مشتری پیچیده تر می کند.

آدرس پذیری میکروسرویس ها و رجیستری خدمات

Ehsan — Sat, 11 Feb 2023 11:05:17 +0330

هر میکروسرویس یک نام منحصر به فرد (URL) دارد که برای تعیین موقعیت مکانی آن استفاده می شود. میکروسرویس شما باید در هر جایی که اجرا می شود آدرس پذیر باشد. اگر باید به این فکر کنید که کدام رایانه یک میکروسرویس خاص را اجرا می کند، ممکن است همه چیز به سرعت خراب شود. همانطور که DNS یک URL به یک کامپیوتر خاص را حل می کند، میکروسرویس شما باید یک نام منحصر به فرد داشته باشد تا مکان فعلی آن قابل کشف باشد. میکروسرویس‌ها به نام‌های آدرس‌پذیر نیاز دارند که آنها را از زیرساختی که روی آن اجرا می‌کنند مستقل کند. این رویکرد حاکی از آن است که تعاملی بین نحوه استقرار سرویس شما و نحوه کشف آن وجود دارد، زیرا باید یک رجیستری سرویس وجود داشته باشد. در همین راستا، هنگامی که یک کامپیوتر از کار می افتد، سرویس رجیستری باید بتواند محل اجرای سرویس را مشخص کند.الگوی رجیستری خدمات بخش کلیدی کشف سرویس است. رجیستری یک پایگاه داده حاوی مکان های شبکه نمونه های سرویس است. یک رجیستری خدمات باید بسیار در دسترس و به روز باشد. کلاینت‌ها می‌توانند مکان‌های شبکه به‌دست‌آمده از رجیستری سرویس را کش کنند. با این حال، این اطلاعات در نهایت قدیمی می شود و مشتریان دیگر نمی توانند نمونه های خدمات را کشف کنند. بنابراین، یک رجیستری خدمات شامل خوشه ای از سرورها است که از یک پروتکل تکرار برای حفظ ثبات استفاده می کنند.در برخی از محیط‌های استقرار میکروسرویس (که خوشه‌ها نامیده می‌شوند، که در بخش بعدی پوشش داده می‌شود)، کشف سرویس تعبیه شده است. برای مثال، یک محیط Azure Kubernetes Service (AKS) می‌تواند ثبت نمونه سرویس و لغو ثبت را انجام دهد. همچنین یک پروکسی را روی هر میزبان خوشه ای اجرا می کند که نقش روتر کشف سمت سرور را بازی می کند.

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

Ehsan — Sat, 11 Feb 2023 11:02:31 +0330

Microservice API قراردادی بین سرویس و مشتریانش است. تنها در صورتی قادر خواهید بود که یک میکروسرویس را به طور مستقل توسعه دهید که قرارداد API آن را نقض نکنید، به همین دلیل است که قرارداد بسیار مهم است. اگر قرارداد را تغییر دهید، بر برنامه های مشتری یا دروازه API شما تأثیر می گذارد.ماهیت تعریف API به پروتکلی که از آن استفاده می کنید بستگی دارد. به عنوان مثال، اگر از پیام رسانی (مانند AMQP) استفاده می کنید، API از انواع پیام ها تشکیل شده است. اگر از سرویس های HTTP و RESTful استفاده می کنید، API از URL ها و فرمت های JSON درخواست و پاسخ تشکیل شده است.با این حال، حتی اگر در مورد قرارداد اولیه خود فکر کنید، API سرویس باید در طول زمان تغییر کند. وقتی این اتفاق می‌افتد - و به‌ویژه اگر API شما یک API عمومی است که توسط چندین برنامه مشتری مصرف می‌شود - معمولاً نمی‌توانید همه کلاینت‌ها را مجبور کنید به قرارداد API جدید خود ارتقا دهند. معمولاً باید نسخه‌های جدید یک سرویس را به‌صورت تدریجی اجرا کنید، به گونه‌ای که نسخه‌های قدیمی و جدید قرارداد خدمات به طور همزمان اجرا شوند. بنابراین، مهم است که یک استراتژی برای نسخه‌سازی سرویس خود داشته باشید.وقتی تغییرات API کوچک هستند، مثلاً اگر ویژگی‌ها یا پارامترهایی را به API خود اضافه کنید، کلاینت‌هایی که از API قدیمی‌تری استفاده می‌کنند باید تغییر کنند و با نسخه جدید سرویس کار کنند. ممکن است بتوانید مقادیر پیش‌فرض را برای هر ویژگی گمشده‌ای که مورد نیاز است ارائه کنید، و کلاینت‌ها ممکن است بتوانند هر ویژگی پاسخ اضافی را نادیده بگیرند.با این حال، گاهی اوقات شما نیاز به ایجاد تغییرات عمده و ناسازگار در API سرویس دارید. از آنجایی که ممکن است نتوانید برنامه‌ها یا سرویس‌های کلاینت را مجبور کنید فوراً به نسخه جدید ارتقا پیدا کنند، یک سرویس باید برای مدتی از نسخه‌های قدیمی‌تر API پشتیبانی کند. اگر از مکانیزم مبتنی بر HTTP مانند REST استفاده می کنید، یکی از روش ها این است که شماره نسخه API را در URL یا در یک هدر HTTP جاسازی کنید. سپس می توانید بین پیاده سازی هر دو نسخه سرویس به طور همزمان در یک نمونه سرویس یا استقرار نمونه های مختلف که هر کدام یک نسخه از API را مدیریت می کنند تصمیم بگیرید. یک رویکرد خوب برای این عملکرد، الگوی Mediator (به عنوان مثال، کتابخانه MediatR) برای جدا کردن نسخه‌های پیاده‌سازی مختلف به کنترل‌کننده‌های مستقل است.در نهایت، اگر از معماری REST استفاده می‌کنید، Hypermedia بهترین راه‌حل برای نسخه‌سازی سرویس‌های شما و اجازه دادن به APIهای قابل تکامل است.

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

Ehsan — Sat, 11 Feb 2023 09:23:57 +0330

پیام‌های ناهمزمان و ارتباطات مبتنی بر رویداد هنگام انتشار تغییرات در چندین ریزسرویس و مدل‌های دامنه مرتبط با آن‌ها حیاتی هستند. همانطور که قبلاً در بحث میکروسرویس ها و زمینه های محدود (BCs) ذکر شد، مدل ها (کاربر، مشتری، محصول، حساب و غیره) می توانند معانی مختلفی برای میکروسرویس ها یا BC های مختلف داشته باشند. این بدان معناست که وقتی تغییرات رخ می دهد، شما به روشی برای تطبیق تغییرات در مدل های مختلف نیاز دارید. یک راه حل، ارتباط نهایی و رویداد محور مبتنی بر پیام رسانی ناهمزمان است.هنگام استفاده از پیام رسانی، فرآیندها با تبادل پیام به صورت ناهمزمان با یکدیگر ارتباط برقرار می کنند. یک کلاینت با ارسال پیام به سرویس، دستور یا درخواستی را برای آن ارسال می کند. اگر سرویس نیاز به پاسخگویی داشته باشد، پیام دیگری به مشتری ارسال می کند. از آنجایی که این یک ارتباط مبتنی بر پیام است، مشتری فرض می‌کند که پاسخ بلافاصله دریافت نمی‌شود و ممکن است اصلاً پاسخی وجود نداشته باشد.یک پیام توسط یک سربرگ (فراداده مانند اطلاعات شناسایی یا امنیتی) و یک بدنه تشکیل شده است. پیام ها معمولاً از طریق پروتکل های ناهمزمان مانند AMQP ارسال می شوند.زیرساخت ارجح برای این نوع ارتباط در جامعه میکروسرویس، یک واسطه پیام سبک وزن است که با کارگزاران و ارکسترهای بزرگ مورد استفاده در SOA متفاوت است. در یک کارگزار پیام سبک، زیرساخت معمولاً "گنگ" است و تنها به عنوان یک واسطه پیام عمل می کند، با پیاده سازی های ساده مانند RabbitMQ یا یک گذرگاه خدمات مقیاس پذیر در ابر مانند Azure Service Bus. در این سناریو، بیشتر تفکر «هوشمند» هنوز در نقاط پایانی که پیام‌ها را تولید و مصرف می‌کنند زندگی می‌کنند، یعنی در میکروسرویس‌ها.قانون دیگری که باید سعی کنید تا حد امکان از آن پیروی کنید این است که فقط از پیام‌های ناهمزمان بین سرویس‌های داخلی استفاده کنید و از ارتباطات همزمان (مانند HTTP) فقط از برنامه‌های سرویس گیرنده به سرویس‌های فرانت‌اند (API Gateways به علاوه سطح اول میکروسرویس ها).دو نوع ارتباط پیام رسانی ناهمزمان وجود دارد: ارتباط مبتنی بر پیام گیرنده تکی و ارتباط مبتنی بر پیام گیرنده های متعدد. در بخش های بعدی جزئیاتی در مورد آنها ارائه می شود.ارتباط مبتنی بر پیام تک گیرندهارتباط ناهمزمان مبتنی بر پیام با یک گیرنده به این معنی است که یک ارتباط نقطه به نقطه وجود دارد که پیامی را دقیقاً به یکی از مصرف‌کنندگانی که از کانال می‌خواند می‌رساند و این پیام فقط یک بار پردازش می‌شود. با این حال، شرایط خاصی وجود دارد. به عنوان مثال، در یک سیستم ابری که سعی می‌کند به طور خودکار خرابی‌ها را بازیابی کند، یک پیام می‌تواند چندین بار ارسال شود. به دلیل مشکلات شبکه یا سایر خرابی‌ها، کلاینت باید بتواند مجدداً پیام‌ها را ارسال کند، و سرور باید برای پردازش یک پیام خاص، عملیاتی را اجرا کند که ناتوان باشد.ارتباطات مبتنی بر پیام تک گیرنده مخصوصاً برای ارسال دستورات ناهمزمان از یک میکروسرویس به سرویس دیگر مناسب است.هنگامی که شروع به ارسال ارتباطات مبتنی بر پیام (چه با دستورات یا رویدادها) کردید، باید از ترکیب ارتباطات مبتنی بر پیام با ارتباطات HTTP همزمان خودداری کنید.هنگامی که دستورات از برنامه های مشتری می آیند، می توانند به عنوان دستورات همزمان HTTP پیاده سازی شوند. هنگامی که به مقیاس پذیری بالاتری نیاز دارید یا زمانی که در حال حاضر در یک فرآیند تجاری مبتنی بر پیام هستید، از دستورات مبتنی بر پیام استفاده کنید.ارتباطات مبتنی بر پیام چند گیرندهبه عنوان یک رویکرد انعطاف‌پذیرتر، ممکن است بخواهید از مکانیزم انتشار/اشتراک استفاده کنید تا ارتباط شما از فرستنده برای میکروسرویس‌های مشترک اضافی یا برنامه‌های خارجی در دسترس باشد. بنابراین، به شما کمک می کند تا از اصل باز/بسته در سرویس ارسال پیروی کنید. به این ترتیب، می‌توان در آینده بدون نیاز به تغییر سرویس فرستنده، مشترکین بیشتری اضافه کرد.وقتی از ارتباط انتشار/اشتراک استفاده می‌کنید، ممکن است از رابط اتوبوس رویداد برای انتشار رویدادها برای هر مشترکی استفاده کنید.ارتباط ناهمزمان رویداد محورهنگام استفاده از ارتباطات مبتنی بر رویداد ناهمزمان، یک میکروسرویس یک رویداد یکپارچه‌سازی را زمانی منتشر می‌کند که چیزی در دامنه آن اتفاق می‌افتد و میکروسرویس دیگری باید از آن آگاه باشد، مانند تغییر قیمت در یک ریزسرویس کاتالوگ محصول. میکروسرویس‌های اضافی در رویدادها مشترک می‌شوند تا بتوانند آنها را به صورت ناهمزمان دریافت کنند. هنگامی که این اتفاق می افتد، گیرنده ها ممکن است موجودیت های دامنه خود را به روز کنند، که می تواند باعث انتشار رویدادهای ادغام بیشتر شود. این سیستم انتشار/اشتراک با استفاده از پیاده‌سازی گذرگاه رویداد انجام می‌شود. اتوبوس رویداد می تواند به عنوان یک انتزاع یا رابط طراحی شود، با API که برای اشتراک یا لغو اشتراک رویدادها و انتشار رویدادها مورد نیاز است. گذرگاه رویداد همچنین می‌تواند یک یا چند پیاده‌سازی بر اساس هر واسطه بین فرآیندی و پیام‌رسانی داشته باشد، مانند صف پیام یا گذرگاه سرویس که از ارتباطات ناهمزمان و مدل انتشار/اشتراک پشتیبانی می‌کند.اگر یک سیستم از ثبات نهایی ناشی از رویدادهای یکپارچه سازی استفاده می کند، توصیه می شود که این رویکرد برای کاربر نهایی روشن شود. سیستم نباید از رویکردی استفاده کند که رویدادهای یکپارچه سازی را تقلید کند، مانند SignalR یا سیستم های نظرسنجی از مشتری. کاربر نهایی و مالک کسب و کار باید به صراحت از ثبات نهایی در سیستم استقبال کنند و بدانند که در بسیاری از موارد کسب و کار با این رویکرد مشکلی ندارد، تا زمانی که صریح باشد. این رویکرد مهم است زیرا کاربران ممکن است انتظار داشته باشند برخی از نتایج را فورا ببینند و این جنبه ممکن است با ثبات نهایی اتفاق نیفتد.همانطور که قبلاً در بخش چالش ها و راه حل ها برای مدیریت داده های توزیع شده ذکر شد، می توانید از رویدادهای یکپارچه سازی برای اجرای وظایف تجاری که چندین میکروسرویس را در بر می گیرند استفاده کنید. بنابراین، شما در نهایت سازگاری بین آن خدمات خواهید داشت. یک تراکنش در نهایت سازگار از مجموعه ای از اقدامات توزیع شده تشکیل شده است. در هر اقدام، میکروسرویس مربوطه یک موجودیت دامنه را به‌روزرسانی می‌کند و رویداد یکپارچه‌سازی دیگری را منتشر می‌کند که اقدام بعدی را در همان کار تجاری انتها به انتها افزایش می‌دهد.یک نکته مهم این است که ممکن است بخواهید با چندین میکروسرویس که در یک رویداد مشترک هستند ارتباط برقرار کنید. می توانید از پیام های انتشار/اشتراک بر اساس ارتباطات رویداد محور استفاده کنید. این مکانیسم انتشار/اشتراک منحصر به معماری میکروسرویس نیست. این شبیه به روشی است که Context های محدود در DDD باید با هم ارتباط برقرار کنند، یا به روشی که شما به روز رسانی ها را از پایگاه داده نوشتن به پایگاه داده خوانده شده در الگوی معماری Command and Query Responsibility Segregation (CQRS) منتشر می کنید. هدف این است که در نهایت بین منابع داده چندگانه در سراسر سیستم توزیع شده شما سازگاری داشته باشید.در ارتباطات ناهمزمان رویداد محور، یک میکروسرویس رویدادها را در یک اتوبوس رویداد منتشر می‌کند و بسیاری از میکروسرویس‌ها می‌توانند در آن مشترک شوند تا مطلع شوند و بر اساس آن عمل کنند. پیاده سازی شما تعیین می کند که از چه پروتکلی برای ارتباطات پیام محور و مبتنی بر رویداد استفاده کنید. AMQP می تواند به دستیابی به ارتباطات صف قابل اعتماد کمک کند.هنگامی که از یک گذرگاه رویداد استفاده می کنید، ممکن است بخواهید از یک سطح انتزاعی (مانند رابط اتوبوس رویداد) بر اساس پیاده سازی مرتبط در کلاس ها با کد با استفاده از API از یک واسطه پیام مانند RabbitMQ یا یک گذرگاه خدمات مانند Azure Service Bus با موضوعات استفاده کنید. . از طرف دیگر، ممکن است بخواهید از یک گذرگاه خدمات سطح بالاتر مانند NServiceBus، MassTransit یا Brighter برای بیان اتوبوس رویداد خود و سیستم انتشار/اشتراک استفاده کنید.یادداشتی در مورد فن آوری های پیام رسانی برای سیستم های تولیدفن آوری های پیام رسانی موجود برای اجرای گذرگاه رویداد انتزاعی شما در سطوح مختلف هستند. به عنوان مثال، محصولاتی مانند RabbitMQ (یک حمل و نقل واسطه پیام رسانی) و Azure Service Bus در سطح پایین تری نسبت به سایر محصولات مانند NServiceBus، MassTransit یا Brighter قرار دارند که می توانند در بالای RabbitMQ و Azure Service Bus کار کنند. انتخاب شما به تعداد ویژگی های غنی در سطح برنامه و مقیاس پذیری خارج از جعبه برای برنامه خود بستگی دارد. برای پیاده‌سازی یک گذرگاه رویداد اثبات مفهوم برای محیط توسعه‌تان، همانطور که در نمونه eShopOnContainers انجام شد، یک پیاده‌سازی ساده در بالای RabbitMQ در حال اجرا بر روی یک ظرف Docker ممکن است کافی باشد.با این حال، برای سیستم‌های تولیدی و حیاتی که نیاز به مقیاس‌پذیری بیش از حد دارند، ممکن است بخواهید Azure Service Bus را ارزیابی کنید. برای انتزاع‌ها و ویژگی‌های سطح بالا که توسعه برنامه‌های کاربردی توزیع‌شده را آسان‌تر می‌کنند، توصیه می‌کنیم سایر اتوبوس‌های خدمات تجاری و منبع باز مانند NServiceBus، MassTransit و Brighter را ارزیابی کنید. البته، می‌توانید ویژگی‌های سرویس اتوبوس خود را بر روی فناوری‌های سطح پایین‌تر مانند RabbitMQ و Docker ایجاد کنید. اما این کار لوله کشی ممکن است برای یک برنامه سازمانی سفارشی هزینه زیادی داشته باشد.در حال انتشار به اتوبوس رویدادچالشی که هنگام پیاده‌سازی یک معماری رویداد محور در چندین میکروسرویس وجود دارد این است که چگونه به‌صورت اتمی وضعیت را در میکروسرویس اصلی به‌روزرسانی کنیم و در عین حال رویداد یکپارچه‌سازی مرتبط آن را به‌گونه‌ای بر اساس تراکنش‌ها منتشر کنیم. در زیر چند راه برای انجام این عملکرد وجود دارد، اگرچه می‌تواند رویکردهای دیگری نیز وجود داشته باشد.با استفاده از صف معاملاتی (مبتنی بر DTC) مانند MSMQ. (با این حال، این یک رویکرد قدیمی است.)استفاده از استخراج لاگ تراکنشبا استفاده از الگوی کامل رویداد منبع یابی.استفاده از الگوی صندوق خروجی: یک جدول پایگاه داده تراکنشی به عنوان یک صف پیام که پایه یک مؤلفه ایجاد کننده رویداد است که رویداد را ایجاد و منتشر می کند.

ارتباطات در معماری میکروسرویس

Ehsan — Sat, 11 Feb 2023 09:11:41 +0330

در یک برنامه یکپارچه که روی یک فرآیند اجرا می شود، اجزا با استفاده از روش سطح زبان یا فراخوانی تابع، یکدیگر را فراخوانی می کنند. اگر شما در حال ایجاد اشیاء با کد هستید (برای مثال، ClassName) ، می‌توان آنها را قویاً جفت کرد، یا اگر از تزریق وابستگی با ارجاع به انتزاعات به جای نمونه‌های شی مشخص استفاده می‌کنید، می‌توان آنها را به صورت جداشده فراخوانی کرد. در هر صورت، اشیاء در همان فرآیند در حال اجرا هستند. بزرگترین چالش هنگام تغییر از یک برنامه یکپارچه به یک برنامه کاربردی مبتنی بر ریزسرویس، تغییر مکانیسم ارتباطی است. تبدیل مستقیم از فراخوانی‌های روش درون‌فرایند به تماس‌های RPC به سرویس‌ها باعث ایجاد یک ارتباط پرحرف و ناکارآمد می‌شود که در محیط‌های توزیع‌شده به خوبی عمل نمی‌کند. چالش‌های طراحی سیستم توزیع‌شده به‌خوبی به‌خوبی شناخته شده‌اند که حتی قانونی به نام مغالطه‌های محاسبات توزیع‌شده وجود دارد که مفروضاتی را فهرست می‌کند که توسعه‌دهندگان معمولاً هنگام حرکت از طرح‌های یکپارچه به طرح‌های توزیع شده انجام می‌دهند.یک راه حل وجود ندارد، بلکه چندین راه حل وجود دارد. یک راه حل شامل جداسازی ریز سرویس های تجاری تا حد امکان است. سپس از ارتباط ناهمزمان بین میکروسرویس‌های داخلی استفاده می‌کنید و ارتباطات ریزدانه را که در ارتباطات درون فرآیندی بین اشیاء با ارتباطات درشت‌تر است، جایگزین می‌کنید. می‌توانید این کار را با گروه‌بندی تماس‌ها و با برگرداندن داده‌هایی که نتایج چند تماس داخلی را جمع‌آوری می‌کند، به مشتری انجام دهید.یک برنامه کاربردی مبتنی بر میکروسرویس یک سیستم توزیع شده است که بر روی چندین فرآیند یا سرویس اجرا می شود، معمولاً حتی در چندین سرور یا میزبان. هر نمونه سرویس معمولاً یک فرآیند است. بنابراین، خدمات باید با استفاده از یک پروتکل ارتباطی بین فرآیندی مانند HTTP، AMQP یا یک پروتکل باینری مانند TCP، بسته به ماهیت هر سرویس، تعامل داشته باشند.جامعه میکروسرویس فلسفه «نقاط پایانی هوشمند و لوله‌های گنگ» را ترویج می‌کند. این شعار طرحی را تشویق می‌کند که تا حد امکان بین میکروسرویس‌ها جدا شده و تا حد ممکن در یک میکروسرویس منسجم باشد. همانطور که قبلا توضیح داده شد، هر میکروسرویس دارای داده های خود و منطق دامنه خود است. اما ریزسرویس‌هایی که یک برنامه کاربردی سرتاسر را ایجاد می‌کنند، معمولاً به سادگی با استفاده از ارتباطات REST به جای پروتکل‌های پیچیده مانند WS-* و ارتباطات رویداد محور انعطاف‌پذیر به جای هماهنگ‌کننده‌های متمرکز فرآیندهای تجاری طراحی می‌شوند.دو پروتکل رایج مورد استفاده عبارتند از درخواست/پاسخ HTTP با APIهای منبع (بیشتر از همه، هنگام پرس و جو)، و پیام‌رسانی ناهمزمان سبک هنگام برقراری ارتباط به‌روزرسانی‌ها در چندین میکروسرویس. این موارد در بخش های بعدی با جزئیات بیشتر توضیح داده شده است.انواع ارتباطاتمشتری و خدمات می توانند از طریق انواع مختلفی از ارتباطات ارتباط برقرار کنند که هر کدام سناریو و اهداف متفاوتی را هدف قرار می دهند. در ابتدا می توان آن نوع ارتباطات را در دو محور طبقه بندی کرد.محور اول مشخص می کند که پروتکل همزمان یا ناهمزمان باشد:پروتکل سنکرون HTTP یک پروتکل همزمان است. مشتری یک درخواست ارسال می کند و منتظر پاسخ از طرف سرویس است. این مستقل از اجرای کد کلاینت است که می تواند همزمان (رشته مسدود شده است) یا ناهمزمان (رشته مسدود نشده است، و پاسخ در نهایت به یک تماس پاسخ می رسد). نکته مهم در اینجا این است که پروتکل (HTTP/HTTPS) همزمان است و کد کلاینت تنها زمانی می تواند کار خود را ادامه دهد که پاسخ سرور HTTP را دریافت کند.پروتکل ناهمزمان پروتکل های دیگری مانند AMQP (پروتکلی که توسط بسیاری از سیستم عامل ها و محیط های ابری پشتیبانی می شود) از پیام های ناهمزمان استفاده می کنند. کد مشتری یا فرستنده پیام معمولاً منتظر پاسخ نمی ماند. این فقط پیام را مانند هنگام ارسال پیام به صف RabbitMQ یا هر واسطه پیام دیگری ارسال می کند.محور دوم مشخص می کند که آیا ارتباط یک گیرنده یا چندین گیرنده دارد:گیرنده تک. هر درخواست باید دقیقاً توسط یک گیرنده یا سرویس پردازش شود. نمونه ای از این ارتباط الگوی Command است.گیرنده های متعدد هر درخواست را می توان از صفر تا چند گیرنده پردازش کرد. این نوع ارتباط باید ناهمزمان باشد. یک مثال مکانیسم انتشار/اشتراک مورد استفاده در الگوهایی مانند معماری رویداد محور است. این بر اساس یک رابط رویداد-باس یا کارگزار پیام هنگام انتشار به روز رسانی داده ها بین چندین میکروسرویس از طریق رویدادها است. معمولاً از طریق یک سرویس باس یا مصنوع مشابه مانند Azure Service Bus با استفاده از موضوعات و اشتراک ها پیاده سازی می شود.یک برنامه کاربردی مبتنی بر میکروسرویس اغلب از ترکیبی از این سبک های ارتباطی استفاده می کند. رایج ترین نوع ارتباط تک گیرنده با یک پروتکل همزمان مانند HTTP/HTTPS هنگام فراخوانی یک سرویس HTTP Web API معمولی است. میکروسرویس ها نیز معمولاً از پروتکل های پیام رسانی برای ارتباط ناهمزمان بین میکروسرویس ها استفاده می کنند.دانستن این محورها خوب است، بنابراین مکانیسم‌های ارتباطی احتمالی را شفاف می‌سازید، اما در هنگام ساخت میکروسرویس‌ها نگرانی مهمی نیستند. نه ماهیت ناهمزمان اجرای نخ کلاینت و نه ماهیت ناهمزمان پروتکل انتخاب شده نکات مهمی در هنگام ادغام میکروسرویس ها نیستند. آنچه مهم است این است که بتوانید میکروسرویس های خود را به صورت ناهمزمان ادغام کنید و در عین حال استقلال میکروسرویس ها را حفظ کنید، همانطور که در بخش زیر توضیح داده شد.ادغام میکروسرویس ناهمزمان استقلال میکروسرویس را تقویت می کندهمانطور که گفته شد، نکته مهم هنگام ساخت یک اپلیکیشن مبتنی بر میکروسرویس، نحوه ادغام میکروسرویس های خود است. در حالت ایده آل، باید سعی کنید ارتباط بین میکروسرویس های داخلی را به حداقل برسانید. هرچه ارتباطات بین میکروسرویس ها کمتر باشد، بهتر است. اما در بسیاری از موارد، باید به نحوی میکروسرویس ها را ادغام کنید. هنگامی که شما نیاز به انجام آن دارید، قانون اساسی در اینجا این است که ارتباط بین میکروسرویس ها باید ناهمزمان باشد. این بدان معنا نیست که باید از پروتکل خاصی استفاده کنید (مثلاً پیام رسانی ناهمزمان در مقابل HTTP همزمان). فقط به این معنی است که ارتباط بین میکروسرویس ها باید فقط با انتشار داده ها به صورت ناهمزمان انجام شود، اما سعی کنید به عنوان بخشی از عملیات درخواست/پاسخ HTTP سرویس اولیه به سایر میکروسرویس های داخلی وابسته نباشید.در صورت امکان، هرگز به ارتباط همزمان (درخواست/پاسخ) بین چندین میکروسرویس وابسته نباشید، حتی برای پرس و جوها. هدف هر میکروسرویس مستقل بودن و در دسترس بودن برای مشتری مشتری است، حتی اگر سایر خدماتی که بخشی از برنامه انتها به انتها هستند از کار افتاده یا ناسالم باشند. اگر فکر می‌کنید برای اینکه بتوانید به یک برنامه مشتری پاسخ دهید، باید از یک میکروسرویس به میکروسرویس‌های دیگر (مانند انجام یک درخواست HTTP برای پرس و جوی داده) تماس برقرار کنید، معماری دارید که در مواردی انعطاف‌پذیر نیست. میکروسرویس ها شکست می خورندعلاوه بر این، داشتن وابستگی به HTTP بین میکروسرویس‌ها، مانند ایجاد چرخه‌های طولانی درخواست/پاسخ با زنجیره‌های درخواست HTTP، نه تنها باعث می‌شود میکروسرویس‌های شما مستقل نباشند، بلکه عملکرد آنها نیز به محض اینکه تحت تأثیر قرار می‌گیرد. یکی از خدمات در آن زنجیره عملکرد خوبی ندارد.هر چه بیشتر وابستگی های همزمان بین میکروسرویس ها، مانند درخواست های پرس و جو اضافه کنید، زمان پاسخ کلی برای برنامه های مشتری بدتر می شود.همانطور که در نمودار بالا نشان داده شده است، در ارتباطات همزمان یک "زنجیره ای" از درخواست ها بین ریزسرویس ها ایجاد می شود و در حین ارائه درخواست مشتری انجام می شود. این یک ضد الگو است. در میکروسرویس‌های ارتباط ناهمزمان از پیام‌های ناهمزمان یا نظرسنجی http برای برقراری ارتباط با سایر میکروسرویس‌ها استفاده می‌شود، اما درخواست مشتری بلافاصله ارائه می‌شود.اگر میکروسرویس شما نیاز به انجام یک اقدام اضافی در میکروسرویس دیگری دارد، در صورت امکان، آن عمل را به صورت همزمان و به عنوان بخشی از عملیات درخواست و پاسخ میکروسرویس اصلی انجام ندهید. در عوض، این کار را به صورت ناهمزمان انجام دهید (با استفاده از پیام‌های ناهمزمان یا رویدادهای یکپارچه‌سازی، صف‌ها و غیره). اما تا حد امکان، عمل را به صورت همزمان به عنوان بخشی از عملیات درخواست و پاسخ همزمان اصلی فراخوانی نکنید.و در نهایت (و این همان جایی است که بیشتر مشکلات هنگام ساخت میکروسرویس ها ایجاد می شود)، اگر میکروسرویس اولیه شما به داده هایی نیاز دارد که در اصل متعلق به سایر میکروسرویس ها است، به درخواست های همزمان برای آن داده ها تکیه نکنید. در عوض، آن داده ها (فقط ویژگی هایی که نیاز دارید) را با استفاده از سازگاری نهایی (معمولاً با استفاده از رویدادهای یکپارچه سازی، همانطور که در بخش های آینده توضیح داده شده است) در پایگاه داده سرویس اولیه تکرار یا منتشر کنید.همانطور که قبلاً در شناسایی مرزهای مدل دامنه برای هر بخش میکروسرویس ذکر شد، کپی کردن برخی از داده ها در چندین میکروسرویس طراحی نادرستی نیست - برعکس، هنگام انجام این کار می توانید داده ها را به زبان یا شرایط خاص آن دامنه اضافی ترجمه کنید. یا متن محدود. به عنوان مثال، در برنامه eShopOnContainers شما یک میکروسرویس به نام ID-api دارید که مسئول بیشتر داده های کاربر با موجودی به نام User است. با این حال، زمانی که نیاز به ذخیره داده‌های مربوط به کاربر در میکروسرویس سفارش دارید، آن‌ها را به‌عنوان موجودیت دیگری به نام خریدار ذخیره می‌کنید. موجودیت خریدار هویت یکسانی با موجودیت کاربر اصلی دارد، اما ممکن است فقط چند ویژگی مورد نیاز دامنه سفارش را داشته باشد و نه کل نمایه کاربر.شما ممکن است از هر پروتکلی برای برقراری ارتباط و انتشار داده ها به صورت ناهمزمان در میان میکروسرویس ها استفاده کنید تا در نهایت سازگاری داشته باشید. همانطور که گفته شد، می توانید از رویدادهای یکپارچه سازی با استفاده از یک گذرگاه رویداد یا واسطه پیام استفاده کنید یا حتی می توانید با نظرسنجی از سرویس های دیگر از HTTP استفاده کنید. مهم نیست. قانون مهم این است که وابستگی همزمان بین میکروسرویس های خود ایجاد نکنید.بخش‌های زیر چندین سبک ارتباطی را توضیح می‌دهند که می‌توانید در برنامه‌های مبتنی بر میکروسرویس استفاده کنید.سبک های ارتباطیبسته به نوع ارتباطی که می خواهید استفاده کنید، پروتکل ها و انتخاب های زیادی وجود دارد که می توانید برای ارتباط از آنها استفاده کنید. اگر از مکانیزم ارتباطی مبتنی بر درخواست/پاسخ همزمان استفاده می‌کنید، پروتکل‌هایی مانند رویکردهای HTTP و REST رایج‌ترین هستند، به‌ویژه اگر خدمات خود را خارج از میزبان Docker یا خوشه میکروسرویس منتشر می‌کنید. اگر به صورت داخلی بین سرویس‌ها ارتباط برقرار می‌کنید (در داخل میزبان Docker یا خوشه میکروسرویس‌ها)، ممکن است بخواهید از مکانیسم‌های ارتباطی با فرمت باینری (مانند WCF با استفاده از TCP و فرمت باینری) استفاده کنید. همچنین می توانید از مکانیسم های ارتباطی ناهمزمان و مبتنی بر پیام مانند AMQP استفاده کنید.همچنین چندین فرمت پیام مانند JSON یا XML یا حتی فرمت های باینری وجود دارد که می تواند کارآمدتر باشد. اگر فرمت باینری انتخابی شما استاندارد نیست، احتمالاً ایده خوبی نیست که خدمات خود را با استفاده از آن فرمت به صورت عمومی منتشر کنید. می توانید از یک فرمت غیر استاندارد برای ارتباط داخلی بین میکروسرویس های خود استفاده کنید. شما ممکن است این کار را هنگام برقراری ارتباط بین میکروسرویس ها در میزبان داکر یا خوشه میکروسرویس خود (به عنوان مثال، ارکستراتورهای Docker)، یا برای برنامه های کاربردی مشتری اختصاصی که با میکروسرویس ها صحبت می کنند، انجام دهید.ارتباط درخواست/پاسخ با HTTP و RESTهنگامی که یک مشتری از ارتباط درخواست/پاسخ استفاده می کند، درخواستی را به یک سرویس ارسال می کند، سپس سرویس درخواست را پردازش می کند و پاسخی را ارسال می کند. ارتباط درخواست/پاسخ مخصوصاً برای جست‌وجوی داده‌ها برای یک رابط کاربری هم‌زمان (یک رابط کاربری زنده) از برنامه‌های مشتری مناسب است. بنابراین، همانطور که در شکل 4-16 نشان داده شده است، در معماری میکروسرویس احتمالاً از این مکانیسم ارتباطی برای اکثر پرس و جوها استفاده خواهید کرد.هنگامی که مشتری از ارتباط درخواست/پاسخ استفاده می کند، فرض می کند که پاسخ در مدت زمان کوتاهی، معمولاً کمتر از یک ثانیه یا حداکثر چند ثانیه می رسد. برای پاسخ‌های با تأخیر، باید ارتباطات ناهمزمان را بر اساس الگوهای پیام‌رسانی و فناوری‌های پیام‌رسانی پیاده‌سازی کنید، که رویکرد متفاوتی است.یک سبک معماری محبوب برای ارتباط درخواست/پاسخ REST است. این رویکرد مبتنی بر پروتکل HTTP است که افعال HTTP مانند GET، POST و PUT را در بر می گیرد. REST رایج ترین کمون معماری استیک سبک معماری محبوب برای ارتباط درخواست/پاسخ REST است. این رویکرد مبتنی بر پروتکل HTTP است که افعال HTTP مانند GET، POST و PUT را در بر می گیرد. REST رایج ترین رویکرد ارتباطی معماری مورد استفاده در هنگام ایجاد خدمات است. هنگامی که خدمات ASP.NET Core Web API را توسعه می دهید، می توانید خدمات REST را پیاده سازی کنید.هنگام استفاده از خدمات HTTP REST به عنوان زبان تعریف رابط، ارزش بیشتری وجود دارد. به عنوان مثال، اگر از ابرداده Swagger برای توصیف API سرویس خود استفاده می‌کنید، می‌توانید از ابزارهایی استفاده کنید که خرد مشتری را تولید می‌کنند که می‌تواند مستقیماً خدمات شما را کشف و مصرف کند.

الگوی دروازه API در مقابل ارتباط مستقیم مشتری به میکرو سرویس قسمت دوم

Ehsan — Fri, 10 Feb 2023 19:41:02 +0330

الگوی API Gateway چیست؟هنگامی که برنامه های بزرگ یا پیچیده مبتنی بر میکروسرویس را با چندین برنامه مشتری طراحی و می سازید، یک رویکرد خوب برای در نظر گرفتن می تواند یک API Gateway باشد. این الگو سرویسی است که برای گروه های خاصی از ریزسرویس ها یک نقطه ورود تکی فراهم می کند. این شبیه به الگوی نما از طراحی شی گرا است، اما در این مورد، بخشی از یک سیستم توزیع شده است. الگوی API Gateway گاهی اوقات به عنوان "backend for frontend" (BFF) نیز شناخته می شود، زیرا شما آن را در حالی که به نیازهای برنامه مشتری فکر می کنید، می سازید.بنابراین، دروازه API بین برنامه های مشتری و میکروسرویس ها قرار می گیرد. به عنوان یک پروکسی معکوس عمل می کند و درخواست ها را از مشتریان به خدمات هدایت می کند. همچنین می تواند ویژگی های متقاطع دیگری مانند احراز هویت، خاتمه SSL و حافظه پنهان را ارائه دهد.برنامه‌ها به یک نقطه پایانی متصل می‌شوند، API Gateway، که برای ارسال درخواست‌ها به میکروسرویس‌های جداگانه پیکربندی شده است. در این مثال، API Gateway به عنوان یک سرویس سفارشی ASP.NET Core WebHost اجرا می شود که به عنوان یک کانتینر اجرا می شود.مهم است که برجسته کنید که در آن نمودار، از یک سرویس API Gateway سفارشی استفاده می‌کنید که با برنامه‌های مشتری متعدد و متفاوت روبرو است. این واقعیت می تواند یک خطر مهم باشد زیرا سرویس API Gateway شما بر اساس نیازهای مختلف برنامه های مشتری در حال رشد و تکامل خواهد بود. در نهایت، به دلیل آن نیازهای مختلف، پف می‌کند و به طور موثر می‌تواند شبیه یک برنامه یکپارچه یا سرویس یکپارچه باشد. به همین دلیل است که بسیار توصیه می شود که دروازه API را به چندین سرویس یا چندین دروازه کوچکتر API تقسیم کنید، به عنوان مثال، یکی از انواع فرم فاکتور برنامه هر مشتری.هنگام اجرای الگوی API Gateway باید مراقب باشید. معمولاً داشتن یک API Gateway که همه میکروسرویس های داخلی برنامه شما را جمع آوری می کند، ایده خوبی نیست. اگر این کار را انجام دهد، به عنوان یک جمع کننده یا ارکستر کننده یکپارچه عمل می کند و با جفت کردن همه میکروسرویس ها، استقلال میکروسرویس را نقض می کند.بنابراین، دروازه‌های API باید بر اساس مرزهای تجاری و برنامه‌های سرویس گیرنده تفکیک شوند و به عنوان یک جمع‌کننده واحد برای همه میکروسرویس‌های داخلی عمل نکنند.هنگامی که لایه API Gateway را به چندین دروازه API تقسیم می‌کنید، اگر برنامه شما دارای چندین برنامه مشتری باشد، می‌تواند محور اصلی در شناسایی انواع دروازه‌های API متعدد باشد، به طوری که می‌توانید برای نیازهای هر برنامه مشتری نمای متفاوتی داشته باشید. این مورد الگویی به نام "Backend for Frontend" (BFF) است که در آن هر دروازه API می تواند یک API متفاوت متناسب با هر نوع برنامه مشتری ارائه دهد، احتمالاً حتی بر اساس فاکتور فرم مشتری با پیاده سازی کد آداپتور خاص که در زیر چندین میکروسرویس داخلی فراخوانی می کند. همانطور که در تصویر زیر نشان داده شده است:یک برنامه وب سنتی به یک میکروسرویس MVC متصل می شود که از دروازه API وب استفاده می کند. این مثال یک معماری ساده شده با چند دروازه API ریزدانه را نشان می دهد. در این مورد، مرزهای شناسایی شده برای هر مدرسه API صرفاً بر اساس الگوی "Backend for Frontend" (BFF) است، بنابراین فقط بر اساس API مورد نیاز برای هر برنامه مشتری است. اما در برنامه‌های بزرگ‌تر نیز باید جلوتر رفته و برنامه‌های API دیگری را بر اساس مرزهای تجاری به عنوان محور دوم طراحی ایجاد کنید.ویژگی های اصلی در الگوی دروازه APIیک API Gateway می تواند ویژگی هایی را ارائه دهد. بسته به محصول، ویژگی‌های غنی‌تر یا ساده‌تری ارائه می‌دهد، با این حال، مهم‌ترین و مهم‌ترین ویژگی‌های هر دروازه API الگوهای طراحی زیر است:معکوس مسیریابی پروکسی یا دروازه. API Gateway یک پروکسی معکوس برای تغییر مسیر یا مسیریابی درخواست‌ها (مسیریابی لایه ۷، معمولاً درخواست‌های HTTP) به نقاط انتهایی میکروسرویس‌های داخلی ارائه می‌دهند. این دروازه یک نقطه پایانی یا URL برای برنامه های ارائه دهنده می کند و سپس به درخواست های داخلی داخلی می دهد را به گروهی از ریزسرویس های داخلی نگاشت می کند. این ویژگی به جدا کردن برنامه‌های سرویس گیرنده از میکروسرویس‌ها کمک می‌کند، اما هنگام انجام یک API یکپارچه با دادن دروازه API بین API یکپارچه و برنامه‌های مشتری، راحت است، سپس می‌توانید APIهای جدید را به‌عنوان ریزسرویس‌های جدید اضافه کنید. از آن استفاده می کنید. API یکپارچه تا زمانی که در آینده به مقدار زیادی از ریزسرویس تقسیم می شود. به دلیل وجود دروازه API، برنامه‌های سرویس گیرنده متوجه نمی‌شوند، آیا APIهای مورد استفاده به‌عنوان ریزسرویس‌های داخلی یا یک API یکپارچه پیاده‌سازی می‌شوند و مهمتر از آن، هنگام شروع و تغییر API یکپارچه به میکروسرویس‌ها، به لطف مسیریابی API Gateway، برنامه‌های مشتریان. با هیچ تغییری URI تحت تأثیر قرار نخواهد گرفت.درخواست تجمیع به عنوان بخشی از الگوی دروازه، می‌توانید درخواست کنید (معمولاً درخواست‌های HTTP) را با هدف قرار دادن میکروسرویس‌های داخلی در یک درخواست درخواست پاسخ‌گویی کنید. این الگو مخصوصاً زمانی مناسب است که صفحه/صفحه مشتری به اطلاعاتی از میکروسرویس نیاز دارد. با این، برنامه مشتری یک درخواست را به دروازه API ارسال می کند که درخواست را به میکروسرویس های داخلی ارسال می کند و سپس نتایج را جمع آوری می کند و همه چیز را به برنامه مشتری ارسال می کند. مزیت و هدف اصلی این الگوی طراحی، کاهش چت بین برنامه های مشتری و API باطن است، که به ویژه برای برنامه هایی از دور خارج از مرکز داده می شود که در آن میکروسرویس ها زندگی می کنند، مانند برنامه های تلفن همراه یا درخواست هایی که از برنامه های SPA می آیند، مهم است. جاوا اسکریپت در مرورگرهای راه دور مشتری. برای برنامه های وب معمولی که درخواست ها را در محیط سرور می دهد (مانند برنامه وب ASP.NET Core MVC)، این الگو بسیار مهم نیست زیرا بسیار کمتر از برنامه های راهنمای راه دور است.بسته به محصول API Gateway که استفاده می‌کنید، ممکن است این تجمیع را انجام دهید. با این حال، در بسیاری از موارد، ایجاد ریزسرویس‌های تجمیع تحت محدوده API Gateway پذیرش‌تر است، بنابراین تجمیع را در کد (یعنی کد C#) تعریف می‌کنید:اطلاعات مقطعی یا مربی دروازه. بسته به ویژگی‌هایی که هر محصول API Gateway ارائه می‌کند، می‌تواند عملکردها را از میکروسرویس‌های خارج از دروازه منتقل کند، که اجرای هر میکروسرویس را با ادغام نگرانی‌های متقابل در یک لایه ساده می‌کند. این ویژگی ویژه برای ویژگی‌های تخصصی که می‌تواند در هر میکروسرویس داخلی پیچیده باشد، مانند عملکرد زیر، مناسب است:احراز هویت و مجوزادغام خدمات کشفذخیره شده پاسخسیاست ها، قطع کننده مدار و QoS را دوباره امتحان کنیدمحدود کردن نرخ و گازمقایسه بارثبت، ردیابی، همبستگیهدرها، رشته های پرس و جو و تبدیل ادعاهاIP مجاز فهرستاستفاده از محصولات با ویژگی های API Gatewayبسته به هر پیاده‌سازی، نگرانی‌های متقابل بسیاری توسط محصولات API Gateways ارائه می‌شود. در اینجا بررسی می کنیم:Azure API ManagementOcelotAzure API ManagementAzure API Management نه تنها نیازهای API Gateway شما را برطرف می کند، بلکه ویژگی هایی مانند جمع آوری بینش از API های شما را ارائه می دهد. اگر از یک راه حل مدیریت API استفاده می کنید، یک API Gateway تنها جزء آن راه حل کامل مدیریت API است.Azure API Management هم نیازهای Gateway API و هم نیازهای مدیریتی شما مانند ورود به سیستم، امنیت، اندازه‌گیری و غیره را برطرف می‌کند. در این مورد، هنگام استفاده از محصولی مانند Azure API Management، این واقعیت که شما ممکن است یک API Gateway داشته باشید چندان خطرناک نیست زیرا این نوع دروازه‌های API "نازک‌تر" هستند، به این معنی که شما کد C# سفارشی را که می‌تواند به سمت یک جزء یکپارچه تکامل یابد، پیاده‌سازی نمی‌کنید.محصولات API Gateway معمولاً مانند یک پروکسی معکوس برای ارتباطات ورودی عمل می‌کنند، جایی که می‌توانید APIها را از میکروسرویس‌های داخلی فیلتر کنید و مجوز را برای APIهای منتشر شده در این لایه اعمال کنید.بینش‌های موجود از یک سیستم مدیریت API به شما کمک می‌کند تا درک درستی از نحوه استفاده و عملکرد API‌های خود داشته باشید. آنها این فعالیت را با امکان مشاهده گزارش های تحلیلی در زمان واقعی و شناسایی روندهایی که ممکن است بر تجارت شما تأثیر بگذارند، انجام می دهند. به علاوه، می‌توانید گزارش‌هایی درباره فعالیت‌های درخواست و پاسخ برای تجزیه و تحلیل بیشتر آنلاین و آفلاین داشته باشید.با مدیریت Azure API، می توانید API های خود را با استفاده از کلید، رمز و فیلتر IP ایمن کنید. این ویژگی‌ها به شما امکان می‌دهند سهمیه‌ها و محدودیت‌های نرخ انعطاف‌پذیر و دقیق را اعمال کنید، شکل و رفتار API‌های خود را با استفاده از خط‌مشی‌ها تغییر دهید، و عملکرد را با ذخیره پاسخ بهبود بخشید.در این راهنما و نرم افزار نمونه مرجع (eShopOnContainers)، معماری به یک معماری کانتینری ساده تر و سفارشی محدود شده است تا بر روی کانتینرهای ساده بدون استفاده از محصولات PaaS مانند مدیریت Azure API تمرکز شود. اما برای برنامه‌های کاربردی مبتنی بر میکروسرویس بزرگ که در Microsoft Azure مستقر شده‌اند، ما شما را تشویق می‌کنیم مدیریت API Azure را به‌عنوان پایه‌ای برای دروازه‌های API خود در تولید ارزیابی کنید.OcelotOcelot یک دروازه API سبک وزن است که برای رویکردهای ساده تر توصیه می شود. Ocelot یک دروازه API مبتنی بر منبع باز دات نت است که به ویژه برای معماری های میکروسرویس هایی ساخته شده است که به نقاط ورود یکپارچه به سیستم خود نیاز دارند. این سبک، سریع و مقیاس پذیر است و مسیریابی و احراز هویت را در میان بسیاری از ویژگی های دیگر فراهم می کند.دلیل اصلی انتخاب Ocelot برای برنامه مرجع eShopOnContainers 2.0 این است که Ocelot یک دروازه API سبک وزن هسته دات نت است که می توانید آن را در همان محیط استقرار برنامه که در آن میکروسرویس ها/کانتینرهای خود را استقرار می دهید، مانند میزبان Docker، Kubernetes، مستقر کنید. و غیره. و از آنجایی که مبتنی بر NET Core است، کراس پلتفرم است که به شما امکان می دهد روی لینوکس یا ویندوز مستقر شوید.نمودارهای قبلی که دروازه‌های API سفارشی را در کانتینرها نشان می‌دهند، دقیقاً نحوه اجرای Ocelot را در یک کانتینر و برنامه مبتنی بر میکروسرویس نشان می‌دهند.علاوه بر این، بسیاری از محصولات دیگر در بازار وجود دارند که ویژگی‌های API Gateways را ارائه می‌کنند، مانند Apigee، Kong، MuleSoft، WSO2، و محصولات دیگری مانند Linkerd و Istio برای ویژگی‌های کنترل‌کننده ورودی مش خدمات.بعد از بخش‌های توضیح اولیه معماری و الگوها، بخش‌های بعدی نحوه پیاده‌سازی API Gateways با Ocelot را توضیح می‌دهند.معایب الگوی دروازه APIمهمترین اشکال این است که وقتی یک API Gateway را پیاده سازی می کنید، آن ردیف را با میکروسرویس های داخلی جفت می کنید. اتصال مانند این ممکن است مشکلات جدی برای برنامه شما ایجاد کند. کلمنس واستر، معمار تیم اتوبوس خدمات Azure، در جلسه «پیام‌رسانی و میکروسرویس‌ها» در GOTO 2016 از این مشکل بالقوه به عنوان «ESB جدید» یاد می‌کند.استفاده از یک میکروسرویس API Gateway یک نقطه احتمالی دیگر از شکست ایجاد می کند.یک API Gateway می تواند زمان پاسخگویی را به دلیل تماس شبکه اضافی افزایش دهد. با این حال، این تماس اضافی معمولاً تأثیر کمتری نسبت به داشتن یک رابط مشتری دارد که به طور مستقیم با میکروسرویس‌های داخلی تماس می‌گیرد.اگر به درستی مقیاس بندی نشود، API Gateway می تواند به یک گلوگاه تبدیل شود.یک دروازه API اگر شامل منطق سفارشی و تجمیع داده ها باشد، به هزینه توسعه اضافی و تعمیر و نگهداری آینده نیاز دارد. توسعه دهندگان باید API Gateway را به روز کنند تا نقاط پایانی هر میکروسرویس را در معرض دید قرار دهند. علاوه بر این، تغییرات پیاده‌سازی در میکروسرویس‌های داخلی ممکن است باعث تغییرات کد در سطح دروازه API شود. با این حال، اگر دروازه API فقط امنیت، ورود به سیستم و نسخه‌سازی را اعمال می‌کند (مانند زمانی که از مدیریت API Azure استفاده می‌کنید)، این هزینه توسعه اضافی ممکن است اعمال نشود.اگر API Gateway توسط یک تیم توسعه داده شود، ممکن است یک گلوگاه توسعه ایجاد شود. این جنبه دلیل دیگری است که چرا یک رویکرد بهتر، داشتن چندین دروازه API ریز دانه است که به نیازهای مختلف مشتری پاسخ می دهد. همچنین می‌توانید API Gateway را به صورت داخلی به چندین ناحیه یا لایه‌هایی که متعلق به تیم‌های مختلف کار بر روی میکروسرویس‌های داخلی هستند، تفکیک کنید.

الگوی دروازه API در مقابل ارتباط مستقیم مشتری به میکرو سرویس قسمت اول

Ehsan — Fri, 10 Feb 2023 19:33:01 +0330

در معماری میکروسرویس، هر میکروسرویس مجموعه ای از (معمولا) نقاط پایانی ریز دانه را در معرض دید قرار می دهد. همانطور که در این بخش توضیح داده شد، این واقعیت می تواند بر ارتباط مشتری به میکروسرویس تأثیر بگذارد.ارتباط مستقیم مشتری به میکروسرویس یک رویکرد ممکن، استفاده از معماری ارتباط مستقیم مشتری به میکرو سرویس است. در این رویکرد، یک برنامه مشتری می‌تواند درخواست‌ها را مستقیماً به برخی از میکروسرویس‌ها، ارسال کند.در این رویکرد، هر میکروسرویس دارای یک نقطه پایانی عمومی است که گاهی اوقات برای هر میکروسرویس یک پورت TCP متفاوت دارد. نمونه ای از URL برای یک سرویس خاص می تواند URL زیر در Azure باشد:http://eshoponcontainers.westus.cloudapp.azure.com:88/در یک محیط تولید مبتنی بر یک خوشه، آن URL به بار متعادل کننده استفاده شده در خوشه نقشه می‌دهد، که به نوبه خود درخواست‌ها را در میان ریزسرویس‌ها توزیع می‌کند. در محیط های تولیدی، می توانید یک Application Delivery Controller (ADC) مانند Azure Application Gateway بین میکروسرویس های خود و اینترنت داشته باشید. این لایه به عنوان یک لایه شفاف عمل می کند که نه تنها تعادل بار را انجام می دهد، بلکه خدمات شما را با ارائه پایان SSL ایمن می کند. این رویکرد با بارگذاری خاتمه SSL فشرده CPU و سایر وظایف مسیریابی به Azure Application Gateway، بار میزبان شما را بهبود می بخشد. در هر صورت، متعادل کننده بار و ADC از نقطه نظر معماری کاربردی منطقی شفاف هستند.یک معماری ارتباط مستقیم مشتری به میکروسرویس می تواند برای یک برنامه کاربردی کوچک مبتنی بر میکروسرویس به اندازه کافی خوب باشد، به خصوص اگر برنامه مشتری یک برنامه وب سمت سرور مانند یک برنامه ASP.NET MVC باشد. با این حال، هنگامی که برنامه‌های کاربردی مبتنی بر میکروسرویس بزرگ و پیچیده می‌سازید (به عنوان مثال، هنگام مدیریت ده‌ها نوع میکروسرویس)، و به‌ویژه زمانی که برنامه‌های سرویس گیرنده، برنامه‌های تلفن همراه یا برنامه‌های وب SPA از راه دور هستند، این رویکرد با چند مشکل مواجه می‌شود.هنگام توسعه یک برنامه کاربردی بزرگ بر اساس میکروسرویس، سؤالات زیر را در نظر بگیرید:چگونه برنامه‌های سرویس گیرنده می‌توانند تعداد درخواست‌ها را به بک‌اند به حداقل برسانند و ارتباطات چت را به چندین میکروسرویس کاهش دهند؟تعامل با چندین میکروسرویس برای ایجاد یک صفحه رابط کاربری واحد، تعداد رفت و برگشت ها را در سراسر اینترنت افزایش می دهد. این رویکرد تاخیر و پیچیدگی را در سمت UI افزایش می دهد. در حالت ایده آل، پاسخ ها باید به طور موثر در سمت سرور جمع شوند. این رویکرد تأخیر را کاهش می دهد، زیرا چندین قطعه داده به صورت موازی برمی گردند و برخی از UI می توانند داده ها را به محض آماده شدن نشان دهند.چگونه می توانید نگرانی های مقطعی مانند مجوز، تبدیل داده ها، و ارسال پویا درخواست را مدیریت کنید؟پیاده سازی امنیت و نگرانی های بین بخشی مانند امنیت و مجوز در هر میکروسرویس می تواند به تلاش توسعه قابل توجهی نیاز داشته باشد. یک رویکرد ممکن این است که آن سرویس‌ها را در میزبان Docker یا خوشه داخلی برای محدود کردن دسترسی مستقیم به آنها از خارج، و پیاده‌سازی آن نگرانی‌های مقطعی در یک مکان متمرکز، مانند دروازه API، داشته باشیم.چگونه برنامه های سرویس گیرنده می توانند با سرویس هایی که از پروتکل های غیر اینترنتی استفاده می کنند ارتباط برقرار کنند؟پروتکل های مورد استفاده در سمت سرور (مانند AMQP یا پروتکل های باینری) در برنامه های مشتری پشتیبانی نمی شوند. بنابراین، درخواست ها باید از طریق پروتکل هایی مانند HTTP/HTTPS انجام شوند و پس از آن به پروتکل های دیگر ترجمه شوند. رویکرد مرد میانی می تواند در این شرایط کمک کند.چگونه می توانید یک نما که مخصوص برنامه های موبایل ساخته شده است را شکل دهید؟API چندین میکروسرویس ممکن است به خوبی برای نیازهای برنامه های کاربردی مشتری مختلف طراحی نشده باشد. به عنوان مثال، نیازهای یک برنامه تلفن همراه ممکن است با نیازهای یک برنامه وب متفاوت باشد. برای برنامه های تلفن همراه، ممکن است نیاز به بهینه سازی بیشتر داشته باشید تا پاسخ های داده کارآمدتر باشند. می‌توانید این عملکرد را با جمع‌آوری داده‌ها از چندین میکروسرویس و بازگرداندن یک مجموعه از داده‌ها، و گاهی اوقات حذف هر گونه داده در پاسخی که برای برنامه تلفن همراه مورد نیاز نیست، انجام دهید. و البته ممکن است این داده ها را فشرده کنید. باز هم، یک نما یا API بین اپلیکیشن موبایل و میکروسرویس ها می تواند برای این سناریو راحت باشد.چرا به جای ارتباط مستقیم مشتری به میکرو سرویس، دروازه های API را در نظر بگیریددر معماری میکروسرویس‌ها، برنامه‌های سرویس گیرنده معمولاً نیاز به استفاده از عملکرد بیش از یک میکروسرویس دارند. اگر این مصرف مستقیماً انجام شود، مشتری باید چندین تماس را با نقاط پایانی میکروسرویس انجام دهد. وقتی برنامه تکامل می یابد و میکروسرویس های جدید معرفی می شوند یا میکروسرویس های موجود به روز می شوند چه اتفاقی می افتد؟ اگر برنامه شما دارای ریزسرویس‌های زیادی است، رسیدگی به بسیاری از نقاط پایانی از برنامه‌های مشتری می‌تواند یک کابوس باشد. از آنجایی که برنامه مشتری با آن نقاط پایانی داخلی همراه می شود، توسعه میکروسرویس ها در آینده می تواند تأثیر زیادی برای برنامه های مشتری ایجاد کند.بنابراین، داشتن یک سطح متوسط یا ردیف غیرمستقیم (Gateway) می تواند برای برنامه های کاربردی مبتنی بر میکروسرویس مناسب باشد. اگر دروازه‌های API ندارید، برنامه‌های سرویس گیرنده باید درخواست‌ها را مستقیماً به میکروسرویس‌ها ارسال کنند و این مشکلاتی مانند مشکلات زیر را ایجاد می‌کند:اتصال: بدون الگوی API Gateway، برنامه های مشتری به میکروسرویس های داخلی کوپل می شوند. برنامه های سرویس گیرنده باید بدانند که چگونه مناطق مختلف برنامه در میکروسرویس ها تجزیه می شوند. هنگام تکامل و بازسازی ریزسرویس‌های داخلی، این اقدامات بر تعمیر و نگهداری تأثیر می‌گذارند، زیرا به دلیل ارجاع مستقیم به میکروسرویس‌های داخلی از برنامه‌های سرویس گیرنده، باعث ایجاد تغییرات در برنامه‌های مشتری می‌شوند. برنامه های سرویس گیرنده باید به طور مکرر به روز شوند و این راه حل را دشوارتر می کند.رفت و برگشت بیش از حد: یک صفحه/صفحه واحد در برنامه مشتری ممکن است به چندین تماس با چندین سرویس نیاز داشته باشد. این رویکرد می تواند منجر به چندین رفت و برگشت شبکه بین مشتری و سرور شود و تأخیر قابل توجهی را اضافه کند. تجمیع در سطح متوسط می تواند عملکرد و تجربه کاربر را برای برنامه مشتری بهبود بخشد.مسائل امنیتی: بدون دروازه، همه میکروسرویس‌ها باید در معرض «جهان خارجی» قرار گیرند و سطح حمله را بزرگ‌تر از مخفی کردن میکروسرویس‌های داخلی که مستقیماً توسط برنامه‌های مشتری استفاده نمی‌شوند، می‌کند. هرچه سطح حمله کوچکتر باشد، برنامه شما می تواند ایمن تر باشد.نگرانی های متقاطع: هر میکروسرویس که به صورت عمومی منتشر می شود باید به نگرانی هایی مانند مجوز و SSL رسیدگی کند. در بسیاری از موقعیت‌ها، این نگرانی‌ها می‌توانند در یک لایه مدیریت شوند، بنابراین میکروسرویس‌های داخلی ساده‌تر می‌شوند.

مرزهای مدل دامنه را برای هر میکروسرویس شناسایی کنید

Ehsan — Fri, 10 Feb 2023 19:24:52 +0330

هدف از شناسایی مرزها و اندازه مدل برای هر میکروسرویس رسیدن به جداسازی دانه ای ممکن نیست، اگرچه در صورت امکان باید به سمت میکروسرویس های کوچک گرایش پیدا کنید. در عوض، هدف شما باید رسیدن به معنی‌دارترین جدایی باشد که توسط دانش دامنه شما هدایت می‌شود. تاکید بر اندازه نیست، بلکه بر قابلیت های تجاری است. علاوه بر این، اگر انسجام واضحی برای یک منطقه خاص از برنامه بر اساس تعداد زیادی وابستگی وجود داشته باشد، این نشان دهنده نیاز به یک میکروسرویس واحد نیز هست. انسجام راهی برای شناسایی نحوه جدا کردن یا گروه بندی میکروسرویس ها است. در نهایت، در حالی که دانش بیشتری در مورد دامنه به دست می آورید، باید اندازه میکروسرویس خود را به طور مکرر تطبیق دهید. یافتن اندازه مناسب یک فرآیند یکباره نیست.سام نیومن، مروج شناخته شده میکروسرویس ها و نویسنده کتاب Building Microservices، تاکید می کند که باید میکروسرویس های خود را بر اساس الگوی Bounded Context (BC) (بخشی از طراحی دامنه محور) طراحی کنید، همانطور که قبلاً معرفی شد. گاهی اوقات، یک BC می تواند از چندین سرویس فیزیکی تشکیل شده باشد، اما نه برعکس.یک مدل دامنه با موجودیت های دامنه خاص در یک BC بتن یا میکروسرویس اعمال می شود. BC کاربرد یک مدل دامنه را مشخص می‌کند و به اعضای تیم توسعه‌دهنده درک واضح و مشترکی از آنچه باید منسجم باشد و آنچه که می‌توان به طور مستقل توسعه داد می‌دهد. اینها همان اهداف برای میکروسرویس ها هستند.یکی دیگر از ابزارهایی که به انتخاب طراحی شما اطلاع می دهد قانون کانوی است که بیان می کند یک برنامه منعکس کننده مرزهای اجتماعی سازمانی است که آن را تولید کرده است. اما گاهی اوقات برعکس است - سازمان شرکت توسط نرم افزار تشکیل شده است. ممکن است لازم باشد قانون کانوی را معکوس کنید و مرزها را طوری بسازید که می خواهید شرکت سازماندهی شود و به سمت مشاوره فرآیندهای تجاری متمایل شود.برای شناسایی زمینه های محدود، می توانید از یک الگوی DDD به نام الگوی نگاشت زمینه استفاده کنید. با Context Mapping، زمینه های مختلف برنامه و مرزهای آنها را شناسایی می کنید. برای مثال، برای هر زیرسیستم کوچک، زمینه و مرز متفاوتی وجود دارد. نقشه زمینه راهی برای تعریف و مشخص کردن مرزهای بین دامنه ها است. یک BC مستقل است و شامل جزئیات یک دامنه واحد - جزئیاتی مانند موجودیت های دامنه - است و قراردادهای یکپارچه سازی را با سایر BC ها تعریف می کند. این شبیه به تعریف میکروسرویس است: مستقل است، قابلیت دامنه خاصی را پیاده سازی می کند و باید رابط هایی را ارائه دهد. به همین دلیل است که Context Mapping و الگوی Bounded Context رویکردهای خوبی برای شناسایی مرزهای مدل دامنه میکروسرویس‌های شما هستند.هنگام طراحی یک برنامه کاربردی بزرگ، خواهید دید که چگونه مدل دامنه آن می تواند تکه تکه شود - به عنوان مثال، یک متخصص دامنه از دامنه کاتالوگ، نام نهادها را در حوزه کاتالوگ و موجودی متفاوت از یک متخصص دامنه حمل و نقل می کند. یا زمانی که با یک متخصص CRM که می‌خواهد تمام جزئیات مشتری را ذخیره کند، ممکن است موجودیت دامنه کاربر از نظر اندازه و تعداد ویژگی‌ها متفاوت باشد تا کارشناس دامنه سفارش‌دهنده که فقط به داده‌های جزئی درباره مشتری نیاز دارد. ابهام‌زدایی از همه اصطلاحات دامنه در همه دامنه‌های مرتبط با یک برنامه کاربردی بسیار سخت است. اما مهمترین چیز این است که شما نباید سعی کنید شرایط را یکسان کنید. در عوض، تفاوت ها و غنای ارائه شده توسط هر دامنه را بپذیرید. اگر سعی کنید یک پایگاه داده یکپارچه برای کل برنامه داشته باشید، تلاش برای ایجاد یک واژگان یکپارچه دشوار خواهد بود و به نظر هیچ یک از متخصصان چند دامنه درست نخواهد بود. بنابراین، BC ها (که به عنوان میکروسرویس پیاده سازی می شوند) به شما کمک می کنند تا مشخص کنید کجا می توانید از اصطلاحات دامنه خاصی استفاده کنید و کجا باید سیستم را تقسیم کنید و BC های اضافی با دامنه های مختلف ایجاد کنید.اگر روابط قوی بین مدل‌های دامنه کمی داشته باشید، می‌دانید که مرزها و اندازه‌های مناسب هر مدل BC و دامنه را دریافت کرده‌اید، و معمولاً نیازی به ادغام اطلاعات از مدل‌های چند دامنه در هنگام انجام عملیات برنامه معمولی ندارید.شاید بهترین پاسخ به این سوال که یک مدل دامنه برای هر میکروسرویس چقدر باید بزرگ باشد، این است: این مدل باید یک BC مستقل داشته باشد، تا حد امکان جدا شده، که شما را قادر می سازد بدون نیاز به تغییر مداوم به زمینه های دیگر کار کنید (میکروسرویس های دیگر مدل ها). با این حال، ممکن است موجودیت هایی نیز داشته باشید که شکل متفاوتی دارند اما هویت یکسانی را در مدل های چند دامنه از چندین میکروسرویس به اشتراک می گذارند. به عنوان مثال، موجودیت کاربر در میکروسرویس مدیریت کنفرانس ها شناسایی می شود. همان کاربر، با همان هویت، شخصی است که در میکروسرویس سفارش، خریدار نام دارد، یا در میکروسرویس پرداخت به نام Payer، و حتی در میکروسرویس خدمات مشتری، مشتری نام دارد. این به این دلیل است که بسته به زبانی که هر متخصص دامنه استفاده می‌کند، کاربر ممکن است دیدگاه متفاوتی داشته باشد، حتی با ویژگی‌های متفاوت. موجودیت کاربر در مدل میکروسرویس به نام مدیریت کنفرانس ها ممکن است بیشتر ویژگی های داده های شخصی خود را داشته باشد. با این حال، همان کاربر به شکل پرداخت کننده در پرداخت میکروسرویس یا به شکل مشتری در خدمات مشتری میکروسرویس ممکن است به لیستی از ویژگی ها نیاز نداشته باشد.هنگام تجزیه یک مدل داده سنتی بین زمینه‌های محدود، می‌توانید موجودیت‌های مختلفی داشته باشید که هویت یکسانی دارند (خریدار نیز کاربر است) با ویژگی‌های متفاوت در هر بافت محدود. می‌توانید ببینید که چگونه کاربر در مدل ریزسرویس مدیریت کنفرانس‌ها به‌عنوان موجودیت کاربر حضور دارد و همچنین در قالب موجودیت خریدار در میکروسرویس قیمت‌گذاری، با ویژگی‌ها یا جزئیات جایگزین در مورد کاربر زمانی که در واقع خریدار است، حضور دارد. هر میکروسرویس یا BC ممکن است به همه داده‌های مربوط به یک موجودیت کاربر نیاز نداشته باشد، فقط بخشی از آن، بسته به مشکلی که باید حل شود یا زمینه. به عنوان مثال، در مدل میکروسرویس Pricing، شما به آدرس یا نام کاربر نیازی ندارید، فقط به شناسه (به عنوان هویت) و وضعیت نیاز دارید که در هنگام قیمت گذاری صندلی ها به ازای هر خریدار بر تخفیف ها تأثیر می گذارد.موجودیت Seat در هر مدل دامنه، نام یکسانی دارد اما ویژگی‌های متفاوتی دارد. با این حال، Seat هویت را بر اساس همان شناسه به اشتراک می گذارد، همانطور که برای کاربر و خریدار اتفاق می افتد.اساساً، یک مفهوم مشترک از یک کاربر وجود دارد که در چندین سرویس (دامنه) وجود دارد، که همگی هویت آن کاربر را به اشتراک می گذارند. اما در هر مدل دامنه ممکن است جزئیات اضافی یا متفاوتی در مورد موجودیت کاربر وجود داشته باشد. بنابراین، باید راهی برای نگاشت یک موجودیت کاربر از یک دامنه (microservice) به دامنه دیگر وجود داشته باشد.به اشتراک گذاشتن یک موجودیت کاربری مشابه با تعداد مشخصه های یکسان در دامنه ها مزایای متعددی دارد. یکی از مزایای آن کاهش تکرار است، به طوری که مدل های میکروسرویس هیچ داده ای را که نیاز ندارند ندارند. مزیت دیگر داشتن یک میکروسرویس اولیه است که دارای نوع خاصی از داده ها در هر نهاد است، به طوری که به روز رسانی ها و جستجوهای مربوط به آن نوع داده تنها توسط آن میکروسرویس انجام می شود.

پیش نیازهای میکروسرویس ها

Ehsan — Fri, 10 Feb 2023 19:18:51 +0330

همانطور که با مردم در مورد استفاده از سبک معماری میکروسرویس صحبت می کنم، خوش بینی های زیادی می شنوم. توسعه دهندگان از کار با واحدهای کوچکتر لذت می برند و انتظارات ماژولار بودن بهتری نسبت به یکپارچه ها دارند. اما مانند هر تصمیم معماری، معاوضه هایی وجود دارد. به ویژه در مورد ریزسرویس‌ها، عواقب جدی برای عملیات‌ها وجود دارد، که اکنون مجبورند اکوسیستمی از خدمات کوچک را به جای یک مونولیت واحد و کاملاً تعریف شده مدیریت کنند. در نتیجه، اگر شایستگی‌های پایه خاصی ندارید، نباید از سبک میکروسرویس استفاده کنید.تهیه سریع: شما باید بتوانید یک سرور جدید را در عرض چند ساعت راه اندازی کنید. طبیعتاً این با Cloud Computing مطابقت دارد، اما همچنین کاری است که می‌توان بدون یک سرویس ابری کامل انجام داد. برای اینکه بتوانید چنین تدارکات سریعی را انجام دهید، به اتوماسیون زیادی نیاز دارید - ممکن است برای شروع لازم نباشد کاملاً خودکار باشد، اما برای انجام ریزسرویس‌های جدی بعداً باید به آن راه برسد.نظارت اولیه: با بسیاری از سرویس‌هایی که در تولید با همدیگر همکاری می‌کنند، چیزهایی که در محیط‌های آزمایشی به سختی قابل تشخیص هستند، اشتباه می‌شوند. در نتیجه ضروری است که یک رژیم نظارتی برای شناسایی سریع مشکلات جدی وجود داشته باشد. خط پایه در اینجا تشخیص مسائل فنی (شمارش خطاها، در دسترس بودن خدمات و غیره) است، اما ارزش نظارت بر مسائل تجاری (مانند تشخیص کاهش سفارشات) را نیز دارد. اگر یک مشکل ناگهانی ظاهر شد، باید اطمینان حاصل کنید که می‌توانید به سرعت به عقب برگردید، بنابراین…استقرار سریع برنامه: با بسیاری از خدمات برای مدیریت، باید بتوانید به سرعت آنها را هم برای آزمایش محیط ها و هم برای تولید به کار بگیرید. معمولاً این شامل یک DeploymentPipeline است که می تواند در کمتر از چند ساعت اجرا شود. برخی از مداخلات دستی در مراحل اولیه مشکلی ندارند، اما به زودی به دنبال خودکارسازی کامل آن خواهید بود.این قابلیت ها حاکی از یک تغییر سازمانی مهم است - همکاری نزدیک بین توسعه دهندگان و عملیات: DevOpsCulture. این همکاری برای اطمینان از اینکه تدارک و استقرار می‌تواند به سرعت انجام شود، لازم است، همچنین مهم است که اطمینان حاصل شود که می‌توانید در زمانی که نظارت شما مشکلی را نشان می‌دهد، سریع واکنش نشان دهید. به طور خاص، هر گونه مدیریت حادثه نیاز به مشارکت تیم توسعه و عملیات دارد، هم در رفع مشکل فوری و هم در تجزیه و تحلیل علت ریشه ای برای اطمینان از رفع مشکلات اساسی.با این نوع تنظیم، شما برای اولین سیستم با استفاده از تعداد انگشت شماری میکروسرویس آماده هستید. این سیستم را مستقر کنید و از آن در تولید استفاده کنید، انتظار داشته باشید در مورد سالم نگه داشتن آن و اطمینان از اینکه همکاری devops به خوبی کار می کند چیزهای زیادی یاد بگیرید. برای انجام این کار به خودتان زمان بدهید، از آن بیاموزید، و قبل از اینکه تعداد خدمات خود را افزایش دهید، توانایی بیشتری کسب کنید.اگر اکنون این قابلیت ها را ندارید، باید اطمینان حاصل کنید که آنها را توسعه داده اید تا زمانی که یک سیستم میکروسرویس را وارد مرحله تولید کنید آماده باشند. در واقع اینها قابلیت هایی هستند که شما واقعاً باید برای سیستم های یکپارچه نیز داشته باشید. در حالی که آنها به طور جهانی در سازمان‌های نرم‌افزاری وجود ندارند، مکان‌های بسیار کمی وجود دارند که نباید در اولویت قرار گیرند.فراتر رفتن از تعداد انگشت شماری از خدمات، به موارد بیشتری نیاز دارد. شما باید تراکنش‌های تجاری را از طریق چندین سرویس ردیابی کنید و با پذیرش کامل Continuous Delivery، تهیه و استقرار خود را خودکار کنید. همچنین تغییر به سمت تیم های محصول محور است که باید راه اندازی شود. شما باید محیط توسعه خود را سازماندهی کنید تا توسعه دهندگان بتوانند به راحتی بین چندین مخزن، کتابخانه و زبان جابه جا شوند. برخی از مخاطبین من احساس می‌کنند که می‌تواند یک MaturityModel مفید در اینجا وجود داشته باشد که می‌تواند به سازمان‌ها در هنگام اجرای میکروسرویس‌های بیشتر کمک کند - ما باید در چند سال آینده شاهد گفتگوهای بیشتری در مورد آن باشیم.

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

Ehsan — Fri, 10 Feb 2023 19:11:36 +0330

یک قانون مهم برای معماری میکروسرویس ها این است که هر میکروسرویس باید داده ها و منطق دامنه خود را داشته باشد. همانطور که یک برنامه کامل دارای منطق و داده های خود است، هر میکروسرویس نیز باید منطق و داده های خود را تحت یک چرخه حیات مستقل، با استقرار مستقل در هر میکروسرویس، داشته باشد.این بدان معنی است که مدل مفهومی دامنه بین زیرسیستم ها یا ریزسرویس ها متفاوت است. برنامه‌های کاربردی سازمانی را در نظر بگیرید، جایی که برنامه‌های مدیریت ارتباط با مشتری (CRM)، زیرسیستم‌های خرید معاملاتی، و زیرسیستم‌های پشتیبانی مشتری هر کدام ویژگی‌ها و داده‌های موجودیت مشتری منحصر به فرد را فراخوانی می‌کنند، و جایی که هر یک از یک زمینه محدود (BC) متفاوتی استفاده می‌کنند.این اصل در طراحی دامنه محور (DDD) مشابه است، که در آن هر زمینه محدود یا زیرسیستم یا سرویس مستقل باید مدل دامنه خود را داشته باشد (داده به علاوه منطق و رفتار). هر زمینه DDD Bounded با یک ریزسرویس تجاری (یک یا چند سرویس) مرتبط است. این نکته در مورد الگوی Bounded Context در بخش بعدی بسط داده می شود.از سوی دیگر، رویکرد سنتی (داده‌های یکپارچه) مورد استفاده در بسیاری از برنامه‌ها، داشتن یک پایگاه داده متمرکز یا فقط چند پایگاه داده است. این اغلب یک پایگاه داده SQL نرمال شده است که برای کل برنامه و همه زیرسیستم های داخلی آن، استفاده می شود.در رویکرد سنتی، یک پایگاه داده واحد وجود دارد که در همه سرویس‌ها به اشتراک گذاشته می‌شود، معمولاً در معماری لایه‌ای. در رویکرد میکروسرویس، هر میکروسرویس مدل/داده خود را دارد. رویکرد پایگاه داده متمرکز در ابتدا ساده‌تر به نظر می‌رسد و به نظر می‌رسد استفاده مجدد از موجودیت‌ها را در زیرسیستم‌های مختلف برای سازگار کردن همه چیز ممکن می‌سازد. اما واقعیت این است که شما در نهایت با جداول بزرگی مواجه می شوید که به بسیاری از زیرسیستم های مختلف خدمت می کنند و شامل ویژگی ها و ستون هایی هستند که در بیشتر موارد مورد نیاز نیستند. این مانند تلاش برای استفاده از نقشه فیزیکی مشابه برای پیاده روی در یک مسیر کوتاه، یک سفر یک روزه با ماشین و یادگیری جغرافیا است.یک برنامه یکپارچه با معمولاً یک پایگاه داده رابطه‌ای دو مزیت مهم دارد: تراکنش‌های ACID و زبان SQL که هر دو در تمام جداول و داده‌های مربوط به برنامه شما کار می‌کنند. این رویکرد راهی برای نوشتن آسان یک پرس و جو فراهم می کند که داده ها را از چندین جدول ترکیب می کند.با این حال، هنگامی که به معماری میکروسرویس می‌روید، دسترسی به داده‌ها بسیار پیچیده‌تر می‌شود. حتی در هنگام استفاده از تراکنش‌های ACID در یک میکروسرویس یا زمینه محدود، مهم است که در نظر داشته باشید که داده‌های متعلق به هر میکروسرویس برای آن میکروسرویس خصوصی است و فقط باید به صورت همزمان از طریق نقاط پایانی API آن (REST، gRPC، SOAP، و غیره) یا به صورت ناهمزمان از طریق پیام رسانی (AMQP یا مشابه).کپسوله کردن داده‌ها تضمین می‌کند که میکروسرویس‌ها به‌طور سست جفت شده‌اند و می‌توانند مستقل از یکدیگر تکامل یابند. اگر چندین سرویس به داده های مشابهی دسترسی داشتند، به روز رسانی طرحواره به به روز رسانی هماهنگ برای همه سرویس ها نیاز دارد. این امر استقلال چرخه حیات میکروسرویس را از بین می برد. اما ساختارهای داده توزیع شده به این معنی است که شما نمی توانید یک تراکنش ACID را در میان ریزسرویس ها انجام دهید. این به نوبه خود به این معنی است که شما باید از یکپارچگی نهایی استفاده کنید زمانی که یک فرآیند کسب و کار چندین میکروسرویس را در بر می گیرد. پیاده سازی این بسیار سخت تر از اتصالات SQL ساده است، زیرا نمی توانید محدودیت های یکپارچگی ایجاد کنید یا از تراکنش های توزیع شده بین پایگاه های داده جداگانه استفاده کنید، همانطور که در ادامه توضیح خواهیم داد. به طور مشابه، بسیاری از ویژگی های دیگر پایگاه داده رابطه ای در چندین میکروسرویس در دسترس نیستند.حتی فراتر از این، میکروسرویس های مختلف اغلب از انواع مختلفی از پایگاه داده استفاده می کنند. برنامه های کاربردی مدرن انواع مختلفی از داده ها را ذخیره و پردازش می کنند و پایگاه داده رابطه ای همیشه بهترین انتخاب نیست. برای برخی موارد استفاده، یک پایگاه داده NoSQL مانند Azure CosmosDB یا MongoDB ممکن است مدل داده راحت تری داشته باشد و عملکرد و مقیاس پذیری بهتری نسبت به پایگاه داده SQL مانند SQL Server یا پایگاه داده Azure SQL ارائه دهد. در موارد دیگر، پایگاه داده رابطه ای هنوز بهترین رویکرد است. بنابراین، برنامه های کاربردی مبتنی بر میکروسرویس ها اغلب از ترکیبی از پایگاه های داده SQL و NoSQL استفاده می کنند که گاهی اوقات به آن رویکرد پایداری چند زبانه می گویند.یک معماری پارتیشن بندی شده و پایدار چند زبانه برای ذخیره سازی داده ها مزایای زیادی دارد. اینها شامل خدمات با اتصال ضعیف و عملکرد بهتر، مقیاس پذیری، هزینه ها و مدیریت پذیری است. با این حال، می‌تواند برخی از چالش‌های مدیریت داده‌های توزیع‌شده را معرفی کند، همانطور که در «شناسایی مرزهای مدل دامنه» بعداً در این فصل توضیح داده شد.رابطه بین میکروسرویس ها و الگوی زمینه محدودمفهوم میکروسرویس از الگوی زمینه محدود (BC) در طراحی دامنه محور (DDD) ناشی می شود. DDD با مدل‌های بزرگ با تقسیم آن‌ها به چندین BC و مشخص کردن مرزهایشان سر و کار دارد. هر BC باید مدل و پایگاه داده خود را داشته باشد. به همین ترتیب، هر میکروسرویس دارای داده های مربوط به خود است. علاوه بر این، هر BC معمولاً زبان همه جا حاضر خود را دارد تا به ارتباط بین توسعه دهندگان نرم افزار و کارشناسان دامنه کمک کند.آن عبارات (عمدتاً موجودیت‌های دامنه) در زبان فراگیر می‌توانند نام‌های متفاوتی در زمینه‌های محدود متفاوت داشته باشند، حتی زمانی که موجودیت‌های دامنه‌های مختلف هویت یکسانی دارند (یعنی شناسه منحصربه‌فردی که برای خواندن موجودیت از ذخیره‌سازی استفاده می‌شود). به عنوان مثال، در یک زمینه Bounded پروفایل کاربر، موجودیت دامنه کاربر ممکن است هویت خود را با موجودیت دامنه خریدار در زمینه Bounded سفارش دهنده به اشتراک بگذارد.بنابراین یک میکروسرویس مانند یک زمینه محدود است، اما همچنین مشخص می کند که یک سرویس توزیع شده است. این به عنوان یک فرآیند جداگانه برای هر زمینه محدود ساخته شده است، و باید از پروتکل های توزیع شده استفاده کند، مانند HTTP/HTTPS، WebSockets، یا AMQP. با این حال، الگوی Bounded Context مشخص نمی کند که آیا Bounded Context یک سرویس توزیع شده است یا اینکه صرفاً یک مرز منطقی (مانند یک زیر سیستم عمومی) در یک برنامه کاربردی یکپارچه است.مهم است که تاکید کنیم که تعریف یک سرویس برای هر زمینه محدود نقطه خوبی برای شروع است. اما لازم نیست طراحی خود را به آن محدود کنید. گاهی اوقات شما باید یک زمینه محدود یا یک میکروسرویس تجاری متشکل از چندین سرویس فیزیکی طراحی کنید. اما در نهایت، هر دو الگو -Bounded Context و microservice- ارتباط نزدیکی با هم دارند.DDD با بدست آوردن مرزهای واقعی در قالب ریزسرویس های توزیع شده از میکروسرویس ها سود می برد. اما ایده هایی مانند به اشتراک گذاری نکردن مدل بین میکروسرویس ها همان چیزی است که شما نیز در یک زمینه محدود می خواهید.