19-сентябрда Москвада микросервистерге арналган HUG (Highload++ User Group) биринчи тематикалык жолугушуусу. “Микросервистерди иштетүү: Сизде Кубернете болсо да, чоңдук маанилүү” презентациясы болуп, анда биз Фланттын микросервис архитектурасы менен долбоорлорду иштетүү боюнча кеңири тажрыйбасы менен бөлүштүк. Биринчиден, бул ыкманы учурдагы же келечектеги долбоорунда колдонууну ойлоп жаткан бардык иштеп чыгуучулар үчүн пайдалуу болот.
тааныштыруу (50 мүнөт, макалага караганда алда канча маалыматтуу), ошондой эле текст түрүндө андан негизги үзүндү.
Эскертүү: Видео жана презентация да ушул посттун аягында жеткиликтүү.
тааныштыруу
Адатта жакшы окуянын башталышы, негизги сюжети жана резолюциясы болот. Бул репортаж көбүрөөк прелюдияга окшош жана трагедиялуу. Ал микросервистерге бөтөн адамдын көз карашын камсыз кылаарын да белгилей кетүү керек. иштеп жаткан.
Мен бул графиктен баштайын, анын автору (2015-ж.) Мартин Фаулер:
Ал белгилүү бир мааниге жеткен монолиттүү колдонууда кантип өндүрүмдүүлүк төмөндөй баштаганын көрсөтөт. Микросервистер алар менен баштапкы өндүрүмдүүлүк төмөн болгону менен айырмаланат, бирок татаалдык өскөн сайын эффективдүүлүктүн начарлашы алар үчүн анча байкалбайт.
Мен Kubernetes колдонуу үчүн бул графикке кошом:
Эмне үчүн микросервистери бар тиркеме жакшыраак? Анткени мындай архитектура архитектурага олуттуу талаптарды коёт, алар өз кезегинде Кубернетестин мүмкүнчүлүктөрү менен толук камтылган. Башка жагынан алып караганда, бул функциянын кээ бирлери монолит үчүн пайдалуу болот, өзгөчө, анткени типтүү монолит бүгүнкү күндө так монолит эмес (детальдар кийинчерээк отчетто берилет).
Көрүнүп тургандай, акыркы график (монолиттик жана микросервис тиркемелери Kubernetes менен инфраструктурада болгондо) түпнускадан анча деле айырмаланбайт. Кийинки биз Kubernetes менен иштетилген колдонмолор жөнүндө сүйлөшөбүз.
Пайдалуу жана зыяндуу микросервистер
Жана бул жерде негизги идея:
Бул не нормалдуу микросервис архитектурасы? Бул иш натыйжалуулугун жогорулатуу, реалдуу пайда алып келиши керек. Графикке кайрылсак, бул жерде:
Эгер сиз аны чакырсаңыз пайдалуу, анда графиктин башка тарабында болот зыяндуу микросервистер (жумушка тоскоол болот):
"Негизги идеяга" кайтуу: мен өзүмдүн тажрыйбама такыр ишенишим керекпи? Ушул жылдын башынан бери карадым 85 долбоор. Алардын баары эле микросервис болгон эмес (алардын үчтөн бир жарымына жакыны ушундай архитектурага ээ болгон), бирок бул дагы эле чоң сан. Биз (Flant компаниясы) аутсорсер катары чакан компанияларда (5 иштеп чыгуучу менен) жана чоңдордо (~500 иштеп чыгуучу) иштелип чыккан ар кандай тиркемелерди көрө алабыз. Кошумча артыкчылыгы - бул тиркемелерди көрүп, жылдар бою өнүгүп жатканын көрөбүз.
Эмне үчүн микросервистер?
Микросервистердин артыкчылыктары жөнүндө суроо бар мурда айтылган Мартин Фаулерден:
- модулдуктун так чектери;
- көз карандысыз жайылтуу;
- технологияларды тандоо эркиндиги.
Мен программалык камсыздоонун архитекторлору жана иштеп чыгуучулары менен көп сүйлөштүм жана аларга микросервис эмне үчүн керек экенин сурадым. Анан мен алардын күткөн тизмесин түздүм. Бул жерде эмне болду:
Эгерде биз кээ бир пункттарды "сезимдердеги" сүрөттөй турган болсок, анда:
- модулдардын так чектери: бул жерде бизде коркунучтуу монолит бар, эми баары Гит репозиторийлеринде тыкан жайгаштырылат, анда баары "текчелерде", жылуу менен жумшак аралашпаган;
- жайылтуунун көз карандысыздыгы: өнүгүү ылдамыраак болушу үчүн кызматтарды өз алдынча жайылта алабыз (параллель жаңы функцияларды жарыялоо);
- өнүгүүнүн көз карандысыздыгы: биз бул микросервисти бир командага/иштеп чыгуучуга, экинчисине экинчисине бере алабыз, анын аркасында биз тезирээк өнүгүп кете алабыз;
- бокөбүрөөк ишенимдүүлүк: жарым-жартылай бузулуу болсо (20дан бир микросервис түшүп кетсе), анда бир гана баскыч иштебей калат, ал эми тутум бүтүндөй иштей берет.
Типтүү (зыяндуу) микросервис архитектурасы
Эмне үчүн чындык биз күткөндөй эмес экенин түшүндүрүү үчүн мен сунуш кылам коллективдуу көптөгөн ар кандай долбоорлордун тажрыйбасына негизделген микросервис архитектурасынын сүрөтү.
Мисалы, Amazon же жок дегенде OZON менен атаандаша турган абстрактуу онлайн дүкөнү болот. Анын микросервис архитектурасы төмөнкүдөй көрүнөт:
Бир нече себептерден улам, бул микросервистер ар кандай платформаларда жазылган:
Ар бир микросервис автономияга ээ болушу керек болгондуктан, алардын көбүнө өздөрүнүн маалымат базасы жана кэш керек. акыркы архитектура төмөнкүдөй:
Анын кесепеттери кандай?
Фаулерде да ушундай бар — микросервистерди колдонуу үчүн «төлөм» жөнүндө:
Жана биздин күтүүлөрүбүз акталганбы, көрөбүз.
Модулдардын чектерин тактоо...
бирок канча микросервисти оңдошубуз керек?өзгөртүү киргизүү үчүн? Биз баары бөлүштүрүлгөн трекерсиз кантип иштээрин түшүнө алабызбы (анткени, ар кандай суроо-талап микросервистердин жарымы тарабынан иштелип чыгат)?
үлгү бар "", жана бул жерде бир топурактан таралган бир кесек болуп чыкты. Муну ырастоо үчүн, бул жерде сурамдардын кандайча кеткенинин болжолдуу иллюстрациясы келтирилген:
Жайгаштыруу көз карандысыздыгы...
Техникалык жактан бул жетишилди: биз ар бир микросервисти өзүнчө чыгара алабыз. Бирок иш жүзүндө ал ар дайым чыгып турганын эске алуу керек көп микросервис, жана биз эске алышыбыз керек аларды чыгаруунун тартиби. Жакшы жагынан алганда, биз жалпысынан релизди туура тартипте чыгарып жатканыбызды өзүнчө схемада сынап көрүшүбүз керек.
Технологияны тандоо эркиндиги...
Ал. Эркиндик көп учурда мыйзамсыздык менен чектеш экенин унутпаңыз. Бул жерде жөн гана алар менен "ойноо" үчүн технологияларды тандабоо абдан маанилүү.
Өнүктүрүүнүн көз карандысыздыгы...
Бүтүндөй тиркеме үчүн сыноо циклин кантип жасоо керек (ушунча көп компоненттер менен)? Бирок сиз дагы деле аны жаңыртып турушуңуз керек. Мына ушунун бардыгы ушуга алып келет сыноо схемаларынын чыныгы саны, биз принципиалдуу түрдө камтый алабыз, минималдуу болуп чыгат.
Жана мунун баарын локалдуу жайгаштыруубу?.. Көрсө, иштеп чыгуучу көп учурда өз ишин өз алдынча жасайт, бирок “кокусунан”, анткени ал схема тестирлөө үчүн бош болгуча күтүүгө аргасыз болот.
Өзүнчө масштабдоо...
Ооба, бирок ал колдонулган DBMS чөйрөсүндө чектелген. Берилген архитектуралык мисалда Кассандрада көйгөйлөр болбойт, бирок MySQL жана PostgreSQLде көйгөйлөр жаралат.
Бокөбүрөөк ишенимдүүлүк ...
Чындыгында бир микросервистин иштебей калышы бүткүл системанын туура иштешин бузуп гана койбостон, жаңы көйгөй да бар: ар бир микросервисти катага чыдамдуу кылуу абдан кыйын. Микросервистерде ар кандай технологиялар (memcache, Redis ж.
Жүктүн өлчөө мүмкүнчүлүгү...
Бул чынында эле жакшы.
Микросервистердин "жеңилдиги"...
Бизде зор гана эмес тармактын ашыкча чыгымы (DNS үчүн суроо-талаптар көбөйүүдө ж.б.), бирок ошондой эле биз баштаган көптөгөн субсуроолордон улам маалыматтарды кайталоо (дүкөн кэштери), бул сактоонун олуттуу көлөмүнө алып келди.
Жана бул жерде биздин күтүүлөрүбүздүн натыйжасы болуп саналат:
Бирок бул баары эмес!
Себеби:
- Кыязы, бизге билдирүү автобус керек болот.
- Кантип ырааттуу камдык көчүрмөнү керектүү учурда жасоо керек? жалгыз чыныгы параметр бул үчүн трафикти өчүрүү болуп саналат. Бирок муну өндүрүштө кантип жасоо керек?
- Эгерде биз бир нече регионду колдоо женунде айта турган болсок, анда алардын ар биринде туруктуулукту уюштуруу абдан эмгекти талап кылган иш.
- Борборлоштурулган өзгөртүүлөрдү киргизүү маселеси келип чыгат. Мисалы, PHP версиясын жаңыртышыбыз керек болсо, анда биз ар бир репозиторийге милдеттендиришибиз керек (жана алардын ондогондору бар).
- Операциялык татаалдыктын өсүшү экспоненциалдуу болуп саналат.
Мунун баарын эмне кылуу керек?
Монолиттик колдонмо менен баштаңыз. Фоулердин тажрыйбасы дээрлик бардык ийгиликтүү микросервис тиркемелери монолит катары башталып, өтө чоң болуп, андан кийин бузулган. Ошол эле учурда микросервис катары курулган дээрлик бардык системалар башынан эле эртеби-кечпи олуттуу көйгөйлөргө туш болушкан.
Дагы бир баалуу ой, микросервис архитектурасы бар долбоор ийгиликтүү болушу үчүн сиз абдан жакшы билишиңиз керек жана предметтик аймак жана микросервистерди кантип жасоо керек. Ал эми предметтик аймакты үйрөнүүнүн эң жакшы жолу монолит жасоо.
Бирок, биз буга чейин эле ушундай абалда болсокчы?
Кандайдыр бир көйгөйдү чечүүнүн биринчи кадамы - бул аны менен макул болуу жана бул көйгөй экенин, биз мындан ары кыйналгыбыз келбейт.
Эгерде, ашыкча монолит болгон учурда (ал үчүн кошумча ресурстарды сатып алуу мүмкүнчүлүгүбүз түгөнүп калганда), биз аны кесип салсак, анда бул учурда тескери окуя болот: ашыкча микросервистер жардам бербей, бирок тоскоолдук кылганда - ашыкча кесип жана чоңойтуу!
Мисалы, жогоруда талкууланган жамааттык образ үчүн...
Эң шектүү микросервистерден арылыңыз:
Frontend түзүү үчүн жооптуу бардык микросервистерди бириктириңиз:
... бир микросервиске, бир (заманбап жана өзүңүз ойлогондой нормалдуу) тилде/алкакта жазылган:
Анын бир ORM (бир DBMS) жана биринчи бир нече тиркемелери болот:
... бирок, жалпысынан, сиз төмөнкү натыйжаны алып, ал жакка дагы көп которо аласыз:
Мындан тышкары, Кубернетеде биз мунун баарын өзүнчө инстанцияларда иштетебиз, демек, биз дагы эле жүктү өлчөп, аларды өзүнчө масштабдай алабыз.
Кыскача айтканда
Чоңураак сүрөттү караңыз. Көбүнчө, микросервистерге байланыштуу бул көйгөйлөрдүн баары кимдир бирөө өз милдетин аткарып, бирок "микросервистер менен ойногусу" келгендиктен келип чыгат.
"Микросервис" сөзүндө "микро" бөлүк ашыкча.. Алар чоң монолиттен кичине болгондуктан гана "микро" болуп саналат. Бирок аларды кичинекей нерсе деп ойлобоңуз.
Ал эми акыркы ой үчүн, келгиле, баштапкы диаграммага кайрылып көрөлү:
Ага жазуу жазылган (жогорку оң) экенине ынандырат Сиздин долбоорңузду түзгөн команданын көндүмдөрү ар дайым негизги болуп саналат — алар сиздин микросервис менен монолитти тандооңузда негизги ролду ойнойт. Эгерде команда жетиштүү жөндөмгө ээ болбосо, бирок ал микросервистерди жасай баштаса, окуя сөзсүз түрдө өлүмгө алып келет.
Видеолор жана слайддар
Сөздөн видео (~50 мүнөт; тилекке каршы, ал коноктордун көптөгөн эмоцияларын билдирбейт, бул баяндаманын маанайын негизинен аныктады, бирок ушундай):
Докладдын презентациясы:
PS
Биздин блогдогу башка отчеттор:
- «» (Дмитрий Столяров; 28-жылдын 2018-майы, RootConf сайтында);
- «» (Дмитрий Столяров; 7-жылдын 2017-ноябрында HighLoad++ боюнча);
- «» (Дмитрий Столяров; 6-жылдын 2017-июнунда RootConf сайтында);
- «» (Дмитрий Столяров; 8-жылдын 2016-ноябрында HighLoad++ боюнча);
- «» (Дмитрий Столяров; 31-жылдын 2016-майы, RootConf сайтында).
Сизди төмөнкү басылмалар да кызыктырышы мүмкүн:
- «";
- «";
- ««.
Source: www.habr.com