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

سیستم های توزیع شده برای مدتی وجود داشته اند. مانند دهه 1970، ما در حال ساخت برنامه هایی با مقیاس بزرگ و در دسترس بودن زیاد بوده ایم. ما از زمان حباب اینترنت در حوالی سال 95 حتی بیشتر به این سمت رفتیم و هنوز هم ادامه می دهیم. سپس، در آغاز سال 2010، میکروسرویس ها اتفاق افتاد. آدریان کاکرافت، مدیر سابق سیستم‌های ابری در نتفلیکس، «SOA ریز دانه» را چگونه توصیف کرد، دنیای توسعه را در دست گرفت.اکنون، تقریباً 10 سال آینده، یک سیستم مبتنی بر میکروسرویس چیزی عادی است که بسیاری از ما روی آنها کار کرده ایم. اما چند نفر از ما به آن‌ها نگاه می‌کنیم و واقعاً سیستم‌های توزیع‌شده را به‌جای دسته‌ای از برنامه‌های کوچک جداشده، هماهنگ‌شده، می‌بینیم؟ چه مسائلی را انتظار نداریم که هر روز با آن برخورد کنیم؟سیستم های توزیع شده چیست؟آنها سیستم هایی هستند که اجزای خود را به صورت شبکه ای در اختیار دارند و از طریق ارسال پیام با یکدیگر ارتباط برقرار می کنند. اجزاء همزمان، مستقل و فاقد هماهنگی ساعت هستند. اجزای سیستم توزیع شده ممکن است بسته به اجرا همگن یا ناهمگن باشند. ایده اصلی پشت آن‌ها این است که برای یک مشکل بزرگ‌تر، استفاده از تعداد زیادی ماشین‌های با کارایی پایین، تقسیم مشکل به قطعات کوچک‌تر و موازی کردن اجرا آسان‌تر است. نمونه ای از سیستم های توزیع شده، سیستم های مبتنی بر SOA است که در آن عملکردها (سرویس ها) در داخل یک برنامه کاربردی از طریق اجزای برنامه جداگانه ای که از طریق شبکه ارتباط برقرار می کنند، ارائه می شود. هر سرویس نشان دهنده یک عملکرد کپسوله شده است.سیستم های میکروسرویس چیست؟اینها زیرگروهی از سیستم‌های مبتنی بر SOA هستند، که در آن برنامه از سرویس‌های ریز و ریز جفت شده تشکیل شده است که از طریق پروتکل‌های سبک وزن ارتباط برقرار می‌کنند. هدف هر میکروسرویس کپسوله کردن یک لایه، یک دامنه یا یک عملکرد از سیستم است و تمایل دارد تا حد ممکن مستقل از سایرین باشد. آنها معمولاً مزایای قابل توجهی نسبت به یکپارچه ها دارند که در یک لحظه در مورد آنها صحبت خواهیم کرد، اما همچنین دارای معایب و عوارضی هستند که نباید از قلم افتاد.مزایای اصلی رویکرد میکروسرویسمدولار بودنبا طراحی، میکروسرویس ها مستقل هستند. آنها فقط می دانند که به چه چیزی نیاز دارند یا به آن اهمیت می دهند. با ساختن آنها تا حد امکان هرمتیک، هر سرویس می تواند به زبانی متفاوت، مستقل از سایر خدمات نوشته شود. این ویژگی باعث می‌شود درک، توسعه و آزمایش آسان‌تر آن‌ها آسان‌تر شود. در صورت خرابی سرویس، تنها بخش کوچکی از عملکرد برنامه در دسترس نیست و می توان آن را به طور مستقل از بقیه سیستم ثابت و مستقر کرد. به طور کلی هرچه ماژولارتر شوند، چشم انداز میکروسرویس بهتر است.مقیاس پذیریبه دنبال ماژولار بودن، و به نوعی پیامد آن، مقیاس پذیری از استقلال هر میکروسرویس در پیاده سازی و استقرار ناشی می شود. اگر آن نقطه بارگذاری شده بتواند به صورت افقی مقیاس شود، بار لحظه ای بالاتر روی یک نقطه در سیستم لزوماً عملکرد را مسدود نمی کند. حتی اگر این مقیاس‌پذیری نامحدود نباشد، مدیریت و توسعه آن بسیار آسان‌تر است زیرا سرویس مقیاس‌شده (در تئوری) کوچک و ساده است.ادغامبرنامه ها، به ویژه آنهایی که به معماری میکروسرویس نیاز دارند، معمولاً به یکباره اجرا نمی شوند. ماژولار بودن آن اجازه می دهد تا اجزای متوالی را به طور مستقل بسازید و آنها را با بقیه سیستم ادغام کنید. معمولاً کشیدن ساده‌تر از اجرای یک لایه/کامپوننت در یک مونولیت است. علاوه بر این، هر گونه تغییر احتمالی در آینده می تواند در یک میکروسرویس پیاده سازی و مستقر شود.توسعه پراکنده و موازیدر نتیجه دومی، پس از طراحی و مشخص شدن، می توان بخش هایی از سیستم را به طور مستقل توسعه داد. این هم به معنای توسعه همزمان خدمات مختلف، به عنوان امکان توزیع پیاده سازی به صورت جغرافیایی است. این به ویژه برای برنامه های کاربردی در مقیاس بزرگ و سازمان های بزرگتر با چندین تیم که روی یک سیستم واحد کار می کنند مفید است.اشکالات اصلی رویکرد میکروسرویسمعماری سیستم و ارتباطاتنحوه ارتباط اجزای سیستم اغلب پیچیده است. متوجه می‌شوید که در بسیاری از موارد استراحت ساده کافی نیست و یک صف، یک جریان یا موضوعی لازم است. این به پیچیدگی کلی می‌افزاید، اما در بیشتر موارد انعطاف‌پذیری سیستم را نیز افزایش می‌دهد.منابع، زیرساخت و نگهداریبا توجه به مقدار اجزای زیرساختی اضافی که ممکن است مورد نیاز باشد، همانطور که در نکته قبل ذکر شد، مقدار خام منابع مورد نیاز برای اجرای همه آنها بسیار زیاد است. موارد اصلی که باید برای هر سرویس در نظر گرفته شود عبارتند از: مخزن، پیکربندی، خط لوله CI/CD، اسکریپت های توسعه. همچنین، تعمیر و نگهداری باید در اینجا در نظر گرفته شود، زیرا با زیرساخت های پیچیده تر، اصلاح و عملیاتی نگه داشتن آن دشوارتر است.آزمایش کردنحتی اگر هنگام استفاده از میکروسرویس‌ها، آزمایش اجزا آسان‌تر شود، باید آزمایش‌های اضافی برای اطمینان از کیفیت انجام شود - به‌ویژه آزمایش‌های یکپارچه‌سازی و آزمایش‌های انتها به انتها. هدف از تست های ادغام، افشای عیوب در تعاملات بین میکروسرویس ها است. مشکل فقط به مقدار زیاد ادغام اجزا برای آزمایش نیست، بلکه جنبه فنی راه اندازی یک محیط آزمایشی است که چنین آزمایش هایی را تسهیل می کند. آزمایش انتها به انتها برای کاربردهای مبتنی بر میکروسرویس تا حد زیادی به مشخصات و اجرای آن بستگی دارد. اگرچه، با در نظر گرفتن چندین مؤلفه سیستم و جریان داده، معمولاً کار آسانی نیست.توسعه، اشکال زدایی و ردیابیاین مکالمه به‌عنوان حل‌وفصل شده توسط baszo علامت‌گذاری شد هنگام توسعه یک مؤلفه، توسعه‌دهنده اغلب می‌خواهد آن را به صورت محلی یا در یک محیط مستقر کند، با دیباگر ارتباط برقرار کند و بتواند عمر آن را اشکال‌زدایی کند. در مورد چند سرویس به دلیل تعداد مؤلفه هایی که جریان داده از آن عبور می کند، پیچیدگی زیرساخت و محدودیت های محیط های استقرار، بسیار پیچیده تر است. همین امر در مورد ردیابی و ثبت گزارش نیز صدق می کند، خوشبختانه اکنون ابزارهایی برای ردیابی جریان بین میکروسرویس ها وجود دارد.شرکت های کوچکبه طور کلی در نظر گرفته می‌شود که سیستم‌های میکروسرویس چیزی نیست که شرکت‌های کوچک بخواهند در آن مشارکت داشته باشند. برخی از ابزارها سعی می‌کنند این مشکل را برطرف کنند، اما با توجه به برنامه‌های کاربردی کوچک متعدد، استقرار ناهمزمان، مسائل زیرساختی و آزمایش‌های پیچیده، هزینه مورد نیاز اغلب برای کوچک‌تر بسیار زیاد است. سازمان های.معاملاتبرای یک برنامه یکپارچه، تراکنش ها معمولاً یک کار مستقیم هستند و می توانند به راحتی پیاده سازی شوند. وقتی صحبت از میکروسرویس ها می شود، تراکنش ها کمی دشوارتر می شوند. یکی از روش‌های ممکن، پیاده‌سازی مکانیزم تراکنش‌های توزیع‌شده است، اما بسیار پیچیده است، سربار زیادی به سیستم اضافه می‌کند و معمولاً با مقیاس‌بندی خوب عمل نمی‌کند. مزیت آن به حداکثر رساندن ثبات در سراسر سیستم است. رویکرد دیگر ساختن یک سیستم با ثبات نهایی است. در این صورت ما با ناهماهنگی های لحظه ای سیستم، معمولاً از نظر داده، موافقت می کنیم و برای آن آماده می شویم. گزینه دوم برای مقیاس‌بندی و برنامه‌های کاربردی با توان بالا بسیار مناسب‌تر است، اما بیشتر مستعد خطا است و نیاز به کدنویسی دقیق در مورد ناهماهنگی‌ها دارد.Refactoringایجاد تغییرات در کد در سیستم میکروسرویس می تواند مراحل مختلفی داشته باشد. اگر تغییر در سطح میکروسرویس داخلی باشد، بسیار ساده است. اما زمانی که یک تغییر در کل سیستم باشد، آنگاه چند مسئله به وجود می آید. اول، تغییر باید به طور همزمان به تعدادی از اجزاء معرفی شود، قراردادهای بین آنها باید تضمین شود. سپس استقرار تغییرات باید به صورت هماهنگ انجام شود و اغلب کل سیستم باید آفلاین شود.اشتباهات رایج میکروسرویس هابرش مناسبدو رویکرد مکرر و در عین حال نادرست در مورد پارتیشن بندی مناسب یک سیستم مبتنی بر میکروسرویس وجود دارد. اولین آنها - زمانی که یک لایه از سیستم در چندین مؤلفه توزیع می شود. محصور کردن دانش در سیستم تنها بر اساس نیاز به دانستن و پیوند دادن داده‌ها تا حد امکان آزاد است. اشتباه دوم زمانی است که یک جزء دارای دانش، آگاهی سیستم یا مسئولیت بیش از حد است. سپس این نشانه واضحی است که می تواند به دو یا چند جزء کوچکتر و تخصصی تر تقسیم شود.آگاهی مقیاسحتی اگر قرار است یکی از مزایای اصلی سیستم مبتنی بر میکروسرویس باشد، مقیاس‌پذیری اغلب نادیده گرفته می‌شود و میکروسرویس‌ها به گونه‌ای ساخته می‌شوند که نمی‌توانند مقیاس شوند. معمولاً این اتفاق می‌افتد، یعنی وقتی یک میکروسرویس «هسته» برای پیوند دادن همه بخش‌های دیگر پیاده‌سازی می‌شود، سپس به گلوگاه و یک نقطه شکست واحد تبدیل می‌شود.آگاهی کلی معماریهنگام پیاده‌سازی میکروسرویس‌ها، پارتیشن بندی و کپسوله کردن منطق، گره زدن قطعات و شلیک کردن کافی نیست. جریان های داده ای برای در نظر گرفتن، مسائل سازگاری برای حل، دسترسی برای اطمینان، پارتیشن بندی برای مدیریت وجود دارد. این سخت‌ترین جنبه سیستم‌های مبتنی بر میکروسرویس است، با این حال افرادی که تصمیم می‌گیرند به «راه میکروسرویس» بروند اغلب از آن آگاه نیستند.افکار نهاییهیاهو برای میکروسرویس ها همچنان ادامه دارد. هدف این مقاله ترساندن یا دلسرد کردن کسی نیست. هدف این است که نشان دهد انتخاب میکروسرویس‌ها عواقبی دارد. در بسیاری از موارد مزایای متعدد این رویکرد بر آن ها غلبه می کند. اما در بسیاری از موارد چسبیدن به یکپارچه قدیمی اما خوب و ساده به اندازه کافی خوب است.