تفاوت بین SOA و Microservices؟

ما در طول سال ها چندین مقاله در مورد تفاوت ها و شباهت های بین SOA و میکروسرویس ها داشته ایم. برخی معتقدند که از SOA چیزهای زیادی می توان آموخت، در حالی که برخی دیگر معتقدند که فاصله گذاری میکروسرویس ها از SOA مفیدتر است. علاوه بر این، نیل فورد، در میان دیگران، پیشنهاد کرده است که حرکت از معماری‌های یکپارچه به رویکرد مبتنی بر خدمات ممکن است آسان‌تر از رفتن به سمت سرویس‌های کوچک باشد. اخیراً فعالیت زیادی در مورد بحث کلی «SOA یا میکروسرویس‌ها» صورت نگرفته است تا اینکه استفان اوگرادی از RedMonk مقاله‌ای در این زمینه منتشر کرد. در آن O’Grady نشان می دهد که اندازه خدمات عامل تعیین کننده نیست، مشابه آنچه دیگران در طول سال ها استدلال کرده اند، مانند Dan North، و به طور جداگانه Jeppe Cramon بیان کرد:ادامه مطلب..مزایای SOA معماری میکروسرویس AWS میکروسرویس مزایا و چالش های معماری میکروسرویس هاارسال شده در 9 ژانویه 2017 توسط Idexcel Technologiesاز من خواسته شد که یک نمودار معماری را برای برنامه‌ای که از MicroServices استفاده می‌کند، مرور کنم. من توانستم چند API REST را در نمودار پیدا کنم که به یک پایگاه داده متصل می شود.که هزاران سوال ایجاد کرد:1. فقط یک پایگاه داده؟2. اگر پایگاه داده خراب باشد چه؟3. همه سرویس ها در یک سرور واحد میزبانی می شوند؟4. اگر من نیاز به ارتقاء سرور داشته باشم چه؟MicroService چیست؟تعریف MicroService در یک عبارت واحد کار آسانی نخواهد بود. این تعریف به دیدگاه ها و الزامات مختلف بستگی دارد. با این حال، بیشتر ویژگی های برجسته MicroServices عبارتند از:• آنها یک سناریوی مشتری یا کسب و کار را در بر می گیرند.• آنها توسط یک تیم توسعه کوچک توسعه یافته اند.• آنها را می توان به هر زبان برنامه نویسی نوشت و از هر فریم ورکی استفاده کرد.• مفهوم OOPS به صورت آزادانه همراه پیاده سازی شده است• Codebase کوچک است که به طور مستقل نسخه، استقرار و مقیاس بندی شده است.• آنها با سایر MicroService ها از طریق رابط ها و پروتکل های کاملاً تعریف شده تعامل دارند.• آنها دارای نام های منحصر به فرد (URL) هستند که می توان از آنها برای تعیین موقعیت مکانی آنها استفاده کرد.• آنها حتی پس از شکست هم ثابت می مانند.SOA در مقابل میکروسرویس هامیکروسرویس فقط SOA نیست. اگر قرار است Microservices تعریف شود، به سادگی یک شکل ایده آل و تصفیه شده از SOA است. SOA بر برنامه نویسی ضروری تمرکز می کند، در حالی که معماری MicroServices بر سبک برنامه نویسی واکنش گرا متمرکز است. این چیزی شبیه به تجزیه یک سرویس یکپارچه بزرگ به خدمات مستقل کوچکتر است که خود قابل استقرار، پایدار و مقیاس پذیر هستند.معماری میکروسرویس - بررسی اجمالیهمانطور که هیچ تعریف رسمی از اصطلاح MicroServices وجود ندارد، هیچ مدل استانداردی وجود ندارد که در هر سیستمی بر اساس این سبک معماری نشان داده شود. اما می‌توانید انتظار داشته باشید که اکثر سیستم‌های MicroService دارای چند ویژگی قابل توجه مشترک باشند.1. نرم افزار ساخته شده به عنوان MicroService را می توان به چندین مؤلفه تقسیم کرد، به طوری که هر یک از این سرویس ها می توانند به طور مستقل مستقر شوند و بدون به خطر انداختن یکپارچگی یک برنامه کاربردی مجدداً مستقر شوند.2. سبک MicroServices معمولاً تجارت و اولویت ها محور است. بر خلاف رویکرد توسعه یکپارچه سنتی، معماری MicroService از تیم‌های متقابل استفاده می‌کند. در MicroServices، یک تیم در طول عمر خود مالک محصول است، همانطور که در آمازون غالباً نقل قول می شود "شما آن را می سازید، شما آن را اجرا می کنید."3. MicroServices دارای نقاط پایانی هوشمندی است که اطلاعات را پردازش می کند و منطق را اعمال می کند، و لوله های گنگ که اطلاعات از طریق آنها جریان می یابد. آنها درخواست ها را دریافت می کنند، آنها را پردازش می کنند و بر اساس آن پاسخ تولید می کنند.4. کنترل غیرمتمرکز بین تیم ها، به طوری که توسعه دهندگان آن تلاش می کنند تا ابزارهای مفیدی تولید کنند که سپس توسط دیگران برای حل همان مشکلات استفاده شود.5. معماری MicroServices به سرویس های همسایه خود اجازه می دهد تا زمانی که از سرویس خارج می شوند، کار کنند. این معماری همچنین برای پاسخگویی به افزایش ناگهانی تقاضای مشتریان خود مقیاس دارد.6. MicroService برای سیستم های تکاملی که در آن پیش بینی انواع دستگاه هایی که ممکن است به برنامه ما دسترسی داشته باشند دشوار است ایده آل است.معماری MicroService از خدمات به عنوان اجزای کوچک استفاده می کند و معمولاً بر تجارت متمرکز است. بر عملکرد محصولات تمرکز دارد. دارای نقاط انتهایی هوشمند اما مکانیزم های استاندارد ورودی/خروجی است. غیرمتمرکز و همچنین مدیریت داده غیرمتمرکز است. برای مقیاس خودکار طراحی شده است و در برابر شکست مقاوم است. و البته یک مدل تکاملی است.دانش مورد نیاز برای پیاده سازی MicroServiceبرای پایان دادن به مرور مختصر خود در مورد میکروسرویس ها در اینجا، باید مفاهیم زیر را درک اساسی داشته باشیم:• برنامه نویسی شی گرا (OOP) با تکنیک های جفت آزاد• وب سرویس / API/ REST - راهی برای نمایش عملکرد برنامه شما بدون رابط کاربری• معماری سرویس گرا (SOA) - راهی برای ساختاربندی بسیاری از برنامه های کاربردی مرتبط برای کار با هم، به جای تلاش برای حل همه مشکلات در یک برنامه• اصل مسئولیت واحد (SRP) - ایده کد با یک تمرکز• اصل جداسازی رابط (ISP) - ایده کد با مرزهای مشخص.مزایای MicroService• طراحی تکاملی - نیازی به بازنویسی کل برنامه شما نیست. ویژگی های جدید را به عنوان MicroServices اضافه کنید و آنها را به برنامه موجود خود وصل کنید• پایگاه کد کوچک – هر میکروسرویس فقط با یک نگرانی (SoC) سروکار دارد – این منجر به یک پایگاه کد کوچک می شود که به معنای قابلیت نگهداری آسان تر است.• مقیاس خودکار – آزادی مقیاس کردن فقط سرویس بارگذاری شده، زیرا آن سرویس بار بزرگتر را مدیریت می کند.• استقرار آسان - به جای استقرار مجدد کل برنامه، فقط پایگاه کد مورد نیاز را مستقر کنید.• انعطاف پذیری سیستم - اگر برخی از سرویس ها از کار بیفتند، فقط برخی از ویژگی ها تحت تأثیر قرار می گیرند، نه کل برنامه.چالش های MicroServiceمعماری MicroService کمک زیادی می کند، اما چالش های خاص خود را دارد.• ارتباطات بین سرویس – MicroServices به یکدیگر متکی خواهند بود و باید ارتباط برقرار کنند. یک کانال ارتباطی مشترک باید با استفاده از HTTP/ESB و غیره قاب شود.• نظارت بر سلامت – خدمات بیشتری برای نظارت وجود دارد که ممکن است با استفاده از زبان های برنامه نویسی مختلف توسعه داده شوند.• ورود به سیستم توزیع شده – سرویس های مختلف مکانیسم ثبت مختص به خود را خواهند داشت که منجر به GB داده های بدون ساختار توزیع شده می شود.• فراگیر تراکنش – MicroServices ممکن است منجر به گسترش تراکنش ها بر روی چندین سرویس و پایگاه داده شود. مسائلی که در جایی ایجاد می شود منجر به برخی مسائل دیگر در جایی دیگر می شود.• یافتن علت اصلی – منطق توزیع شده با داده های توزیع شده تلاش برای یافتن علت اصلی را افزایش می دهد. علت اصلی مربوط به عملکرد را هنوز می توان با استفاده از ابزارهای APM مانند New Relic & Dynatrace مدیریت کرد.• وابستگی چرخه‌ای بین سرویس‌ها – زمانی که یک مشکل در یک نسخه از بین رفته باشد و با نسخه جدیدتر برگردد، بازتولید یک مشکل بسیار دشوار خواهد بود.نتیجه گیریسبک معماری MicroServices یک ایده مهم است که ارزش توجه جدی برای برنامه های کاربردی سازمانی را دارد. معماری یکپارچه برای کاربردهای ساده و سبک مفید است. اگر برای کاربردهای پیچیده استفاده شود، یک کابوس تعمیر و نگهداری خواهد بود. الگوی معماری MicroServices انتخاب بهتری برای برنامه های پیچیده و در حال تحول علیرغم اشکالات و موارد اجرایی است.