معماری یکپارچه در مقابل میکروسرویس: انتخاب معماری مناسب برای پروژه

دو روش برای ساختن سیستم های پیچیده وجود دارد - یا با استفاده از معماری یکپارچه یا میکروسرویس. کدام یک را انتخاب کنید و کی؟ بگذارید آنرا بفهمیم!

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

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

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

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

چرا اینطور است؟

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

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

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

چه کسی ما را پس از آن نجات می دهد؟ خدمات میکروسرویس!

تجزیه کاربردی در هسته معماری خدمات خرد است.

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

این تجزیه عملکردی در عمل است. فواید آن چیست؟

با معماری خدمات میکرو سرویس ، بسیار ساده تر است:

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

به نظر می رسد بیهوده ، درست است؟ با این حال ، آیا معماری میکروسرویس یک گلوله نقره ای است؟ جواب نه!

در زیر "حقیقت زشت" در مورد خدمات خرد:

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

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

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

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

در اصل در yellow.id منتشر شده است.