Сәлем, Хабр. Жаңа курс ағынына жазылу дәл қазір OTUS-те ашық . Курстың басталу қарсаңында мен сіздермен өзімнің түпнұсқа мақаламмен бөліскім келеді.
Кіріспе
Архитектуралық стильді таңдау ақпараттық жүйені құру кезінде негізгі техникалық шешімдердің бірі болып табылады. Осы мақалалар сериясында мен қосымшаларды салуға арналған ең танымал архитектуралық стильдерді талдауды және қай сәулет стилі ең қолайлы деген сұраққа жауап беруді ұсынамын. Презентация процесінде мен монолиттерден микросервистерге дейінгі архитектуралық стильдердің дамуын түсіндіретін логикалық тізбекті сызуға тырысамын.
Біраз тарих
Егер сіз әзірлеушілерден: «Бізге микросервис не үшін қажет?» Деп сұрағыңыз келсе, әртүрлі жауаптар аласыз. Микросервистердің масштабтауды жақсартатынын, кодты түсінуді жеңілдететінін, ақауларға төзімділікті жақсартатынын және кейде олардың «кодыңызды тазалауға» мүмкіндік беретінін естисіз. Микросервистердің пайда болу мақсатын түсіну үшін тарихты қарастырайық.
Қысқаша айтқанда, біздің қазіргі түсінігіміздегі микросервистер келесідей пайда болды: 2011 жылы Джеймс Льюис әртүрлі компаниялардың жұмысын талдай отырып, SOA-ны орналастыруды жеделдету тұрғысынан оңтайландырған жаңа «микро-қосымша» үлгісінің пайда болуына назар аударды. қызметтер. Біраз уақыттан кейін, 2012 жылы, сәулет саммитінде үлгі микросервис деп өзгертілді. Осылайша, микросервистерді енгізудің бастапқы мақсаты танымалды жақсарту болды нарыққа шығу уақыты.
Микросервистер 2015 жылы жоғары толқында болды. Кейбір зерттеулерге сәйкес, бірде-бір конференция микросервис тақырыбы бойынша баяндамасыз аяқталмаған. Сонымен қатар, кейбір конференциялар тек микросервистерге арналды. Қазіргі уақытта көптеген жобалар осы архитектуралық стильді қолдана бастайды және жобада мыңдаған бұрынғы кодтар болса, микросервистерге көшу белсенді түрде жүргізілуде.
Жоғарыда айтылғандардың бәріне қарамастан, әзірлеушілердің өте аз саны әлі де «микросервис» түсінігін анықтай алады. Бірақ бұл туралы сәл кейінірек айтатын боламыз ...
Монолит
Микросервистерге қарама-қайшы келетін архитектуралық стиль монолит (немесе барлығы бір жерде) болып табылады. Монолиттің не екенін айтудың мағынасы жоқ шығар, сондықтан мен архитектуралық стильдердің одан әрі дамуын бастаған осы архитектуралық стильдің кемшіліктерін дереу тізіп беремін: өлшем, байланыс, орналастыру, масштабтау, сенімділік және қатаңдық. Төменде мен кемшіліктердің әрқайсысын бөлек қарастыруды ұсынамын.
мөлшері
Монолит өте үлкен. Және ол әдетте өте үлкен мәліметтер базасымен байланысады. Қолданба бір әзірлеушіге мүлде түсіну үшін тым үлкен болады. Бұл кодпен жұмыс істеуге көп уақыт жұмсағандар ғана монолитпен жақсы жұмыс істей алады, ал жаңадан бастағандар монолитті анықтауға көп уақыт жұмсайды және олардың оны анықтайтынына кепілдік жоқ. Әдетте, монолитпен жұмыс істегенде, монолитті азды-көпті жақсы білетін және бір жарым жыл ішінде басқа жаңа әзірлеушілердің қолын ұратын кейбір «шартты» аға әрқашан болады. Әрине, мұндай шартты аға - бұл жалғыз сәтсіздік нүктесі, ал оның кетуі монолиттің өліміне әкелуі мүмкін.
Байланыс
Монолит - бұл «үлкен балшық шары», оның өзгеруі күтпеген салдарға әкелуі мүмкін. Бір жерде өзгертулер енгізу арқылы сіз басқа жерде монолитті зақымдай аласыз («сіз құлағыңызды тырнап алдыңыз, *@ құлап қалды»). Бұл монолиттегі құрамдас бөліктердің өте күрделі және ең бастысы айқын емес қарым-қатынастарына байланысты.
Орналастыру
Монолитті орналастыру, оның құрамдас бөліктері арасындағы күрделі қатынастарға байланысты, өзіндік рәсімі бар ұзақ процесс. Мұндай рәсім әдетте толығымен стандартталмаған және «ауызша» беріледі.
Масштабтылық
Монолиттік модульдерде қайшылықты ресурс қажеттіліктері болуы мүмкін, бұл аппараттық құралдарға қатысты ымыраға келуді талап етеді. Сізде A және B қызметтерінен тұратын монолит бар деп елестетіп көріңіз. А қызметі қатты дискінің өлшемін талап етеді, ал В қызметі жедел жадты талап етеді. Бұл жағдайда монолит орнатылған құрылғы екі қызметтің де талаптарын қолдауы керек немесе қызметтердің бірін қолмен, жасанды түрде өшіруге тура келеді.
Тағы бір мысал (классикалық): А қызметі В қызметіне қарағанда әлдеқайда танымал, сондықтан сіз 100 А қызметі және 10 В қызметі болғанын қалайсыз. Тағы да екі нұсқа: не біз 100 толыққанды монолиттерді орналастырамыз, немесе кейбіреулерінде одан кейін. B қызметтерін қолмен өшіру керек.
Сенімділік
Барлық қызметтер бірге орналасқандықтан, монолит құласа, онда барлық қызметтер бірден түседі. Шындығында, бұл соншалықты жаман болмауы мүмкін, кем дегенде бөлінген жүйеде ішінара ақаулар болмайды, бірақ екінші жағынан, пайдаланушылардың 0.001% пайдаланатын функционалдық қатеге байланысты сіз барлық пайдаланушыларды жоғалтуыңыз мүмкін. сіздің жүйеңізден.
Инерция
Монолиттің көлеміне байланысты жаңа технологияларға көшу қиын. Нәтижесінде, сол ағаны қалдыру - бұл бөлек міндет. Жобаның басында таңдалған технологиялық стек өнімнің дамуына кедергі болатын блокқа айналуы мүмкін.
қорытынды
Келесі жолы біз компоненттер мен SOA-ға көшу арқылы адамдар осы мәселелерді шешуге тырысқаны туралы айтатын боламыз.
Ары қарай оқу:
Ақпарат көзі: www.habr.com