Dodo IS arhitektūras vēsture: Back Office Path

Habrs maina pasauli. Mēs esam rakstījuši emuārus vairāk nekā gadu. Apmēram pirms pusgada saņēmām diezgan loģiskas atsauksmes no Habrovskas iedzīvotājiem: “Dodo, tu visur saki, ka tev ir sava sistēma. Kāda veida sistēma šī ir? Un kāpēc picēriju ķēdei tas vajadzīgs?”

Mēs sēdējām un domājām un sapratām, ka jums ir taisnība. Mēģinām visu izskaidrot ar pirkstiem, bet tas iznāk gabalos un nekur nav pilns sistēmas apraksts. Tā sākās garš ceļojums, vākt informāciju, meklējot autorus un rakstot rakstu sēriju par Dodo IS. Ejam!

Pateicības: Paldies, ka dalījāties ar mums savās atsauksmēs. Pateicoties viņam, mēs beidzot aprakstījām sistēmu, sastādījām tehnoradaru un drīzumā izlaidīsim plašu mūsu procesu aprakstu. Bez jums mēs tā būtu sēdējuši vēl 5 gadus.

Rakstu sērija "Kas ir Dodo IS?" stāsta par:

1. Agrīnais monolīts Dodo IS (2011-2015). (Notiek darbs...)
2. Backoffice ceļš: atsevišķas bāzes un autobuss. (Tu esi šeit)
3. Klienta puses ceļš: fasāde virs pamatnes (2016-2017). (Notiek darbs...)
4. Īstu mikropakalpojumu vēsture. (2018-2019). (Notiek darbs...)
5. Pabeigta monolīta zāģēšana un arhitektūras stabilizācija. (Notiek darbs...)

Ja jūs interesē uzzināt kaut ko citu, rakstiet komentāros.

Autora viedoklis par hronoloģisko aprakstu
Regulāri rīkoju tikšanos jaunajiem darbiniekiem par tēmu “Sistēmas arhitektūra”. Mēs to saucam par “Ievads Dodo IS arhitektūrā”, un tā ir daļa no jauno izstrādātāju sagatavošanas procesa. Runājot vienā vai otrā veidā par mūsu arhitektūru, par tās iezīmēm, es izveidoju zināmu vēsturisku pieeju aprakstam.

Tradicionāli mēs aplūkojam sistēmu kā sastāvdaļu (tehnisku vai augstāka līmeņa) kopumu, biznesa moduļus, kas mijiedarbojas viens ar otru, lai sasniegtu kādu mērķi. Un, lai gan šāds skatījums ir pamatots dizainam, tas nav pilnībā piemērots aprakstam un izpratnei. Ir vairāki iemesli:

• Realitāte atšķiras no tā, kas ir uz papīra. Ne viss izdodas kā plānots. Un mēs esam ieinteresēti, kā viss patiesībā izrādījās un darbojas.
• Konsekventa informācijas sniegšana. Faktiski jūs varat pāriet hronoloģiski no sākuma līdz pašreizējam stāvoklim.
• No vienkārša līdz sarežģītam. Nav universāls, bet mūsu gadījumā tas tā ir. Arhitektūra pārcēlās no vienkāršākām pieejām uz sarežģītākām. Bieži vien sarežģījumu dēļ rodas ieviešanas ātruma un stabilitātes problēmas, kā arī desmitiem citu īpašību no nefunkcionālo prasību saraksta (šeit labi runāts par sarežģītības pretstatīšanu citām prasībām).

2011. gadā Dodo IS arhitektūra izskatījās šādi:

Līdz 2020. gadam tas kļuva nedaudz sarežģītāks un kļuva šāds:

Kā šī evolūcija notika? Kāpēc ir vajadzīgas dažādas sistēmas daļas? Kādi arhitektūras lēmumi tika pieņemti un kāpēc? To noskaidrosim šajā rakstu sērijā.

Pirmās 2016. gada problēmas: kāpēc dienestiem būtu jāatstāj monolīts?

Pirmie raksti sērijā būs par dienestiem, kas pirmie atdalījās no monolīta. Lai ieliktu jūs kontekstā, pastāstīšu, kādas problēmas mums bija sistēmā 2016. gada sākumā, ka bija jārisina pakalpojumu nodalīšana.

Viena MySql datu bāze, kurā ierakstīja visas lietojumprogrammas, kas tajā laikā pastāvēja Dodo IS. Sekas bija:

• Liela slodze (tiek nolasīti 85% pieprasījumu).
• Bāze auga. Šī iemesla dēļ izmaksas un atbalsts kļuva par problēmu.
• Viens neveiksmes punkts. Ja viena aplikācija, kas raksta datu bāzē, pēkšņi sāka to darīt aktīvāk, tad citas aplikācijas juta ietekmi.
• Uzglabāšanas un vaicājumu neefektivitāte. Bieži dati tika glabāti kādā struktūrā, kas bija ērta dažiem scenārijiem, bet ne citiem. Indeksi paātrina dažas darbības, bet var palēnināt citas.
• Dažas problēmas atrisināja steidzīgi izveidotās kešatmiņas un datubāzu lasīšanas-reprodukcijas (par to tiks runāts atsevišķā rakstā), taču tās ļāva mums tikai iegūt laiku un būtībā problēmu neatrisināja.

Problēma bija paša monolīta klātbūtne. Sekas bija:

• Unikāli un reti izlaidumi.
• Grūtības ir liela cilvēku skaita kopīgā attīstībā.
• Nespēja ieviest jaunas tehnoloģijas, jaunus ietvarus un bibliotēkas.

Problēmas ar bāzi un monolītu ir aprakstītas daudzkārt, piemēram, saistībā ar avārijām 2018. gada sākumā (Esiet kā Munks vai daži vārdi par tehnisko parādu, Diena, kad Dodo IS apstājās. Asinhronais skripts и Stāsts par Dodo putnu no Fēniksu ģimenes. Lielais Dodo kritiens IR), tāpēc es pārāk daudz nekavēšos. Ļaujiet man tikai teikt, ka mēs vēlējāmies sniegt lielāku elastību, izstrādājot pakalpojumus. Pirmkārt, tas attiecās uz tiem, kas bija visvairāk ielādēti un saknes visā sistēmā - Auth un Tracker.

Back Office ceļš: atsevišķas bāzes un autobuss

Nodaļa Navigācija

1. Monolīta shēma 2016
2. Mēs sākam izkraut monolītu: Auth un Tracker atdalīšana
   
3. Ko dara Auth?
4. No kurienes nāk slodzes?
5. Izkraušana Auth
6. Ko dara Tracker?
7. No kurienes nāk slodzes?
8. Tracker izkraušana

Monolīta shēma 2016

Šeit ir norādīti 2016. gada Dodo IS monolīta galvenie bloki, un tieši zemāk ir sniegts to galveno uzdevumu sadalījums.

Piegādes kase. Kurjeru uzskaite, pasūtījumu izsniegšana kurjeriem.
Kontaktu centrs. Pasūtījumu pieņemšana ar operatora starpniecību.
Vietne. Mūsu tīmekļa vietnes (dodopizza.ru, dodopizza.co.uk, dodopizza.by utt.).
Auth. Autorizācijas un autentifikācijas pakalpojums backoffice.
Tracker. Virtuves pasūtījumu izsekotājs. Pakalpojums gatavības statusu atzīmēšanai, sagatavojot pasūtījumu.
Restorāna kase. Pasūtījumu pieņemšana restorānā, kases saskarnes.
Eksportēt. Pārskatu augšupielāde 1C formātā grāmatvedībai.
Brīdinājumi un rēķini. Balss komandas virtuvē (piemēram, “Pienākusi jauna pica”) + kurjeru rēķinu drukāšana.
Maiņu vadītājs. Saskarnes maiņas vadītāja darbam: pasūtījumu saraksts, produktivitātes diagrammas, darbinieku ievešana uz maiņām.
Ofisa menedžeris. Saskarnes franšīzes ņēmēju un vadītāju darbam: darbinieku pieņemšana, atskaites par picērijas darbu.
Restorāna valde. Izvēlņu parādīšana televizoros picērijās.
Administrators. Konkrētas picērijas iestatījumi: ēdienkarte, cenas, uzskaite, reklāmas kodi, akcijas, vietnes baneri utt.
Darbinieka personīgais konts. Darbinieku darba grafiki, informācija par darbiniekiem.
Virtuves motivācijas padome. Atsevišķs ekrāns, kas karājas virtuvē un parāda picu gatavotāju ātrumu.
Sakari. SMS un e-pasta sūtīšana.
Failu krātuve. Savs pakalpojums statisku failu saņemšanai un izdošanai.

Pirmie mēģinājumi risināt problēmas mums palīdzēja, taču tie bija tikai īslaicīga atelpa. Tie nekļuva par sistēmas risinājumiem, tāpēc bija skaidrs, ka ar bāzēm kaut kas ir jādara. Piemēram, sadaliet vispārējo datu bāzi vairākās specializētākās.

Mēs sākam izkraut monolītu: Auth un Tracker atdalīšana

Galvenie pakalpojumi, kas pēc tam rakstīja un lasīja no datu bāzes vairāk nekā citi:

1. Auth. Autorizācijas un autentifikācijas pakalpojums backoffice.
2. Izsekotājs. Virtuves pasūtījumu izsekotājs. Pakalpojums gatavības statusu atzīmēšanai, sagatavojot pasūtījumu.

Ko dara Auth?

Auth ir pakalpojums, ar kura palīdzību lietotāji piesakās back office (klienta pusē ir atsevišķa neatkarīga pieteikšanās). Uz to ir arī atsauce pieprasījumā, lai nodrošinātu, ka ir pareizās piekļuves tiesības un vai šīs tiesības nav mainījušās kopš pēdējās pieteikšanās. Caur to ierīces iekļūst picērijās.

Piemēram, mēs vēlamies atvērt displeju ar izpildīto pasūtījumu statusu uz televizora, kas karājas zālē. Pēc tam atveram auth.dodopizza.ru, atlasiet “Pieteikties kā ierīce”, parādās kods, kuru var ievadīt speciālā maiņas vadītāja datora lapā, norādot ierīces (ierīces) veidu. Pats televizors pāries uz vēlamo savas picērijas saskarni un sāks tur rādīt to klientu vārdus, kuru pasūtījumi ir gatavi.

No kurienes nāk slodzes?

Katrs pieteicies backoffice lietotājs pēc katra pieprasījuma dodas uz datu bāzi, uz lietotāju tabulu, izvelk lietotāju no turienes caur sql vaicājumu un pārbauda, ​​vai viņam ir vajadzīgā piekļuve un tiesības šai lapai.

Katra no ierīcēm to pašu dara tikai ar ierīču tabulu, pārbaudot savu lomu un piekļuves. Liels skaits pieprasījumu galvenajai datubāzei noved pie tās ielādes un vispārējo datu bāzes resursu izšķērdēšanas šīm darbībām.

Izkraušana Auth

Auth ir izolēts domēns, tas ir, dati par lietotājiem, pieteikumvārdiem vai ierīcēm tiek ievadīti pakalpojumā (šobrīd nākotnē) un tur paliek. Ja kādam tie būs nepieciešami, viņš dosies uz šo servisu pēc datiem.

TAS BIJA. Darba gaita sākotnēji bija šāda:

Es gribētu nedaudz paskaidrot, kā tas darbojās:

1. Ārējais pieprasījums tiek nosūtīts uz aizmugursistēmu (tur Asp.Net MVC), līdzi nesot sesijas sīkfailu, kas tiek izmantots, lai iegūtu sesijas datus no Redis(1). Tajā ir informācija par pieejām, un tad piekļuve kontrollerim ir atvērta (3,4), vai nav.
2. Ja nav piekļuves, jums ir jāiziet autorizācijas procedūra. Šeit vienkāršības labad tas tiek parādīts kā daļa no ceļa tajā pašā atribūtā, lai gan šī ir pāreja uz pieteikšanās lapu. Pozitīva scenārija gadījumā mēs saņemsim pareizi aizpildītu sesiju un dosimies uz Backoffice Controller.
3. Ja ir dati, jums ir jāpārbauda to atbilstība lietotāju datu bāzē. Vai viņa loma ir mainījusies, vai viņu tagad nevajadzētu ielaist lapā? Šajā gadījumā pēc sesijas saņemšanas (1) jums tieši jāiet uz datu bāzi un jāpārbauda lietotāja piekļuve, izmantojot autentifikācijas loģikas slāni (2). Pēc tam dodieties uz pieteikšanās lapu vai pārejiet uz kontrolieri. Šī ir vienkārša sistēma, bet ne pilnībā standarta.
4. Ja visas procedūras ir pabeigtas, mēs izlaižam tālāk loģikā kontrolieros un metodēs.

Lietotāja dati ir atdalīti no visiem citiem datiem, tie tiek glabāti atsevišķā dalības tabulā, funkcijas no AuthService loģikas slāņa var kļūt par API metodēm. Domēna robežas ir noteiktas diezgan skaidri: lietotāji, viņu lomas, piekļuves dati, piekļuves izsniegšana un atsaukšana. Izskatās, ka visu varētu pārvietot uz atsevišķu servisu.

KĻUVA. To viņi darīja:

Šai pieejai ir vairākas problēmas. Piemēram, metodes izsaukšana procesā nav tas pats, kas ārējā pakalpojuma izsaukšana, izmantojot http. Operācijas latentums, uzticamība, atbalstāmība un caurspīdīgums ir pilnīgi atšķirīgi. Andrejs Morevskis savā ziņojumā sīkāk runāja tieši par šīm problēmām "50 mikropakalpojumu nokrāsas".

Autentifikācijas pakalpojums un līdz ar to arī ierīces pakalpojums tiek izmantots back office, tas ir, ražošanā izmantotajiem pakalpojumiem un saskarnēm. Klientu pakalpojumu (piemēram, tīmekļa vietnes vai mobilās lietojumprogrammas) autentifikācija notiek atsevišķi, neizmantojot autentifikāciju. Atdalīšana ilga apmēram gadu, un tagad mēs atkal strādājam pie šīs tēmas, pārceļot sistēmu uz jauniem autentifikācijas pakalpojumiem (ar standarta protokoliem).

Kāpēc šķiršanās prasīja tik ilgu laiku?
Ceļā radās daudzas problēmas, kas mūs palēnināja:

1. Mēs vēlējāmies pārsūtīt datus par lietotājiem, ierīcēm un autentifikāciju no valstu datu bāzēm vienā. Lai to izdarītu, mums bija jāpārnes visas tabulas un lietojums no int identifikatora uz globālo UUId identifikatoru (mēs nesen pārstrādājām šo kodu Romāns Bukins "Uuid - mazas struktūras lielais stāsts" un atvērtā koda projekts Primitīvie). Lietotāja datu glabāšanai (jo tā ir personiska informācija) ir ierobežojumi, un dažās valstīs tie ir jāuzglabā atsevišķi. Bet ir jābūt globālam lietotāja ID.
2. Daudzās datubāzes tabulās ir audita informācija par lietotāju, kurš veica darbību. Tam bija nepieciešams papildu mehānisms, lai nodrošinātu konsekvenci.
3. Pēc API pakalpojumu izveides ilga un pakāpeniska pāreja uz citu sistēmu. Pārslēgšanai bija jānotiek lietotājiem nemanāmi, un bija nepieciešams manuāls darbs.

Shēma ierīces reģistrēšanai picērijā:

Vispārējā arhitektūra pēc pakalpojuma Auth un Devices atdalīšanas:

Piezīme. 2020. gadam mēs strādājam pie jaunas Auth versijas, kuras pamatā ir OAuth 2.0 autorizācijas standarts. Šis standarts ir diezgan sarežģīts, taču noderīgs pilnīgas autentifikācijas pakalpojuma izstrādei. Rakstā "Autorizācijas smalkumi: OAuth 2.0 tehnoloģijas pārskats» mēs, Aleksejs Čerņajevs, centāmies runāt par standartu pēc iespējas vienkāršāk un skaidrāk, lai jūs ietaupītu laiku tā apguvei.

Ko dara Tracker?

Tagad par otro no ielādētajiem pakalpojumiem. Izsekotājs veic dubultu lomu:

• No vienas puses, tā uzdevums ir parādīt darbiniekiem virtuvē, kādi pasūtījumi šobrīd ir procesā, kādi produkti ir jāsagatavo tagad.
• No otras puses, digitalizēt visus procesus virtuvē.

Kad pasūtījumā parādās jauns produkts (piemēram, pica), tas nonāk izsekošanas stacijā “Ripošana”. Šajā stacijā atrodas picu taisītājs, kurš paņem vajadzīgā izmēra bulciņu un izrullē, pēc tam uz tracker planšetes atzīmē, ka ir izpildījis savu uzdevumu un nodod izrullēto mīklas pamatni nākamajai stacijai - “Pildījums” .

Tur nākamais picas taisītājs uzliek picu virsū, pēc tam atzīmē planšetdatorā, ka ir izpildījis savu uzdevumu un ieliek picu cepeškrāsnī (šī arī ir atsevišķa stacija, kas jāatzīmē planšetdatorā). Šāda sistēma pastāvēja no paša sākuma Dodo un no pašiem Dodo IS pirmsākumiem. Tas ļauj pilnībā izsekot un digitalizēt visas darbības. Turklāt izsekotājs iesaka, kā sagatavot konkrēto produktu, veic katru produkta veidu pēc savām ražošanas shēmām, saglabā produkta optimālo gatavošanas laiku un izseko visas darbības ar produktu.

Šādi izskatās planšetdatora ekrāns Raskatkas izsekotāju stacijā.

No kurienes nāk slodzes?

Katrā picērijā ir apmēram piecas tabletes ar izsekotāju. 2016. gadā mums bija vairāk nekā 100 picērijas (un šobrīd jau ir vairāk nekā 600). Katrs planšetdators ik pēc 10 sekundēm veic pieprasījumu aizmugursistēmai un apkopo datus no pasūtījumu tabulas (saite ar klientu un adresi), pasūtījuma sastāva (saite ar produktu un daudzuma norāde) un motivācijas tabulas (tā izseko nospiešanas laiks). Kad picas izgatavotājs noklikšķina uz produkta izsekotājs, ieraksti visās šajās tabulās tiek atjaunināti. Pasūtījumu tabula ir vispārīga, tajā vienlaikus ir ievietojumi, pieņemot pasūtījumu, atjauninājumi no citām sistēmas daļām un daudzi rādījumi, piemēram, televizorā, kas karājas picērijā un rāda klientiem gatavus pasūtījumus.

Cīņas ar slodzēm periodā, kad viss un visi tika saglabāti kešatmiņā un pārsūtīti uz asinhrono datu bāzes kopiju, šīs darbības ar izsekotāju turpināja pāriet uz galveno datu bāzi. Šeit nedrīkst būt kavēšanās, datiem ir jābūt atjauninātiem, sinhronizācija ir nepieņemama.

Arī mūsu pašu tabulu un indeksu trūkums neļāva mums uzrakstīt specifiskākus vaicājumus, kas pielāgoti mūsu lietošanai. Piemēram, izsekotāja pasūtījumu tabulā varētu būt picērijas rādītājs. Picēriju pasūtījumus mēs vienmēr izņemam no tracker datu bāzes. Tajā pašā laikā, lai pieņemtu pasūtījumu, nav tik svarīgi, kurā picērijā tas nonāk, svarīgāk ir tas, kurš klients veica šo pasūtījumu. Tas nozīmē, ka klientam ir jābūt indeksam. Tāpat nav nepieciešams, lai izsekotājs pasūtījumu tabulā saglabātu ar pasūtījumu saistītās izdrukātās kvīts id vai bonusa akcijas. Mūsu izsekotāju pakalpojumu šī informācija neinteresē. Kopējā monolītā datu bāzē tabulas varētu būt tikai kompromiss starp visiem lietotājiem. Šī bija viena no sākotnējām problēmām.

TAS BIJA. Sākotnēji arhitektūra bija šāda:

Pat pēc sadalīšanas atsevišķos procesos lielākā daļa koda bāzes palika kopīga dažādiem pakalpojumiem. Viss, kas atrodas zem kontrolieriem, bija vienots un dzīvoja vienā repozitorijā. Tika izmantotas kopīgas pakalpojumu metodes, repozitoriji un kopēja datu bāze, kurā ir kopīgas tabulas.

Tracker izkraušana

Galvenā izsekotāja problēma ir tā, ka dati ir jāsinhronizē starp dažādām datu bāzēm. Tā arī ir tā galvenā atšķirība no Auth pakalpojuma sadalījuma – pasūtījums un tā statuss var mainīties un ir jāparāda dažādos servisos.

Mēs pieņemam pasūtījumus Restorāna kasē (tas ir pakalpojums), tas tiek saglabāts datu bāzē statusā “Pieņemts”. Pēc tam tam vajadzētu doties uz izsekotāju, kur tas vēl vairākas reizes mainīs savu statusu: no “Virtuve” uz “Iesaiņots”. Šādā gadījumā ar pasūtījumu var rasties kāda ārēja ietekme no Kases vai Shift Manager saskarnes. Pasūtījumu statusus ar to aprakstiem norādīšu tabulā:

Pasūtījuma statusa maiņas shēma izskatās šādi:

Statusi mainās starp dažādām sistēmām. Un šeit izsekotājs nav galīgā sistēma, kurā dati ir bloķēti. Mēs esam redzējuši vairākas iespējamās atdalīšanas pieejas šādā gadījumā:

1. Mēs koncentrējam visas pasūtījuma darbības vienā pakalpojumā. Mūsu gadījumā šī opcija prasa pārāk daudz pakalpojumu, lai apstrādātu pasūtījumu. Ja mēs būtu tur apstājušies, mēs būtu ieguvuši otru monolītu. Mēs nebūtu atrisinājuši problēmas.
2. Viena sistēma zvana citai sistēmai. Otrais variants ir interesantāks. Bet ar to ir iespējamas zvanu ķēdes (kaskādes kļūmes), komponentu savienojamība ir augstāka, un to ir grūtāk pārvaldīt.
3. Mēs organizējam pasākumus, un katrs dienests apmainās ar otru, izmantojot šos pasākumus. Rezultātā tika izvēlēta trešā iespēja, saskaņā ar kuru visi dienesti sāk apmainīties ar notikumiem savā starpā.

Tas, ka izvēlējāmies trešo variantu, nozīmēja, ka izsekotājam būs sava datu bāze, un par katru pasūtījuma izmaiņu tas nosūtīs par to notikumu, uz kuru abonēs citus pakalpojumus un kuri arī tiks iekļauti galvenajā datubāzē. Lai to izdarītu, mums bija nepieciešams pakalpojums, kas nodrošinātu ziņojumu piegādi starp pakalpojumiem.

Līdz tam laikam mums jau bija RabbitMQ kaudzē, tāpēc tika pieņemts galīgais lēmums to izmantot kā ziņojumu brokeri. Diagramma parāda pasūtījuma pāreju no restorāna kases caur Tracker, kur tas maina tā statusu un tā rādīšanu pārvaldnieka pasūtījumu saskarnē. KĻUVA:

Pasūtīšanas ceļš soli pa solim
Pasūtījuma ceļš sākas vienā no pasūtījuma avota pakalpojumiem. Šeit ir restorāna kasiere:

1. Pasūtījums ir pilnībā gatavs kasē, un ir pienācis laiks to nosūtīt uz izsekotāju. Tiek izmests notikums, kuram ir abonēts izsekotājs.
2. Izsekotājs, pieņemot pasūtījumu, saglabā to savā datu bāzē, veicot notikumu “Pasūtījums pieņemts ar izsekotāju” un nosūtot to uz RMQ.
3. Vairāki apstrādātāji jau ir abonējuši pielāgoto notikumu kopni. Mums svarīgs ir tas, kas sinhronizējas ar monolīto datu bāzi.
4. Apdarinātājs saņem notikumu, atlasa no tā tam nozīmīgos datus: mūsu gadījumā tas ir pasūtījuma statuss “Pieņemts Tracker” un atjaunina savu pasūtījuma entītiju galvenajā datu bāzē.

Ja kādam ir nepieciešams pasūtījums tieši no monolītās pasūtījumu tabulas, tad to var izlasīt arī no turienes. Piemēram, Shift Manager saskarnei Pasūtījumi ir nepieciešams:

Visi citi pakalpojumi var arī abonēt notikumu pasūtīšanu no izsekotāja, lai tos izmantotu paši.

Ja pēc kāda laika pasūtījums tiek nodots ražošanā, tā statuss vispirms mainās tā datu bāzē (Tracker datu bāzē), un pēc tam nekavējoties tiek ģenerēts notikums “OrderInWork”. Tas arī nokļūst RMQ, no kurienes tas tiek sinhronizēts monolītā datu bāzē un piegādāts citiem pakalpojumiem. Šajā ceļā var rasties dažādas problēmas; sīkāku informāciju par tām var atrast Ženijas Peškovas ziņojumā par iespējamās konsekvences ieviešanas informāciju programmā Tracker.

Galīgā arhitektūra pēc izmaiņām Auth un Tracker

Apkopot: Sākotnēji man radās doma Dodo IS sistēmas deviņu gadu vēsturi apkopot vienā rakstā. Es gribēju ātri un vienkārši runāt par evolūcijas posmiem. Taču, apsēdusies pētīt materiālu, sapratu, ka viss ir daudz sarežģītāk un interesantāk, nekā šķiet.

Pārdomājot šāda materiāla ieguvumus (vai to trūkumu), nonācu pie secinājuma, ka nepārtraukta attīstība nav iespējama bez pilnvērtīgām notikumu hronikām, detalizētām retrospekcijām un pagātnes lēmumu analīzes.

Ceru, ka jums bija noderīgi un interesanti uzzināt par mūsu ceļojumu. Tagad esmu izvēles priekšā, kuru Dodo IS sistēmas daļu aprakstīt nākamajā rakstā: rakstiet komentāros vai balsojiet.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Par kādu Dodo IS daļu jūs vēlētos uzzināt nākamajā rakstā?

• 24,1%Agrīnais monolīts Dodo IS (2011-2015)14

• 24,1%Pirmās problēmas un to risinājumi (2015-2016)14

• 20,7%Pasūtītāja daļas ceļš: fasāde virs pamatnes (2016-2017)12

• 36,2%Reālu mikropakalpojumu vēsture (2018-2019)21

• 44,8%Pabeigta monolīta griešana un arhitektūras stabilizācija26

• 29,3%Par turpmākajiem sistēmas attīstības plāniem17

• 19,0%Es nevēlos neko zināt par Dodo IS11

Nobalsoja 58 lietotāji. 6 lietotāji atturējās.

Avots: www.habr.com