{"id":87372,"date":"2020-07-07T13:42:34","date_gmt":"2020-07-07T11:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye"},"modified":"2020-07-07T13:42:34","modified_gmt":"2020-07-07T11:42:34","slug":"walking-in-my-shoes-stop-a-oni-markirovannye","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye","title":{"rendered":"\u00abWalking in my shoes\u00bb \u2014 stop, ma sono etichettati?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dal 2019, in Russia \u00e8 in vigore una legge sulla marcatura obbligatoria. La legge non si applica a tutti i gruppi di prodotti e le scadenze per l'entrata in vigore della marcatura obbligatoria variano a seconda dei gruppi di prodotti. I primi ad essere soggetti alla marcatura obbligatoria sono stati tabacco, calzature, medicinali; successivamente verranno inclusi anche altri prodotti, come profumi, tessuti e latte. Questa novit\u00e0 legislativa ha stimolato lo sviluppo di nuove soluzioni IT che consentiranno di monitorare l'intera catena di vita del prodotto, dal momento della produzione fino all'acquisto da parte del consumatore finale, a tutti i partecipanti al processo: sia lo Stato che tutte le organizzazioni che vendono prodotti con marcatura obbligatoria.<\/p>\n

In X5, il sistema che traccer\u00e0 i prodotti con marcatura e scambier\u00e0 dati con lo Stato e i fornitori \u00e8 stato denominato \u201cMarkus\u201d. Spiegheremo nel dettaglio come e chi lo ha sviluppato, quale \u00e8 la sua tecnologia e perch\u00e9 possiamo essere orgogliosi.<\/p>\n

\"\u00abWalking
\n<\/a><\/noindex><\/p>\n

Un vero HighLoad<\/h3>\n

\n\u201cMarkus\u201d risolve numerosi compiti, il principale dei quali \u00e8 l'integrazione tra i sistemi informatici di X5 e il sistema informativo statale per il monitoraggio dei prodotti marcati (GIS MP) per seguire il movimento dei prodotti marcati. Inoltre, la piattaforma conserva tutti i codici di marcatura ricevuti e l'intera storia dei movimenti di questi codici tra gli oggetti, aiutando a eliminare eventuali errori nei prodotti marcati. Ad esempio, nel caso del tabacco, che ha fatto parte dei primi gruppi di prodotti marcati, solo un camion di sigarette contiene circa 600.000 pacchetti, ognuno dei quali ha il proprio codice unico. La nostra missione \u00e8 tracciare e verificare la legalit\u00e0 degli spostamenti di ciascun pacchetto tra magazzini e negozi e, infine, verificare la possibilit\u00e0 della loro vendita al consumatore finale. Inoltre, registriamo circa 125.000 operazioni di cassa all'ora, e dobbiamo anche registrare come ogni pacchetto \u00e8 arrivato nel negozio. Cos\u00ec, considerando tutti gli spostamenti tra gli oggetti, ci aspettiamo decine di miliardi di registrazioni all'anno.<\/p>\n

Il Team M<\/h3>\n

\nNonostante il fatto che \"Markus\" sia considerato un progetto all'interno di X5, viene realizzato secondo un approccio di prodotto. Il team lavora secondo Scrum. L'avvio del progetto \u00e8 avvenuto nell'estate dello scorso anno, ma i primi risultati sono stati ottenuti solo in ottobre: \u00e8 stato completamente formato un team interno, \u00e8 stata sviluppata l'architettura del sistema e sono stati acquistati i dispositivi. Attualmente nel team ci sono 16 persone, sei delle quali si occupano dello sviluppo backend e frontend, tre dell'analisi dei sistemi. Altri sei membri si occupano di test manuali, di carico e automatizzati, oltre che della manutenzione del prodotto. Inoltre, abbiamo uno specialista SRE. <\/p>\n

Nel nostro team, il codice \u00e8 scritto non solo dagli sviluppatori; praticamente tutti i ragazzi sanno programmare e scrivono test automatici, script di carico e script di automazione. Prestiamo particolare attenzione a questo, poich\u00e9 anche il supporto del prodotto richiede un alto livello di automazione. Cerchiamo sempre di offrire supporto e aiuto ai colleghi che non hanno precedentemente programmato, assegnando loro piccoli compiti.<\/p>\n

A causa della pandemia da coronavirus, abbiamo trasferito tutto il team al lavoro remoto; la disponibilit\u00e0 di tutti gli strumenti per la gestione dello sviluppo, il workflow impostato in Jira e GitLab hanno permesso di superare facilmente questa fase. I mesi trascorsi in remoto hanno dimostrato che la produttivit\u00e0 del team non \u00e8 stata compromessa; per molti, il comfort lavorativo \u00e8 aumentato, l'unico aspetto mancante \u00e8 la comunicazione in presenza.<\/p>\n

Incontro del team prima del lavoro remoto<\/h3>\n

\n\"\u00abWalking
\n<\/p>\n

Incontri durante il lavoro remoto<\/h3>\n

\n\"\u00abWalking
\n<\/p>\n

Stack tecnologico della soluzione<\/h3>\n

\nIl repository standard e lo strumento CI\/CD per X5 \u00e8 GitLab. Lo utilizziamo per conservare il codice, per il testing continuo e per il deployment sui server di test e di produzione. Utilizziamo anche la prassi del code review, in cui \u00e8 necessario che almeno 2 colleghi approvino le modifiche apportate dal sviluppatore al codice. Gli analizzatori di codice statici SonarQube e JaCoCo ci aiutano a mantenere il codice pulito e a garantire il livello richiesto di copertura dei test unitari. Tutte le modifiche al codice devono necessariamente passare attraverso queste verifiche. Tutti gli scenari di test eseguiti manualmente vengono successivamente automatizzati.<\/p>\n

Per completare con successo i processi aziendali con \"Markus\", abbiamo dovuto affrontare una serie di sfide tecnologiche, una per una. <\/p>\n

Compito 1. Necessit\u00e0 di scalabilit\u00e0 orizzontale del sistema<\/b><\/p>\n

Per risolvere questo problema, abbiamo scelto un approccio microservizi all'architettura. Era molto importante comprendere le aree di responsabilit\u00e0 dei servizi. Abbiamo cercato di suddividerli per operazioni aziendali tenendo conto delle specificit\u00e0 dei processi. Ad esempio, la ricezione in magazzino \u00e8 un'operazione non molto comune, ma molto articolata, durante la quale \u00e8 necessario ottenere il pi\u00f9 rapidamente possibile dall'ente regolatore le informazioni sulle unit\u00e0 di prodotto ricevute, il cui numero in una singola fornitura pu\u00f2 arrivare fino a 600000, verificare la possibilit\u00e0 di ricevere questo prodotto in magazzino e fornire tutte le informazioni necessarie al sistema di automazione del magazzino. Tuttavia, la spedizione dai magazzini ha una intensit\u00e0 molto maggiore, ma opera con volumi di dati pi\u00f9 piccoli. <\/p>\n

Tutti i servizi vengono realizzati secondo il principio stateless e anche le operazioni interne cerchiamo di suddividerle in fasi, utilizzando quelli che chiamiamo self-topics Kafka. Questo consente al microservizio di inviare messaggi a se stesso, bilanciando cos\u00ec il carico su operazioni pi\u00f9 intensive dal punto di vista delle risorse e semplificando la manutenzione del prodotto, ma di questo parleremo pi\u00f9 avanti. <\/p>\n

Abbiamo deciso di separare in servizi distinti i moduli di interazione con i sistemi esterni. Questo ha consentito di affrontare il problema degli API dei sistemi esterni che cambiano frequentemente, praticamente senza influire sui servizi con funzionalit\u00e0 aziendale.<\/p>\n

\"\u00abWalking
\n
\nTutti i microservizi vengono distribuiti nel cluster OpenShift, che risolve sia il problema della scalabilit\u00e0 di ogni microservizio, sia ci consente di non utilizzare strumenti di Service Discovery di terze parti.<\/p>\n

Compito 2. Necessit\u00e0 di supportare carichi elevati e uno scambio di dati molto intenso tra i servizi della piattaforma:<\/b> solo nella fase di avvio del progetto vengono eseguite circa 600 operazioni al secondo. Prevediamo un aumento di questo valore fino a 5000 opp\/sec man mano che colleghiamo gli oggetti commerciali alla nostra piattaforma.<\/p>\n

Questo problema \u00e8 stato risolto implementando un cluster Kafka e praticamente abbandonando l'interazione sincrona tra i micrservizi della piattaforma. Ci\u00f2 richiede un'analisi molto attenta dei requisiti di sistema, poich\u00e9 non tutte le operazioni possono essere asincrone. Inoltre, non ci limitiamo a trasmettere eventi tramite il broker, ma inviamo nel messaggio tutte le informazioni aziendali necessarie. Pertanto, la dimensione del messaggio pu\u00f2 arrivare a diverse centinaia di kilobyte. Il limite sulla dimensione dei messaggi in Kafka richiede una previsione precisa della grandezza dei messaggi, e, se necessario, li dividiamo, ma questa divisione \u00e8 logica e legata alle operazioni aziendali.
\nAd esempio, per i prodotti arrivati in auto, li dividiamo per scatole. Per le operazioni sincrone vengono individuati micrservizi separati e viene effettuato un accurato test di carico. L'uso di Kafka ha presentato una nuova sfida: il controllo del funzionamento del nostro servizio considerando l'integrazione con Kafka rende tutti i nostri test unitari asincroni. Per risolvere questo compito, abbiamo scritto nostri metodi utili utilizzando l'Embedded Kafka Broker. Questo non esclude la necessit\u00e0 di scrivere test unitari per i singoli metodi, ma i casi complessi preferiamo testarli utilizzando Kafka.<\/p>\n

Abbiamo dedicato molta attenzione alla tracciabilit\u00e0 dei log, affinch\u00e9 i loro TraceId non venissero persi in caso di eccezioni durante l'esecuzione dei servizi o quando si lavora con i batch di Kafka. Se nel primo caso non ci sono state particolari difficolt\u00e0, nel secondo abbiamo dovuto registrare nel log tutti i TraceId con cui \u00e8 arrivato il batch, e selezionare uno per proseguire la tracciabilit\u00e0. Cos\u00ec, cercando l'originale TraceId, l'utente pu\u00f2 facilmente scoprire quale sia stata la continuazione della tracciabilit\u00e0.<\/p>\n

Compito 3. Necessit\u00e0 di conservare una grande quantit\u00e0 di dati: <\/b> oltre 1 miliardo di marchi all'anno solo per il tabacco viene gestito da X5. \u00c8 necessario un accesso costante e veloce. In totale, il sistema deve elaborare circa 10 miliardi di registrazioni sulla storia del movimento dei prodotti marcati.<\/p>\n

Per risolvere il terzo compito \u00e8 stato scelto il database NoSQL MongoDB. Abbiamo allestito uno shard di 5 nodi e in ogni nodo un Replica Set di 3 server. Questo consente di scalare orizzontalmente il sistema, aggiungendo nuovi server<\/a> in cluster e garantire la sua resilienza. Qui ci siamo scontrati con un altro problema: garantire la transazionalit\u00e0 nel cluster mongo considerando l'uso di microservizi scalabili orizzontalmente. Ad esempio, uno dei compiti del nostro sistema \u00e8 identificare i tentativi di rivendita di prodotti con codici di marcatura uguali. Qui sorgono conflitti a causa di scansioni errate o di operazioni errate da parte dei cassieri. Abbiamo scoperto che tali duplicati possono verificarsi sia all'interno di un batch Kafka elaborato sia tra due batch elaborati in parallelo. Pertanto, la verifica dei duplicati tramite una query al database non ha dato risultati. Abbiamo risolto il problema per ciascun microservizio separatamente in base alla logica aziendale di quel servizio. Ad esempio, per le ricevute, abbiamo aggiunto un controllo all'interno del batch e un'elaborazione separata per la comparsa di duplicati durante l'inserimento. <\/p>\n

Affinch\u00e9 il lavoro degli utenti con la cronologia delle operazioni non influenzasse la cosa pi\u00f9 importante \u2014 il funzionamento dei nostri processi aziendali, abbiamo separato tutti i dati storici in un servizio dedicato con un proprio database, che riceve anche informazioni tramite Kafka. In questo modo, gli utenti lavorano con un servizio isolato, senza influenzare i servizi che elaborano dati sulle operazioni correnti.<\/p>\n

Compito 4. Rielaborazione delle code e monitoraggio:<\/b><\/p>\n

Nei sistemi distribuiti sorgono inevitabilmente problemi e errori di disponibilit\u00e0 di database, code e fonti di dati esterne. Nel caso di \"Markus\", la fonte di tali errori \u00e8 l'integrazione con sistemi esterni. Era necessario trovare una soluzione che permettesse di effettuare richieste ripetute per risposte errate con un certo timeout prestabilito, senza per\u00f2 interrompere l'elaborazione delle richieste concluse nella coda principale. A tal fine \u00e8 stata scelta la cosiddetta concezione di \u201cretry basata su topic\u201d. Per ogni topic principale vengono creati uno o pi\u00f9 topic di retry, nei quali vengono indirizzati i messaggi errati e allo stesso tempo \u00e8 escluso il ritardo nell'elaborazione dei messaggi dal topic principale. Schema di interazione \u2014 <\/p>\n

\"\u00abWalking
\n
\nPer realizzare questo schema, abbiamo avuto bisogno di integrare questa soluzione con Spring ed evitare la duplicazione del codice. In rete abbiamo trovato una soluzione simile basata su Spring BeanPostProcessor, ma ci \u00e8 sembrata eccessivamente complessa. Il nostro team ha creato una soluzione pi\u00f9 semplice che permette di inserirsi nel ciclo di creazione dei consumer di Spring e aggiungere ulteriormente i Retry Consumer. Abbiamo proposto il prototipo della nostra soluzione al team di Spring, che pu\u00f2 essere visualizzato qui<\/a><\/noindex>. Il numero di Retry Consumer e il numero di tentativi di ciascun consumer possono essere configurati tramite parametri, in base alle esigenze del processo aziendale, e, affinch\u00e9 tutto funzioni, \u00e8 sufficiente aggiungere l'annotazione gi\u00e0 nota a tutti gli sviluppatori Spring org.springframework.kafka.annotation.KafkaListener.<\/p>\n

Nel caso in cui il messaggio non possa essere elaborato dopo tutti i tentativi di retry, esso viene inviato nel DLT (dead letter topic) tramite il Spring DeadLetterPublishingRecoverer. Su richiesta del supporto, abbiamo ampliato questa funzionalit\u00e0 e creato un servizio separato che consente di visualizzare i messaggi finiti nel DLT, stackTrace, traceId e altre informazioni utili su di essi. Inoltre, sono stati aggiunti monitoraggi e allerte per tutti i topic DLT e ora, essenzialmente, l'arrivo di un messaggio nel topic DLT \u00e8 motivo di indagine e apertura di un difetto. Questo \u00e8 molto conveniente: dal nome del topic capiamo subito in quale fase del processo si \u00e8 verificato il problema, il che accelera notevolmente la ricerca della causa principale.<\/p>\n

\"\u00abWalking
\n
\nRecentemente abbiamo implementato un'interfaccia che consente di reinviare i messaggi con l'assistenza del nostro supporto, dopo che le loro cause sono state risolte (ad esempio, il ripristino della funzionalit\u00e0 di un sistema esterno) e, ovviamente, l'apertura del difetto corrispondente per l'analisi. In questo caso, i nostri self-topic sono stati utili, in modo da non dover riavviare una lunga catena di elaborazione, \u00e8 possibile riprenderla dal passaggio desiderato. <\/p>\n

\"\u00abWalking
\n<\/p>\n

Operazione della piattaforma<\/h3>\n

\nLa piattaforma \u00e8 gi\u00e0 in uso produttivo, ogni giorno eseguiamo consegne e spedizioni, connettiamo nuovi centri di distribuzione e negozi. Nell'ambito del pilota, il sistema funziona con i gruppi di prodotti \"Tabacco\" e \"Calzature\". <\/p>\n

Tutto il nostro team partecipa alla conduzione dei piloti, analizza i problemi che sorgono e propone miglioramenti al nostro prodotto, dall'ottimizzazione dei log a modifiche nei processi. <\/p>\n

Per non ripetere gli stessi errori, tutti i casi riscontrati durante il pilota vengono riflessi nei test automatizzati. L'ampia quantit\u00e0 di test automatici e test unitari consente di svolgere test di regressione e di implementare hotfix in poche ore.<\/p>\n

Attualmente continuiamo a sviluppare e migliorare la nostra piattaforma, affrontando costantemente nuove sfide. Se sei interessato, possiamo raccontarti le nostre soluzioni nei prossimi articoli.
\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0421 2019 \u0433\u043e\u0434\u0430 \u0432 \u0420\u043e\u0441\u0441\u0438\u0438 \u0434\u0435\u0439\u0441\u0442\u0432\u0443\u0435\u0442 \u0437\u0430\u043a\u043e\u043d \u043e\u0431 \u043e\u0431\u044f\u0437\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0440\u043a\u0438\u0440\u043e\u0432\u043a\u0435. \u0417\u0430\u043a\u043e\u043d \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u044f\u0435\u0442\u0441\u044f \u043d\u0435 \u043d\u0430 \u0432\u0441\u0435 \u0433\u0440\u0443\u043f\u043f\u044b \u0442\u043e\u0432\u0430\u0440\u043e\u0432, \u0438 \u0441\u0440\u043e\u043a\u0438 \u0432\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u0432 \u0441\u0438\u043b\u0443 \u043e\u0431\u044f\u0437\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0440\u043a\u0438\u0440\u043e\u0432\u043a\u0438 \u0434\u043b\u044f \u0442\u043e\u0432\u0430\u0440\u043d\u044b\u0445 \u0433\u0440\u0443\u043f\u043f \u0440\u0430\u0437\u043d\u044b\u0435. \u041f\u0435\u0440\u0432\u044b\u043c\u0438 \u043f\u043e\u0434 \u043e\u0431\u044f\u0437\u0430\u0442\u0435\u043b\u044c\u043d\u0443\u044e \u043c\u0430\u0440\u043a\u0438\u0440\u043e\u0432\u043a\u0443 \u043f\u043e\u043f\u0430\u0434\u0430\u044e\u0442 \u0442\u0430\u0431\u0430\u043a, \u043e\u0431\u0443\u0432\u044c, \u043b\u0435\u043a\u0430\u0440\u0441\u0442\u0432\u0430, \u043f\u043e\u0437\u0434\u043d\u0435\u0435 \u0434\u043e\u0431\u0430\u0432\u044f\u0442\u0441\u044f \u0438 \u0434\u0440\u0443\u0433\u0438\u0435 \u0442\u043e\u0432\u0430\u0440\u044b, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0434\u0443\u0445\u0438, \u0442\u0435\u043a\u0441\u0442\u0438\u043b\u044c, \u043c\u043e\u043b\u043e\u043a\u043e. \u042d\u0442\u043e \u0437\u0430\u043a\u043e\u043d\u043e\u0434\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u043d\u043e\u0432\u043e\u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u043f\u043e\u0431\u0443\u0434\u0438\u043b\u043e \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u043d\u043e\u0432\u044b\u0445 \u0418\u0422-\u0440\u0435\u0448\u0435\u043d\u0438\u0439, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":87373,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87372","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00abWalking in my shoes\u00bb \u2014 aspetta, sono marcati?","description":"Dal 2019 in Russia \u00e8 in vigore una legge sulla marcatura obbligatoria. La legge non si applica a tutti i gruppi di prodotti e le scadenze per l'entrata in vigore della marcatura obbligatoria variano a seconda dei gruppi di merce.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye","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\u00abWalking in my shoes\u00bb \u2014 \u0441\u0442\u043e\u043f, \u0430 \u043e\u043d\u0438 \u043c\u0430\u0440\u043a\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0435? | ProHoster","og:description":"\u0421 2019 \u0433\u043e\u0434\u0430 \u0432 \u0420\u043e\u0441\u0441\u0438\u0438 \u0434\u0435\u0439\u0441\u0442\u0432\u0443\u0435\u0442 \u0437\u0430\u043a\u043e\u043d \u043e\u0431 \u043e\u0431\u044f\u0437\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0440\u043a\u0438\u0440\u043e\u0432\u043a\u0435. \u0417\u0430\u043a\u043e\u043d \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u044f\u0435\u0442\u0441\u044f \u043d\u0435 \u043d\u0430 \u0432\u0441\u0435 \u0433\u0440\u0443\u043f\u043f\u044b \u0442\u043e\u0432\u0430\u0440\u043e\u0432, \u0438 \u0441\u0440\u043e\u043a\u0438 \u0432\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u0432 \u0441\u0438\u043b\u0443 \u043e\u0431\u044f\u0437\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0440\u043a\u0438\u0440\u043e\u0432\u043a\u0438 \u0434\u043b\u044f \u0442\u043e\u0432\u0430\u0440\u043d\u044b\u0445 \u0433\u0440\u0443\u043f\u043f \u0440\u0430\u0437\u043d\u044b\u0435.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye","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-07-07T11:42:34+00:00","article:modified_time":"2020-07-07T11:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"87372","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 13:52:22","updated":"2026-02-08 20:33:48","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\/87372","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=87372"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/87372\/revisions"}],"predecessor-version":[{"id":157972,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/87372\/revisions\/157972"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/87373"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=87372"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=87372"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=87372"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}