Бул макалада мен иштеп жаткан долбоор кандайча чоң монолиттен микросервистердин топтомуна айланганы жөнүндө айтып берем.
Долбоор өзүнүн тарыхын бир топ убакыт мурун, 2000-жылдын башында баштаган. Алгачкы версиялары Visual Basic 6да жазылган. Убакыттын өтүшү менен бул тилди өнүктүрүү келечекте колдоо кыйын болору белгилүү болду, анткени IDE ал эми тилдин өзү начар өнүккөн. 2000-жылдардын аягында келечектүү C# тилине өтүү чечими кабыл алынган. Жаңы версия эскисин кайра карап чыгууга параллелдүү жазылган, бара-бара көбүрөөк код .NETте жазылган. C# тилиндеги Backend адегенде сервис архитектурасына багытталган, бирок иштеп чыгуу учурунда логикасы бар жалпы китепканалар колдонулуп, кызматтар бир процессте ишке киргизилген. Натыйжада биз "кызмат монолит" деп атаган тиркеме пайда болду.
Бул айкалыштыруунун бир нече артыкчылыктарынын бири кызматтардын тышкы API аркылуу бири-бирине чалуу мүмкүнчүлүгү болгон. Туурараак тейлөөгө, келечекте микросервис архитектурасына өтүү үчүн айкын өбөлгөлөр бар болчу.
Биз 2015-жылы декомпозиция боюнча ишибизди баштадык. Биз идеалдуу абалга жете элекпиз – чоң долбоордун монолит деп атоого мүмкүн болбогон бөлүктөрү дагы бар, бирок алар микросервистерге да окшобойт. Ошого карабастан прогресс олуттуу.
Мен бул тууралуу макалада айтып берем.
ыраазы
Архитектура жана учурдагы чечүүнүн көйгөйлөрү
Башында архитектурасы мындай болгон: UI өзүнчө тиркеме, монолиттик бөлүгү Visual Basic 6да жазылган, .NET тиркемеси - жетишерлик чоң маалымат базасы менен иштеген тиешелүү кызматтардын жыйындысы.
Мурунку чечимдин кемчиликтери
Бир эле ийгиликсиздик
Бизде бир эле ката болду: .NET тиркемеси бир процессте иштеди. Эгерде кандайдыр бир модуль ишке ашпай калса, анда бардык тиркеме ишке ашпай калды жана аны кайра иштетүү керек болчу. Биз ар кандай колдонуучулар үчүн көп сандагы процесстерди автоматташтыргандыктан, алардын бириндеги мүчүлүштүктөн улам баары бир канча убакыт иштей албай калышты. Ал эми программалык камсыздоо ката болгон учурда, ал тургай, камдык жардам берген жок.
Жакшыртуулардын кезеги
Бул кемчилик кыйла уюштуруучулук болуп саналат. Биздин колдонмо көптөгөн кардарларга ээ жана алардын бардыгы аны мүмкүн болушунча тезирээк жакшыртууну каалашат. Буга чейин муну параллелдүү жүргүзүү мүмкүн эмес болчу, бардык кардарлар кезекке турушкан. Бул процесс бизнес үчүн терс болду, анткени алар өздөрүнүн милдети баалуу экенин далилдеши керек болчу. Ал эми иштеп чыгуу командасы бул кезекти уюштурууга убакыт коротту. Бул көп убакытты жана күч-аракетти талап кылды, натыйжада продукт алар каалагандай тез өзгөрө алган жок.
Ресурстарды оптималдуу эмес пайдалануу
Кызматтарды бир процессте жайгаштырууда, биз ар дайым конфигурацияны серверден серверге толугу менен көчүрүп алдык. Биз ресурстарды текке кетирбөө жана жайылтуу схемабызды ийкемдүү башкарууга ээ болуу үчүн эң оор жүктөлгөн кызматтарды өзүнчө жайгаштыргыбыз келди.
Заманбап технологияларды ишке киргизүү кыйын
Бардык иштеп чыгуучуларга тааныш көйгөй: долбоорго заманбап технологияларды киргизүү каалоосу бар, бирок мүмкүнчүлүк жок. Чоң монолиттүү чечим менен учурдагы китепкананы жаңыртуу, жаңысына өтүүнү айтпаганда да, анча маанилүү эмес ишке айланат. Бул текке кеткен нервден да көп бонус алып келерин топтун жетекчисине далилдеш үчүн көп убакыт керек.
Өзгөртүүлөрдү берүү кыйынчылыгы
Бул эң олуттуу көйгөй болду - биз эки ай сайын релиздерди чыгарып турчубуз.
Ар бир чыгарылыш иштеп чыгуучулардын сыноосуна жана аракеттерине карабастан, банк үчүн чыныгы кырсыкка айланды. Бизнес жуманын башында анын кээ бир функциялары иштебей турганын түшүндү. Жана иштеп чыгуучулар аларды олуттуу окуялар бир жума күтүп турганын түшүнүштү.
Ар бир адам кырдаалды өзгөртүүнү каалаган.
Микросервистерден күтүүлөр
Даяр болгондо компоненттерди чыгаруу. Эритмени ажыратуу жана ар кандай процесстерди бөлүү жолу менен даяр болгондо компоненттерди жеткирүү.
Чакан продукция командалары. Бул маанилүү, анткени эски монолитте иштеген чоң бригаданы башкаруу кыйын болчу. Мындай команда катуу процесс боюнча иштөөгө аргасыз болгон, бирок алар көбүрөөк чыгармачылыкты жана өз алдынчалыкты каалашкан. Муну кичинекей командалар гана көтөрө алмак.
Кызматтарды өзүнчө процесстерде изоляциялоо. Идеалында, мен аны контейнерлерде обочолонткум келди, бирок .NET Frameworkте жазылган көп сандагы кызматтар Windows'до гана иштейт. .NET Core негизиндеги кызматтар азыр пайда болуп жатат, бирок алардын саны азырынча аз.
Жайгаштыруунун ийкемдүүлүгү. Биз кызматтарды код талап кылгандай эмес, бизге керектүү жол менен айкалыштыргыбыз келет.
Жаңы технологияларды колдонуу. Бул ар бир программист үчүн кызыктуу.
Өткөөл көйгөйлөр
Албетте, эгерде монолитти микросервистерге айландыруу оңой болсо, анда ал жөнүндө конференцияларда сөз кылуунун, макала жазуунун кереги жок болмок. Бул процессте көптөгөн тузактар бар, мен бизге тоскоол болгон негизгилерин айтып берейин.
Биринчи көйгөй көпчүлүк монолиттерге мүнөздүү: бизнес логикасынын ырааттуулугу. Биз монолит жазганда, керексиз кодду жазбаш үчүн класстарыбызды кайра колдонгубуз келет. Ал эми микросервистерге өткөндө, бул көйгөйгө айланат: бардык код абдан тыгыз байланышта жана кызматтарды бөлүү кыйын.
Иш башталган учурда репозиторийде 500дөн ашык долбоор жана 700 миңден ашык код саптары болгон. Бул абдан чоң чечим жана экинчи маселе. Аны жөн эле алып, микросервистерге бөлүү мүмкүн эмес болчу.
Үчүнчү маселе — зарыл инфраструктуранын жоктугу. Чынында, биз серверлерге баштапкы кодду кол менен көчүрүп жатканбыз.
Монолиттен микросервистерге кантип өтсө болот
Микросервистерди камсыздоо
Биринчиден, микросервистерди бөлүү итеративдик процесс экенин дароо өзүбүз аныктадык. Бизден дайыма бизнес көйгөйлөрүн параллелдүү иштеп чыгуу талап кылынган. Муну техникалык жактан кантип ишке ашырабыз, ансыз деле биздин көйгөй. Ошондуктан, биз итеративдик процесске даярдандык. Эгер сизде чоң тиркеме бар болсо жана ал башында кайра жазууга даяр болбосо, ал башка жол менен иштебейт.
Микросервистерди изоляциялоо үчүн кандай ыкмаларды колдонобуз?
биринчи ыкмасы — учурдагы модулдарды кызмат катары жылдыруу. Бул жагынан алганда, биз бактылуу болдук: буга чейин WCF протоколун колдонуу менен иштеген катталган кызматтар бар болчу. Алар өзүнчө жыйындарга бөлүнгөн. Биз аларды өзүнчө өткөрүп, ар бир түзүлүшкө кичинекей ишке киргизгичти коштук. Бул колдонмону кызмат катары да, консол катары да иштетүүгө мүмкүндүк берген сонун Topshelf китепканасын колдонуу менен жазылган. Чечимде эч кандай кошумча долбоорлор талап кылынбагандыктан, бул мүчүлүштүктөрдү оңдоо үчүн ыңгайлуу.
Кызматтар бизнес логикасына ылайык туташтырылган, анткени алар жалпы чогулуштарды колдонушкан жана жалпы маалымат базасы менен иштешкен. Аларды таза түрүндө микросервис деп атоого болбойт. Бирок, биз бул кызматтарды өзүнчө, ар кандай процесстерде көрсөтө алмакпыз. Ушунун өзү эле алардын бири-бирине болгон таасирин азайтуу, параллелдүү өнүгүү жана бир эле чекит менен көйгөйлөрдү кыскартууга мүмкүндүк берди.
Хост менен монтаждоо Программа классындагы коддун бир гана сабы. Биз Topshelf менен иштөөнү көмөкчү класста жашырганбыз.
namespace RBA.Services.Accounts.Host
{
internal class Program
{
private static void Main(string[] args)
{
HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");
}
}
}
Микросервистерди бөлүштүрүүнүн экинчи жолу: жаңы көйгөйлөрдү чечүү үчүн аларды түзүү. Эгерде ошол эле учурда монолит өспөсө, бул эң сонун, демек биз туура багытта бара жатабыз. Жаңы көйгөйлөрдү чечүү үчүн биз өзүнчө кызматтарды түзүүгө аракет кылдык. Эгерде мындай мүмкүнчүлүк бар болсо, анда биз өз маалыматтар моделин, өзүнчө маалымат базасын толугу менен башкарган көбүрөөк "канондук" кызматтарды түздүк.
Биз, көптөр сыяктуу эле, аутентификация жана авторизация кызматтарынан баштадык. Алар бул үчүн идеалдуу. Алар көз карандысыз, эреже катары, алар өзүнчө маалымат модели бар. Алар өздөрү монолит менен өз ара аракеттенишпейт, бир гана ал кээ бир маселелерди чечүү үчүн аларга кайрылат. Бул кызматтарды колдонуу менен, сиз жаңы архитектурага өтүүнү баштай аласыз, алардагы инфраструктураны оңдоого, тармактык китепканаларга байланыштуу кээ бир ыкмаларды сынап көрүңүз ж.б. Уюмубузда аутентификация кызматын түзө албаган командалар жок.
Микросервистерди бөлүштүрүүнүн үчүнчү жолуБиз колдонгон бир аз бизге өзгөчө болуп саналат. Бул UI катмарынан бизнес логикасын алып салуу. Биздин негизги UI тиркемебиз десктоп болуп саналат; ал backend сыяктуу C# тилинде жазылган. Иштеп чыгуучулар мезгил-мезгили менен каталарды кетирип, логиканын бөлүктөрүн UIге өткөрүп беришкен, алар backendде болуп, кайра колдонулушу керек болчу.
Эгер сиз UI бөлүгүнүн кодунан чыныгы мисалды карасаңыз, анда бул чечимдин көпчүлүгү UI формасын түзүү үчүн эле эмес, башка процесстерде пайдалуу реалдуу бизнес логикасын камтыганын көрө аласыз.
Чыныгы UI логикасы акыркы эки сапта гана бар. Биз аны кайра колдонуу үчүн серверге өткөрүп бердик, ошону менен UI кыскарып, туура архитектурага жетиштик.
Микросервистерди изоляциялоонун төртүнчү жана эң маанилүү жолу, бул монолитти азайтуу үчүн, иштетүү менен иштеп жаткан кызматтарды алып салуу болуп саналат. Учурдагы модулдарды ошол бойдон алып салганда, натыйжа дайыма эле иштеп чыгуучуларга жаккан эмес жана бизнес процесси функция түзүлгөндөн бери эскирип калган болушу мүмкүн. Рефакторинг менен биз жаңы бизнес процессин колдой алабыз, анткени бизнестин талаптары дайыма өзгөрүп турат. Биз баштапкы кодду жакшырта алабыз, белгилүү кемчиликтерди алып салабыз жана жакшыраак маалымат моделин түзө алабыз. Пайдасы көп.
Кызматтарды кайра иштетүүдөн бөлүү чектелген контекст түшүнүгү менен ажырагыс түрдө байланышкан. Бул Домендик Дизайндын концепциясы. Бул бир тилдин бардык шарттары уникалдуу түрдө аныкталган домен моделинин бөлүмүн билдирет. Мисал катары камсыздандыруунун жана векселдердин контекстин карап көрөлү. Бизде монолиттүү тиркеме бар жана биз камсыздандырууда эсеп менен иштешибиз керек. Биз иштеп чыгуучу башка ассамблеядан учурдагы Каттоо классын таап, ага Камсыздандыруу классынан шилтеме беришин күтөбүз жана бизде жумушчу код болот. DRY принциби сакталат, тапшырма учурдагы кодду колдонуу менен тезирээк аткарылат.
Натыйжада, эсеп жана камсыздандыруу контексттери байланышкан экен. Жаңы талаптар пайда болгондон кийин, бул туташтыруу өнүгүүгө тоскоол болуп, ансыз деле татаал бизнес логикасынын татаалдыгын жогорулатат. Бул көйгөйдү чечүү үчүн коддогу контексттердин ортосундагы чек араларды таап, алардын бузууларын алып салышыңыз керек. Мисалы, камсыздандыруу контекстинде Борбордук банктын 20 орундуу эсеп номери жана эсеп ачылган күнү жетиштүү болушу толук мүмкүн.
Бул чектелген контексттерди бири-биринен бөлүп, микросервистерди монолиттүү чечимден бөлүү процессин баштоо үчүн биз колдонмонун ичинде тышкы API түзүү сыяктуу ыкманы колдондук. Эгерде биз кандайдыр бир модулдун процесстин ичинде кандайдыр бир түрдө өзгөртүлгөн микросервиске айланышы керектигин билсек, анда биз дароо тышкы чалуулар аркылуу башка чектелген контекстке таандык логикага чалууларды жасадык. Мисалы, REST же WCF аркылуу.
Биз бөлүштүрүлгөн транзакцияларды талап кылган коддон качпайбыз деп чечтик. Биздин учурда, бул эрежени сактоо абдан жеңил болуп чыкты. Катуу бөлүштүрүлгөн транзакциялар чындап эле зарыл болгон жагдайларды учура элекпиз - модулдардын ортосундагы акыркы ырааттуулук абдан жетиштүү.
Келгиле, конкреттүү мисалды карап көрөлү. Бизде оркестр деген түшүнүк бар - "колдонмонун" объектисин иштеткен түтүк. Ал кезеги менен кардар, эсеп жана банк картасын түзөт. Эгерде кардар жана эсеп ийгиликтүү түзүлүп, бирок картаны түзүү ишке ашпай калса, тиркеме "ийгиликтүү" статусуна жылбайт жана "карта түзүлгөн эмес" статусунда калат. Келечекте, фон аракети аны алып, аягына чыгарат. Система бир нече убакыттан бери ыраатсыздык абалында болгон, бирок биз муну жалпысынан канааттандырабыз.
Эгер маалыматтардын бир бөлүгүн ырааттуу сактоо зарыл болгондо кырдаал жаралса, биз аны бир процессте иштетүү үчүн кызматты консолидациялоого барабыз.
Микросервисти бөлүштүрүүнүн мисалын карап көрөлү. Кантип аны өндүрүшкө салыштырмалуу коопсуз алып келе аласыз? Бул мисалда бизде системанын өзүнчө бөлүгү бар - эмгек акы төлөө кызматынын модулу, анын код бөлүмдөрүнүн бири биз микросервис жасагыбыз келет.
Биринчиден, биз кодду кайра жазуу менен микросервисти түзөбүз. Бизге жакпаган айрым жактарын жакшыртып жатабыз. Биз кардардын жаңы бизнес талаптарын ишке ашырабыз. Чалууларды багыттоону камсыз кыла турган UI менен бэкенддин ортосундагы байланышка API шлюзун кошобуз.
Андан кийин, биз бул конфигурацияны ишке чыгарабыз, бирок пилоттук абалда. Биздин колдонуучулардын көбү дагы эле эски бизнес процесстер менен иштешет. Жаңы колдонуучулар үчүн биз монолиттик тиркеменин жаңы версиясын иштеп жатабыз, ал мындан ары бул процессти камтыбайт. Негизи, бизде пилоттук катары иштеген монолит менен микросервистин айкалышы бар.
Ийгиликтүү пилот менен биз жаңы конфигурация чындап эле ишке жарамдуу экенин түшүнөбүз, биз теңдемеден эски монолитти алып салып, эски чечимдин ордуна жаңы конфигурацияны калтыра алабыз.
Жалпысынан алганда, биз монолиттин баштапкы кодун бөлүү үчүн дээрлик бардык ыкмаларды колдонобуз. Алардын баары бизге тиркеменин бөлүктөрүнүн көлөмүн азайтууга жана аларды жаңы китепканаларга которууга, баштапкы кодду жакшыртууга мүмкүндүк берет.
Маалыматтар базасы менен иштөө
Маалыматтар базасы баштапкы коддон да начар бөлүнүшү мүмкүн, анткени ал учурдагы схеманы гана эмес, ошондой эле топтолгон тарыхый маалыматтарды камтыйт.
Биздин маалымат базасы, башкалар сыяктуу эле, дагы бир маанилүү кемчилиги бар болчу - анын чоң көлөмү. Бул маалымат базасы монолиттин татаал бизнес логикасына ылайык иштелип чыккан жана ар кандай чектелген контексттердин таблицаларынын ортосунда топтолгон мамилелер.
Биздин учурда, бардык кыйынчылыктарды (чоң маалымат базасы, көптөгөн байланыштар, кээде таблицалардын ортосундагы так эмес чектер) чечүү үчүн көптөгөн ири долбоорлордо пайда болгон көйгөй пайда болду: жалпы маалымат базасынын шаблонун колдонуу. Берилиштер таблицалардан көрүнүш, репликация аркылуу алынды жана бул репликация керек болгон башка системаларга жөнөтүлдү. Натыйжада, биз таблицаларды өзүнчө схемага жылдыра албадык, анткени алар активдүү колдонулган.
Коддогу чектелген контексттерге бирдей бөлүнүү бизге бөлүнүүгө жардам берет. Бул, адатта, маалымат базасынын деңгээлинде маалыматтарды кантип бузушубуз жөнүндө жакшы түшүнүк берет. Биз кайсы таблицалар бир чектелген контекстке, кайсынысы башкасына таандык экенин түшүнөбүз.
Биз маалымат базасын бөлүүнүн эки глобалдуу ыкмасын колдондук: учурдагы таблицаларды бөлүү жана иштетүү менен бөлүү.
Учурдагы таблицаларды бөлүү - эгерде берилиштер структурасы жакшы болсо, бизнес талаптарына жооп берсе жана бардыгы ага ыраазы болсо, колдонуу үчүн жакшы ыкма. Бул учурда, биз бар таблицаларды өзүнчө схемага бөлүп алабыз.
Иштеп чыгуучу бөлүм бизнес модели абдан өзгөргөндө жана таблицалар бизди таптакыр канааттандырбай калганда керек.
Учурдагы таблицаларды бөлүү. Эмнени бөлөрүбүздү аныкташыбыз керек. Бул билимсиз эч нерсе иштебейт жана бул жерде коддогу чектелген контексттерди бөлүү бизге жардам берет. Эреже катары, эгер сиз баштапкы коддогу контексттердин чектерин түшүнө алсаңыз, бөлүм үчүн тизмеге кайсы таблицалар киргизилиши керектиги айкын болот.
Келгиле, бизде эки монолит модулу бир маалымат базасы менен иштешкен чечим бар деп элестетип көрөлү. Бөлүнгөн таблицалардын бөлүмү менен бир гана модуль өз ара аракеттенишине, ал эми экинчиси API аркылуу аны менен иштеше башташына ынанышыбыз керек. Баштоо үчүн, API аркылуу гана жазуу гана жетиштүү. Бул микросервистердин көз карандысыздыгы жөнүндө сөз кылуу үчүн зарыл шарт. Окуу байланыштары чоң көйгөй болбосо эле кала берет.
Кийинки кадам, биз иштетилген же иштетилбеген, бөлүнгөн таблицалар менен иштеген код бөлүмүн өзүнчө микросервиске бөлүп, аны өзүнчө процессте, контейнерде иштете алабыз. Бул монолит базасына жана ага түздөн-түз тиешеси жок таблицаларга туташуу менен өзүнчө кызмат болот. Монолит дагы ажыратылуучу бөлүгү менен окуу үчүн өз ара аракеттенет.
Кийинчерээк биз бул байланышты алып салабыз, башкача айтканда, бөлүнгөн таблицалардан монолиттүү тиркемеден окуу маалыматтары да APIге өткөрүлөт.
Андан кийин, биз жалпы маалымат базасынан жаңы микросервис гана иштеген таблицаларды тандайбыз. Биз таблицаларды өзүнчө схемага же өзүнчө физикалык маалымат базасына жылдыра алабыз. Микросервис менен монолит базасынын ортосунда окуу байланышы дагы эле бар, бирок тынчсыздана турган эч нерсе жок, бул конфигурацияда ал көпкө жашай алат.
акыркы кадам толугу менен бардык байланыштарды алып салуу болуп саналат. Бул учурда, биз негизги маалымат базасынан маалыматтарды көчүрүү керек болушу мүмкүн. Кээде биз бир нече маалымат базаларында тышкы системалардан репликацияланган кээ бир маалыматтарды же каталогдорду кайра колдонгубуз келет. Бул бизде мезгил-мезгили менен болот.
Кайра иштетүү бөлүмү. Бул ыкма биринчи бирине абдан окшош, болгону тескери тартипте. Биз дароо жаңы маалымат базасын жана API аркылуу монолит менен иштешкен жаңы микросервисти бөлүп беребиз. Бирок ошол эле учурда, биз келечекте жок кылгыбыз келген маалыматтар базасынын таблицаларынын топтому бар. Бизге анын кереги жок, биз аны жаңы моделге алмаштырдык.
Бул схема иштеши үчүн бизге өткөөл мезгил керек болот.
Анда эки мүмкүн болгон ыкма бар.
биринчи: биз жаңы жана эски маалымат базаларындагы бардык маалыматтарды кайталайбыз. Бул учурда, бизде ашыкча маалыматтар бар жана синхрондоштуруу көйгөйлөрү келип чыгышы мүмкүн. Бирок биз эки башка кардар алабыз. Бири жаңы версиясы менен, экинчиси эскиси менен иштейт.
экинчи: биз маалыматтарды кээ бир бизнес критерийлерине ылайык бөлүштүрөбүз. Мисалы, бизде эски базада сакталган системада 5 продукт бар болчу. Биз жаңы маалымат базасына жаңы бизнес тапшырманын алкагында алтынчыны жайгаштырабыз. Бирок бизге бул маалыматтарды синхрондоштуруучу жана кардарга кайдан жана эмнени алуу керектигин көрсөткөн API шлюз керек болот.
Эки ыкма тең иштейт, кырдаалга жараша тандаңыз.
Баары иштеп жатканына ынангандан кийин, эски база түзүмдөрү менен иштеген монолиттин бөлүгү өчүрүлүшү мүмкүн.
Акыркы кадам - эски маалымат структураларын алып салуу.
Жыйынтыктап айтканда, бизде маалымат базасы менен көйгөйлөр бар деп айта алабыз: баштапкы кодго салыштырмалуу аны менен иштөө кыйын, бөлүшүү кыйыныраак, бирок аны жасоого болот жана жасоо керек. Биз муну коопсуз кылууга мүмкүндүк берген айрым жолдорду таптык, бирок булак кодуна караганда маалыматтар менен ката кетирүү дагы деле оңой.
Булак коду менен иштөө
Монолиттик долбоорду талдай баштаганда баштапкы код диаграммасы ушундай болгон.
Бул болжол менен үч катмарга бөлүүгө болот. Бул ишке киргизилген модулдардын, плагиндердин, кызматтардын жана жеке иш-аракеттердин катмары. Чынында, бул монолиттүү чечимдин ичинде кирүү пункттары болгон. Алардын баары Common катмар менен тыгыз жабылган. Бул кызматтарды бөлүшкөн бизнес логикасы жана көптөгөн байланыштар бар болчу. Ар бир кызмат жана плагин алардын өлчөмүнө жана иштеп чыгуучулардын абийирине жараша 10го чейин же андан көп жалпы жыйындарды колдонот.
Биз өзүнчө пайдаланууга боло турган инфраструктуралык китепканаларга ээ болуу бактысы болду.
Кээде кээ бир жалпы объектилер чындыгында бул катмарга кирбей калган, бирок инфраструктуралык китепканалар болгон кырдаал келип чыккан. Бул атын өзгөртүү жолу менен чечилди.
Эң чоң тынчсыздануу чектелген контексттер болду. Бир Жалпы чогулушта 3-4 контекст аралашып, бир эле бизнес функцияларында бири-бирин колдонушкан. Бул кайда жана кандай чек аралар боюнча бөлүнүшү мүмкүн экенин түшүнүү керек жана бул бөлүнүүнү баштапкы коддор жыйындарына түшүрүү менен андан ары эмне кылуу керек болчу.
Биз кодду бөлүү процесси үчүн бир нече эрежелерди иштеп чыктык.
биринчи: Биз мындан ары кызматтар, иш-аракеттер жана плагиндер ортосунда бизнес логикасын бөлүшүүнү каалабайбыз. Биз микросервистердин ичинде бизнес логикасын көз карандысыз кылгыбыз келди. Микросервистер, экинчи жагынан, идеалдуу түрдө толугу менен өз алдынча бар кызматтар катары каралат. Мен бул ыкма бир аз ысырап деп эсептейм жана ага жетүү кыйын, анткени, мисалы, C# тилиндеги кызматтар кандай болгон күндө да стандарттуу китепкана менен туташтырылат. Биздин система C# тилинде жазылган, биз башка технологияларды колдоно элекпиз. Ошондуктан, биз жалпы техникалык ассамблеяларды колдоно алабыз деп чечтик. Эң негизгиси, аларда бизнес логикасынын фрагменттери жок. Эгер сизде колдонуп жаткан ORMдин үстүнөн ыңгайлуу таңгыч болсо, аны кызматтан кызматка көчүрүү абдан кымбатка турат.
Биздин команда домендик дизайндын күйөрманы, андыктан пияздын архитектурасы биз үчүн абдан ылайыктуу болду. Биздин кызматтардын негизи маалыматтарга кирүү катмары эмес, домен логикасы менен жыйын болуп саналат, ал бизнес логикасын гана камтыган жана инфраструктура менен эч кандай байланышы жок. Ошол эле учурда, алкактарга байланыштуу көйгөйлөрдү чечүү үчүн домен жыйынын өз алдынча өзгөртө алабыз.
Бул этапта биз биринчи олуттуу көйгөйгө туш болдук. Кызмат бир домен жыйынына кайрылышы керек болчу, биз логиканы көз карандысыз кылгыбыз келди жана DRY принциби бул жерде бизге абдан тоскоолдук кылды. Иштеп чыгуучулар кайталанбоо үчүн кошуна ассамблеялардын класстарын кайра колдонууну каалашкан жана натыйжада домендер кайрадан бири-бирине байланыша баштаган. Биз натыйжаларды талдап чыгып, балким, көйгөй баштапкы кодду сактоочу түзүлүштүн аймагында болушу мүмкүн деп чечтик. Бизде бардык баштапкы кодду камтыган чоң репозиторий бар болчу. Бүтүндөй долбоор үчүн чечим жергиликтүү машинада чогултуу абдан кыйын болгон. Ошондуктан, долбоордун бөлүктөрү үчүн өзүнчө кичинекей чечимдер түзүлгөн жана эч ким аларга кандайдыр бир жалпы же домен жыйынын кошууга жана аларды кайра колдонууга тыюу салган. Бизге муну кылууга жол бербеген жалгыз курал кодду карап чыгуу болду. Бирок кээде ал да ишке ашпай калган.
Андан кийин биз өзүнчө репозиторийлери бар моделге өтө баштадык. Бизнес логикасы мындан ары кызматтан кызматка өтпөйт, домендер чындап көз карандысыз болуп калышты. Чектелген контексттер айкыныраак колдоого алынат. Инфраструктуралык китепканаларды кантип кайра колдонобуз? Биз аларды өзүнчө репозиторийге бөлүп, анан Nuget пакеттерине салып, аларды Artifactoryге киргиздик. Кандайдыр бир өзгөрүү менен чогултуу жана жарыялоо автоматтык түрдө ишке ашат.
Биздин кызматтар тышкы инфраструктуралык пакеттерге окшош эле жол менен кайрыла баштады. Биз Nugetтен тышкы китепканаларды жүктөп алабыз. Бул пакеттерди жайгаштырган Artifactory менен иштөө үчүн эки пакет менеджерин колдондук. Чакан репозиторийлерде биз Nugetти да колдондук. Бир нече кызматтары бар репозиторийлерде биз пакетти колдондук, ал модулдардын ортосунда көбүрөөк версиянын ырааттуулугун камсыз кылат.
Ошентип, баштапкы коддун үстүндө иштөө, архитектураны бир аз өзгөртүү жана репозиторийлерди бөлүү менен биз кызматтарыбызды көбүрөөк көз карандысыз кылабыз.
Инфраструктура көйгөйлөрү
Микросервистерге өтүүнүн терс жактарынын көбү инфраструктурага байланыштуу. Сизге автоматташтырылган жайгаштыруу керек болот, инфраструктураны иштетүү үчүн жаңы китепканалар керек болот.
чөйрөдө кол менен орнотуу
Башында биз чөйрөлөр үчүн чечимди кол менен орноттук. Бул процессти автоматташтыруу үчүн биз CI/CD түтүгүн түздүк. Биз үзгүлтүксүз жеткирүү процессин тандап алдык, анткени үзгүлтүксүз жайылтуу бизнес-процесстердин көз карашы боюнча биз үчүн азырынча алгылыктуу эмес. Ошондуктан, операцияга жөнөтүү баскычтын жардамы менен ишке ашырылат, ал эми сыноо үчүн - автоматтык түрдө.
Булак кодун сактоо үчүн Atlassian, Bitbucket жана куруу үчүн бамбук колдонобуз. Биз Cakeде куруу сценарийлерин жазганды жакшы көрөбүз, анткени ал C# менен бирдей. Даяр пакеттер Artifactory'ге келет, ал эми Ansible автоматтык түрдө тесттик серверлерге жетет, андан кийин алар дароо сыналышы мүмкүн.
Өзүнчө жазуу
Бир убакта монолиттин идеяларынын бири жалпы жыгач кыюуну камсыз кылуу болгон. Биз ошондой эле дисктердеги жеке журналдар менен эмне кылуу керектигин түшүнүшүбүз керек болчу. Биздин журналдар текст файлдарына жазылат. Биз стандарттуу ELK стек колдонууну чечтик. Биз ELKге провайдерлер аркылуу түздөн-түз кат жазган жокпуз, бирок биз текст журналдарын жыйынтыктап, аларга издөө идентификаторун идентификатор катары жазып, бул журналдарды кийинчерээк талдоо үчүн кызматтын атын кошуп жазууну чечтик.
Filebeat колдонуп, биз серверлерден журналдарыбызды чогултуп, андан кийин аларды өзгөртүп, UIде сурамдарды түзүү үчүн Kibana колдонуп, кызматтардын ортосунда чалуу кандай өткөнүн көрүүгө мүмкүнчүлүк алабыз. Trace ID бул менен көп жардам берет.
Тиешелүү кызматтарды текшерүү жана оңдоо
Башында биз иштеп жаткан кызматтарды кантип оңдоону толук түшүнгөн жокпуз. Монолит менен баары жөнөкөй эле, биз аны жергиликтүү машинада иштеттик. Адегенде алар микросервистер менен да ушундай кылууга аракет кылышкан, бирок кээде бир микросервисти толук ишке киргизүү үчүн дагы бир нечесин ишке киргизүү керек, бул ыңгайсыз. Биз жергиликтүү машинада оңдоону каалаган кызматты же кызматтарды гана калтырган моделге өтүшүбүз керек экенин түшүндүк. Калган кызматтар прод менен конфигурацияга дал келген серверлерден колдонулат. Мүчүлүштүктөрдү оңдоодон кийин, тестирлөө учурунда ар бир тапшырма үчүн тест серверине өзгөртүлгөн кызматтар гана берилет. Ошентип, чечим келечекте өндүрүштө пайда боло турган формада сыналат.
Кызматтардын өндүрүштүк версияларын гана иштеткен серверлер бар. Бул серверлер инциденттерде, жайылтуудан мурун жеткирүүнү текшерүү жана ички тренинг үчүн керек.
Биз популярдуу Specflow китепканасын колдонуу менен автоматташтырылган тестирлөө процессин коштук. Сыноолор Ansibleден орнотулгандан кийин дароо NUnit аркылуу автоматтык түрдө иштетилет. Эгер тапшырманы камтуу толугу менен автоматтык болсо, анда кол менен тестирлөөнүн кереги жок. Кээде кошумча кол сыноо дагы деле талап кылынат да. Белгилүү бир маселе боюнча кайсы тесттерди жүргүзүүнү аныктоо үчүн биз Jira'да тегдерди колдонобуз.
Мындан тышкары, жүк тестирлөө муктаждыгы көбөйдү, мурда ал сейрек учурларда гана жүргүзүлчү. Биз тесттерди жүргүзүү үчүн JMeterди, аларды сактоо үчүн InfluxDBди жана процесс графиктерин куруу үчүн Grafana колдонобуз.
Биз эмнеге жетиштик?
Биринчиден, биз "боштондукка чыгаруу" деген түшүнүктөн арылдык. Бул колосс өндүрүш чөйрөсүндө орнотулуп, бизнес процесстерин убактылуу үзгүлтүккө учураткан эки айлык коркунучтуу релиздер жок болду. Азыр биз кызматтарды орто эсеп менен ар бир 1,5 күндө жайгаштырабыз, аларды топтоштурабыз, анткени алар бекитилгенден кийин ишке кирет.
Биздин системада өлүмгө дуушар болгон каталар жок. Эгерде биз микросервисти мүчүлүштүк менен чыгарсак, анда аны менен байланышкан функциялар бузулуп, калган бардык функцияларга таасир этпейт. Бул абдан колдонуучу тажрыйбасын жакшыртат.
Биз жайылтуу үлгүсүн көзөмөлдөй алабыз. Зарыл болсо, башка чечимден өзүнчө кызматтардын топторун тандай аласыз.
Мындан тышкары, биз жакшыртуунун чоң кезеги менен көйгөйдү кыйла азайттык. Азыр бизде айрым кызматтар менен өз алдынча иштеген өзүнчө продукт топтору бар. Scrum процесси бул жерде мурунтан эле туура келет. Белгилүү бир командада ага тапшырмаларды берген өзүнчө Продукт Ээси болушу мүмкүн.
на
- Микросервис татаал системаларды декомпозициялоо үчүн абдан ылайыктуу. Процесстин жүрүшүндө биз системабызда эмне бар, кандай чектелген контексттер бар, алардын чек аралары кайда экенин түшүнө баштайбыз. Бул модулдар арасында жакшыртууларды туура бөлүштүрүүгө жана коддун башаламандыгын алдын алууга мүмкүндүк берет.
- Микросервис уюштуруучулук пайдаларды камсыз кылат. Алар көбүнчө архитектура катары гана айтылып келет, бирок ар кандай архитектура өз алдынча эмес, бизнес муктаждыктарын чечүү үчүн керек. Ошондуктан, Scrum азыр абдан популярдуу экендигин эске алсак, микросервистер чакан командалардагы маселелерди чечүү үчүн абдан ылайыктуу деп айта алабыз.
- Бөлүнүү кайталануучу процесс. Сиз арызды алып, аны микросервистерге бөлө албайсыз. Натыйжадагы продуктунун иштеши күмөн. Микросервистерди арнаганда, учурдагы мурасты кайра жазуу пайдалуу, башкача айтканда, аны бизге жаккан жана функционалдык жана ылдамдык жагынан бизнес муктаждыктарына жакшыраак жооп берген кодго айландыруу пайдалуу.
Кичинекей эскертүү: Микросервистерге өтүүнүн чыгымдары кыйла олуттуу. Жалгыз инфраструктура маселесин чечүүгө көп убакыт кетти. Демек, эгер сизде конкреттүү масштабды талап кылбаган кичинекей тиркемеңиз болсо, анда сиздин командаңыздын көңүлүн жана убактысы үчүн атаандашкан кардарлардын саны көп болбосо, анда микросервистер бүгүнкү күндө сизге керектүү нерсе болбошу мүмкүн. Бул абдан кымбат. Эгерде сиз процессти микросервистерден баштасаңыз, анда сиз монолитти иштеп чыгуу менен бир эле долбоорду баштаганыңызга караганда, чыгымдар башында жогору болот.
P.S. Көбүрөөк эмоционалдуу окуя (жана жеке сиз үчүн) - ылайык .
Бул жерде отчеттун толук версиясы.
Source: www.habr.com