سلام، هابر! تقدیم شما می کنم ترجمه مقاله توسط نویسنده .
در زمانی که دنیای فناوری اطلاعات به تدریج به سمت میکروسرویس ها و ابزارهایی مانند Kubernetes می رود، تنها یک مشکل بیشتر و بیشتر به چشم می خورد. این مشکل - نسخه های میکروسرویس با این حال، جامعه فناوری اطلاعات معتقد است که وضعیت فعلی بسیار بهتر از این است نسل قبلی تکنولوژی با این حال، نسخه سازی میکروسرویس ها یک مشکل بسیار پیچیده است. یکی از دلایل این امر می تواند مقالاتی مانند .
اگر با خواندن این متن باز هم متوجه مشکل نشدید، توضیح دهید. فرض کنید محصول شما از 10 میکروسرویس تشکیل شده است. حال فرض می کنیم 1 نسخه جدید برای هر یک از این میکروسرویس ها منتشر شده است. فقط 1 نسخه - امیدوارم همه بتوانیم موافق باشیم که این یک واقعیت بسیار پیش پا افتاده و بی اهمیت است. اما حالا بیایید نگاهی دیگر به محصول خود بیندازیم. فقط با یک نسخه جدید از هر مؤلفه، اکنون 2^10 - یا 1024 جایگشت از نحوه ترکیب محصول خود داریم.
اگر هنوز سوء تفاهمی وجود دارد، اجازه دهید من ریاضی را تجزیه کنم. بنابراین ما 10 میکروسرویس داریم که هر کدام یک به‌روزرسانی دریافت می‌کنند. یعنی ما برای هر میکروسرویس 2 نسخه ممکن (چه قدیمی و چه جدید) دریافت می کنیم. حال برای هر یک از اجزای محصول می توانیم از یکی از این دو نسخه استفاده کنیم. از نظر ریاضی مثل این است که یک عدد دودویی 10 رقمی داشته باشیم. به عنوان مثال، فرض کنید که 1 نسخه جدید است و 0 نسخه قدیمی است - سپس یک جایگشت ممکن را می توان به عنوان 1001000000 نشان داد - که در آن مؤلفه های 1 و 4 به روز می شوند و بقیه اجزای دیگر نیستند. از ریاضیات می دانیم که یک عدد باینری 10 رقمی می تواند 2^10 یا 1024 مقدار داشته باشد. یعنی مقیاس عددی که با آن سر و کار داریم را تایید کرده ایم.
بیایید استدلال خود را بیشتر ادامه دهیم - اگر 100 میکروسرویس داشته باشیم و هر کدام 10 نسخه ممکن داشته باشند چه اتفاقی خواهد افتاد؟ کل وضعیت کاملاً ناخوشایند می شود - ما اکنون 10^100 جایگشت داریم - که تعداد زیادی است. با این حال، من ترجیح می‌دهم این وضعیت را اینگونه بدانم، زیرا اکنون دیگر پشت کلماتی مانند "kubernetes" پنهان نمی‌شویم، بلکه با مشکل آن‌طور که هست مواجه هستیم.
چرا من اینقدر مجذوب این مشکل هستم؟ تا حدودی به این دلیل که قبلاً در دنیای NLP و AI کار کرده بودیم، حدود 5-6 سال پیش درباره مشکل انفجار ترکیبی زیاد بحث کردیم. فقط به‌جای نسخه‌ها، کلمات جداگانه و به جای محصولات، جملات و پاراگراف‌ها داشتیم. و اگرچه مشکلات NLP و AI تا حد زیادی حل نشده باقی مانده است، باید پذیرفت که پیشرفت قابل توجهی در چند سال گذشته حاصل شده است. (به نظر من می توان پیشرفت کردоبهتر است که افراد در صنعت کمی کمتر به یادگیری ماشین و کمی بیشتر به تکنیک های دیگر توجه کنند - اما این در حال حاضر خارج از موضوع است).
بیایید به دنیای DevOps و میکروسرویس ها برگردیم. ما با یک مشکل بزرگ روبرو هستیم، خود را به عنوان یک فیل در Kunstkamera - زیرا آنچه من اغلب می شنوم این است که "فقط کوبرنت و سکان را بردارید، و همه چیز خوب خواهد شد!" اما نه، اگر همه چیز همانطور که هست رها شود، همه چیز خوب نخواهد بود. علاوه بر این، راه حل تحلیلی برای این مشکل به دلیل پیچیدگی آن قابل قبول به نظر نمی رسد. مانند NLP، ابتدا باید با محدود کردن دامنه جستجو به این مشکل نزدیک شویم - در این مورد، با حذف جایگشت های قدیمی.
یکی از چیزهایی که ممکن است کمک کند چیزی است که سال گذشته نوشتم . همچنین مهم است که توجه داشته باشید که یک فرآیند CI/CD به خوبی طراحی شده تا حد زیادی به کاهش تنوع کمک می کند. با این حال، وضعیت فعلی CI/CD برای حل مشکل جایگشت بدون ابزار اضافی برای اجزای حسابداری و ردیابی به اندازه کافی خوب نیست.
آنچه ما نیاز داریم یک سیستم آزمایش در مرحله یکپارچه سازی است، که در آن بتوانیم عامل خطر را برای هر جزء تعیین کنیم، و همچنین یک فرآیند خودکار برای به روز رسانی اجزای مختلف و آزمایش بدون دخالت اپراتور داشته باشیم - تا ببینیم چه چیزی کار می کند و چه چیزی نیست.
چنین سیستم آزمایشی می تواند به شکل زیر باشد:
- توسعه‌دهندگان تست‌ها را می‌نویسند (این یک مرحله حیاتی است - زیرا در غیر این صورت معیار ارزیابی نداریم - مانند برچسب‌گذاری داده‌ها در یادگیری ماشینی است).
- هر جزء (پروژه) سیستم CI خود را دریافت می کند - این فرآیند اکنون به خوبی توسعه یافته است و مسئله ایجاد یک سیستم CI برای یک جزء تا حد زیادی حل شده است.
- «سیستم ادغام هوشمند» نتایج سیستم‌های مختلف CI را جمع‌آوری می‌کند و پروژه‌های مؤلفه را در محصول نهایی مونتاژ می‌کند، آزمایش را اجرا می‌کند و در نهایت کوتاه‌ترین مسیر را برای دستیابی به عملکرد محصول مورد نظر بر اساس مؤلفه‌ها و عوامل خطر موجود محاسبه می‌کند. اگر امکان به روز رسانی وجود نداشته باشد، این سیستم به توسعه دهندگان در مورد اجزای موجود و اینکه کدام یک از آنها باعث ایجاد خطا شده است اطلاع می دهد. بار دیگر، سیستم آزمون در اینجا از اهمیت حیاتی برخوردار است - زیرا سیستم یکپارچه سازی از آزمون ها به عنوان یک معیار ارزیابی استفاده می کند.
- سیستم CD، که سپس داده ها را از سیستم یکپارچه سازی هوشمند دریافت می کند و به طور مستقیم به روز رسانی را انجام می دهد. این مرحله به چرخه پایان می دهد.
به طور خلاصه، برای من یکی از بزرگترین مشکلات در حال حاضر فقدان چنین "سیستم یکپارچه سازی هوشمند" است که اجزای مختلف را به یک محصول مرتبط می کند و بنابراین به شما امکان می دهد نحوه ترکیب محصول را به طور کلی دنبال کنید. من به افکار جامعه در این مورد علاقه مند خواهم شد (اسپویل - من در حال حاضر روی یک پروژه کار می کنم ، که می تواند به چنین سیستم یکپارچه سازی هوشمند تبدیل شود).
آخرین چیزی که می خواهم به آن اشاره کنم این است که برای من یکپارچه برای هیچ پروژه ای حتی با اندازه متوسط قابل قبول نیست. برای من، تلاش برای سرعت بخشیدن به زمان اجرا و کیفیت توسعه با بازگشت به یکپارچگی، شک و تردید زیادی ایجاد می کند. اولاً ، یک مونولیت مشکل مشابهی در مدیریت مؤلفه ها دارد - در میان کتابخانه های مختلفی که از آنها تشکیل شده است ، با این حال ، همه اینها چندان قابل توجه نیست و در درجه اول در زمان صرف شده توسط توسعه دهندگان ظاهر می شود. پیامد مشکل یکپارچه، عدم امکان مجازی ایجاد تغییرات در کد - و سرعت بسیار پایین توسعه است.
میکروسرویس ها وضعیت را بهبود می بخشند، اما پس از آن معماری میکروسرویس با مشکل انفجار ترکیبی در مرحله ادغام مواجه می شود. بله، در کل همین مشکل را از مرحله توسعه به مرحله یکپارچه سازی منتقل کرده ایم. با این حال، به نظر من، رویکرد میکروسرویس همچنان به نتایج بهتری منجر می شود و تیم ها سریعتر به نتایج می رسند (احتمالاً عمدتاً به دلیل کاهش اندازه واحد توسعه - یا اندازه دسته). با این حال، حرکت از یکپارچه به میکروسرویس ها هنوز این روند را به اندازه کافی بهبود نداده است - انفجار ترکیبی نسخه های میکروسرویس یک مشکل بزرگ است، و ما پتانسیل زیادی برای بهبود وضعیت در حین حل آن داریم.
منبع: www.habr.com