Микросервистер – бул чоң тиркемени жөнөкөй API аркылуу бири-бири менен байланышуучу эркин туташтырылган модулдарга бөлүү жолу.
Акыркы убакта дудуктар гана микросервис жөнүндө сүйлөшпөй калды. Бул барган сайын популярдуу болуп баратат. Модулдук архитектуралык стor өзгөчө булут негизделген чөйрөлөргө ылайыктуу көрүнөт жана популярдуулугу өсүп жатат. Биз майда-чүйдөсүнө чейин, келгиле, бардык нерсеге куштун көзү менен карап көрөлү . Ошондуктан: Микросервистер чоң долбоорду кичинекей, көз карандысыз жана эркин туташтырылган модулдарга бөлүүнүн жолу. Көз карандысыз модулдар так аныкталган жана дискреттик тапшырмалар үчүн жооптуу жана жөнөкөй жана жеткorктүү API аркылуу бири-бири менен байланышат. Башка сөз менен айтканда, микросервистер татаал, негизинен веб-тиркемелерди долбоорлоо үчүн башка архитектуралык стor болуп саналат. Бирок SOA (Кызматка багытталган архитектура) сыяктуу учурдагы архитектуралык чечимдердин эмнеси жаман? SOA аркылуу жазылган көпчүлүк заманбап ишкана чечимдери абдан жакшы иштейт окшойт. Бул, балким, бул тармактын азыркы кездеги кээ бир кыйынчылыктар жөнүндө айтуу үчүн абдан сонун учур болушу мүмкүн... Келгиле, жөнөкөй бир мисал менен баштайлы. Мен Java тorнде жазылган классикалык тиркемени иштетүү керек дейли. Алгач мен Колдонуучу интерфейсин, андан кийин UI менен өз ара аракеттене турган бир нече компоненттери бар бизнес-логикалык катмарды, акырында туруктуу маалымат базасына жеткorктүү болгон маалымат базасы катмарын иштеп чыгам. Эми мен тиркемени иштетгим келгени боюнча, мен WAR/EAR/JAR түзүп, аны serverге орнотом (мисалы, JBoss, Tomcat же WebLogic). Мунун баары бир жерде жасалгандыктан, мен монолиттүү тиркемени алам, бул бардык компоненттер бир жерде экенин билдирет... Сүрөттөгү мисал:
Кыязы, сиз бул ыкма менен мурунтан эле таанышсыз жана аны колдонгонсуз, бирок идея бул архитектуралык чечимди колдонуу менен иштеп чыгуучулар кандай кыйынчылыктарга туш болоорун көрсөтүү үчүн ушул мисалды колдонуу. Монолиттик колдонуу: кыйынчылыктарга дуушар болот
Тиркеме өскөн сайын, жазылган codeдун көлөмү да көбөйөт, аны ачуу керек болгон сайын иштеп чыгуу чөйрөсүн ашыкча жүктөшү мүмкүн. Бул, албетте, иштеп чыгуучунун натыйжалуулугун төмөндөтөт.
Баары бир жерге орнотулушу керек болгондуктан, бул башка программалоо тorне өтүү же башка технологияларга өтүү чоң көйгөйгө алып келет. Мисалы, сиз Java тorнде тиркеме жаздыңыз, бир аздан кийин Котлин чыгып, аны кайра жазууга ынтызар болдуңуз, анткени ал муздак, жакшыраак, тезирээк болуп көтөрүлгөн . Монолиттик тиркемеде рефакторинг жөнүндө ойлонуу да процесстин өзүн айтпаганда да, чыныгы ооруну жаратат. Учурда ушундай жол менен жасалган көптөгөн тиркемелер бар жана codeдун саптарынын саны укмуштуудай.
Эгерде компоненттердин бири кандайдыр бир себептерден улам иштебей калса , бүтүндөй колдонмо да бузулат. Элестетиңиз, авторизация, төлөм, тарых ж.б. сыяктуу модулдары бар веб-тиркеме бар. Анан эмнегедир бирөө сынып калат. Бул жөн гана бизнес үчүн жана натыйжада иштеп чыгуучулар үчүн шок.
Монолиттик тиркемени масштабдоо бир эле түрдөгү башка тиркемени көтөрүү менен гана жетишүүгө болот. Бирок сиз бүтүндөй тиркемени эмес, бир гана компонентти масштабдашыңыз керек болсочы. Канча ресурстар текке кетет?...
Бул колдонмону иштеп чыгуу процессине жана орнотуу процессине чоң таасирин тийгизиши мүмкүн. Тиркеме канчалык чоң болсо, иштеп чыгуучулар тиркемени кичине жумушчу бөлүктөргө бөлүшү ошончолук маанилүү. Монолиттик тиркемедеги бардык модулдар бири-бирине туташтырылгандыктан, иштеп чыгуучулар бул модулдарды бири-биринен көз карандысыз иштей/монтаждай алышпайт. Иштеп чыгуучулар бири-бирине көз каранды болгондуктан, иштеп чыгуу убактысы көбөйөт.
Ошол эле учурда биз микросервистердин маанисин, тактап айтканда, SOA стor менен жоголгон ийкемдүүлүктү калыбына келтирүү үчүн кантип колдонсо болорун карап чыгууга жана түшүнүүгө даярбыз. Кудай микросервистери жардамга келет. Ар бир архитектуралык чечимдин эң маанилүү мүнөздөмөлөрүнүн бири масштабдуулук болуп саналат. Мен микросервистерди биринчи жолу үйрөнүп жатканымда, баары "Өсөмдүүлүк искусствосу" китебиндеги цитаталарга абдан окшош экенин көрдүм. Бул эң сонун башталгыч жана талкуулоо үчүн жер. Бул китеп үч өлчөмдүү масштабдуу системаны сүрөттөгөн "Масштабдык кубу" моделин аныктайт:
Көрүнүп тургандай, X огу "горизонталдык масштабдоону" сүрөттөйт (бул монолиттүү архитектуралар үчүн да бар экенин көрдүк), Y огу ар кандай тейлөө компоненттерин бөлүү маанисинде масштабдаштырууну билдирет . Z огунун идеясы маалыматтар бөлүнгөндө түшүнүлөт жана тиркеме сурамдарды маалыматтар так жайгашкан жерге жөнөтөт. Башкача айтканда, алардын баары бир жерде эмес. Y огу идеясы - биз кененирээк токтолобуз. Бул огу функциялык ажыроону билдирет . Бул стратегияда ар кандай функцияларды көз карандысыз кызматтар катары кароого болот. Ошондуктан, бардык тиркемени бүтүргөндөн кийин гана орнотуу менен, иштеп чыгуучулар жеке кызматтарды бири-биринен көз карандысыз орното алышат жана башкалардын модулдары боюнча иштөөсүн күтпөйт. Бул иштеп чыгуу убактысын гана жакшыртпастан, ошондой эле тиркеменин калган компоненттери жөнүндө кабатыр болбостон, өзгөртүү жана кайра өткөрүү ийкемдүүлүгүн сунуштайт. Бул диаграмманы мурунку монолит менен салыштырып көрөлү:
Микросервистер: Артыкчылыктар Микросервистердин пайдасы Amazon, Netflix, Ebay сыяктуу ишканаларды иштеп чыгуучуларды бул ыкманы колдонууга ынандыруу үчүн жетиштүү окшойт. Монолиттик архитектуралык колдонмолордон айырмаланып, микросервистер:
Компоненттин бузулушунун изоляциясын жакшыртат: Чоң тиркемелер бир модуль иштебей калса дагы натыйжалуу иштей берет.
Колдонмонун бир технология стекине болгон милдеттенмесин жокко чыгарат: эгер сиз кандайдыр бир кызматта жаңы технологиялык стекти сынап көргүңүз келсе, улантыңыз. Көз карандылыктар монолиттикке караганда бир топ жеңил болот, ошондой эле баарын артка кайтаруу оңой болот. Бир тиркемедеги code канчалык аз болсо, иштөө ошончолук жеңил болот.
Жаңы кызматкерлерге кызматтын функционалдуулугун түшүнүү бир топ жеңилдейт.
Микросервистер: монтаждоо жана виртуалдаштыруу өзгөчөлүктөрү Эми биз микросервис деген эмне экенин түшүнөбүз. Ал эми эң чоң артыкчылыгы - ал бирден ашык WAR/EAR/JAR архиви менен орнотулган. Бирок ал кантип орнотулган? Микросервистерди контейнерлердин ичине орнотуунун эң жакшы жолу. Контейнер - бул конфигурацияланган керектүү чөйрөсү бар толук конфигурацияланган виртуалдык операциялык система, ал контейнер орнотулган аппараттык системанын ресурстарына кирүү мүмкүнчүлүгүн обочолонтууга жардам берет. Базардагы эң белгилүү чечим, албетте, Docker . IaaS (кызмат катары инфраструктура) AWS сыяктуу виртуалдык машиналар да микросервистерди орнотуу үчүн жакшы иштей алат, бирок салыштырмалуу жеңил микросервистер виртуалдык машинадагы бардык ресурстарды колдонбой калышы мүмкүн, бул колдонуунун кирешелүүлүгүн төмөндөтөт. Сиз ошондой эле OSGI (Open Service Gateway Initiative) пакетин колдонуп микросервисиңизди орното аласыз . Бул учурда, бардык микросервистер бир JVMде иштейт, бирок бул башкаруу жана обочолонуунун ортосундагы соодалашууну камтыйт. Микросервистер: Кемчorктер "Мунун баары сонун" жана "Биз муну мурун көргөн эмеспиз" дегени эч кандай кемчorктер жок дегенди билдирбейт. Төмөндө микросервис архитектурасы менен кошо оорунун мүмкүн болгон аймактарынын тизмеси келтирилген:
Бөлүштүрүлгөн системаларды иштеп чыгуу кыйын болушу мүмкүн. Муну менен мен бардык компоненттер азыр көз карандысыз кызматтар экенин айткым келет - модулдар ортосунда өтүүчү суроо-талаптарды өтө кылдаттык менен иштетүү керек. Бир модуль жооп бербей жаткан сценарий болушу мүмкүн, бул системаны кыйратпоо үчүн кошумча code жазууга мажбурлайт. Алыскы чалуулар күтүү убактысына сезгич болсо, бул кыйыныраак болушу мүмкүн .
Бир нече маалымат базалары жана транзакцияларды башкаруу чыныгы азап болушу мүмкүн.
микросервис тиркемелерин текшерүү түйшүктүү болушу мүмкүн. Монолиттик тиркемени колдонуу менен биз serverде WAR/EAR/JAR архивин иштетип, анын маалымат базасына туташып турганын текшеришибиз керек. Ал эми микросервистерде тестирлөө башталганга чейин ар бир жеке кызмат башталышы керек.
Тиркемелерди орнотуу татаал болушу мүмкүн. Алар бир нече кызматтардын айланасында координациялоону талап кылышы мүмкүн, аларды WAR контейнериндей орнотуу оңой эмес.
.... Албетте, туура шаймандар жана ыкмалар менен бул кемчorктерден качууга болот. Бирок алар өздөрү колдоого муктаж жана бардык көйгөйлөрдү толук чечпейт. Макала CloudAcademy сайтынан которулган . Акысыз котормо. Ар бир адам өз оюн комментарийде эркин билдирүүгө укуктуу. Алар сөзсүз окулат. Түпнуска макала Менин Github аккаунтум
GO TO FULL VERSION