Habr zmienia świat. Blogujemy już od ponad roku. Około pół roku temu otrzymaliśmy całkiem logiczną informację zwrotną od mieszkańców Chabrowska: „Dodo, wszędzie mówisz, że masz swój system. Co to za system? A po co to sieci pizzerii?”
Siedzieliśmy, myśleliśmy i zdaliśmy sobie sprawę, że masz rację. Próbujemy wszystko wytłumaczyć palcami, ale wychodzi w kawałkach i nigdzie nie ma pełnego opisu systemu. Tak rozpoczęła się długa podróż polegająca na zbieraniu informacji, poszukiwaniu autorów i pisaniu serii artykułów na temat Dodo IS. Chodźmy!
Podziękowania: Dziękujemy za podzielenie się z nami swoją opinią. Dzięki niemu w końcu opisaliśmy system, skompilowaliśmy technoradar i wkrótce udostępnimy obszerny opis naszych procesów. Bez Was siedzielibyśmy tak przez kolejne 5 lat.
Seria artykułów „Czym jest Dodo IS?” opowiada o:
- Wczesny monolit w Dodo IS (2011-2015). (W trakcie...)
- Ścieżka Backoffice: oddzielne bazy i autobus. (Jesteś tutaj)
- Ścieżka od strony klienta: elewacja nad bazą (2016-2017). (W trakcie...)
- Historia prawdziwych mikroserwisów. (2018-2019). (W trakcie…)
- Zakończono piłowanie monolitu i stabilizację architektury. (W trakcie…)
Jeżeli jesteś zainteresowany nauczeniem się czegoś jeszcze, napisz w komentarzu.
Opinia o opisie chronologicznym od autora
Regularnie organizuję spotkania dla nowych pracowników na temat „Architektura systemu”. Nazywamy to „Wprowadzeniem do architektury Dodo IS” i stanowi część procesu wdrażania nowych programistów. Mówiąc w tej czy innej formie o naszej architekturze, o jej cechach, wypracowałem pewne historyczne podejście do opisu.
Tradycyjnie patrzymy na system jako na zbiór komponentów (technicznych lub wyższego poziomu), modułów biznesowych, które współdziałają ze sobą, aby osiągnąć jakiś cel. I choć taki pogląd jest uzasadniony projektowo, nie do końca nadaje się do opisu i zrozumienia. Jest kilka powodów:
- Rzeczywistość jest inna niż na papierze. Nie wszystko układa się zgodnie z planem. Jesteśmy ciekawi, jak wszystko faktycznie się potoczyło i działa.
- Spójna prezentacja informacji. Tak naprawdę można przejść chronologicznie od początku do stanu bieżącego.
- Od prostych do złożonych. Nie jest to uniwersalne, ale w naszym przypadku tak jest. Architektura przeszła od prostszych podejść do bardziej złożonych. Często przez komplikacje, problemy z szybkością i stabilnością wdrożenia, a także dziesiątki innych właściwości z listy wymagań niefunkcjonalnych ( dobrze mówiono o kontrastowaniu złożoności z innymi wymaganiami).
W 2011 roku architektura Dodo IS wyglądała tak:
Do 2020 roku sytuacja stała się nieco bardziej skomplikowana i wyglądała następująco:
Jak doszło do tej ewolucji? Dlaczego potrzebne są różne części systemu? Jakie decyzje architektoniczne zostały podjęte i dlaczego? Dowiemy się tego w tej serii artykułów.
Pierwsze problemy 2016 roku: dlaczego usługi mają wyjść z monolitu?
Pierwsze artykuły z cyklu będą dotyczyć usług, które jako pierwsze wydzieliły się z monolitu. Żeby przybliżyć Wam kontekst, opowiem, jakie problemy mieliśmy w systemie na początku 2016 roku, że musieliśmy się uporać z rozdziałem usług.
Pojedyncza baza danych MySql, w której zapisywały się wszystkie aplikacje istniejące wówczas w Dodo IS. Konsekwencje były następujące:
- Duże obciążenie (odczytywane jest 85% żądań).
- Baza rosła. Z tego powodu koszt i wsparcie stały się problemem.
- Pojedynczy punkt awarii. Jeśli jedna aplikacja zapisująca do bazy danych nagle zacznie robić to aktywniej, inne aplikacje odczują tego skutki.
- Nieefektywność przechowywania i zapytań. Często dane były przechowywane w jakiejś strukturze, która była wygodna w niektórych scenariuszach, ale nie w innych. Indeksy przyspieszają niektóre operacje, ale mogą spowalniać inne.
- Część problemów rozwiązano poprzez pospieszne tworzenie pamięci podręcznych i replik odczytu do baz danych (będzie to omówione w osobnym artykule), ale pozwoliły one jedynie zyskać na czasie i nie rozwiązały zasadniczo problemu.
Problemem była obecność samego monolitu. Konsekwencje były następujące:
- Unikalne i rzadkie wydania.
- Trudność polega na wspólnym rozwoju dużej liczby osób.
- Brak możliwości wprowadzenia nowych technologii, nowych frameworków i bibliotek.
Problemy z podstawą i monolitem były opisywane wielokrotnie, np. w kontekście awarii na początku 2018 roku (, и ), więc nie będę się za bardzo rozwodzić. Powiem tylko, że chcieliśmy zapewnić większą elastyczność przy opracowywaniu usług. Przede wszystkim dotyczyło to tych, które były najbardziej obciążone i rootowane w całym systemie – Auth i Tracker.
Ścieżka Back Office: oddzielne bazy i magistrala
Nawigacja rozdziałów
Schemat monolitu 2016
Oto główne bloki monolitu Dodo IS 2016, a tuż poniżej znajduje się zestawienie ich głównych zadań.
Kasa dostawcza. Księgowość kurierów, wydawanie zamówień kurierom.
Centrum Kontaktu. Przyjmowanie zamówień za pośrednictwem operatora.
teren. Nasze strony internetowe (dodopizza.ru, dodopizza.co.uk, dodopizza.by itp.).
Auth. Usługa autoryzacji i uwierzytelniania dla backoffice.
Tracker. Śledzenie zamówień w kuchni. Usługa oznaczania statusów gotowości podczas przygotowywania zamówienia.
Kasa restauracyjna. Przyjmowanie zamówień w restauracji, interfejsy kasjera.
Export. Przesyłanie raportów w 1C do księgowości.
Alerty i faktury. Komendy głosowe w kuchni (np. „Przyjechała nowa pizza”) + druk faktur dla kurierów.
Kierownik zmiany. Interfejsy do pracy kierownika zmiany: lista zamówień, wykresy produktywności, doprowadzanie pracowników na zmiany.
Kierownik biura. Interfejsy do pracy franczyzobiorców i menadżerów: recepcja pracowników, raporty z pracy pizzerii.
Tablica restauracji. Wyświetlanie menu na telewizorach w pizzeriach.
Admin. Ustawienia dla konkretnej pizzerii: menu, ceny, księgowość, kody promocyjne, promocje, banery na stronę itp.
Konto osobiste pracownika. Harmonogramy pracy pracowników, informacje o pracownikach.
Kuchenna tablica motywacyjna. Oddzielny ekran, który wisi w kuchni i wyświetla prędkość producentów pizzy.
Komunikacja. Wysyłanie SMS-ów i e-maili.
Nośnik danych. Własna usługa przyjmowania i wydawania plików statycznych.
Pierwsze próby rozwiązania problemów nam pomogły, ale były tylko chwilowym wytchnieniem. Nie stały się one rozwiązaniami systemowymi, więc było jasne, że trzeba coś zrobić z podstawami. Na przykład podziel ogólną bazę danych na kilka bardziej wyspecjalizowanych.
Zaczynamy rozładowywać monolit: oddzielenie Auth i Trackera
Główne usługi, które następnie zapisywały i czytały z bazy danych częściej niż inne:
- Autoryt. Usługa autoryzacji i uwierzytelniania dla backoffice.
- Abstrakt. Śledzenie zamówień w kuchni. Usługa oznaczania statusów gotowości podczas przygotowywania zamówienia.
Co robi Auth?
Auth to usługa, za pośrednictwem której użytkownicy logują się do back office (istnieje osobne, niezależne logowanie po stronie klienta). W żądaniu znajduje się również odniesienie do zapewnienia, że istnieją prawidłowe prawa dostępu i że prawa te nie uległy zmianie od ostatniego logowania. Urządzenia wchodzą przez nią do pizzerii.
Przykładowo chcemy otworzyć wyświetlacz ze statusem zrealizowanych zamówień na telewizorze wiszącym w przedpokoju. Następnie otwieramy auth.dodopizza.ru, wybieramy „Zaloguj się jako urządzenie”, pojawia się kod, który można wprowadzić na specjalnej stronie na komputerze kierownika zmiany, wskazując typ urządzenia (urządzenia). Telewizor sam przejdzie do żądanego interfejsu swojej pizzerii i zacznie wyświetlać tam nazwiska klientów, których zamówienia są już gotowe.
Skąd pochodzą ładunki?
Każdy zalogowany użytkownik backoffice po każde żądanie trafia do bazy danych, do tabeli użytkowników, wyciąga stamtąd użytkownika poprzez zapytanie sql i sprawdza, czy ma niezbędne dostępy i uprawnienia do tej strony.
Każde z urządzeń robi to samo tylko z tabelą urządzeń, sprawdzając swoją rolę i dostępy. Duża liczba żądań do bazy master prowadzi do jej ładowania i marnowania ogólnych zasobów bazy danych na te operacje.
Rozładunek autoryzacji
Auth ma wyizolowaną domenę, czyli dane o użytkownikach, loginach czy urządzeniach wchodzą do usługi (obecnie przyszłej) i tam pozostają. Jeżeli ktoś będzie ich potrzebował, to po dane sięgnie do tego serwisu.
BYŁ. Na początku przebieg pracy wyglądał następująco:
Chciałbym trochę wyjaśnić jak to działa:
- Do backendu (tam Asp.Net MVC) przychodzi zewnętrzne żądanie, niosąc ze sobą sesyjny plik cookie, który służy do uzyskiwania danych sesji z Redis(1). Zawiera informację o dostępach i wtedy dostęp do kontrolera jest otwarty (3,4) lub nie.
- Jeśli nie ma dostępu, musisz przejść procedurę autoryzacji. Tutaj dla uproszczenia jest ona pokazana jako część ścieżki w tym samym atrybucie, chociaż jest to przejście do strony logowania. W przypadku pozytywnego scenariusza otrzymamy prawidłowo wypełnioną sesję i przejdziemy do Kontrolera Backoffice.
- Jeśli istnieją dane, musisz sprawdzić je pod kątem trafności w bazie danych użytkowników. Czy jego rola się zmieniła, czy nie należy go teraz dopuścić na stronę? W tym przypadku po odebraniu sesji (1) należy bezpośrednio przejść do bazy danych i sprawdzić dostęp użytkownika za pomocą warstwy logiki uwierzytelniania (2). Następnie przejdź do strony logowania lub przejdź do kontrolera. To prosty system, ale nie do końca standardowy.
- Jeśli wszystkie procedury zostaną zakończone, wówczas pomijamy logikę w kontrolerach i metodach.
Dane użytkownika są oddzielone od wszystkich innych danych, są przechowywane w osobnej tabeli członkostwa, funkcje z warstwy logicznej AuthService mogą równie dobrze stać się metodami API. Granice domeny są określone dość jasno: użytkownicy, ich role, dane dostępowe, nadawanie i cofanie dostępu. Wszystko wygląda na to, że dałoby się to przenieść do osobnego serwisu.
STAŁ SIĘ. Oto co zrobili:
To podejście wiąże się z wieloma problemami. Na przykład wywołanie metody wewnątrz procesu nie jest tym samym, co wywołanie usługi zewnętrznej za pośrednictwem protokołu http. Opóźnienie, niezawodność, łatwość obsługi i przejrzystość operacji są zupełnie inne. Dokładnie te problemy opisał w swoim raporcie Andrey Morevsky .
Usługa uwierzytelniania, a wraz z nią usługa urządzenia wykorzystywana jest w back office, czyli usługach i interfejsach wykorzystywanych w produkcji. Uwierzytelnianie w przypadku usług klienckich (takich jak witryna internetowa lub aplikacja mobilna) odbywa się oddzielnie, bez użycia funkcji Auth. Separacja trwała około roku, a teraz ponownie pracujemy nad tym tematem, przenosząc system do nowych usług uwierzytelniania (ze standardowymi protokołami).
Dlaczego rozłąka trwała tak długo?
Po drodze pojawiło się wiele problemów, które nas spowalniały:
- Chcieliśmy przenieść dane o użytkownikach, urządzeniach i uwierzytelnianiu z krajowych baz danych do jednego. Aby to zrobić, musieliśmy przenieść wszystkie tabele i użycie z identyfikatora int do globalnego identyfikatora UUId (ostatnio przerobiliśmy ten kod i projekt open source ). Przechowywanie danych użytkownika (ponieważ są to dane osobowe) ma swoje ograniczenia i w niektórych krajach konieczne jest przechowywanie ich oddzielnie. Ale musi istnieć globalny identyfikator użytkownika.
- Wiele tabel w bazie danych zawiera informacje kontrolne dotyczące użytkownika, który wykonał operację. Wymagało to dodatkowego mechanizmu zapewniającego spójność.
- Po stworzeniu usług API nastąpił długi i stopniowy okres transferu na inny system. Przełączniki musiały przebiegać płynnie dla użytkowników i wymagały pracy ręcznej.
Schemat rejestracji urządzenia w pizzerii:
Ogólna architektura po oddzieleniu usługi Auth i Devices:
Operacja. Na rok 2020 pracujemy nad nową wersją Auth, która opiera się na standardzie autoryzacji OAuth 2.0. Ten standard jest dość złożony, ale przydatny do opracowania kompleksowej usługi uwierzytelniania. W artykule "» my, Aleksiej Czerniajew, staraliśmy się mówić o standardzie tak prosto i jasno, jak to możliwe, abyś oszczędził czas na jego studiowanie.
Co robi Tracker?
Teraz o drugiej z załadowanych usług. Tracker pełni podwójną rolę:
- Z jednej strony jego zadaniem jest pokazanie pracownikom kuchni, jakie zamówienia są aktualnie w trakcie realizacji, jakie produkty należy teraz przygotować.
- Z drugiej strony zdigitalizuj wszystkie procesy w kuchni.
Gdy w zamówieniu pojawi się nowy produkt (np. pizza), trafia on do stacji śledzenia „Rolling”. Na tym stanowisku znajduje się producent pizzy, który bierze bułkę o wymaganej wielkości i ją wałkuje, po czym zaznacza na tablecie, że wykonał swoje zadanie i przekazuje rozwałkowaną bazę ciasta do kolejnego stanowiska – „Napełnianie”. .
Tam kolejny pizzerz nakrywa pizzę, po czym zaznacza na tabliczce, że wykonał swoje zadanie i wkłada pizzę do piekarnika (jest to również osobne stanowisko, które należy zaznaczyć na tabliczce). Taki system był obecny od samego początku w Dodo i od samego początku Dodo IS. Pozwala w pełni śledzić i digitalizować wszystkie operacje. Ponadto tracker podpowiada, jak przygotować konkretny produkt, realizuje każdy rodzaj produktu według własnych schematów produkcyjnych, przechowuje optymalny czas gotowania produktu i śledzi wszystkie operacje na produkcie.
Tak wygląda ekran tabletu na stacji śledzącej Raskatka.
Skąd pochodzą ładunki?
Każda pizzeria ma około pięciu tabletów z trackerem. W 2016 roku mieliśmy ponad 100 pizzerii (obecnie jest ich ponad 600). Każdy z tabletów co 10 sekund wysyła żądanie do backendu i zbiera dane z tabeli zamówień (link do klienta i adresu), składu zamówienia (link do produktu i wskazanie ilości) oraz tabeli motywacyjnej (śledzi czas naciśnięcia). Gdy producent pizzy kliknie produkt w module śledzącym, rekordy we wszystkich tabelach zostaną zaktualizowane. Tabela zamówień ma charakter ogólny, zawiera jednocześnie wpisy przy przyjęciu zamówienia, aktualizacje z innych części systemu oraz liczne odczyty np. na telewizorze wiszącym w pizzerii i pokazującym klientom gotowe zamówienia.
W okresie zmagań z obciążeniami, kiedy wszystko i wszyscy byli buforowani i przenoszeni do asynchronicznej repliki bazy danych, te operacje z trackerem nadal trafiały do bazy master. Nie powinno tu być żadnych opóźnień, dane muszą być aktualne, brak synchronizacji jest niedopuszczalny.
Również brak własnych tabel i indeksów na nich nie pozwolił nam na napisanie bardziej szczegółowych zapytań dostosowanych do naszego użytku. Na przykład dla modułu śledzącego może być skuteczne umieszczenie indeksu pizzerii w tabeli zamówień. Zawsze usuwamy zamówienia z pizzerii z bazy danych modułu śledzącego. Jednocześnie, aby przyjąć zamówienie, nie jest tak ważne, do której pizzerii się ono zalicza, ważniejsze jest, który klient złożył to zamówienie. Oznacza to, że na kliencie musi znajdować się indeks. Nie jest również konieczne, aby moduł śledzący zapisywał w tabeli zamówień identyfikator wydrukowanego paragonu lub promocji bonusowych związanych z zamówieniem. Nasza usługa śledzenia nie jest zainteresowana tymi informacjami. We wspólnej monolitycznej bazie danych tabele mogą stanowić jedynie kompromis między wszystkimi użytkownikami. To był jeden z pierwotnych problemów.
BYŁ. Początkowo architektura wyglądała tak:
Nawet po rozdzieleniu na osobne procesy większość bazy kodu pozostała wspólna dla różnych usług. Wszystko poniżej kontrolerów zostało zunifikowane i znajdowało się w jednym repozytorium. Zastosowano wspólne metody usług, repozytoria i wspólną bazę danych zawierającą wspólne tabele.
Rozładunek trackera
Głównym problemem modułu śledzącego jest to, że dane muszą być synchronizowane pomiędzy różnymi bazami danych. Na tym też polega główna różnica w stosunku do podziału usługi Auth – zlecenie i jego status mogą się zmieniać i powinny być wyświetlane w różnych serwisach.
Przyjmujemy zamówienia w Kasie Restauracyjnej (jest to usługa), zapisywane są one w bazie danych w statusie „Przyjęte”. Następnie powinien trafić do trackera, gdzie jeszcze kilkukrotnie zmieni swój status: z „Kuchnia” na „Zapakowany”. W takim przypadku na zamówienie mogą wystąpić pewne wpływy zewnętrzne z interfejsu Kasjera lub Kierownika Zmiany. Statusy zamówień podam wraz z ich opisami w tabeli:
Schemat zmiany statusu zamówienia wygląda następująco:
Statusy zmieniają się pomiędzy różnymi systemami. I tutaj tracker nie jest ostatecznym systemem, w którym dane są zablokowane. Widzieliśmy kilka możliwych podejść do separacji w takim przypadku:
- Wszystkie działania związane ze zleceniami skupiamy w jednej usłudze. W naszym przypadku opcja ta wymaga zbyt dużej obsługi, aby móc zrealizować zamówienie. Gdybyśmy na tym poprzestali, otrzymalibyśmy drugi monolit. Nie rozwiązalibyśmy problemów.
- Jeden system łączy się z drugim. Druga opcja jest bardziej interesująca. Ale dzięki niemu możliwe są łańcuchy połączeń (), łączność komponentów jest większa i trudniejsza w zarządzaniu.
- Organizujemy wydarzenia, a poszczególne służby wymieniają się między sobą za pośrednictwem tych wydarzeń. W rezultacie wybrano opcję trzecią, zgodnie z którą wszystkie serwisy zaczynają wymieniać między sobą zdarzenia.
To, że wybraliśmy trzecią opcję oznaczało, że tracker miałby własną bazę danych, a przy każdej zmianie kolejności wysyłał o tym zdarzenie, do którego subskrybowałyby inne serwisy i które również znalazłoby się w bazie master. Do tego potrzebowaliśmy jakiejś usługi, która zapewniłaby dostarczanie wiadomości pomiędzy usługami.
W tym czasie mieliśmy już na stosie RabbitMQ, stąd ostateczna decyzja o wykorzystaniu go jako brokera komunikatów. Diagram przedstawia przejście zamówienia z Kasjera Restauracji przez Tracker, gdzie zmienia się jego status i sposób wyświetlania w interfejsie Zamówień Menedżera. STAĆ SIĘ:
Zamów ścieżkę krok po kroku
Ścieżka zamówienia rozpoczyna się w jednej z usług źródła zamówienia. Oto kasjer restauracji:
- Zamówienie jest już całkowicie gotowe w kasie i czas wysłać je do trackera. Zgłaszane jest zdarzenie, do którego subskrybowany jest moduł śledzący.
- Tracker przyjmując zamówienie zapisuje je we własnej bazie danych, tworząc zdarzenie „Zamówienie przyjęte przez Trackera” i wysyłając je do RMQ.
- Kilka procedur obsługi jest już subskrybowanych do niestandardowej magistrali zdarzeń. Dla nas ważny jest ten, który synchronizuje się z monolityczną bazą danych.
- Handler odbiera zdarzenie, wybiera z niego istotne dla niego dane: w naszym przypadku jest to status zamówienia „Zaakceptowane przez Tracker” i aktualizuje swoją encję zamówienia w głównej bazie danych.
Jeśli ktoś potrzebuje zamówienia konkretnie z tabeli zamówień monolitycznych, to też może je stamtąd odczytać. Na przykład tego właśnie potrzebuje interfejs Zamówienia w Menedżerze Zmiany:
Wszystkie inne usługi mogą również subskrybować zamawianie zdarzeń z modułu śledzącego, aby móc z nich korzystać dla siebie.
Jeśli po pewnym czasie zamówienie zostanie przyjęte do produkcji, najpierw zmienia się jego status w jego bazie danych (bazie Tracker), a następnie natychmiast generowane jest zdarzenie „OrderInWork”. Dostaje się także do RMQ, skąd jest synchronizowany w monolitycznej bazie danych i dostarczany do innych usług. Na tej drodze mogą pojawić się różne problemy, więcej szczegółów na ich temat można znaleźć w raporcie Żeńki Peszkowa .
Ostateczna architektura po zmianach w Auth i Trackerze
Podsumowując: Początkowo wpadłem na pomysł, aby w jednym artykule zebrać dziewięcioletnią historię systemu Dodo IS. Chciałem szybko i prosto opowiedzieć o etapach ewolucji. Jednak siadając do przestudiowania materiału, zdałem sobie sprawę, że wszystko jest o wiele bardziej złożone i interesujące, niż się wydaje.
Zastanawiając się nad zaletami (lub ich brakiem) takiego materiału, doszedłem do wniosku, że ciągły rozwój nie jest możliwy bez pełnoprawnych kronik wydarzeń, szczegółowych retrospektyw i analizy podjętych decyzji.
Mam nadzieję, że poznanie naszej podróży było dla Ciebie przydatne i interesujące. Teraz stoję przed wyborem, którą część systemu Dodo IS opisać w kolejnym artykule: pisać w komentarzach, czy głosować.
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
O której części Dodo IS chciałbyś dowiedzieć się w następnym artykule?
-
24,1%Wczesny monolit w Dodo IS (2011-2015)14
-
24,1%Pierwsze problemy i ich rozwiązania (2015-2016)14
-
20,7%Ścieżka części klienckiej: elewacja nad podstawą (2016-2017)12
-
36,2%Historia prawdziwych mikroserwisów (2018-2019)21
-
44,8%Zakończono rozcięcie monolitu i stabilizację architektury26
-
29,3%O dalszych planach rozwoju systemu17
-
19,0%Nie chcę nic wiedzieć o Dodo IS11
Głosowało 58 użytkowników. 6 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com