مرگ (یا نه) میکروسرویس ها

نوعی از توسعه نرم افزار که اجزای کوچک و مستقل را در بر می گیرد، میکروسرویس ها شهرت بحث برانگیزی دارند که هم به عنوان بهترین چیز بعدی و هم چیزی که بسیار گذرا است، ممکن است قبلا مرده باشد.طرفداران میکروسرویس ها به سرعت به موفقیت های نتفلیکس و آمازون اشاره می کنند که هر دو با نوعی فرهنگ DevOps کار می کنند و در عین حال از رویکرد میکروسرویس در توسعه نرم افزار خود استقبال می کنند. استقرار موفقیت آمیز میکروسرویس ها می تواند این تصور را ایجاد کند که سیستم شما بسیار انعطاف پذیر و مقاوم در برابر خطا است. به علاوه، یک مکتب فکری، به درستی یا نادرست، میکروسرویس ها را با فرهنگ DevOps که به خوبی کار می کند، مرتبط می کند.برخی دیگر می‌گویند که میکروسرویس‌ها آخرین کلمه کلیدی برای رویکردی است که برای توسعه نرم‌افزار انجام شده است، اما رویکردی که به لطف توسعه سریع در فناوری کانتینر و ارکستراسیون در حال بهبود است.چه طرفدار یا مخالف میکروسرویس ها باشید، چیزی برای تغییر رویکرد ما در توسعه نرم افزار وجود دارد. فناوری در چند سال به سرعت تغییر می کند، چه رسد به یک نسل کامل، بنابراین باید تغییراتی را در نحوه رویکرد توسعه نرم افزار در نظر بگیریم. شاید میکروسرویس ها یک رویکرد باشد.جذابیت میکروسرویس هامیکروسرویس‌ها به یک تکنیک توسعه نرم‌افزار اشاره دارند که نوعی معماری سرویس‌گرا (SOA) است. توسعه میکروسرویس ها به این معنی است که شما نرم افزاری را به عنوان مجموعه ای از خدمات قابل استقرار مستقل طراحی می کنید. محیط ایده‌آل برای میکروسرویس‌ها بسیار دانه‌دار است و دارای پروتکل‌های سبک وزن و عملکرد است.در واقع، استقلال کلید خدمات میکرو است. در حالی که هیچ معماری خاصی برای میکروسرویس ها وجود ندارد، یک محیط میکروسرویس اغلب دارای ویژگی های مشترکی مانند سازماندهی حول قابلیت های تجاری، استقرار خودکار، کنترل غیرمتمرکز زبان ها و داده ها و هوشمندی نقطه پایانی است.در مقایسه با یک سیستم یکپارچه، میکروسرویس ها راحت تر قابل درک هستند. یک برنامه سنتی یکپارچه معمولاً به صورت یک واحد ساخته می شود که دارای سه بخش اصلی است:برنامه سمت سرور، که درخواست های HTTP را مدیریت می کند، منطق دامنه را اجرا می کند و داده ها را از پایگاه داده(های) مرتبط فراخوانی می کند.پایگاه های داده و کتابخانه های خارجیرابط کاربری سمت مشتریدر چنین سیستم یکپارچه‌ای، هر تغییری در نرم‌افزار مستلزم ساخت، آزمایش و استقرار یک نسخه کاملاً جدید از برنامه سمت سرور است، بدون اینکه زمان قطعی یا کاهش خدمات در UX سمت کلاینت وجود داشته باشد.در نمونه مورد علاقه همه از میکروسرویس ها، نتفلیکس با یک واحد بزرگ نرم افزار شروع به کار کرد: یک پلت فرم پخش ویدئو. همانطور که استفاده در سراسر جهان و کتابخانه محتوای آنها گسترش یافت، عملکرد آنها ضربه خورد. راه حل آنها؟ برای شکستن واحد تک حجیم خود به چندین واحد خدمات کوچکتر - میکروسرویس ها. هر میکروسرویس یک نقش خاص و فردی دارد: رمزگذاری، آپلود، پخش جریانی، دانلود، توصیه و مدیریت اشتراک‌ها.میکروسرویس ها: مزایا و معایباغلب وسوسه انگیز است که قدیمی را با جدید جایگزین کنید. توسعه‌دهندگان ممکن است فکر کنند که می‌توانند این کار را بهتر انجام دهند، یا حداقل با زبانی که با آن آشناتر است، به مشکل نرم‌افزاری نزدیک شوند تا آن را کمتر متورم کنند.ایده شکستن یک سیستم عظیم به عملکردهای مستقل کوچکتر در نگاه اول سودمند به نظر می رسد. در واقع، این استقلال می تواند برخی از فرهنگ های توسعه دهنده را بهبود بخشد. در اینجا برخی از مزایای رایج میکروسرویس ها آورده شده است:توسعه مستقل اگر تیم کوچک شما روی یک یا دو عملکرد متمرکز است، می‌توانید با سرعت بسیار بیشتری یاد بگیرید و تولید کنید، به خصوص اگر نیازی به دخالت در کارهایی که تیم‌های توسعه‌دهنده دیگر روی آن‌ها کار می‌کنند، ندارید - چه برسد به اینکه بدانید.استقرار مستقل از آنجایی که اجزای یک میکروسرویس با اجزای موجود در دیگری (حداقل در تئوری) مرتبط نیستند، می‌توانید سریع‌تر با کاهش خطر برای سایر سرویس‌ها مستقر شوید.مقیاس پذیری مستقل بسته به محصول شما، ممکن است اوقات شلوغی داشته باشید که نیاز به افزایش مقیاس داشته باشد. اما اگر فقط نیاز دارید بخشی از محصول خود را افزایش دهید، میکروسرویس ها این اجازه را می دهند. به عنوان مثال، نتفلیکس ممکن است بخواهد میکروسرویس استریم خود را حول یک نسخه جدید بزرگ بهبود بخشد (مثلاً، فصل سوم Stranger Things). با میکروسرویس‌ها، آن‌ها می‌توانند تنها یک میکروسرویس را بهبود ببخشند، که آسان‌تر، کم خطرتر و مقرون‌به‌صرفه‌تر از ابزار مجدد کل سیستم است.کاهش هزینه ها. توسعه برای یک تابع به جای یک پلتفرم کامل به کنترل منابع کمک می کند.قابلیت استفاده مجدد از آنجایی که میکروسرویس ها برای یک عملکرد بسیار خاص هستند، این عملکرد را می توان برای استفاده مجدد در یک محصول کاملاً متفاوت، تنها با چند ترفند و بدون همراه کردن کل محیط یکپارچه سازگار کرد. بیایید در اینجا سبک قدم برداریم. فقط به این دلیل که همه ما می‌توانیم به میکروسرویس‌ها روی بیاوریم به این معنی نیست که باید این کار را انجام دهیم. میکروسرویس ها به عنوان یک راه حل ساده برای یک مشکل پیچیده ظاهر می شوند. متأسفانه، حقیقت در نهایت آشکار می‌شود: میکروسرویس‌ها پیچیدگی‌های واقعی خود را آشکار می‌کنند، چیزی که می‌تواند ناامیدکننده و حل کردن آن دشوار باشد.توسعه دهندگان باتجربه خاطرنشان می کنند که عملکرد مستقل اغلب یک بت دروغین است: در دنیای واقعی، بعید است که بسیاری از مؤلفه ها یا عملکردها بتوانند در واقع تا این حد مستقل کار کنند. مرزهای بین اجزاء بسیار تیره‌تر از آن چیزی است که ما فکر می‌کنیم، با تکیه بر قطعات دیگر، نیاز به برقراری ارتباط بین عملکردهای مختلف. مگر اینکه بتوانید به وضوح مرزها را تعریف کنید و قطعات را بر اساس آن جدا کنید، در واقع با وابستگی های متقابل کار خواهید کرد - کاری که سیستم یکپارچه شما در حال حاضر انجام می دهد.سپس مسئله موارد بیشتر وجود دارد: هرچه بیشتر توابع را تقسیم بندی کنید، تخصص بیشتری مورد نیاز است. این به این دلیل است که بسیاری از چیزها پیچیده تر می شوند: اجرای هر سرویس در یک ویژگی به جای اجرای یک برنامه واحد، کارکرد و نگهداری خدمات بسیار بیشتر، تلاش برای اطمینان از برقراری ارتباط روان، به ویژه با افزایش مسیرهای ارتباطی). با بیشتر شدن خطر شکست، و در مکان‌های بیشتر، بیشتر می‌شود.برای شرکت‌های غیر DevOps، تیم تعمیر و نگهداری احتمالاً باید ده‌ها یا صدها میکروسرویس را به جای یک یا دو مونولیت مدیریت کند. و اگر در فرهنگ DevOps کار می‌کنید، به فردی نیاز دارید که تفاوت‌های ظریف و تغییرات سریع در سیستم‌های ارکستراسیون کانتینر را درک کند و به‌روز بماند – که تضمین می‌کند همه میکروسرویس‌های شما راه‌اندازی و اجرا می‌شوند. به طور خلاصه، به نظر می‌رسد که ریزسرویس‌ها کارها را ساده‌تر می‌کنند، اما تمام قطعات زیربنایی را در نظر بگیرید که به احتمال زیاد، پیچیده‌تر خواهند شد. بدون تخصص جدی، کامپوننت‌سازی می‌تواند کثیف باشد. یک راه خوب برای سنجش تخصص تیم شما: اگر یک سیستم یکپارچه به خوبی کار نمی کند، شکستن آنها به سرویس های کوچکتر احتمالاً آن را بهتر نمی کند.رویکرد ترکیبی برای توسعه نرم افزارروند کنونی مبادله سیستم‌های قدیمی یکپارچه برای دسته‌ای از میکروسرویس‌های مستقل اما انعطاف‌پذیر است که مطمئناً جذاب است. اما، بیایید دیدگاه طولانی را در نظر بگیریم. به نظر می رسد که سیستم های قدیمی شهرت بدی به دست آورده اند، هرچند ناخواسته. سیستم‌های میراث حداقل تا حدی به این دلیل نامیده می‌شوند که دوام داشتند، آنها بخشی از یک میراث بودند، یک چیز مثبت.امروزه، سیستم‌های یکپارچه به دلایل خوبی بیشترین استفاده را در معماری نرم‌افزارهای مختلف دارند: توسعه آن‌ها آسان‌تر است. در حالی که آنها با مشکلات ذاتی همراه هستند، به ویژه هرچه مدت زمان بیشتری استفاده شوند و توسعه دهندگان بیشتری آنها را لمس کنند، به طرز شگفت انگیزی توسعه آنها در مراحل اولیه محصول ساده است. توسعه سریع به معنای زمان سریع‌تر برای بازاریابی است، چیزی که استارت‌آپ‌ها و SMB‌ها می‌توانند با آن‌ها همراه شوند.به جای انتخاب یک رویکرد منحصر به فرد برای توسعه نرم افزار، شاید پاسخ این باشد که به میکروسرویس ها به عنوان یک ابزار در جعبه ابزار توسعه دهندگان خود نزدیک شوید. در کنار سیستم‌های یکپارچه و برنامه‌های بدون سرور، میکروسرویس‌ها برای انواع خاصی از وظایف و برنامه‌ها مفید و مناسب هستند.آینده ای برای میکروسرویس ها؟ما آماده نیستیم که میکروسرویس‌ها را به عنوان گلوله نقره‌ای توسعه نرم‌افزار اعلام کنیم، اما به همان اندازه برای به صدا درآوردن ناقوس مرگ آماده نیستیم. همانطور که برخی از مونولیت ها ضعیف هستند، این احتمال وجود دارد که برخی از میکروسرویس ها نیز همین کار را انجام دهند. نکته اصلی این است که تجزیه یک سیستم به اجزای مستقل همیشه خطرناک است زیرا به مرزهای بسیار واضحی نیاز دارد که تشخیص آنها در دنیای واقعی اغلب دشوار است. اگر نمی توانید این تعادل را پیدا کنید، به سادگی پیچیدگی را تغییر می دهید. و کارشناسان هشدار می دهند، به خاطر تغییر از تغییر اجتناب کنید. گرایش‌ها می‌آیند و می‌روند، بنابراین اگر فرآیندهای شما در حال حاضر به خوبی کار می‌کنند، زمان و پول را برای ارائه ارزش در جایی که واقعاً مورد نیاز است، سرمایه‌گذاری کنید.محتمل ترین شرط برای میکروسرویس ها؟ به تیم خود، مهارت های آن ها و محصولی که در دست دارید مراجعه کنید. تیم های خوب با ابزارهای خوب محصولات خوب می سازند و عکس آن را می توان در مورد تیم های بد گفت.