Историја на архитектурата на Додо ИС: Патеката за задната канцеларија

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

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

Благодарност: Ви благодариме што ги споделивте вашите повратни информации со нас. Благодарение на него, конечно го опишавме системот, составивме технорадар и наскоро ќе објавиме голем опис на нашите процеси. Без тебе ќе седевме вака уште 5 години.

Серија написи „Што е Додо ИС? ќе каже за:

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

Доколку сте заинтересирани да научите нешто друго, пишете во коментарите.

Мислење за хронолошкиот опис од авторот
Редовно одржувам состанок за новите вработени на тема „Системска архитектура“. Ние го нарекуваме „Вовед во архитектурата на Додо ИС“ и е дел од процесот на вградување на новите програмери. Зборувајќи во една или друга форма за нашата архитектура, за нејзините карактеристики, развив одреден историски пристап кон описот.

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

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

Во 2011 година, архитектурата Додо ИС изгледаше вака:

До 2020 година, стана малку покомплицирано и стана вака:

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

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

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

Единствена MySql база на податоци во која сите апликации што постоеја во тоа време во Dodo IS ги запишаа своите записи. Последиците беа:

• Голем товар (со 85% од барањата што се читаат).
• Основата растеше. Поради ова, цената и поддршката станаа проблем.
• Единствена точка на неуспех. Ако една апликација која пишува во базата на податоци одеднаш почна да го прави тоа поактивно, тогаш другите апликации го почувствуваа влијанието.
• Неефикасност во складирањето и прашањата. Честопати податоците беа складирани во некоја структура што беше погодна за некои сценарија, но не и за други. Индексите забрзуваат некои операции, но можат да ги забават другите.
• Некои од проблемите беа решени со набрзина направени кешови и читање-реплики на базите на податоци (за ова ќе се дискутира во посебна статија), но тие ни овозможија само да добиеме време и не го решија фундаментално проблемот.

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

• Уникатни и ретки изданија.
• Тешкотијата е во заедничкиот развој на голем број луѓе.
• Неможност да се воведат нови технологии, нови рамки и библиотеки.

Проблемите со основата и монолитот се опишани многу пати, на пример, во контекст на несреќи во почетокот на 2018 година (Бидете како Мунк, или неколку зборови за технички долг, Денот кога Додо е запрен. Асинхрона скрипта и Приказната за птицата Додо од семејството Феникс. Големиот пад на Додо е), затоа нема да се задржувам премногу. Само да кажам дека сакавме да дадеме поголема флексибилност при развивањето на услугите. Пред сè, ова се однесуваше на оние кои беа најоптоварени и најраспространети во целиот систем - Auth и Tracker.

Backoffice патека: посебни бази и автобус

Навигација на поглавја

1. Шема на монолитот 2016 година
2. Почнуваме да го растовараме монолитот: одвојување на Auth и Tracker
   
3. Што прави Auth?
4. Од каде доаѓаат товарите?
5. Се растоварува авт
6. Што прави Tracker?
7. Од каде доаѓаат товарите?
8. Растоварување на Тракерот

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

Еве ги главните блокови на монолитот Dodo IS од 2016 година, а веднаш подолу е преглед на нивните главни задачи.

Каса за испорака. Сметководство за курири, издавање нарачки на курири.
Контакт центар. Прифаќање нарачки преку операторот.
Мапа. Нашите веб-страници (dodopizza.ru, dodopizza.co.uk, dodopizza.by, итн.).
Auth. Услуга за овластување и автентикација за backoffice.
Тракер. Тракер за нарачки во кујната. Сервис за означување на статуси на подготвеност при подготовка на нарачка.
Каса во ресторанот. Примање нарачки во ресторан, касиерски интерфејси.
Извоз. Поставување извештаи во 1C за сметководство.
Известувања и фактури. Гласовни команди во кујната (на пример, „Пристигна нова пица“) + печатење на фактури за курири.
Менаџер на смена. Интерфејси за работа на менаџер на смена: список на нарачки, графикони за продуктивност, доведување на вработените во смени.
Канцелариски менаџер. Интерфејси за работа на франшизи и менаџери: прием на вработени, извештаи за работата на пицеријата.
Ресторан табла. Прикажување менија на телевизори во пицериите.
Админ. Поставки за одредена пицерија: мени, цени, сметководство, промотивни кодови, промоции, банери за страницата итн.
Лична сметка на вработен. Распоред на работа на вработените, информации за вработените.
Одбор за мотивација во кујната. Посебен екран кој виси во кујната и ја прикажува брзината на производителите на пица.
Порака. Испраќање смс и е-пошта.
Складирање на датотеки. Сопствена услуга за примање и издавање статични датотеки.

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

Почнуваме да го растовараме монолитот: одвојување на Auth и Tracker

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

1. Авт. Услуга за овластување и автентикација за backoffice.
2. Тракер. Тракер за нарачки во кујната. Сервис за означување на статуси на подготвеност при подготовка на нарачка.

Што прави Auth?

Auth е услуга преку која корисниците се најавуваат во задната канцеларија (има посебно независно најавување на страната на клиентот). Исто така, се наведува во барањето за да се осигура дека се присутни правилните права за пристап и дека овие права не се променети од последното најавување. Преку него уредите влегуваат во пицериите.

На пример, сакаме да отвориме дисплеј со статус на завршени нарачки на телевизорот што виси во салата. Потоа отвораме auth.dodopizza.ru, изберете „Најави се како уред“, се појавува код што може да се внесе на посебна страница на компјутерот на менаџерот на смена, означувајќи го типот на уредот (уредот). Самиот телевизор ќе оди до саканиот интерфејс на својата пицерија и ќе почне да ги прикажува имињата на клиентите чии нарачки се подготвени.

Од каде доаѓаат товарите?

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

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

Се растоварува авт

Auth има изолиран домен, односно податоците за корисници, најавувања или уреди влегуваат во услугата (во моментов во иднина) и остануваат таму. Ако некому му требаат, ќе оди на оваа услуга за податоци.

БЕШЕ. Работниот тек првично беше вака:

Би сакал да објаснам малку како функционираше:

1. Доаѓа надворешно барање до задниот дел (Asp.Net MVC таму), со себе носи колаче за сесија, кое се користи за добивање податоци за сесијата од Redis(1). Тој или содржи информации за пристапите, а потоа пристапот до контролорот е отворен (3,4) или не.
2. Ако нема пристап, треба да поминете низ процедурата за овластување. Овде, за едноставност, тој е прикажан како дел од патеката во истиот атрибут, иако ова е транзиција кон страницата за најавување. Во случај на позитивно сценарио, ќе добиеме правилно пополнета сесија и ќе одиме во Backoffice Controller.
3. Ако има податоци, тогаш треба да ги проверите за релевантност во базата на податоци на корисници. Дали му се смени улогата, сега да не му се дозволи на страницата? Во овој случај, по добивањето на сесијата (1), треба директно да отидете во базата на податоци и да го проверите пристапот на корисникот користејќи го логичкиот слој за автентикација (2). Следно, одете на страницата за најавување или одете до контролорот. Ова е едноставен систем, но не сосема стандарден.
4. Ако сите процедури се завршени, тогаш прескокнуваме понатаму во логиката во контролорите и методите.

Корисничките податоци се одделени од сите други податоци, се чуваат во посебна табела за членство, функциите од логичкиот слој AuthService може да станат методи на API. Границите на доменот се дефинирани сосема јасно: корисници, нивните улоги, пристап до податоци, издавање и одземање на пристап. Сè изгледа како да може да се премести во посебна услуга.

СТАНА. Така направија:

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

Услугата за автентикација и со неа услугата на уреди се користат за back office, односно за услуги и интерфејси кои се користат во производството. Автентикацијата за услугите на клиентите (како веб-локација или мобилна апликација) се случува одделно без користење на Auth. Раздвојувањето траеше околу една година, а сега повторно работиме на оваа тема, префрлајќи го системот на нови сервиси за автентикација (со стандардни протоколи).

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

1. Сакавме да ги пренесеме податоците за корисниците, уредите и автентикацијата од базите на податоци на земјите во една. За да го направите ова, моравме да ги префрлиме сите табели и употреба од идентификаторот int на глобалниот идентификатор UUId (неодамна го преработивме овој код Роман Букин „Uuid - голема приказна за мала структура“ и проект со отворен код Примитивци). Зачувувањето на корисничките податоци (бидејќи ова се лични податоци) има свои ограничувања и за некои земји е неопходно да се складираат посебно. Но, мора да има глобален кориснички ID.
2. Многу табели во базата на податоци имаат ревизорски информации за корисникот кој ја извршил операцијата. Ова бара дополнителен механизам за да се обезбеди конзистентност.
3. По создавањето на API услугите, имаше долг и постепен период на префрлање во друг систем. Прекинувачите мораа да се случуваат беспрекорно за корисниците и бараа рачна работа.

Шема за регистрација на уред во пицерија:

Општа архитектура по одвојувањето на услугата Auth и Devices:

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

Што прави Tracker?

Сега за втората од вчитаните услуги. Тракерот врши двојна улога:

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

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

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

Вака изгледа екранот на таблетот на тракерската станица Раскатка.

Од каде доаѓаат товарите?

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

За време на периодот на борба со оптоварувањата, кога сè и сите беа кеширани и префрлени во асинхрона реплика на базата на податоци, овие операции со тракерот продолжија да одат во главната база на податоци. Овде не треба да има задоцнување, податоците мора да бидат ажурирани, несинхронизирано е неприфатливо.

Исто така, недостатокот на сопствени табели и индекси на нив не ни дозволи да пишуваме поконкретни прашања прилагодени за наша употреба. На пример, може да биде ефективно за тракерот да има индекс за пицерија на табелата за нарачки. Ние секогаш ги бришеме нарачките од пицеријата од базата на податоци за тракери. Во исто време, за да се прифати нарачка, не е толку важно во која пицерија спаѓа, поважно е кој клиент ја направил оваа нарачка. Ова значи дека треба да има индекс на клиентот. Исто така, не е неопходно тракерот да го складира ID на отпечатената сметка или бонусните промоции поврзани со нарачката во табелата за нарачки. Нашата услуга за следење не е заинтересирана за овие информации. Во заедничка монолитна база на податоци, табелите би можеле да бидат само компромис помеѓу сите корисници. Ова беше еден од првобитните проблеми.

БЕШЕ. Првично архитектурата беше вака:

Дури и откако беше поделена во посебни процеси, поголемиот дел од базата на кодови остана заедничка за различни услуги. Сè што беше под контролорите беше обединето и живееше во едно складиште. Беа користени заеднички методи на услуги, складишта и заедничка база на податоци што содржи заеднички табели.

Растоварување на Тракерот

Главниот проблем со тракерот е што податоците мора да се синхронизираат помеѓу различни бази на податоци. Ова е и нејзината главна разлика од поделбата на услугата Auth; редоследот и нејзиниот статус може да се менуваат и треба да се прикажуваат во различни услуги.

Прифаќаме нарачки во касата на ресторанот (ова е услуга), таа се чува во базата на податоци во статусот „Прифатено“. После тоа, треба да оди во тракерот, каде што ќе го промени својот статус уште неколку пати: од „Кујна“ во „Спакувано“. Во овој случај, со нарачката може да се појават некои надворешни влијанија од интерфејсот на Cashier или Shift Manager. Ќе ги дадам статусите на нарачките со нивните описи во табелата:

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

Статусите се менуваат помеѓу различни системи. И тука тракерот не е конечниот систем во кој податоците се заклучени. Видовме неколку можни пристапи за одвојување во таков случај:

1. Ние ги концентрираме сите дејства на нарачката во една услуга. Во нашиот случај, оваа опција бара премногу услуга за да се обработи нарачката. Да застаневме таму, ќе завршевме со втор монолит. Немаше да ги решиме проблемите.
2. Еден систем упатува повик до друг. Втората опција е поинтересна. Но, со тоа, можни се синџири на повици (каскадни неуспеси), поврзаноста на компонентите е поголема, а потешко е да се управува.
3. Ние организираме настани и секоја услуга се разменува со другата преку овие настани. Како резултат на тоа, беше избрана третата опција, според која сите услуги почнуваат да разменуваат настани едни со други.

Тоа што ја избравме третата опција значеше дека тракерот ќе има своја база на податоци и за секоја промена на редоследот ќе испраќа настан за ова, на кој ќе се претплатат други услуги и кој исто така ќе биде вклучен во главната база на податоци. За да го направиме ова, ни требаше некоја услуга која ќе обезбеди испорака на пораки помеѓу услугите.

Во тоа време, веќе го имавме RabbitMQ во магацинот, па оттука и конечната одлука да го користиме како брокер за пораки. Дијаграмот го прикажува преминот на нарачката од Касиерката на ресторанот преку Следење, каде што го менува нејзиниот статус и прикажувањето на интерфејсот за нарачки на менаџерот. СТАНА:

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

1. Нарачката е целосно подготвена на Checkout и време е да ја испратите до тракерот. Настанот на кој е претплатен тракерот е фрлен.
2. Следачот, прифаќајќи нарачка, ја зачувува во сопствената база на податоци, правејќи го настанот „Нарачка прифатена од Следач“ и испраќајќи ја до RMQ.
3. Неколку ракувачи се веќе претплатени на автобусот за приспособени настани. За нас е важна онаа што се синхронизира со монолитната база на податоци.
4. Ракувачот го прима настанот, од него ги избира податоците што се значајни за него: во нашиот случај, ова е статусот на нарачката „Прифатен од Следач“ и го ажурира својот ентитет на нарачка во главната база на податоци.

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

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

Ако по одредено време се внесе нарачка во производство, нејзиниот статус прво се менува во нејзината база на податоци (база на податоци Tracker), а потоа веднаш се генерира настанот „OrderInWork“. Влегува и во RMQ, од каде што се синхронизира во монолитна база на податоци и се доставува до други услуги. Може да има различни проблеми на овој пат; повеќе детали за нив може да најдете во извештајот на Жења Пешков за деталите за имплементација на евентуална конзистентност во Тракер.

Конечна архитектура по промените во Auth и Tracker

За да резимираме: Првично, имав идеја да ја спакувам деветгодишната историја на системот Додо ИС во една статија. Сакав брзо и едноставно да зборувам за фазите на еволуцијата. Сепак, откако седнав да го проучувам материјалот, сфатив дека сè е многу покомплексно и поинтересно отколку што изгледа.

Размислувајќи за придобивките (или недостатокот) од таквиот материјал, дојдов до заклучок дека континуираниот развој е невозможен без полноправни хроники на настани, детални ретроспективи и анализа на нечии минати одлуки.

Се надевам дека ви беше корисно и интересно да дознаете за нашето патување. Сега сум соочен со избор кој дел од системот 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 корисници беа воздржани.

Извор: www.habr.com