Хабр дүйнөнү өзгөртүп жатат. Биз бир жылдан ашык убакыттан бери блог жүргүзүп келебиз. Жарым жыл мурун биз Хабаровск шаарынын тургундарынан абдан логикалык пикир алдык: “Додо, сен бардык жерде өз системасы бар деп айтасың. Бул кандай система? Ал эми пиццерия тармагына анын эмне кереги бар?»
Ойлонуп отуруп сиздин туура экениңизди түшүндүк. Биз бардыгын манжаларыбыз менен түшүндүрүүгө аракет кылып жатабыз, бирок ал жыртылып чыгып, системанын толук сүрөттөлүшү эч жерде жок. Ошентип, Додо ИМ жөнүндө маалымат чогултуу, авторлорду издөө жана бир катар макалаларды жазуу боюнча узак сапар башталды. Кеттик!
Ыраазычылык: Пикириңизди биз менен бөлүшкөнүңүз үчүн рахмат. Анын аркасында биз акыры системаны сүрөттөп бердик, технорадарды түздүк жана жакында процесстерибиздин чоң сүрөттөлүшүн чыгарабыз. Сен болбосон дагы 5 жыл ушинтип отурмакпыз.
Макалалар сериясы "Додо IS деген эмне?" жөнүндө айтып берет:
- Додо ИСте алгачкы монолит (2011-2015). (Прогрессте...)
- Backoffice жолу: өзүнчө базалар жана автобус. (Сен бул жерде)
- Кардар бөлүгүнүн жолу: базанын үстүндөгү фасад (2016-2017). (Прогрессте...)
- Чыныгы микросервистердин тарыхы. (2018-2019). (Прогрессте...)
- Монолитти кесүү жана архитектураны турукташтыруу аяктады. (Прогрессте...)
Эгер сиз дагы бир нерсе үйрөнгүңүз келсе, комментарийге жазыңыз.
Автордун хронологиялык сүрөттөө боюнча пикири
Мен дайыма жаңы кызматкерлер үчүн "Системалык архитектура" деген темада жолугушуу өткөрөм. Биз аны "Dodo IS архитектурасына киришүү" деп атайбыз жана ал жаңы иштеп чыгуучулар үчүн борттук процесстин бир бөлүгү. Биздин архитектура, анын өзгөчөлүктөрү жөнүндө тигил же бул формада айтып жатып, мен сүрөттөөгө белгилүү бир тарыхый мамилени иштеп чыктым.
Салттуу түрдө биз системаны кандайдыр бир максатка жетүү үчүн бири-бири менен өз ара аракеттенүүчү компоненттердин (техникалык же жогорку деңгээлдеги), бизнес модулдарынын жыйындысы катары карайбыз. Ал эми мындай көз караш дизайн үчүн негиздүү болуп саналат, ал эми сүрөттөп жана түшүнүү үчүн толугу менен ылайыктуу эмес. Бир нече себептери бар:
- Чындык кагаздагыдан башкача. Баары пландалгандай боло бербейт. Ал эми биз баары чындыгында кандай болуп, кандай иштеп жатканына кызыкдарбыз.
- Маалыматты ырааттуу берүү. Чындыгында, сиз башынан азыркы абалга чейин хронологиялык түрдө өтсөңүз болот.
- Жөнөкөйдөн татаалга. универсалдуу эмес, бирок бизде ушундай. Архитектура жөнөкөй ыкмалардан татаалыраак ыкмаларга өттү. Көбүнчө, татаалдашып, ишке ашыруу ылдамдыгы жана туруктуулугу көйгөйлөрү, ошондой эле функционалдык эмес талаптардын тизмесинен ондогон башка касиеттер ( татаалдыгын башка талаптарга карама-каршы коюу жөнүндө жакшы айтылган).
2011-жылы, Dodo IS архитектурасы төмөнкүдөй болгон:
2020-жылга чейин, ал бир аз татаалдашып, мындай болуп калды:
Бул эволюция кантип болгон? Системанын ар кандай бөлүктөрү эмне үчүн керек? Кандай архитектуралык чечимдер кабыл алынган жана эмне үчүн? Бул макалалардын сериясынан билели.
2016-жылдын биринчи көйгөйлөрү: эмне үчүн кызматтар монолиттен чыгышы керек?
Сериядагы биринчи макалалар монолиттен биринчи болуп бөлүнгөн кызматтар тууралуу болмокчу. Сизди контекстке киргизүү үчүн, мен 2016-жылдын башында системада кандай көйгөйлөр бар экенин айтып берем, биз кызматтарды бөлүү менен күрөшүүгө туура келди.
Dodo ISде ошол кездеги бардык тиркемелер өз жазууларын жазган бирдиктүү MySql маалымат базасы. кесепеттери болгон:
- Оор жүк (суроолордун 85% окулуп жатат).
- База өсүп жатты. Ушундан улам, чыгымдар жана колдоо көйгөй болуп калды.
- Бир эле ийгиликсиздик. Эгер маалымат базасына жазып жаткан бир тиркеме күтүлбөгөн жерден жигердүү иштей баштаса, анда башка тиркемелер таасир эткен.
- Сактоо жана сурамдардын натыйжасыздыгы. Көбүнчө маалыматтар кээ бир сценарийлер үчүн ыңгайлуу болгон, бирок башкалар үчүн эмес, кандайдыр бир структурада сакталган. Индекстер кээ бир операцияларды тездетет, бирок башкаларды жайлатышы мүмкүн.
- Кээ бир көйгөйлөр шашылыш жасалган кэштер жана маалымат базаларына окуу-репликалар аркылуу чечилди (бул өзүнчө макалада талкууланат), бирок алар бизге убакытты утууга гана мүмкүндүк берди жана маселени түп тамырынан бери чече алган жок.
Көйгөй монолиттин өзүндө болгон. кесепеттери болгон:
- Уникалдуу жана сейрек релиздер.
- Кыйынчылык - көп сандагы адамдардын биргелешкен өнүгүүсүндө.
- Жаңы технологияларды, жаңы фреймворктарды жана китепканаларды киргизүүгө жөндөмсүздүк.
База жана монолит менен байланышкан көйгөйлөр көп жолу сүрөттөлгөн, мисалы, 2018-жылдын башындагы кыйроолордун контекстинде (, и ), ошондуктан мен көп отурбайм. Жөн эле айта кетейин, биз кызматтарды иштеп чыгууда көбүрөөк ийкемдүүлүк бергибиз келген. Биринчиден, бул бүтүндөй тутумда эң көп жүктөлгөн жана тамыр болгондорго тиешелүү - Auth and Tracker.
Backoffice жолу: өзүнчө базалар жана автобус
Бөлүм Навигация
Монолиттин схемасы 2016
Бул жерде 2016-жылдын Dodo IS монолитинин негизги блоктору, ал эми төмөндө алардын негизги милдеттеринин бөлүштүрүлүшү болуп саналат.
Жеткирүү кассасы. Чабармандардын эсебин алуу, чабармандарга приказ берүү.
Байланыш борбору. Оператор аркылуу заказдарды кабыл алуу.
сайт. Биздин веб-сайттар (dodopizza.ru, dodopizza.co.uk, dodopizza.by, ж.б.).
Мектептер. Бэк-офис үчүн авторизация жана аутентификация кызматы.
Атаны. Ашканага буйрутма трекер. Буйрутманы даярдоодо даярдык статустарын белгилөө кызматы.
Ресторандын кассасы. Ресторанда заказдарды кабыл алуу, кассир интерфейстери.
экспорттоо. Бухгалтердик эсепке алуу үчүн 1Сге отчетторду жүктөө.
Эскертүүлөр жана эсеп-фактуралар. Ашканадагы үн буйруктары (мисалы, “Жаңы пицца келди”) + чабармандар үчүн эсеп-фактураларды басып чыгаруу.
Shift Manager. Сменалык жетекчинин иштөөсү үчүн интерфейстер: буйруктардын тизмеси, өндүрүмдүүлүк диаграммалары, кызматкерлерди сменага алып келүү.
Office Manager. Франчайзилердин жана менеджерлердин иши үчүн интерфейстер: кызматкерлерди кабыл алуу, пиццериянын иши жөнүндө отчеттор.
Ресторан тактасы. Пиццериялардагы сыналгыларда менюларды көрсөтүү.
Админ. Белгилүү бир пиццерия үчүн орнотуулар: меню, баалар, эсепке алуу, жарнамалык коддор, акциялар, сайт үчүн баннерлер ж.б.
Кызматкердин жеке эсеби. Кызматкерлердин иш тартиби, кызматкерлер жөнүндө маалымат.
Kitchen Motivation Board. Ашканада илинип турган жана пицца жасоочулардын ылдамдыгын көрсөткөн өзүнчө экран.
байланыш. SMS жана электрондук почта жөнөтүү.
FileStorage. Статикалык файлдарды кабыл алуу жана берүү боюнча өздүк сервис.
Маселелерди чечүүнүн алгачкы аракеттери бизге жардам берди, бирок алар убактылуу тыныгуу гана болду. Алар системалык чечимдерге айланган жок, ошондуктан базалар менен бир нерсе кылуу керек экени айкын болду. Мисалы, жалпы маалымат базасын дагы бир нече адистештирилгенге бөлүңүз.
Биз монолитти түшүрө баштайбыз: Auth жана Tracker бөлүү
Андан кийин башкаларга караганда маалымат базасынан жазган жана окуган негизги кызматтар:
- Auth. Бэк-офис үчүн авторизация жана аутентификация кызматы.
- Tracker. Ашканага буйрутма трекер. Буйрутманы даярдоодо даярдык статустарын белгилөө кызматы.
Auth эмне кылат?
Auth – бул колдонуучулар бэк-офиске кирүүчү кызмат (кардар тарапта өзүнчө көз карандысыз логин бар). Ошондой эле туура кирүү укуктары бар экендигин жана бул укуктар акыркы логинден бери өзгөрбөгөндүгүн текшерүү үчүн өтүнүчтө шилтеме кылынат. Аппараттар ал аркылуу пиццерияга кирет.
Мисалы, залда илинип турган сыналгыга аткарылган заказдардын статусу жазылган дисплейди ачкыбыз келет. Андан кийин биз auth.dodopizza.ru сайтын ачып, "Аппарат катары кирүү" дегенди тандаңыз, нөөмөт менеджеринин компьютериндеги атайын баракка киргизиле турган код пайда болуп, аппараттын (түзмөктүн) түрүн көрсөтөт. Телевизордун өзү пиццериясынын каалаган интерфейсине өтүп, ал жерде заказдары даяр кардарлардын ысымдарын көрсөтө баштайт.
Жүктөр кайдан келет?
Ар бир кирген бэк-офис колдонуучусу ар бир суроо боюнча маалымат базасына, колдонуучу таблицасына барат, ал жерден SQL сурамы аркылуу колдонуучуну чыгарат жана анын бул баракка керектүү кирүү мүмкүнчүлүгү жана укуктары бар же жок экенин текшерет.
Түзмөктөрдүн ар бири анын ролун жана кирүү мүмкүнчүлүктөрүн текшерип, түзмөк таблицасы менен гана ушундай кылат. Негизги маалымат базасына көп сандагы суроо-талаптар анын жүктөлүшүнө жана бул операцияларга жалпы маалымат базасынын ресурстарынын ысырап болушуна алып келет.
Жүктөө Auth
Auth обочолонгон доменге ээ, башкача айтканда, колдонуучулар, логиндер же түзмөктөр жөнүндө маалыматтар кызматка кирет (учурда келечекте) жана ошол жерде калат. Кимдир бирөө аларга керек болсо, ал маалымат үчүн бул кызматка барат.
БОЛГОН. Иш агымы башында мындай болгон:
Мен анын кантип иштегенин бир аз түшүндүргүм келет:
- Сырткы суроо-талап бэкендге келет (Аsp.Net MVC ошол жерде), аны менен бирге Redis(1) сеанс маалыматтарын алуу үчүн колдонулган сеанс кукисин алып келет. Ал же кирүүлөр жөнүндө маалыматты камтыйт, андан кийин контроллерге кирүү ачык (3,4) же жок.
- Мүмкүнчүлүк жок болсо, авторизация процедурасынан өтүшүңүз керек. Бул жерде, жөнөкөйлүк үчүн, ал ошол эле атрибутта жолдун бөлүгү катары көрсөтүлгөн, бирок бул кирүү барагына өтүү. Оң сценарий болгон учурда, биз туура толтурулган сеансты алып, Backoffice Controllerге барабыз.
- Эгерде маалыматтар бар болсо, анда сиз аны колдонуучунун маалымат базасында актуалдуулугун текшеришиңиз керек. Анын ролу өзгөрдүбү, аны азыр баракчага киргизбеш керекпи? Бул учурда, сессияны (1) алгандан кийин, сиз түз маалымат базасына кирип, аныктыгын текшерүү логикалык катмарын (2) колдонуу менен колдонуучунун мүмкүнчүлүгүн текшерүү керек. Андан кийин, кирүү барагына өтүңүз же контроллерге өтүңүз. Бул жөнөкөй система, бирок толугу менен стандарттуу эмес.
- Эгерде бардык процедуралар аткарылса, анда биз контроллерлордо жана методдордо логикага өтүп кетебиз.
Колдонуучунун маалыматтары башка бардык маалыматтардан бөлүнгөн, алар өзүнчө мүчөлүк таблицада сакталат, AuthService логикалык катмарынын функциялары API методдору болуп калышы мүмкүн. Домендин чек аралары так аныкталган: колдонуучулар, алардын ролдору, кирүү маалыматтары, кирүү мүмкүнчүлүгүн берүү жана жокко чыгаруу. Баарын өзүнчө кызматка көчүрсө болот окшойт.
БОЛДУ. Алар эмне кылышты:
Бул ыкманын бир катар көйгөйлөрү бар. Мисалы, процесстин ичиндеги ыкманы чакыруу http аркылуу тышкы кызматты чакыруу менен бирдей эмес. Операциянын кечигүү, ишенимдүүлүк, колдоо жана ачык-айкындуулугу такыр башкача. Андрей Моревский езунун докладында дал мына ушул проблемаларга кененирээк токтолду .
Аутентификация кызматы жана аны менен бирге түзмөк кызматы бэк-офис үчүн, башкача айтканда, өндүрүштө колдонулган кызматтар жана интерфейстер үчүн колдонулат. Кардар кызматтарынын аутентификациясы (мисалы, веб-сайт же мобилдик тиркеме) Auth колдонулбастан өзүнчө ишке ашат. Бөлүнүү бир жылга жакын убакытты алды, эми биз кайрадан бул теманын үстүндө иштеп жатабыз, системаны жаңы аутентификация кызматтарына өткөрүп жатабыз (стандарттык протоколдор менен).
Эмне үчүн ажырашуу мынчалык узакка созулду?
Жолдо бизди жайлаткан көптөгөн көйгөйлөр бар эле:
- Биз өлкөнүн маалымат базаларынан колдонуучулар, түзмөктөр жана аутентификация жөнүндө маалыматтарды бирге өткөргүбүз келди. Бул үчүн, биз бардык таблицаларды жана колдонууну int идентификаторунан глобалдык UUId идентификаторуна өткөрүп беришибиз керек болчу (биз жакында бул кодду кайра иштеп чыктык. жана ачык булак долбоору ). Колдонуучунун маалыматтарын сактоонун (бул жеке маалымат болгондуктан) өзүнүн чектөөлөрү бар жана кээ бир өлкөлөр үчүн аны өзүнчө сактоо зарыл. Бирок глобалдык колдонуучу ID болушу керек.
- Берилиштер базасындагы көптөгөн таблицаларда операцияны аткарган колдонуучу тууралуу аудит маалыматы бар. Бул ырааттуулукту камсыз кылуу үчүн кошумча механизмди талап кылды.
- API кызматтары түзүлгөндөн кийин башка системага өтүүнүн узак жана акырындык мезгили болгон. Которгучтар колдонуучулар үчүн үзгүлтүксүз болушу керек жана кол менен иштөөнү талап кылган.
Пиццерияда аппаратты каттоо схемасы:
Auth жана Devices кызматын бөлгөндөн кийин жалпы архитектура:
пикир. 2020-жылга биз OAuth 2.0 авторизация стандартына негизделген Authтин жаңы версиясынын үстүндө иштеп жатабыз. Бул стандарт абдан татаал, бирок аныктыгын текшерүү кызматын иштеп чыгуу үчүн пайдалуу. макаласында"» Биз Алексей Черняев стандарт жөнүндө мүмкүн болушунча жөнөкөй жана так айтууга аракет кылдык, ошондо сиз аны изилдөөгө убакытты үнөмдөйсүз.
Tracker эмне кылат?
Эми жүктөлгөн кызматтардын экинчиси жөнүндө. Трекер эки ролду аткарат:
- Бир жагынан анын милдети ашканада иштегендерге азыр кандай заказдар аткарылып жаткандыгын, азыр кандай продукцияларды даярдоо керек экендигин керсетуу.
- Экинчи жагынан, ашканадагы бардык процесстерди санариптештириңиз.
Жаңы продукт (мисалы, пицца) иретинде пайда болгондо, ал "Rolling" трекер станциясына барат. Бул станцияда пицца жасоочу бар, ал керектүү өлчөмдөгү булочканы алып, аны жайып салат, андан кийин ал өзүнүн тапшырмасын аткарганын тракердик планшетте белгилейт жана жайылган камырдын негизин кийинки станцияга өткөрүп берет - "Толуктоо" .
Ал жерде кезектеги пицца жасоочу пиццанын үстүнө чыгат, андан кийин өзүнүн тапшырмасын аткарганын планшетте белгилейт жана пиццаны мешке салат (бул да өзүнчө станция, аны планшетте белгилеш керек). Мындай система Дододо эң башынан жана Додо ИСтин эң башынан эле бар болчу. Бул бардык операцияларды толук көзөмөлдөөгө жана санариптештирүүгө мүмкүндүк берет. Мындан тышкары, трекер белгилүү бир продуктуну кантип даярдоону сунуштайт, продукциянын ар бир түрүн өзүнүн өндүрүш схемаларына ылайык ишке ашырат, продукт үчүн оптималдуу бышыруу убактысын сактайт жана буюмдагы бардык операцияларга көз салат.
Раскатка трекер станциясында планшеттин экраны ушундай көрүнөт.
Жүктөр кайдан келет?
Ар бир пиццерияда трекери бар бешке жакын таблетка бар. 2016-жылы бизде 100дөн ашык пиццерия болгон (азыр 600дөн ашык). Планшеттердин ар бири ар бир 10 секунд сайын бэкендге суроо-талапты жасайт жана заказ таблицесинен (кардар жана дарек менен шилтеме), заказдын курамынан (продукцияга шилтеме жана санын көрсөтүү) жана мотивация таблицесинен (ал көз салат) маалыматтарды чогултат. басуу убактысы). Пицца жасоочу трекердеги өнүмгө чыкылдатканда, бул таблицалардагы жазуулар жаңыланат. Буйрутма таблицасы жалпы болуп саналат, ал бир эле учурда заказды кабыл алууда киргизүүлөрдү, системанын башка бөлүктөрүнөн жаңыртууларды жана көптөгөн окууларды камтыйт, мисалы, пиццерияда илинип турган сыналгыда жана кардарларга даяр заказдарды көрсөтөт.
Жүктөөлөр менен күрөшүү мезгилинде, бардыгы жана бардыгы кэштелип, маалымат базасынын асинхрондук репликасына которулганда, трекер менен бул операциялар башкы маалымат базасына бара берген. Бул жерде эч кандай артта калуу болбошу керек, маалыматтар актуалдуу болушу керек, синхрондоштурууга болбойт.
Ошондой эле, өзүбүздүн таблицалардын жана алар боюнча индекстердин жоктугу биздин колдонууга ылайыкташтырылган конкреттүү суроо-талаптарды жазууга мүмкүндүк берген жок. Мисалы, трекердин заказдар столунда пиццериянын индекси болушу натыйжалуу болушу мүмкүн. Биз ар дайым пиццерия заказдарын трекердин базасынан кырып алабыз. Ошол эле учурда буйрутманы кабыл алуу үчүн анын кайсы пиццерияга киргени маанилүү эмес, эң негизгиси бул заказды кайсы кардар жасаганы маанилүү. Бул кардар боюнча индекс болушу керек дегенди билдирет. Ошондой эле трекерге басылган квитанциянын идентификаторун же буйрутма менен байланышкан бонустук акцияларды буйрутма таблицасында сактоо зарыл эмес. Биздин трекер кызматы бул маалыматка кызыкдар эмес. Жалпы монолиттүү маалымат базасында таблицалар бардык колдонуучулардын ортосундагы компромисс гана болушу мүмкүн. Бул баштапкы көйгөйлөрдүн бири болгон.
БОЛГОН. Башында архитектура мындай болгон:
Өзүнчө процесстерге бөлүнгөндөн кийин да, код базасынын көбү ар кандай кызматтар үчүн жалпы бойдон кала берди. Контролёрлордун астындагы бардыгы бириккен жана бир репозиторийде жашашкан. Кызматтардын жалпы ыкмалары, репозиторийлер жана жалпы таблицаларды камтыган жалпы маалымат базасы колдонулган.
Tracker түшүрүлүүдө
Трекердин негизги көйгөйү - бул маалыматтар ар кандай маалымат базаларынын ортосунда шайкештештирилиши керек. Бул ошондой эле анын Auth кызматынын бөлүнүшүнөн негизги айырмасы; тартип жана анын статусу өзгөрүшү мүмкүн жана ар кандай кызматтарда көрсөтүлүшү керек.
Биз заказдарды Restaurant Checkout'та кабыл алабыз (бул кызмат), ал маалымат базасында "Кабыл алынган" статусунда сакталат. Андан кийин, ал трекерге барышы керек, анда ал статусун дагы бир нече жолу өзгөртөт: "Ашканадан" "Топтолгонго". Бул учурда, кассир же Shift менеджери интерфейсинин кээ бир тышкы таасирлери буйрук менен болушу мүмкүн. Мен таблицада алардын сүрөттөлүшү менен буйрук статустарын берем:
Буйрутма статусун өзгөртүү схемасы төмөнкүдөй көрүнөт:
Статустар ар кандай системалардын ортосунда өзгөрөт. Жана бул жерде трекер маалыматтар кулпуланган акыркы система эмес. Биз мындай учурда бөлүү үчүн бир нече мүмкүн болгон ыкмаларды көрдүк:
- Биз бардык буйрук аракеттерин бир кызматка топтойбуз. Биздин учурда, бул параметр заказды иштетүү үчүн өтө көп кызматты талап кылат. Эгерде биз ошол жерде токтоп калсак, экинчи монолит менен аяктамакпыз. Биз көйгөйлөрдү чечмек эмеспиз.
- Бир система экинчисине чалуу жасайт. Экинчи вариант кызыктуураак. Бирок аны менен чалуу чынжырлары мүмкүн (), компоненттердин байланышы жогору, аны башкаруу кыйыныраак.
- Биз иш-чараларды уюштурабыз жана ар бир кызмат ушул иш-чаралар аркылуу бири-бири менен алмашып турат. Натыйжада, үчүнчү вариант тандалды, ага ылайык бардык кызматтар бири-бири менен окуяларды алмаштыра башташат.
Үчүнчү вариантты тандап алганыбыз трекердин өзүнүн маалымат базасына ээ болорун жана тартиптин ар бир өзгөрүүсү үчүн ал бул тууралуу окуяны жөнөтө турганын, башка кызматтар жазыла турганын жана алар да башкы маалымат базасына кирерин билдирген. Бул үчүн бизге кызматтардын ортосунда билдирүүлөрдү жеткирүүнү камсыз кыла турган кандайдыр бир кызмат керек болчу.
Ошол убакта бизде RabbitMQ стекте болгон, ошондуктан аны билдирүү брокери катары колдонуу боюнча акыркы чечим кабыл алынган. Диаграмма заказдын ресторандын кассиринен Tracker аркылуу өтүшүн көрсөтөт, ал жерде анын статусу жана Менеджердин Заказдары интерфейсинде дисплей өзгөрөт. БОЛДУ:
Этап-этабы менен жолду буйрутма
Буйрутма жолу заказ булагы кызматтарынын биринен башталат. Бул жерде ресторандын кассири:
- Заказ текшерүүдө толугу менен даяр жана аны трекерге жөнөтүүгө убакыт келди. Трекер жазылган окуя ыргытылат.
- Трекер буйрутманы кабыл алып, аны өзүнүн маалымат базасына сактап, “Заказ кабыл алынган Tracker” окуясын жасап, RMQга жөнөтөт.
- Бир нече иштетүүчүлөр ыңгайлаштырылган окуя автобусуна мурунтан эле жазылган. Биз үчүн монолиттүү маалымат базасы менен синхрондоштуруу маанилүү.
- Иштеп чыгуучу окуяны кабыл алат, андан ал үчүн маанилүү болгон маалыматтарды тандап алат: биздин учурда, бул "Трекер тарабынан кабыл алынган" буйрутма статусу жана негизги маалымат базасында анын заказдык объектисин жаңыртат.
Эгер кимдир бирөө өзгөчө монолиттик заказдар таблицасында буйрутма керек болсо, анда алар аны ошол жерден окуй алышат. Мисалы, Shift башкаргычындагы Заказдар интерфейсине эмне керек:
Бардык башка кызматтар, ошондой эле аларды өздөрү үчүн колдонуу үчүн трекерден буйрутма окуяларга жазыла алышат.
Эгерде бир нече убакыт өткөндөн кийин заказ өндүрүшкө киргизилсе, анын статусу адегенде анын маалымат базасында өзгөрөт (Tracker базасы), андан кийин "OrderInWork" окуясы дароо түзүлөт. Ал ошондой эле RMQге кирет, ал жерден монолиттүү маалымат базасында синхрондолуп, башка кызматтарга жеткирилет. Бул жолдо ар кандай көйгөйлөр болушу мүмкүн, алар тууралуу кененирээк маалымат Женя Пешковдун баяндамасынан тапса болот .
Auth жана Tracker өзгөртүүлөрдөн кийин акыркы архитектура
Жыйынтыктап айтканда: Башында менде Dodo IS системасынын тогуз жылдык тарыхын бир макалага топтоо идеясы бар болчу. Мен эволюциянын этаптары жөнүндө тез жана жөнөкөй айткым келди. Бирок, материалды изилдөө үчүн отуруп, мен баары көрүнгөндөн алда канча татаал жана кызыктуу экенин түшүндүм.
Мындай материалдын пайдасы (же анын жоктугу) жөнүндө ой жүгүртүп, мен окуялардын толук кандуу хроникасы, деталдуу ретроспективалары жана мурунку чечимдерин талдоосуз үзгүлтүксүз өнүгүү мүмкүн эмес деген жыйынтыкка келдим.
Биздин саякатыбыз тууралуу билүү сизге пайдалуу жана кызыктуу болду деп ишенем. Эми мен Dodo IS системасынын кайсы бөлүгүн кийинки макалада сүрөттөшүмдү тандоо алдында турам: комментарийге жазыңыз же добуш бериңиз.
Сурамжылоого катталган колдонуучулар гана катыша алышат. , өтүнөмүн.
Кийинки макалада Dodo ISтин кайсы бөлүгү жөнүндө билгиңиз келет?
-
24,1%Додо ИСдеги алгачкы монолит (2011-2015)14
-
24,1%Биринчи көйгөйлөр жана аларды чечүү жолдору (2015-2016)14
-
20,7%Кардар бөлүгүнүн жолу: базанын үстүндөгү фасад (2016-2017)12
-
36,2%Чыныгы микросервистердин тарыхы (2018-2019)21
-
44,8%Монолитти кесүү жана архитектураны турукташтыруу аяктады26
-
29,3%Системаны өнүктүрүүнүн мындан аркы пландары жөнүндө17
-
19,0%Мен Dodo IS11 жөнүндө эч нерсе билгим келбейт
58 колдонуучу добуш берди. 6 колдонуучу добуш берүүдөн баш тартты.
Source: www.habr.com