Мен көптөн бери микросервис архитектурасы темасында макала жазгым келди, бирок эки нерсе мени токтото берди - мен темага канчалык терең кирген сайын, мага ошончолук менин билгендерим ачык көрүнүп тургандай сезилди жана мен эмнени билем? t билүү жана изилдөө керек. Башка жагынан алганда, менин оюмча, кеңири аудитория арасында талкуулоо үчүн бир нерсе бар. Андыктан альтернативалуу пикирлер кабыл алынат.
Конвей мыйзамы жана бизнес, уюм жана маалымат системасынын ортосундагы байланыш
Дагы бир жолу цитата кылууга уруксат берейин:
"Системаны иштеп чыккан ар кандай уюм (кеңири мааниде) структурасы ошол уюмдагы командалардын структурасын кайталаган дизайнды алат."
- Мелвин Конвей, 1967
Менин оюмча, бул мыйзам түздөн-түз маалымат системасына эмес, бизнести уюштуруунун максатка ылайыктуулугуна көбүрөөк тиешелүү. Бир мисал менен түшүндүрүп берейин. Келгиле, бизде бизнести уюштуруунун мааниси ушунчалык узун жашоо цикли менен кыйла туруктуу бизнес мүмкүнчүлүгү бар дейли (бул ката эмес, бирок мен уурдаган бул термин мага абдан жагат). Албетте, бул бизнести колдоо системасы. уюштуруу жана процесстик жактан бул бизнеске дал келет.
Маалыматтык системалардын бизнес багыты
Бир мисал менен түшүндүрүп берейин. Пицца сатуу бизнесин уюштурууга бизнес мүмкүнчүлүгү бар дейли. V1 версиясында (алдын ала маалымат дейли) компания пиццерия, кассалык аппарат жана жеткирүү кызматы болгон. Бул версия экологиялык өзгөргүчтүк төмөн шарттарда узак жашаган. Андан кийин анын ордуна 2-версия келди - кыйла өнүккөн жана монолиттүү архитектурасы менен бизнес үчүн өзөктүү маалыматтык системаны колдонууга жөндөмдүү. Бул жерде, менин оюмча, монолиттерге карата жөн эле коркунучтуу адилетсиздик бар - монолиттүү архитектура домендик бизнес моделине туура келбейт. Ооба, эгер ушундай болсо, система такыр иштей алмак эмес – ошол эле Конуэй мыйзамына жана акыл-эске карама-каршы келет. Жок, монолиттүү архитектура бизнести өнүктүрүүнүн бул этабында бизнес моделине толугу менен шайкеш келет - мен, албетте, система буга чейин түзүлгөн жана ишке киргизилген баскычты билдирет. Архитектуралык мамилеге карабастан, сервиске багытталган архитектуранын 3 версиясы да, микросервис архитектурасынын N версиясы да бирдей жакшы иштей тургандыгы абдан сонун чындык. Эмне кармады?
Баары агып турат, баары өзгөрөт же микросервистер татаалдык менен күрөшүүнүн каражатыбы?
Улантуудан мурун, микросервис архитектурасы жөнүндө кээ бир туура эмес түшүнүктөрдү карап көрөлү.
Микросервис ыкмасын колдонуунун жактоочулары көп учурда микросервистерге монолитти бузуу айрым кызматтардын коддук базасын кыскартуу аркылуу өнүгүү ыкмасын жөнөкөйлөтөт деп ырасташат. Менимче, бул сөз толук болбогон сөз. Олуттуу түрдө, монолиттүү жана бир тектүү коддун ичиндеги ачык өз ара аракеттенүү татаал окшойт? Эгер чындап эле ошондой болсо, анда бардык долбоорлор алгач микросервис катары курулмак, ал эми практика көрсөткөндөй, монолиттен микросервистерге өтүү кеңири таралган. Татаалдуулук жоголбойт; ал жөн гана жеке модулдардан интерфейстерге (маалымат автобустары, RPC, API жана башка протоколдор болсун) жана башкаруу тутумдарына өтөт. Жана бул кыйын!
Гетерогендүү стекти колдонуунун артыкчылыгы да күмөндүү. Мен бул да мүмкүн деп талашпайм, бирок чындыгында ал сейрек кездешет (Алдыга караганда - бул болушу керек - тескерисинче, артыкчылык эмес, натыйжа катары).
Продукциянын жашоо цикли жана кызматтын жашоо цикли
Жогорудагы диаграмманы дагы бир жолу карап көрүңүз. Мен бизнестин өзүнчө версиясынын жашоо циклинин кыскарышын бекеринен белгилеген эмесмин – азыркы шарттарда бизнестин версиялар ортосунда өтүшүн тездетүү анын ийгилиги үчүн чечүүчү нерсе. Продукциянын ийгилиги андагы бизнес гипотезаларын текшерүү ылдамдыгы менен аныкталат. Бул жерде, менин оюмча, микросервис архитектурасынын негизги артыкчылыгы. Бирок ирети менен кетели.
Маалыматтык системалардын эволюциясынын кийинки этабына – SOAнын сервистик багытталган архитектурасына өтөбүз. Ошентип, белгилүү бир учурда биз продуктубузда баса белгилегенбиз узак мөөнөттүү кызматтар - буюмдун версияларынын ортосунда өтүүдө кызматтын жашоо цикли буюмдун кийинки версиясынын жашоо циклинен узунураак болуу мүмкүнчүлүгү бар деген мааниде узак мөөнөттүү. Аларды такыр эле өзгөртпөө логикага туура келет - биз Эң негизгиси кийинки версияга өтүү ылдамдыгы. Бирок тилекке каршы, биз кызматтарга тынымсыз өзгөртүүлөрдү киргизүүгө аргасызбыз - бул жерде бардыгы биз үчүн иштейт, DevOps тажрыйбалары, контейнерлештирүү жана башкалар - акылга келгендин баары. Бирок булар дагы эле микросервис эмес!
Татаалдуулук менен күрөшүү үчүн каражат катары микросервистер... конфигурацияны башкаруу
Бул жерде биз акыры микросервистердин аныктоочу ролуна өтө алабыз - бул продукт конфигурациясын башкарууну жөнөкөйлөтүүчү ыкма. Көбүрөөк айтканда, ар бир микросервистин функциясы продукттун ичиндеги бизнес-функцияны домендик моделге ылайык так сүрөттөйт - булар кыска мөөнөттүү версияда эмес, узак мөөнөттүү бизнес мүмкүнчүлүктөрүндө жашаган нерселер. Ал эми буюмдун кийинки версиясына өтүү сөзмө-сөз байкалбастан ишке ашат - сиз бир микросервисти, балким, жөн гана алардын өз ара аракеттенүү схемасын өзгөртөсүз/кошуңуз жана күтүлбөгөн жерден сиз өзүңүздү келечекте табасыз, алар версияларынын ортосунда секирүүнү уланткан ыйлаган атаандаштарды артта калтырасыз. алардын монолиттери. Эми алдын ала аныкталган интерфейстери жана бизнес мүмкүнчүлүктөрү бар микросервистердин кыйла чоң көлөмү бар деп элестетиңиз. Ал эми сиз келип, продуктунун структурасын даяр микросервистерден түзөсүз - мисалы, диаграмманы тартуу менен. Куттуктайбыз - сизде платформа бар - эми сиз өзүңүз үчүн бизнести тарта аласыз. Кыялдар Кыялдар.
табылгалары
- Системанын архитектурасы анын компоненттеринин жашоо цикли менен аныкталышы керек. Эгерде компонент өнүм версиясында жашаса, микросервис ыкмасын колдонуу менен системанын татаалдыгын жогорулатуунун мааниси жок.
- Микросервис архитектурасы домен моделине негизделиши керек - анткени бизнес мүмкүнчүлүгү эң узак жашаган домен болуп саналат
- Жеткирүү практикалары (DevOps практикалары) жана оркестрлөө микросервис архитектурасы үчүн эң маанилүүлөрдүн бири болуп саналат, анткени компоненттердин өзгөрүү ылдамдыгынын өсүшү жеткирүүнүн ылдамдыгына жана сапатына талаптарды жогорулатат.
Source: www.habr.com