{"id":95786,"date":"2020-10-03T13:42:12","date_gmt":"2020-10-03T11:42:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/istoriya-arhitektury-dodo-is-put-bekofisa"},"modified":"2020-10-03T13:42:12","modified_gmt":"2020-10-03T11:42:12","slug":"istoriya-arhitektury-dodo-is-put-bekofisa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/istoriya-arhitektury-dodo-is-put-bekofisa","title":{"rendered":"Storia dell'architettura Dodo IS: il percorso del back office","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Habr sta cambiando il mondo. Da oltre un anno gestiamo il nostro blog. Circa sei mesi fa abbiamo ricevuto un feedback piuttosto logico dai lettori di Habr: \u00abDodo, voi dite sempre che avete il vostro sistema. Ma che tipo di sistema \u00e8? E a cosa serve per una catena di pizzerie?\u00bb. <\/p>\n<p>Ci siamo seduti, abbiamo riflettuto e capito che avevate ragione. Cerchiamo di spiegare tutto in modo semplice, ma ci\u00f2 risulta fragmentario e non c'\u00e8 una descrizione completa del sistema. Cos\u00ec \u00e8 iniziato un lungo percorso di raccolta di informazioni, ricerca di autori e scrittura di una serie di articoli su Dodo IS. Andiamo!<\/p>\n<blockquote><p><i>Ringraziamenti: grazie per condividere il vostro feedback con noi. Grazie a esso, siamo finalmente riusciti a descrivere il sistema, abbiamo creato un technoradar e presto pubblicheremo una descrizione completa dei nostri processi. Senza di voi saremmo stati fermi per altri 5 anni. <\/i><\/p><\/blockquote>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/dcfd06b2ec1544e1e19994d60e9594ac.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<blockquote><p><b>La serie di articoli \u00abCosa \u00e8 Dodo IS?\u00bb parler\u00e0 di:<\/b><\/p>\n<ol>\n<li>Monolite iniziale in Dodo IS (2011-2015). (In corso...)<\/li>\n<li>Il percorso del back office: database separati e bus. (Sei qui)<\/li>\n<li>Percorso del frontend: facciata sopra il database (2016-2017). (In corso...)<\/li>\n<li>Storia dei veri microservizi. (2018-2019). (In corso...)<\/li>\n<li>Divisione completata del monolite e stabilizzazione dell'architettura. (In corso...)<\/li>\n<\/ol>\n<p>\n<b>Se sei interessato a scoprire qualcos'altro, scrivi nei commenti. <\/b><\/p><\/blockquote>\n<p><\/p>\n<p>                        <b class=\"spoiler_title\">Opinione sull'esposizione cronologica da parte dell'autore<\/b><br \/>\n                        Regolarmente tengo incontri per i nuovi dipendenti sul tema \u00abArchitettura del sistema\u00bb. Da noi si chiama \u00abIntroduzione all'Architettura di Dodo IS\u00bb ed \u00e8 parte del processo di onboarding per i nuovi sviluppatori. Raccontando in un modo o nell'altro della nostra architettura e delle sue peculiarit\u00e0, ho sviluppato un approccio storico per la descrizione. <\/p>\n<p>Tradizionalmente, guardiamo al sistema come un insieme di componenti (tecnici o di livello pi\u00f9 elevato), moduli aziendali che interagiscono tra loro per raggiungere un determinato obiettivo. E se per la progettazione questo punto di vista \u00e8 giustificato, per la descrizione e comprensione non \u00e8 del tutto adeguato. Le ragioni sono diverse:<\/p>\n<ul>\n<li>La realt\u00e0 \u00e8 diversa da quella scritta su carta. Non tutto ci\u00f2 che era previsto si realizza. E a noi interessa come sia effettivamente il tutto e come funzioni. <\/li>\n<li>Esposizione sequenziale delle informazioni. In sostanza, \u00e8 possibile procedere cronologicamente dall'inizio fino allo stato attuale. <\/li>\n<li>Dal semplice al complesso. Non \u00e8 universale, ma nel nostro caso funziona proprio cos\u00ec. Da approcci pi\u00f9 semplici, l'architettura \u00e8 passata a modelli pi\u00f9 complessi. Spesso attraverso la complicazione si risolvevano problemi di velocit\u00e0 di implementazione e stabilit\u00e0, cos\u00ec come decine di altre caratteristiche della lista dei requisiti non funzionali (<noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=6m4XPje76WU\">qui<\/a><\/noindex> ben raccontato il contrasto tra complessit\u00e0 e altri requisiti).<\/li>\n<\/ul>\n<p>Nel 2011, l'architettura di Dodo IS appariva cos\u00ec:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/3f447154d2d7e7323806f11aeec88e98.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Entro il 2020 si \u00e8 leggermente complicata e ha assunto questa forma:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/407b5fead36d6d6d39ab14ea5edcdd5b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCome \u00e8 avvenuta questa evoluzione? A cosa servono le diverse parti del sistema? Quali soluzioni architettoniche sono state adottate e perch\u00e9? Approfondiremo in questa serie di articoli. <\/p>\n<h2>I primi problemi del 2016: perch\u00e9 i servizi devono uscire dal monolite<\/h2>\n<p>\nI primi articoli del ciclo riguarderanno i servizi che si sono staccati per primi dal monolite. Per introdurvi nel contesto, parler\u00f2 dei problemi che avevamo nel sistema all'inizio del 2016 e di cosa abbiamo dovuto fare per separare i servizi.<\/p>\n<p><b>Un'unica base MySql, in cui tutti le applicazioni esistenti al momento in Dodo IS scrivevano le loro registrazioni.<\/b> Le conseguenze furono le seguenti:<\/p>\n<ul>\n<li>Carico elevato (85% delle richieste erano per letture). <\/li>\n<li>Il database si espandeva. Di conseguenza, il suo costo e la sua manutenzione diventavano un problema.<\/li>\n<li>Unico punto di fallimento. Se un'applicazione che scriveva nel database iniziava a farlo improvvisamente in modo pi\u00f9 intensivo, le altre applicazioni ne sentivano gli effetti.<\/li>\n<li>Inefficienza nella memorizzazione e nelle richieste. Spesso i dati erano conservati in una certa struttura, che era comoda per alcuni scenari, ma non si adattava ad altri. Gli indici acceleravano alcune operazioni, ma potevano rallentare altre.<\/li>\n<li>Alcuni problemi sono stati alleviati con cache e read-replicas del database fatti in fretta (ne parler\u00f2 in un articolo separato), ma questi hanno solo permesso di guadagnare tempo e non risolvevano il problema in modo fondamentale.<\/li>\n<\/ul>\n<p>\n<b>Il problema era la presenza stessa del monolite<\/b>. Le conseguenze furono le seguenti:<\/p>\n<ul>\n<li>Rilasci unici e rari.<\/li>\n<li>Difficolt\u00e0 nella collaborazione di un gran numero di persone.<\/li>\n<li>Impossibilit\u00e0 di introdurre nuove tecnologie, nuovi framework e librerie. <\/li>\n<\/ul>\n<p>\nProblemi con il database e il monolite sono stati descritti pi\u00f9 volte, ad esempio, nel contesto dei crash all'inizio del 2018 (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzadev\/blog\/455264\/\">Sii come Munk, o qualche parola sul debito tecnico<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzadev\/blog\/461081\/\">Il giorno in cui Dodo IS si \u00e8 fermata. Scenari asincroni<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzadev\/blog\/498280\/\">La storia dell'uccello Dodo della famiglia dei Fenici. La grande caduta di Dodo IS<\/a><\/noindex>), quindi non mi soffermer\u00f2 ulteriormente. Dir\u00f2 solo che volevamo offrire una maggiore flessibilit\u00e0 nello sviluppo dei servizi. Questo riguardava soprattutto quelli che erano i pi\u00f9 carichi e fondamentali in tutto il sistema: Auth e Tracker.<\/p>\n<h2>Il percorso del back office: database separati e bus<\/h2>\n<p><\/p>\n<blockquote><p><b>Navigazione nel capitolo<\/b><\/p>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"#Q0\">Schema del monolite del 2016<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#Q1\">Iniziamo a ridurre il carico del monolite: separazione di Auth e Tracker<br \/>\n<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#Q2\">Cosa fa Auth<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#Q3\">Da dove proviene il carico?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#Q4\">Riduciamo il carico da Auth<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#Q5\">Cosa fa Tracker<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#Q6\">Da dove proviene il carico?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#Q4\">Riduciamo il carico da Tracker<\/a><\/noindex><\/li>\n<\/ol>\n<\/blockquote>\n<p>\n<noindex><a rel=\"nofollow\" name=\"Q0\"><\/a><\/noindex><\/p>\n<h4>Schema del monolite del 2016<\/h4>\n<p>\nDi fronte a voi ci sono i principali blocchi del monolite Dodo IS del 2016, e qui sotto la spiegazione delle loro principali funzioni. <br \/>\n<img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/25ae104d94957aebbbab6d54ebb62f5e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Cassa Consegna.<\/b> Gestione dei corrieri, rilascio degli ordini ai corrieri.<br \/>\n<b>Centro Contatto<\/b>. Accettazione degli ordini tramite operatore. <br \/>\n<b>Sito<\/b>. I nostri siti (dodopizza.ru, dodopizza.co.uk, dodopizza.by ecc.).<br \/>\n<b>Auth<\/b>. Servizio di autorizzazione e autenticazione per il back office.<br \/>\n<b>Tracker<\/b>. Tracker degli ordini in cucina. Servizio di segnalazione degli stati di preparazione durante la preparazione dell'ordine. <br \/>\n<b>Cassa Ristorante<\/b>. Accettazione degli ordini nel ristorante, interfacce per il cassiere.<br \/>\n<b>Export<\/b>. Esportazione dei rapporti in 1C per la contabilit\u00e0.<br \/>\n<b>Notifiche e bolle<\/b>. Comandi vocali in cucina (ad esempio, \u00ab\u00c8 arrivata una nuova pizza\u00bb) + stampa delle bolle per i corrieri.<br \/>\n<b>Manager Turno<\/b>. Interfacce per il lavoro del manager di turno: elenco degli ordini, grafici di produttivit\u00e0, assegnazione del personale per il turno. <br \/>\n<b>Manager Ufficio<\/b>. Interfacce per il lavoro dei franchisor e del manager: assunzione del personale, rapporti sull'attivit\u00e0 della pizzeria.<br \/>\n<b>Tabellone Ristorante<\/b>. Visualizzazione del menu sui televisori nelle pizzerie.<br \/>\n<b>Admin<\/b>. Impostazioni specifiche per la pizzeria: menu, prezzi, gestione, codici promozionali, offerte, banner per il sito, ecc.<br \/>\n<b>Area Personale Dipendente<\/b>. Grafici di lavoro dei dipendenti, informazioni sui dipendenti.<br \/>\n<b>Tabellone Motivazione Cucina<\/b>. Schermo separato, appeso in cucina, che mostra la velocit\u00e0 di lavoro dei pizzaioli.<br \/>\n<b>Comunicazione<\/b>. Invio di sms e email.<br \/>\n<b>FileStorage<\/b>. Servizio proprietario per la ricezione e il rilascio di file statici.<\/p>\n<p>I primi tentativi di risolvere i problemi ci hanno aiutato, ma sono stati solo una pausa temporanea. Non sono diventati soluzioni sistemiche, quindi era chiaro che era necessario fare qualcosa con i database. Ad esempio, separare il database comune in pi\u00f9 database specializzati. <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"Q1\"><\/a><\/noindex><\/p>\n<h4>Iniziamo a ridurre il carico del monolite: separazione di Auth e Tracker<\/h4>\n<p>\nI principali servizi che all'epoca registravano e leggevano di pi\u00f9 dal database:<\/p>\n<ol>\n<li>Auth. Servizio di autorizzazione e autenticazione per il back office.<\/li>\n<li>Tracker. Tracker degli ordini in cucina. Servizio di segnalazione degli stati di preparazione durante la preparazione dell'ordine. <\/li>\n<\/ol>\n<p>\n<noindex><a rel=\"nofollow\" name=\"Q2\"><\/a><\/noindex><\/p>\n<h4>Cosa fa Auth<\/h4>\n<p>\nAuth \u00e8 il servizio attraverso il quale gli utenti accedono al back office (nella parte cliente c'\u00e8 un accesso separato e indipendente). Viene anche utilizzato per verificare che siano presenti i diritti di accesso necessari e che questi diritti non siano cambiati dall'ultimo accesso. Attraverso di esso avviene anche l'accesso dei dispositivi nelle pizzerie. <\/p>\n<p>Ad esempio, vogliamo aprire sul televisore appeso in sala un display con gli stati degli ordini pronti. Quindi apriamo auth.dodopizza.ru, selezioniamo \"Accesso come dispositivo\", appare un codice che pu\u00f2 essere inserito in una pagina speciale sul computer del manager di turno, specificando il tipo di dispositivo. Il televisore passer\u00e0 automaticamente all'interfaccia della propria pizzeria e inizier\u00e0 a visualizzare i nomi dei clienti i cui ordini sono pronti. <\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/7a246bcbdbf0dcd6af3e21eb1645e9ac.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"Q3\"><\/a><\/noindex><\/p>\n<h4>Da dove proviene il carico? <\/h4>\n<p>\nOgni utente autenticato del back office, per ogni richiesta, accede al database, estrae l'utente dalla tabella utenti tramite una query SQL e controlla se ha i necessari accessi e diritti per quella pagina. <\/p>\n<p>Ogni dispositivo fa lo stesso, verificando il proprio ruolo e i propri accessi con la tabella dei dispositivi. Un gran numero di richieste al master database porta al suo sovraccarico e al consumo di risorse del database generale per queste operazioni.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"Q4\"><\/a><\/noindex><\/p>\n<h4>Riduciamo il carico da Auth<\/h4>\n<p>\nAuth ha un dominio isolato, cio\u00e8 i dati sugli utenti, login o dispositivi vengono inviati al servizio (futuro) e l\u00ec rimangono. Se qualcuno ne avr\u00e0 bisogno, andr\u00e0 a quel servizio per i dati.<\/p>\n<p><b>C'ERA.<\/b> Il processo di lavoro inizialmente era il seguente:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/60ca37fb873cb4fff4a30691e9f1ea56.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoglio chiarire un po' come funzionava:<\/p>\n<ol>\n<li>Una richiesta esterna arriva al backend (l\u00ec c'\u00e8 Asp.Net MVC), portando con s\u00e9 un cookie di sessione, che viene utilizzato per ottenere i dati di sessione da Redis(1). Qui c'\u00e8 o meno informazione sugli accessi, e se c'\u00e8, l'accesso al controller \u00e8 aperto (3,4), altrimenti no. <\/li>\n<li>Se non ci sono accessi, \u00e8 necessario superare la procedura di autorizzazione. Qui, per semplificare, viene mostrata come parte del percorso nello stesso attributo, anche se si tratta di un passaggio alla pagina di login. In caso di scenario positivo, riceveremo una sessione correttamente compilata e passeremo al Backoffice Controller. <\/li>\n<li>Se i dati sono presenti, \u00e8 necessario verificarne l'attualit\u00e0 nel database utente. \u00c8 cambiato il suo ruolo? Potrebbe non aver accesso ora a quella pagina. In questo caso, dopo aver ricevuto la sessione (1), \u00e8 necessario accedere direttamente al database e verificare gli accessi dell'utente tramite il livello logico di autenticazione (2). Successivamente, si passa o alla pagina di login o al controllo del controller. \u00c8 un sistema piuttosto semplice, ma non del tutto standard.<\/li>\n<li>Se tutte le procedure sono state completate, proseguiamo nella logica nei controller e nei metodi. <\/li>\n<\/ol>\n<p>\nI dati degli utenti sono separati da tutte le altre informazioni, vengono memorizzati in una tabella separata denominata membership, le funzioni del layer logico AuthService possono benissimo diventare metodi API. I confini del dominio sono definiti in modo chiaro: utenti, i loro ruoli, informazioni sugli accessi, concessione e revoca degli accessi. Tutto sembra poter essere estratto in un servizio separato.<\/p>\n<p><b>\u00c8 SUCCESSO.<\/b> E cos\u00ec abbiamo fatto:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/3e8629b75ae68b95afa475286d4c5d2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesto approccio ha alcune problematiche. Ad esempio, chiamare un metodo all'interno di un processo non \u00e8 la stessa cosa che chiamare un servizio esterno via http. La latenza, l'affidabilit\u00e0, la manutenibilit\u00e0 e la trasparenza dell'operazione sono completamente diverse. Di queste problematiche ha parlato in dettaglio Andrey Morevsky nella sua conferenza <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=XeNrWkRmVWw\">\u00ab50 sfumature di microservizi\u00bb<\/a><\/noindex>.<\/p>\n<p>Il servizio di autenticazione e il servizio dispositivi vengono utilizzati per il back office, ovvero per servizi e interfacce utilizzati nella produzione. L'autenticazione per i servizi client (come il sito web o l'app mobile) avviene separatamente senza utilizzare Auth. La separazione ha richiesto circa un anno, e ora ci stiamo nuovamente occupando di questo tema, migrando il sistema a nuovi servizi di autenticazione (con protocolli standard). <\/p>\n<p>                        <b class=\"spoiler_title\">Perch\u00e9 la separazione \u00e8 durata cos\u00ec a lungo?<\/b><br \/>\n                        Lungo il percorso ci sono stati numerosi problemi che hanno rallentato:<\/p>\n<ol>\n<li>Volevamo trasferire i dati sugli utenti, dispositivi e autenticazione da database nazionali a uno solo. Per questo abbiamo dovuto trasferire tutte le tabelle e cambiare l'uso dell'identificatore int in un identificatore globale UUID (questo codice \u00e8 stato recentemente rielaborato <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=OGK4Lkd6p6s\">Roman Bukin \u00abUuid \u2014 una grande storia di una piccola struttura\u00bb<\/a><\/noindex> e progetto open-source <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dodopizza\/primitives\">Primitives<\/a><\/noindex>). La memorizzazione dei dati sugli utenti (poich\u00e9 si tratta di informazioni personali) ha delle limitazioni e, per alcuni paesi, devono essere archiviati separatamente. Ma l'identificatore globale dell'utente deve esserci.<\/li>\n<li>Molte tabelle nel database contengono informazioni sul audit dell'utente che ha effettuato l'operazione. Questo ha richiesto un meccanismo aggiuntivo per garantire la consistenza.<\/li>\n<li>Dopo la creazione dei servizi API, c'\u00e8 stato un lungo e graduale periodo di migrazione a un altro sistema. Le transizioni dovevano avvenire senza interruzioni per gli utenti e richiedevano intervento manuale.<\/li>\n<\/ol>\n<p>Schema di registrazione del dispositivo nella pizzeria:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/1e054d01de40d63c2994a4d49e47b215.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nArchitettura generale dopo la separazione del servizio Auth e Devices:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/069d176197674ef8414981ac98f30704.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><b>Nota<\/b>. Nel 2020 stiamo lavorando a una nuova versione di Auth, basata sullo standard di autorizzazione OAuth 2.0. Questo standard \u00e8 piuttosto complesso, ma sar\u00e0 utile per lo sviluppo del servizio di autenticazione end-to-end. Nell'articolo \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dododev\/blog\/520046\/\">Le sfumature dell'autenticazione: una panoramica della tecnologia OAuth 2.0<\/a><\/noindex>\u00bb abbiamo cercato di spiegare il standard in modo semplice e chiaro, in modo che tu possa risparmiare tempo nella sua comprensione.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"Q5\"><\/a><\/noindex><\/p>\n<h4>Cosa fa Tracker <\/h4>\n<p>\nOra parliamo del secondo dei servizi ad alto carico. Il tracker svolge un ruolo duplice:<\/p>\n<ul>\n<li>Da un lato, il suo compito \u00e8 mostrare ai dipendenti in cucina quali ordini sono attualmente in lavorazione e quali ingredienti devono essere preparati. <\/li>\n<li>Dall'altro lato, deve digitalizzare tutti i processi in cucina. <\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/5d13756308ee0cdb6e4000489b6b402d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuando un nuovo prodotto (ad esempio, una pizza) appare in un ordine, viene inviato alla stazione del tracker 'Stesura'. In questa stazione c'\u00e8 un pizzaiolo che prende la pasta della dimensione necessaria e la stende, quindi segna sul tablet del tracker che ha completato il suo compito e passa il disco di pasta alla stazione successiva - 'Farcitura'. <\/p>\n<p>Qui, un altro pizzaiolo farcisce la pizza, quindi segna sul tablet che ha completato il suo compito e mette la pizza nel forno (questa \u00e8 anche una stazione separata, che deve essere segnata sul tablet). Questo sistema \u00e8 stato utilizzato fin dall'inizio in Dodo e dall'esistenza di Dodo IS. Permette di tracciare e digitalizzare completamente tutte le operazioni. Inoltre, il tracker fornisce indicazioni su come preparare prodotti specifici, guida ogni tipo di prodotto attraverso le proprie schede di produzione, conserva il tempo di preparazione ottimale del prodotto e monitora tutte le operazioni relative al prodotto. <\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/d745bf6f981c1a5b43e6091b090644ad.png\" style=\"display:block;margin: 0 auto;\" \/><i>Ecco come appare lo schermo del tablet alla stazione del tracker 'Stesura'<\/i><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"Q6\"><\/a><\/noindex><\/p>\n<h4>Da dove proviene il carico? <\/h4>\n<p>\nIn ogni pizzeria ci sono circa cinque tablet con un tracker. Nel 2016 avevamo pi\u00f9 di 100 pizzerie (ora sono oltre 600). Ognuno di questi tablet fa una richiesta al backend ogni 10 secondi e recupera dati dalla tabella degli ordini (associazione con il cliente e l'indirizzo), dal contenuto dell'ordine (associazione con il prodotto e indicazione della quantit\u00e0), dalla tabella di monitoraggio delle motivazioni (dove viene registrato il tempo di pressione). Quando il pizzaiolo preme sul prodotto nel tracker, vengono aggiornate le registrazioni in tutte queste tabelle. La tabella degli ordini \u00e8 comune, in essa vengono effettuate contemporaneamente inserimenti quando viene accettato un ordine, aggiornamenti da altre parti del sistema e molte letture, ad esempio, sul televisore appeso nella pizzeria che mostra agli clienti gli ordini pronti. <\/p>\n<p>Durante il periodo di gestione dei carichi, quando tutto e tutti venivano memorizzati nella cache e trasferiti su una replica asincrona del database, queste operazioni con il tracker continuavano a passare al database principale. Non deve esserci alcun ritardo, i dati devono essere aggiornati, la desincronizzazione non \u00e8 accettabile.<\/p>\n<p>Inoltre, l'assenza di tabelle e indici propri non consentiva di scrivere query pi\u00f9 specifiche, mirate al proprio utilizzo. Ad esempio, per il tracker potrebbe essere efficace avere un indice sulla pizzeria nella tabella degli ordini. Recuperiamo sempre dal database del tracker gli ordini per la pizzeria. Tuttavia, per l'accettazione dell'ordine non \u00e8 cos\u00ec importante a quale pizzeria appartiene, \u00e8 pi\u00f9 importante quale cliente ha effettuato quest'ordine. Pertanto, \u00e8 necessario un indice sul cliente. Inoltre, per il tracker nella tabella degli ordini non \u00e8 necessario memorizzare l'id della ricevuta stampata o le promozioni bonus associate all'ordine. Queste informazioni non interessano il nostro servizio di tracker. Nella base monolitica generale, le tabelle potevano essere solo una compromissione tra tutti gli utenti. Questo era uno dei problemi iniziali.<\/p>\n<p><b>C'ERA. <\/b>Inizialmente, l'architettura era la seguente:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/085ebab3131ae5edc772d1e6f8c6de76.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAnche dopo la separazione in processi distinti, la maggior parte del codice rimaneva comune per diversi servizi. Tutto ci\u00f2 che era al di sotto dei controller era unico e viveva in un unico repository. Venivano utilizzati metodi comuni per servizi, repository, un database comune in cui si trovavano tabelle comuni.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"Q7\"><\/a><\/noindex><\/p>\n<h4>Riduciamo il carico da Tracker<br \/>\n<\/h4>\n<p>\nIl problema principale con il tracker \u00e8 che i dati devono essere sincronizzati tra diverse basi. Questa \u00e8 anche la sua principale differenza dalla separazione del servizio Auth, dato che un ordine e il suo stato possono cambiare e devono essere visualizzati in diversi servizi. <\/p>\n<p>Accettiamo ordini al Cassa del Ristorante (questo \u00e8 un servizio), che vengono salvati nel database con lo stato \"Accettato\". Successivamente devono passare al tracker, dove cambiano ancora diverse volte il loro stato: da \"Cucina\" a \"Imballato\". Durante questo processo, possono esserci influenze esterne dall'interfaccia di Cassa o dal Manager di turno. Riporter\u00f2 nella tabella gli stati dell'ordine con le loro descrizioni:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/b6a5a586a3f65715acccea2114725c8e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLo schema di cambiamento degli stati dell'ordine \u00e8 il seguente:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/92e58a2d60706b0e32aedbef7fa42f93.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGli stati cambiano tra sistemi diversi. Qui il tracker non \u00e8 un sistema finale in cui si chiudono i dati. Abbiamo visto diversi approcci possibili per la separazione in questo caso:<\/p>\n<ol>\n<li><b>Concentriamo tutte le azioni dell'ordine in un solo servizio.<\/b> Nel nostro caso, questa opzione richiede un servizio troppo grande per la gestione degli ordini. Se ci fossimo fermati a questo, avremmo creato un secondo monolite. Non avremmo risolto i problemi.<\/li>\n<li><b>Un sistema effettua una chiamata a un altro.<\/b> La seconda opzione \u00e8 gi\u00e0 pi\u00f9 interessente. Ma con essa sono possibili catene di chiamate (<noindex><a rel=\"nofollow\" href=\"https:\/\/landing.google.com\/sre\/sre-book\/chapters\/addressing-cascading-failures\/\">fallimenti a cascata<\/a><\/noindex>), la connessione tra i componenti \u00e8 maggiore e gestirla \u00e8 pi\u00f9 complesso. <\/li>\n<li><b>Organizziamo eventi, e ogni servizio comunica con un altro tramite questi eventi.<\/b> Alla fine \u00e8 stata scelta proprio la terza opzione, secondo cui tutti i servizi iniziano a scambiarsi eventi tra loro. <\/li>\n<\/ol>\n<p>\nIl fatto che abbiamo scelto la terza opzione significava che il tracker avrebbe avuto il proprio database, e ad ogni modifica dell'ordine avrebbe inviato un evento al riguardo, a cui si iscrivono gli altri servizi e che finisce anche nel master database. Per questo avevamo bisogno di un servizio che garantisse la consegna dei messaggi tra i servizi. <\/p>\n<p>A quel tempo nel nostro stack avevamo gi\u00e0 RabbitMQ, da qui la soluzione finale di utilizzare esso come broker di messaggi. Nello schema \u00e8 mostrato il passaggio dell'ordine dalla Cassa del Ristorante attraverso il Tracker, dove cambia i suoi stati e la sua visualizzazione nell'interfaccia Ordini del manager. <b>\u00c8 DIVENTATO<\/b>: <\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/eed09f7b11202556d6641036aa8ffb1f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<p>                        <b class=\"spoiler_title\">Il percorso dell'ordine passo dopo passo<\/b><br \/>\n                        Il percorso dell'ordine inizia in uno dei servizi fonte dell'ordine. Qui \u00e8 la Cassa del Ristorante: <\/p>\n<ol>\n<li>Alla Cassa l'ordine \u00e8 pronto per essere inviato al tracker. Viene sollevato un evento a cui il tracker \u00e8 iscritto. <\/li>\n<li>Il tracker, accettando l'ordine, lo salva nel proprio database, generando l'evento \u00abOrdineAccettatoDalTracker\u00bb e inviandolo a RMQ. <\/li>\n<li>Nel bus degli eventi, ci sono gi\u00e0 diversi gestori iscritti all'ordine. Per noi \u00e8 importante quello che esegue la sincronizzazione con il database monolitico. <\/li>\n<li>Il gestore riceve l'evento, estrae i dati significativi per lui: nel nostro caso, questo \u00e8 lo stato dell'ordine \u00abAccettatoDalTracker\u00bb e aggiorna la sua entit\u00e0 d'ordine nel database principale. <\/li>\n<\/ol>\n<p>Se a qualcuno serve l'ordine proprio dalla tabella monolitica degli ordini, pu\u00f2 leggerlo anche da l\u00ec. Questo \u00e8 necessario, ad esempio, per l'interfaccia Ordini nel Gestore dei Turni:<\/p>\n<p><img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/97c16e7fecd6709aad7e10f9dff6c037.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAnche tutti gli altri servizi possono iscriversi agli eventi dell'ordine dal tracker, per utilizzarli a loro favore.<\/p>\n<p>Se dopo un po' l'ordine viene preso in carico, il suo stato viene inizialmente modificato nel proprio database (il database del Tracker), e poi viene immediatamente generato l'evento \u00abOrdineInLavoro\u00bb. Anche questo entra in RMQ, da dove si sincronizza nel database monolitico e viene consegnato ad altri servizi. Lungo questo percorso possono verificarsi vari problemi, a proposito dei quali si pu\u00f2 consultare la relazione di Zhenya Peshkov <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=DWfJWCWV_eQ\">sui dettagli dell'implementazione della Consistenza Eventuale nel Tracker<\/a><\/noindex>. <\/p>\n<h4>L'architettura finale dopo le modifiche in Auth e Tracker<\/h4>\n<p>\n<img decoding=\"async\" alt=\"Storia dell&#039;architettura Dodo IS: il percorso del back office\" src=\"\/wp-content\/uploads\/2020\/10\/7cc517f78c8a381bd570cd26be25ace0.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><b>Per fare un bilancio intermedio:<\/b> inizialmente avevo l'idea di racchiudere una storia di nove anni del sistema Dodo IS in un solo articolo. Volevo raccontare rapidamente e semplicemente le fasi dell'evoluzione. Tuttavia, una volta seduto sui materiali, ho capito che tutto \u00e8 molto pi\u00f9 complesso e interessante di quanto sembri. <\/p>\n<p>Riflettendo sull'utilit\u00e0 (o assenza di essa) di un tale materiale, sono giunto alla conclusione che lo sviluppo continuo non \u00e8 possibile senza cronache complete degli eventi, retrospettive dettagliate e analisi delle proprie decisioni passate.<\/p>\n<p>Spero che sia stato utile e interessante conoscere il nostro percorso. Ora sono a un bivio, decidendo quale parte del sistema Dodo IS descrivere nel prossimo articolo: scrivete nei commenti o votate.<\/p>\n<p class=\"for_users_only_msg\">Solo gli utenti registrati possono partecipare al sondaggio. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Accedi<\/a><\/noindex>, per favore.<\/p>\n<h2 class=\"default-block__polling-title\">Quale parte di Dodo IS vi piacerebbe conoscere nel prossimo articolo?<\/h2>\n<ul class=\"poll-result\">\n<li class=\"poll-result__item\">\n<p>                <strong class=\"poll-result__data-percent\">24,1%<\/strong>Primo monolitico in Dodo IS (2011-2015)<\/p>\n<\/li>\n<li class=\"poll-result__item\">\n<p>                <strong class=\"poll-result__data-percent\">24,1%<\/strong>Prime problematiche e le loro soluzioni (2015-2016)<\/p>\n<\/li>\n<li class=\"poll-result__item\">\n<p>                <strong class=\"poll-result__data-percent\">20,7%<\/strong>Il percorso della parte client: facciata sopra il database (2016-2017)<\/p>\n<\/li>\n<li class=\"poll-result__item\">\n<p>                <strong class=\"poll-result__data-percent\">36,2%<\/strong>Storia dei veri microservizi (2018-2019)<\/p>\n<\/li>\n<li class=\"poll-result__item\">\n<p>                <strong class=\"poll-result__data-percent  poll-result__data-percent_winner\">44,8%<\/strong>Taglio completo del monolite e stabilizzazione dell'architettura26<\/p>\n<\/li>\n<li class=\"poll-result__item\">\n<p>                <strong class=\"poll-result__data-percent\">29,3%<\/strong>Sui futuri piani di sviluppo del sistema17<\/p>\n<\/li>\n<li class=\"poll-result__item\">\n<p>                <strong class=\"poll-result__data-percent\">19,0%<\/strong>Non voglio sapere nulla di Dodo IS11<\/p>\n<\/li>\n<\/ul>\n<p>    Hanno votato 58 utenti. Si sono astenuti 6 utenti.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzadev\/blog\/506136\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0425\u0430\u0431\u0440 \u043c\u0435\u043d\u044f\u0435\u0442 \u043c\u0438\u0440. \u0411\u043e\u043b\u044c\u0448\u0435 \u0433\u043e\u0434\u0430 \u043c\u044b \u0432\u0435\u0434\u0451\u043c \u0441\u0432\u043e\u0439 \u0431\u043b\u043e\u0433. \u0413\u0434\u0435-\u0442\u043e \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434 \u043d\u0430\u043c \u043f\u0440\u0438\u043b\u0435\u0442\u0435\u043b \u0432\u043f\u043e\u043b\u043d\u0435 \u043b\u043e\u0433\u0438\u0447\u043d\u044b\u0439 \u0444\u0438\u0434\u0431\u044d\u043a \u043e\u0442 \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d: \u00ab\u0414\u043e\u0434\u043e, \u0432\u043e\u0442 \u0432\u044b \u0432\u0435\u0437\u0434\u0435 \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u0435, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0441\u0432\u043e\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430. \u0410 \u0447\u0442\u043e \u044d\u0442\u043e \u0437\u0430 \u0441\u0438\u0441\u0442\u0435\u043c\u0430? \u0418 \u0437\u0430\u0447\u0435\u043c \u043e\u043d\u0430 \u043d\u0443\u0436\u043d\u0430 \u0441\u0435\u0442\u0438 \u043f\u0438\u0446\u0446\u0435\u0440\u0438\u0439?\u00bb. \u041c\u044b \u043f\u043e\u0441\u0438\u0434\u0435\u043b\u0438, \u043f\u043e\u0434\u0443\u043c\u0430\u043b\u0438 \u0438 \u043f\u043e\u043d\u044f\u043b\u0438, \u0447\u0442\u043e \u0432\u044b \u043f\u0440\u0430\u0432\u044b. \u041c\u044b \u043f\u0440\u043e\u0431\u0443\u0435\u043c \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u0442\u044c \u0432\u0441\u0451 \u043d\u0430 \u043f\u0430\u043b\u044c\u0446\u0430\u0445, \u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":95787,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-95786","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0425\u0430\u0431\u0440 \u043c\u0435\u043d\u044f\u0435\u0442 \u043c\u0438\u0440. \u0411\u043e\u043b\u044c\u0448\u0435 \u0433\u043e\u0434\u0430 \u043c\u044b \u0432\u0435\u0434\u0451\u043c \u0441\u0432\u043e\u0439 \u0431\u043b\u043e\u0433. \u0413\u0434\u0435-\u0442\u043e \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434 \u043d\u0430\u043c \u043f\u0440\u0438\u043b\u0435\u0442\u0435\u043b \u0432\u043f\u043e\u043b\u043d\u0435 \u043b\u043e\u0433\u0438\u0447\u043d\u044b\u0439 \u0444\u0438\u0434\u0431\u044d\u043a \u043e\u0442 \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d: \u00ab\u0414\u043e\u0434\u043e, \u0432\u043e\u0442 \u0432\u044b \u0432\u0435\u0437\u0434\u0435 \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u0435, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0441\u0432\u043e\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/istoriya-arhitektury-dodo-is-put-bekofisa\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b Dodo IS: \u043f\u0443\u0442\u044c \u0431\u044d\u043a\u043e\u0444\u0438\u0441\u0430 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0425\u0430\u0431\u0440 \u043c\u0435\u043d\u044f\u0435\u0442 \u043c\u0438\u0440. \u0411\u043e\u043b\u044c\u0448\u0435 \u0433\u043e\u0434\u0430 \u043c\u044b \u0432\u0435\u0434\u0451\u043c \u0441\u0432\u043e\u0439 \u0431\u043b\u043e\u0433. \u0413\u0434\u0435-\u0442\u043e \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434 \u043d\u0430\u043c \u043f\u0440\u0438\u043b\u0435\u0442\u0435\u043b \u0432\u043f\u043e\u043b\u043d\u0435 \u043b\u043e\u0433\u0438\u0447\u043d\u044b\u0439 \u0444\u0438\u0434\u0431\u044d\u043a \u043e\u0442 \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d: \u00ab\u0414\u043e\u0434\u043e, \u0432\u043e\u0442 \u0432\u044b \u0432\u0435\u0437\u0434\u0435 \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u0435, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0441\u0432\u043e\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/istoriya-arhitektury-dodo-is-put-bekofisa\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-10-03T11:42:12+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-10-03T11:42:12+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Storia dell'architettura Dodo IS: il percorso del back office | ProHoster","description":"Habr sta cambiando il mondo. Da oltre un anno gestiamo il nostro blog. Circa sei mesi fa abbiamo ricevuto un feedback abbastanza logico da parte degli utenti di Habr: \u00abDodo, voi dite sempre che avete un vostro sistema.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/istoriya-arhitektury-dodo-is-put-bekofisa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b Dodo IS: \u043f\u0443\u0442\u044c \u0431\u044d\u043a\u043e\u0444\u0438\u0441\u0430 | ProHoster","og:description":"\u0425\u0430\u0431\u0440 \u043c\u0435\u043d\u044f\u0435\u0442 \u043c\u0438\u0440. \u0411\u043e\u043b\u044c\u0448\u0435 \u0433\u043e\u0434\u0430 \u043c\u044b \u0432\u0435\u0434\u0451\u043c \u0441\u0432\u043e\u0439 \u0431\u043b\u043e\u0433. \u0413\u0434\u0435-\u0442\u043e \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434 \u043d\u0430\u043c \u043f\u0440\u0438\u043b\u0435\u0442\u0435\u043b \u0432\u043f\u043e\u043b\u043d\u0435 \u043b\u043e\u0433\u0438\u0447\u043d\u044b\u0439 \u0444\u0438\u0434\u0431\u044d\u043a \u043e\u0442 \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d: \u00ab\u0414\u043e\u0434\u043e, \u0432\u043e\u0442 \u0432\u044b \u0432\u0435\u0437\u0434\u0435 \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u0435, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0441\u0432\u043e\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/istoriya-arhitektury-dodo-is-put-bekofisa","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-03T11:42:12+00:00","article:modified_time":"2020-10-03T11:42:12+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"95786","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:57:48","updated":"2022-09-27 15:42:36","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/95786","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=95786"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/95786\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/95787"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=95786"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=95786"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=95786"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}