Микросервистердің шарықтау шыңы артта қалған сияқты. Біз енді аптасына бірнеше рет «Мен монолитті 150 қызметке қалай ауыстырдым» деген жазбаларды оқымаймыз. Қазір мен қарапайым ойларды естимін: «Мен монолитті жек көрмеймін, мен тек тиімділікке мән беремін». Тіпті бірнеше көші-қонды да байқадық . Бір үлкен қолданбадан бірнеше кішігірім қызметтерге ауысқан кезде бірнеше жаңа мәселелерді шешуге тура келеді. Оларды мүмкіндігінше қысқаша тізіп көрейік.
Орнату: негізгі химиядан кванттық механикаға дейін
Негізгі дерекқор мен қосымшаны фондық процесспен орнату өте қарапайым процесс болды. Мен Readme-ді Github-да жариялаймын - және жиі бір сағат ішінде, ең көбі бір-екі сағат ішінде бәрі жұмыс істейді және мен жаңа жобаны бастаймын. Ең болмағанда бастапқы орта үшін кодты қосу және іске қосу бірінші күні орындалады. Бірақ егер біз микросервистерге кірісетін болсақ, бастапқы іске қосу уақыты күрт көтеріледі. Иә, қазір бізде оркестрі бар Docker және K8 машиналарының кластері бар, бірақ жаңадан келген бағдарламашы үшін мұның бәрі әлдеқайда күрделі. Көптеген жасөспірімдер үшін бұл шын мәнінде қажетсіз асқыну болып табылатын ауыртпалық.
Жүйені түсіну оңай емес
Бір сәт кенжемізге назар аударайық. Монолитті қолданбалармен қате орын алса, оны қадағалау оңай болды және бірден жөндеуге көшті. Енді бізде басқа қызметті өңдейтін хабарлар шинасында бірдеңені кезекте тұрған басқа қызметпен сөйлесетін қызмет бар, содан кейін қате пайда болды. Мы должны собрать воедино все эти части, чтобы в конечном итоге узнать, что служба А работает в версии 11, а служба Е уже ожидает версию 12. Это сильно отличается от моего стандартного консолидированного журнала: приходится использовать интерактивный терминал/отладчик, чтобы пройти через процесс бірте-бірте. Түзету және түсіну қиынырақ болды.
Егер оны жөндеу мүмкін болмаса, біз оларды сынап көреміз
Үздіксіз интеграция мен үздіксіз даму қазір үйреншікті құбылысқа айналып отыр. Мен көретін көптеген жаңа қолданбалар әрбір жаңа шығарылыммен автоматты түрде сынақтар жасайды және іске қосады және тіркеуден бұрын сынақтардан өтіп, тексерілуін талап етеді. Бұл тастап кетпеу керек тамаша процестер және көптеген компаниялар үшін үлкен өзгеріс болды. Бірақ қазір қызметті шынымен сынау үшін қосымшамның толық жұмыс нұсқасын шығаруым керек. 8 қызметтен тұратын K150 кластері бар жаңа инженер есіңізде ме? Енді біз CI жүйемізге барлығы шынымен жұмыс істейтінін тексеру үшін осы жүйелердің барлығын қалай тәрбиелеу керектігін үйретеміз. Бұл тым көп күш жұмсауы мүмкін, сондықтан біз әрбір бөлікті оқшаулап тексереміз: техникалық сипаттамаларымыз жеткілікті жақсы, API интерфейстері таза және қызмет ақаулығы оқшауланған және басқаларға әсер етпейтініне сенімдімін.
Барлық ымыралардың жақсы себебі бар. Дұрыс па?
Микросервистерге көшудің көптеген себептері бар. Мен мұны икемділік, командаларды масштабтау, өнімділік және тұрақтылықты жақсарту үшін жасалғанын көрдім. Бірақ шын мәнінде, біз одан әрі дамып келе жатқан монолиттерді жасау үшін құралдар мен тәжірибелерге ондаған жылдарды инвестицияладық. Мен әртүрлі технологиялардағы кәсіби мамандармен жұмыс істеймін. Біз әдетте масштабтау туралы айтамыз, өйткені олар бір Postgres дерекқор түйінінің шегіне кіреді. Әңгімелесулердің көпшілігі осы туралы .
Бірақ мен олардың архитектурасы туралы білуге әрқашан қызығамын. Олар микросервистерге өтудің қандай сатысында? Көптеген инженерлердің монолитті қолдануына риза екенін айтуы қызық. Көптеген адамдар микросервистердің пайдасын көреді және артықшылықтар көшу жолындағы кедергілерден асып түседі. Бірақ жеке менің монолитті өтінішімді, жағажайдағы орынды беріңізші - мен толығымен бақыттымын.
Ақпарат көзі: www.habr.com