Историја Додо ИС арһитектуре: Пут у позадину

Хабр мења свет. Блогирамо више од годину дана. Пре отприлике шест месеци добили смо сасвим логичну повратну информацију од становника Хабровска: „Додо, свуда говориш да имаш свој систем. Какав је ово систем? А зашто је то потребно ланцу пицерија?”

Седели смо и размишљали и схватили да сте у праву. Покушавамо све да објаснимо прстима, али то излази на комаде и нигде нема пуног описа система. Тако је започео дуг пут прикупљања информација, тражења аутора и писања серије чланака о Додо ИС. Идемо!

Признања: Хвала вам што сте поделили своје повратне информације са нама. Захваљујући њему, коначно смо описали систем, саставили технорадар и ускоро ћемо избацити велики опис наших процеса. Без вас бисмо седели овако још 5 година.

Серија чланака „Шта је Додо ИС?“ говори о:

1. Рани монолит у Додо ИС (2011-2015). (У току...)
2. Бацкоффице путања: одвојене базе и аутобус. (Овде си)
3. Путања на страни клијента: фасада преко базе (2016-2017). (У току...)
4. Историја правиһ микросервиса. (2018-2019). (У току...)
5. Завршено тестерисање монолита и стабилизација арһитектуре. (У току...)

Ако сте заинтересовани да научите још нешто, пишите у коментарима.

Мишљење о хронолошком опису од аутора
Редовно одржавам састанке за новозапослене на тему „Архитектура система“. Ми то зовемо „Увод у Додо ИС архитектуру“ и део је процеса уградње нових програмера. Говорећи у овом или оном облику о нашој архитектури, о њеним карактеристикама, развио сам одређени историјски приступ опису.

Традиционално, на систем гледамо као на скуп компоненти (техничких или вишег нивоа), пословних модула који међусобно комуницирају да би постигли неки циљ. И док је такав поглед оправдан за дизајн, није сасвим погодан за опис и разумевање. Постоји неколико разлога:

• Стварност је другачија од онога што је на папиру. Не иде све како је планирано. А нас занима како је све заправо испало и функционише.
• Доследно представљање информација. У ствари, можете ићи хронолошки од почетка до тренутног стања.
• Од једноставног до сложеног. Није универзално, али у нашем случају јесте тако. Архитектура је прешла са једноставнијих приступа на сложеније. Често се, кроз компликације, јављају проблеми брзине и стабилности имплементације, као и десетине других својстава са листе нефункционалних захтева (овде добро речено о контрастирању сложености са другим захтевима).

У 2011, Додо ИС арһитектура је изгледала овако:

До 2020. постало је мало компликованије и постало је овако:

Како је дошло до ове еволуције? Зашто су потребни различити делови система? Које су архитектонске одлуке донете и зашто? Хајде да сазнамо у овој серији чланака.

Први проблеми 2016: зашто би службе требало да напусте монолит?

Први чланци у серијалу биће о службама које су се прве одвојиле од монолита. Да вас ставим у контекст, рећи ћу вам какве смо проблеме имали у систему почетком 2016. године, да смо морали да се бавимо раздвајањем услуга.

Јединствена МиСкл база података у коју су све апликације које су постојале у то време у Додо ИС-у уписивале своје записе. Последице су биле:

• Велико оптерећење (са 85% читања захтева).
• База је расла. Због тога су трошкови и подршка постали проблем.
• Једна тачка неуспеха. Ако је једна апликација која пише у базу података одједном почела да то чини активније, онда су друге апликације осетиле утицај.
• Неефикасност складиштења и упита. Често су подаци били ускладиштени у некој структури која је била згодна за неке сценарије, али не и за друге. Индекси убрзавају неке операције, али могу успорити друге.
• Неки од проблема су решени на брзину направљеним кешовима и репликама за читање база података (о томе ће бити речи у посебном чланку), али су нам само омогућили да добијемо на времену и нису суштински решили проблем.

Проблем је било присуство самог монолита. Последице су биле:

• Јединствена и ретка издања.
• Тешкоћа је у заједничком развоју великог броја људи.
• Немогућност увођења нових технологија, нових оквира и библиотека.

Проблеми са базом и монолитом су описани много пута, на пример, у контексту пада на почетку 2018 (Будите као Мунцх, или неколико речи о техничком дугу, Дан када је Додо ИС стао. Асинхрона скрипта и Прича о птици Додо из породице Феникс. Велики пад Додоа ИС), тако да се нећу превише задржавати. Дозволите ми само да кажем да смо желели да пружимо више флексибилности приликом развоја услуга. Пре свега, ово се тицало оних који су били највише оптерећени и роот у целом систему - Аутх и Трацкер.

Путања позадинске канцеларије: одвојене базе и аутобус

Навигација у поглављу

1. Шема монолита 2016
2. Почињемо да истоварујемо монолит: раздвајање Аутх-а и Трацкер-а
   
3. Шта ради Аутх?
4. Одакле долазе оптерећења?
5. Унлоадинг Аутх
6. Шта ради Трацкер?
7. Одакле долазе оптерећења?
8. Истовар Трацкер

Шема монолита 2016

Ево главних блокова монолита Додо ИС из 2016, а одмах испод је преглед њихових главних задатака.

Благајна за доставу. Рачуноводство курира, издавање налога куририма.
Контакт центар. Прихватање налога преко оператера.
Сајт. Наше веб странице (додопизза.ру, додопизза.цо.ук, додопизза.би, итд.).
Аутх. Услуга ауторизације и аутентификације за бацкоффице.
Трацкер. Праћење наруџби у кухињи. Сервис за обележавање статуса спремности приликом припреме поруџбине.
Благајна ресторана. Примање поруџбина у ресторану, интерфејси благајне.
извоз. Отпремање извештаја у 1Ц за рачуноводство.
Упозорења и фактуре. Гласовне команде у кухињи (на пример, „Стигла је нова пица“) + штампање рачуна за курире.
Руководилац смене. Интерфејси за рад менаџера смене: листа налога, графикони продуктивности, довођење запослених у смене.
Оффице Манагер. Интерфејси за рад примаоца франшизе и менаџера: пријем запослених, извештаји о раду пицерије.
Табла ресторана. Приказивање менија на телевизорима у пицеријама.
Админ. Подешавања за одређену пицерију: мени, цене, рачуноводство, промотивни кодови, промоције, банери за сајт итд.
Лични рачун запослених. Распоред рада запослених, подаци о запосленима.
Мотивациони одбор кухиње. Засебан екран који виси у кухињи и приказује брзину произвођача пице.
Комуникација. Слање смс-а и е-поште.
ФилеСтораге. Сопствени сервис за пријем и издавање статичких фајлова.

Први покушаји решавања проблема су нам помогли, али су били само привремени предах. Нису постала системска решења, па је било јасно да се са базама мора нешто урадити. На пример, поделите општу базу података на неколико специјализованих.

Почињемо да истоварујемо монолит: раздвајање Аутх-а и Трацкер-а

Главни сервиси који су тада писали и читали из базе података више од других:

1. Аутх. Услуга ауторизације и аутентификације за бацкоффице.
2. Трацкер. Праћење наруџби у кухињи. Сервис за обележавање статуса спремности приликом припреме поруџбине.

Шта ради Аутх?

Аутх је услуга преко које се корисници пријављују у бацк оффице (постоји засебна независна пријава на страни клијента). Такође се помиње у захтеву како би се осигурало да постоје исправна права приступа и да се та права нису променила од последњег пријављивања. Преко њега уређаји улазе у пицерије.

На пример, желимо да отворимо дисплеј са статусом извршених поруџбина на телевизору који виси у сали. Затим отворимо аутх.додопизза.ру, изаберемо „Пријави се као уређај“, појављује се код који се може унети на посебну страницу на рачунару менаџера смене, који означава тип уређаја (уређаја). Сам ТВ ће отићи до жељеног интерфејса своје пицерије и тамо почети да приказује имена купаца чије су поруџбине спремне.

Одакле долазе оптерећења?

Сваки пријављен бацкоффице корисник за сваки захтев одлази у базу података, у корисничку табелу, извлачи корисника одатле кроз скл упит и проверава да ли има потребан приступ и права на ову страницу.

Сваки од уређаја ради исто само са табелом уређаја, проверава своју улогу и приступе. Велики број захтева ка главној бази података доводи до њеног учитавања и расипања општих ресурса базе података на ове операције.

Унлоадинг Аутх

Аутх има изолован домен, односно подаци о корисницима, пријавама или уређајима улазе у сервис (тренутно будући) и тамо остају. Ако неком затребају, он ће отићи у овај сервис по податке.

БИО. Ток рада је у почетку био овакав:

Желео бих да објасним мало како је то функционисало:

1. Спољни захтев долази у позадину (тамо Асп.Нет МВЦ), доносећи са собом колачић сесије, који се користи за добијање података о сесији од Редис(1). Или садржи информације о приступима, а онда је приступ контролеру отворен (3,4), или не.
2. Ако нема приступа, потребно је да прођете кроз процедуру ауторизације. Овде је, ради једноставности, приказан као део путање у истом атрибуту, иако је ово прелазак на страницу за пријаву. У случају позитивног сценарија, добићемо исправно попуњену сесију и отићи ћемо на Бацкоффице Цонтроллер.
3. Ако постоје подаци, онда их морате проверити да ли су релевантни у корисничкој бази података. Да ли се његова улога променила, да га сада не пусте на страницу? У овом случају, након пријема сесије (1), потребно је да директно одете у базу података и проверите приступ корисника помоћу логичког слоја аутентификације (2). Затим или идите на страницу за пријаву или идите на контролер. Ово је једноставан систем, али није сасвим стандардан.
4. Ако су све процедуре завршене, онда прескачемо даље у логици у контролерима и методама.

Кориснички подаци су одвојени од свих осталих података, чувају се у посебној табели чланства, функције из логичког слоја АутхСервице могу постати АПИ методе. Границе домена су прилично јасно дефинисане: корисници, њихове улоге, приступни подаци, издавање и укидање приступа. Све изгледа као да би се могло преместити у посебан сервис.

БЕЦАМЕ. То су урадили:

Овај приступ има низ проблема. На пример, позивање методе унутар процеса није исто што и позивање спољне услуге преко хттп. Латенција, поузданост, подршка и транспарентност операције су потпуно различите. Андреи Моревски је детаљније говорио о управо овим проблемима у свом извештају "50 нијанси микросервиса".

Сервис аутентификације и са њим сервис уређаја користе се за бацк оффице, односно за сервисе и интерфејсе који се користе у производњи. Аутентификација за клијентске услуге (као што је веб локација или мобилна апликација) се одвија одвојено без коришћења Аутх. Раздвајање је трајало око годину дана, а сада поново радимо на овој теми, преносећи систем на нове сервисе за аутентификацију (са стандардним протоколима).

Зашто је раздвајање трајало толико дуго?
Било је много проблема на путу који су нас успоравали:

1. Желели смо да пренесемо податке о корисницима, уређајима и аутентификацији из база података земаља у једну. Да бисмо то урадили, морали смо да пренесемо све табеле и употребу са инт идентификатора на глобални УУИд идентификатор (недавно смо прерадили овај код Роман Букин "Ууид - велика прича о малој структури" и пројекат отвореног кода Примитивес). Чување корисничких података (будући да се ради о личним подацима) има своја ограничења и за неке земље их је неопходно чувати одвојено. Али мора постојати глобални кориснички ИД.
2. Многе табеле у бази података имају информације ревизије о кориснику који је извршио операцију. Ово је захтевало додатни механизам да би се обезбедила доследност.
3. Након креирања АПИ сервиса, уследио је дуг и постепен период преласка на други систем. Прекидачи су се морали одвијати неприметно за кориснике и захтевали су ручни рад.

Шема за регистрацију уређаја у пицерији:

Општа архитектура након раздвајања услуге Аутх и Девицес:

Приметити. За 2020. радимо на новој верзији Аутх-а, која је заснована на ОАутх 2.0 стандарду ауторизације. Овај стандард је прилично сложен, али користан за развој услуге аутентификације од краја до краја. У чланку "Суптилности ауторизације: преглед технологије ОАутх 2.0» ми, Алексеј Черњајев, покушали смо да причамо о стандарду што једноставније и јасније како бисте уштедели време на његовом проучавању.

Шта ради Трацкер?

Сада о другом од учитаних сервиса. Тракер има двоструку улогу:

• С једне стране, њен задатак је да покаже запосленима у кухињи које су поруџбине тренутно у току, које производе сада треба припремити.
• С друге стране, дигитализујте све процесе у кухињи.

Када се нови производ (на пример, пица) појави у поруџбини, он иде на станицу за праћење „Роллинг“. На овој станици се налази пиззаџија који узима лепињу потребне величине и размотава је, након чега на таблету за праћење означава да је обавио задатак и предаје разваљану подлогу за тесто следећој станици - „Пилњење“ .

Тамо следећи произвођач пице ставља пицу на врх, затим на таблету означава да је завршио свој задатак и ставља пицу у рерну (ово је такође посебна станица коју треба обележити на таблету). Такав систем је био присутан од самог почетка у Додоу и од самог почетка Додо ИС. Омогућава вам да у потпуности пратите и дигитализујете све операције. Поред тога, трацкер предлаже како припремити одређени производ, изводи сваку врсту производа према сопственим производним шемама, чува оптимално време кувања за производ и прати све операције на производу.

Овако изгледа екран таблета на станици за праћење Раскатка.

Одакле долазе оптерећења?

Свака пицерија има око пет таблета са трекером. У 2016. имали смо више од 100 пицерија (а сада их има више од 600). Сваки од таблета сваких 10 секунди шаље захтев бацкенд-у и прикупља податке из табеле поруџбина (веза са клијентом и адресом), састава поруџбине (веза са производом и назнаком количине) и табеле мотивације (прати време пресовања). Када произвођач пице кликне на производ на трагачу, подаци у свим овим табелама се ажурирају. Табела поруџбина је општа, она истовремено садржи уметања приликом прихватања поруџбине, ажурирања из других делова система и бројна очитавања, на пример, на ТВ-у који виси у пицерији и приказује готове поруџбине купцима.

Током периода борбе са оптерећењима, када је све и свако кеширано и пребачено у асинхрону реплику базе података, ове операције са трагачем су наставиле да иду у главну базу података. Овде не би требало да буде кашњења, подаци морају бити ажурни, несинхронизовани су неприхватљиви.

Такође, недостатак сопствених табела и индекса на њима није нам дозволио да напишемо конкретније упите прилагођене нашој употреби. На пример, може бити ефикасно да пратилац има индекс за пицерију у својој табели поруџбина. Наруџбине пицерије увек извлачимо из базе података за праћење. При томе, за прихватање поруџбине није толико важно у коју пицерију спада, важније је који клијент је направио ову поруџбину. То значи да мора постојати индекс на клијенту. Такође није неопходно да пратилац складишти ИД одштампаног рачуна или бонус промоције повезане са поруџбином у табели поруџбина. Наш сервис за праћење није заинтересован за ове информације. У заједничкој монолитној бази података, табеле могу бити само компромис између свих корисника. Ово је био један од првобитних проблема.

БИО. У почетку је архитектура била оваква:

Чак и након што је раздвојен у засебне процесе, већина базе кода је остала заједничка за различите услуге. Све испод контролора било је обједињено и живело је у једном спремишту. Коришћене су уобичајене методе сервиса, спремишта и заједничка база података која садржи заједничке табеле.

Истовар Трацкер

Главни проблем са трацкером је тај што подаци морају бити синхронизовани између различитих база података. То је и његова главна разлика у односу на подјелу Аутх сервиса; налог и његов статус се могу мијењати и треба их приказати у различитим сервисима.

Поруџбине примамо на благајни ресторана (ово је услуга), она се чува у бази података у статусу „Прихваћено“. Након тога, требало би да оде у трагач, где ће још неколико пута променити свој статус: из „Кухиња” у „Упаковано”. У овом случају, неки спољни утицаји из Благајне или интерфејса Менаџера смене могу се појавити са налогом. Даћу статусе поруџбина са њиховим описима у табели:

Шема промене статуса поруџбине изгледа овако:

Статуси се мењају између различитих система. А овде трагач није коначни систем у којем су подаци закључани. Видели смо неколико могућих приступа за раздвајање у таквом случају:

1. Ми концентришемо све акције наруџбине у једну услугу. У нашем случају, ова опција захтева превише услуге за обраду поруџбине. Да смо ту стали, завршили бисмо са другим монолитом. Не бисмо решили проблеме.
2. Један систем позива други. Друга опција је занимљивија. Али уз то су могући ланци позива (каскадни кварови), повезаност компоненти је већа и теже је управљати.
3. Организујемо догађаје и свака служба размењује са другом кроз ове догађаје. Као резултат тога, изабрана је трећа опција, према којој све службе почињу да размењују догађаје једни са другима.

Чињеница да смо изабрали трећу опцију значила је да ће трекер имати своју базу података и за сваку промену у редоследу слати догађај о томе, на који би се други сервиси претплатили и који би такође био укључен у мастер базу података. Да бисмо то урадили, била нам је потребна нека услуга која би обезбедила испоруку порука између сервиса.

У то време смо већ имали РаббитМК у стеку, па је стога коначна одлука да га користимо као посредника за поруке. Дијаграм приказује прелазак наруџбине са благајне ресторана кроз Трацкер, где она мења свој статус и приказ на интерфејсу налога менаџера. ПОСТАНИ:

Наручите пут корак по корак
Путања поруџбине почиње на једној од услуга извора поруџбине. Ево благајника ресторана:

1. Наруџба је потпуно спремна на благајни и време је да је пошаљете на праћење. Догађај на који је пратилац претплаћен се баца.
2. Тракер, прихватајући наруџбу, чува је у својој бази података, прави догађај „Наруџбу је прихватио Трацкер“ и шаље је у РМК.
3. Неколико руковалаца је већ претплаћено на прилагођену сабирницу догађаја. За нас је важан онај који се синхронизује са монолитном базом података.
4. Руковалац прима догађај, бира из њега податке који су значајни за њега: у нашем случају, ово је статус поруџбине „Прихватио Трацкер“ и ажурира свој ентитет наруџбине у главној бази података.

Ако некоме треба налог посебно из табеле монолитних наруџби, онда може и одатле да га прочита. На пример, ово је оно што је потребно интерфејсу Ордерс у Менаџеру смена:

Све друге услуге се такође могу претплатити на наручивање догађаја са трагача како би их користили за себе.

Ако се након неког времена поруџбина преузме у производњу, њен статус се прво мења у бази података (Трацкер база података), а затим се одмах генерише догађај „ОрдерИнВорк“. Такође улази у РМК, одакле се синхронизује у монолитну базу података и испоручује другим сервисима. На овом путу може бити разних проблема; више детаља о њима може се наћи у извештају Жење Пешкова о детаљима имплементације Евентуал Цонсистенци у Трацкер-у.

Коначна архитектура након промена у Аутх и Трацкер-у

Да резимирамо: У почетку сам имао идеју да деветогодишњу историју Додо ИС система упакујем у један чланак. Желео сам да брзо и једноставно причам о фазама еволуције. Међутим, када сам сео да проучавам материјал, схватио сам да је све много сложеније и занимљивије него што се чини.

Размишљајући о предностима (или недостатку) таквог материјала, дошао сам до закључка да је континуирани развој немогућ без пуноправних хроника догађаја, детаљних ретроспектива и анализе нечијих прошлих одлука.

Надам се да вам је било корисно и занимљиво сазнати о нашем путовању. Сада сам пред избором који део Додо ИС система да опишем у следећем чланку: пишите у коментарима или гласајте.

Само регистровани корисници могу учествовати у анкети. Пријавите се, Добродошао си.

О ком делу Додо ИС-а бисте желели да сазнате у следећем чланку?

• 100%Рани монолит у Додо ИС (2011-2015)14

• 100%Први проблеми и њихова решења (2015-2016)14

• 100%Стаза клијентског дела: фасада изнад основе (2016-2017)12

• 100%Историја стварних микросервиса (2018-2019)21

• 100%Завршено сечење монолита и стабилизација архитектуре26

• 100%О даљим плановима развоја система17

• 100%Не желим да знам ништа о Додо ИС11

Гласало је 58 корисника. Уздржано је било 6 корисника.

Извор: ввв.хабр.цом