{"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 fermati, ma sono contrassegnati?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dal 2019, in Russia, \u00e8 in vigore una legge sulla marcatura obbligatoria. Questa legge non si applica a tutti i gruppi di prodotti e le scadenze per l'entrata in vigore della marcatura obbligatoria variano per i diversi gruppi di merce. I primi prodotti soggetti a marcatura obbligatoria includono tabacco, calzature e farmaci; in seguito, saranno inclusi anche altri articoli, come profumi, tessuti e latte. Questa innovazione legislativa ha incentivato lo sviluppo di nuove soluzioni IT per tracciare l'intero ciclo di vita del prodotto, dalla produzione fino all'acquisto da parte del consumatore finale, per tutti i soggetti coinvolti: sia lo stato che tutte le aziende che vendono beni 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 si chiama \u201cMarcus\u201d. Vi racconteremo con ordine come e chi l'ha sviluppato, qual \u00e8 la sua architettura tecnologica e perch\u00e9 possiamo esserne orgogliosi.<\/p>\n

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

Un vero HighLoad<\/h3>\n

\n\u201cMarcus\u201d affronta molte sfide, la principale \u00e8 l'integrazione tra i sistemi informatici di X5 e il sistema informatico statale per la tracciabilit\u00e0 dei prodotti marcati (GIS MP) per seguire il movimento dei prodotti marcati. Inoltre, la piattaforma memorizza tutti i codici di marcatura ricevuti e l'intera storia del movimento di questi codici tra i diversi oggetti, aiutando a prevenire errori nella classificazione dei prodotti marcati. Prendendo ad esempio i prodotti del tabacco, che sono stati inclusi nei primi gruppi di beni marcati, un singolo camion di sigarette contiene circa 600.000 pacchetti, ognuno dei quali ha un codice unico. Il compito del nostro sistema \u00e8 monitorare e verificare la legalit\u00e0 dei movimenti di ogni pacchetto tra magazzini e negozi, e alla fine garantire la legittimit\u00e0 della loro vendita al consumatore finale. Registriamo circa 125.000 operazioni di cassa all'ora, e dobbiamo anche tenere traccia di come ogni pacchetto sia arrivato nel negozio. Considerando tutti i movimenti tra gli oggetti, prevediamo decine di miliardi di registrazioni all'anno.<\/p>\n

Il team M<\/h3>\n

\nNonostante \u201cMarcus\u201d sia considerato un progetto di X5, viene implementato con un approccio di prodotto. Il team lavora secondo la metodologia Scrum. Il progetto \u00e8 iniziato la scorsa estate, ma i primi risultati sono arrivati solo in ottobre: \u00e8 stato formato un team completo, \u00e8 stata sviluppata l'architettura del sistema e acquistato l'hardware. Attualmente, la squadra \u00e8 composta da 16 persone, di cui sei si occupano dello sviluppo backend e frontend, tre dell'analisi sistematica. Altre sei persone si occupano di test manuali, di carico, di automazione e del supporto del prodotto. Inoltre, abbiamo uno specialista SRE. <\/p>\n

Non scrivono codice solo gli sviluppatori nel nostro team; praticamente tutti i ragazzi sanno programmare e scrivono autovalutazioni, 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 consigliare e aiutare i colleghi che non hanno mai programmato, assegnando loro compiti brevi.<\/p>\n

A causa della pandemia di coronavirus, abbiamo trasferito l'intero team al lavoro remoto; la disponibilit\u00e0 di tutti gli strumenti per la gestione dello sviluppo e il workflow stabilito in Jira e GitLab hanno reso facile affrontare questa fase. I mesi trascorsi in remoto hanno dimostrato che la produttivit\u00e0 del team non \u00e8 calata; per molti il comfort lavorativo \u00e8 aumentato, l'unica cosa che manca \u00e8 la comunicazione di persona.<\/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

Il stack tecnologico della soluzione<\/h3>\n

\nIl repository standard e lo strumento CI\/CD per X5 \u00e8 GitLab. Lo utilizziamo per memorizzare codice, test continuo e distribuzione su server di test e produzione. Adottiamo anche la pratica della revisione del codice, dove almeno due colleghi devono approvare le modifiche apportate dal programmatore. Gli analizzatori statici di codice SonarQube e JaCoCo ci aiutano a mantenere il codice pulito e garantire il livello di copertura richiesto per i test unitari. Tutte le modifiche al codice devono obbligatoriamente superare questi controlli. Tutti gli scenari di test eseguiti manualmente vengono successivamente automatizzati.<\/p>\n

Per il successo dei processi aziendali di \u201cMarcus\u201d, abbiamo dovuto risolvere una serie di sfide tecnologiche, una per una. <\/p>\n

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

Per affrontare questa sfida, abbiamo scelto un approccio architetturale basato su microservizi. Era molto importante comprendere le aree di responsabilit\u00e0 dei servizi. Abbiamo cercato di suddividerli in base alle operazioni aziendali, tenendo conto delle specificit\u00e0 dei processi. Ad esempio, l'accettazione in magazzino \u00e8 un'operazione non molto frequente ma molto intensa, durante la quale \u00e8 necessario ottenere rapidamente dall'ente regolatorio informazioni sulle unit\u00e0 di prodotto accettate, il cui numero in una singola spedizione pu\u00f2 arrivare fino a 600.000, verificare l'ammissibilit\u00e0 dell'accettazione di questi beni in magazzino e fornire tutte le informazioni necessarie al sistema di automazione del magazzino. D'altra parte, le spedizioni dai magazzini sono molto pi\u00f9 frequenti, ma operano su volumi di dati pi\u00f9 piccoli. <\/p>\n

Tutti i nostri servizi sono realizzati secondo il principio stateless e cerchiamo di suddividere anche le operazioni interne in fasi, utilizzando, come li chiamiamo, self-topic Kafka. Questo avviene quando un microservizio invia un messaggio a se stesso, permettendo di bilanciare il carico nelle operazioni pi\u00f9 intensive e semplificando la manutenzione del prodotto, ma ne parleremo pi\u00f9 avanti. <\/p>\n

Abbiamo deciso di separare i moduli di interazione con i sistemi esterni in servizi autonomi. Questo ha permesso di risolvere il problema delle API esterne in continua evoluzione senza impattare i servizi con funzionalit\u00e0 aziendale.<\/p>\n

\"\u00abWalking
\n
\nTutti i microservizi vengono distribuiti all'interno di un cluster OpenShift, il quale risolve sia il problema della scalabilit\u00e0 di ciascun microservizio, sia ci consente di non utilizzare strumenti di Service Discovery di terze parti.<\/p>\n

Compito 2. La necessit\u00e0 di supportare un elevato carico e un intenso scambio di dati tra i servizi della piattaforma:<\/b> solo nella fase di avvio del progetto vengono eseguite circa 600 operazioni al secondo. Ci aspettiamo un incremento di questo valore fino a 5000 op\/sec man mano che i punti vendita si collegano alla nostra piattaforma.<\/p>\n

Abbiamo affrontato questa sfida distribuendo un cluster Kafka e rinunciando praticamente all'interazione sincrona tra i microservizi della piattaforma. Ci\u00f2 richiede un'analisi molto attenta dei requisiti del sistema, poich\u00e9 non tutte le operazioni possono essere asincrone. Inoltre, non ci limitiamo a trasmettere eventi tramite un broker, ma inviamo nel messaggio tutte le informazioni aziendali necessarie. Pertanto, il peso del messaggio pu\u00f2 arrivare a diverse centinaia di kilobyte. Il limite sul volume dei messaggi in Kafka richiede una previsione accurata delle dimensioni dei messaggi e, se necessario, li dividiamo, ma tale divisione \u00e8 logica e legata alle operazioni aziendali.
\nAd esempio, un prodotto arrivato in un veicolo viene suddiviso in base alle scatole. Per le operazioni sincrone vengono dedicati microservizi separati e viene condotta un'attenta prova di carico. L'uso di Kafka ci ha posto una nuova sfida: il collaudo della funzionalit\u00e0 del nostro servizio, considerando l'integrazione con Kafka, rende tutti i nostri test unitari asincroni. Abbiamo risolto questo compito scrivendo metodi utili personalizzati utilizzando un Broker Kafka Embedded. Questo non elimina la necessit\u00e0 di scrivere test unitari per metodi separati, ma preferiamo testare casi complessi utilizzando Kafka.<\/p>\n

Abbiamo prestato molta attenzione alla tracciabilit\u00e0 dei log, affinch\u00e9 il loro TraceId non andasse perso durante l'insorgere di eccezioni durante il funzionamento dei servizi o durante l'interazione con il batch di Kafka. Se per il primo caso non ci sono stati problemi particolari, nel secondo caso siamo stati costretti a registrare nel log tutti i TraceId con cui \u00e8 arrivato il batch e scegliere uno per continuare la tracciabilit\u00e0. Cos\u00ec, cercando tramite il TraceId originale, l'utente pu\u00f2 facilmente scoprire con quale \u00e8 proseguita la tracciabilit\u00e0.<\/p>\n

Compito 3. La necessit\u00e0 di memorizzare un grande volume di dati: <\/b> pi\u00f9 di 1 miliardo di etichette all'anno, solo per il tabacco, entra in X5. Queste richiedono accesso costante e veloce. L'intero sistema deve elaborare circa 10 miliardi di registrazioni sulla storia dei movimenti dei prodotti etichettati.<\/p>\n

Per affrontare la terza sfida, \u00e8 stata scelta una base NoSQL MongoDB. Abbiamo costruito uno shard composto da 5 nodi, e in ogni nodo un Replica Set di 3 server. Questo consente di scalare il sistema orizzontalmente, aggiungendo nuovi server<\/a> nel cluster e garantire la sua resilienza. Qui ci siamo trovati di fronte a un\u2019altra problematica: garantire la transazionalit\u00e0 nel cluster Mongo tenendo conto dell'uso di microservizi scalabili orizzontalmente. Ad esempio, uno degli obiettivi del nostro sistema \u00e8 identificare tentativi di rivendita di prodotti con codici di marcatura identici. Qui si presentano conflitti dovuti a scansioni errate o a operazioni errate da parte dei cassieri. Abbiamo scoperto che tali duplicati possono verificarsi sia all'interno di un batch Kafka elaborato che tra due batch elaborati in parallelo. Pertanto, la verifica della presenza di duplicati tramite query al database non forniva risultati. Abbiamo risolto il problema separatamente per ciascuno dei microservizi sulla base della logica di business specifica di ciascun servizio. Ad esempio, per le ricevute abbiamo aggiunto un controllo all'interno del batch e un\u2019elaborazione separata per identificare i duplicati durante l'inserimento. <\/p>\n

Per garantire che l'interazione degli utenti con la cronologia delle operazioni non influisse sul funzionamento dei nostri processi aziendali, abbiamo isolato tutti i dati storici in un servizio separato con un proprio database, che riceve informazioni tramite Kafka. Cos\u00ec gli utenti lavorano con un servizio isolato, senza influenzare i servizi che elaborano i dati delle operazioni correnti.<\/p>\n

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

Nelle architetture distribuite, sorgono inevitabilmente problemi e errori di disponibilit\u00e0 dei database, delle code e delle 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 eseguire richieste ripetute in caso di risposte errate con un timeout specificato, senza interrompere l'elaborazione delle richieste riuscite nella coda principale. Pertanto \u00e8 stata scelta la cosiddetta concezione \"topic based retry\". Per ogni topic principale, vengono creati uno o pi\u00f9 topic di retry, nei quali vengono indirizzati i messaggi errati, escludendo nel contempo ritardi nell'elaborazione dei messaggi dal topic principale. Lo schema di interazione \u00e8 <\/p>\n

\"\u00abWalking
\n
\nPer implementare tale schema avevamo bisogno di integrare questa soluzione con Spring e di evitare la duplicazione del codice. Navigando nella rete, ci siamo imbattuti in una soluzione simile basata su Spring BeanPostProcessor, ma l'abbiamo trovata eccessivamente complessa. La nostra squadra ha creato una soluzione pi\u00f9 semplice, che permette di integrarsi nel ciclo di creazione dei consumer di Spring e aggiungere ulteriori Retry Consumer. Abbiamo presentato il prototipo della nostra soluzione al team di Spring, pu\u00f2 essere visualizzato qui<\/a><\/noindex>. Il numero di Retry Consumer e il numero di tentativi di ciascun consumer sono configurabili tramite parametri, in base alle esigenze del processo aziendale, e per far funzionare tutto ci\u00f2, \u00e8 sufficiente aggiungere l'annotazione familiare a tutti i programmatori Spring org.springframework.kafka.annotation.KafkaListener.<\/p>\n

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

\"\u00abWalking
\n
\nPoco tempo fa, abbiamo implementato un'interfaccia che consente di reinviare messaggi tramite il nostro supporto dopo la risoluzione delle loro cause (ad esempio, il ripristino della funzionalit\u00e0 di un sistema esterno) e, ovviamente, l'apertura del difetto corrispondente per l'analisi. Qui sono stati utili i nostri self-topic, cos\u00ec da non dover riavviare l'intera catena di elaborazione; \u00e8 possibile riavviarla dal passo richiesto. <\/p>\n

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

Utilizzo della piattaforma<\/h3>\n

\nLa piattaforma \u00e8 gi\u00e0 in produzione, ogni giorno effettuiamo consegne e scarichi, collegando nuovi centri di distribuzione e negozi. Nel quadro del progetto pilota, il sistema lavora con gruppi di prodotti \"Tabacco\" e \"Calzature\". <\/p>\n

Tutta la nostra squadra partecipa alla conduzione dei piloti, analizza i problemi emergenti e propone miglioramenti per il nostro prodotto, dall'ottimizzazione dei log a modifiche nei processi. <\/p>\n

Per evitare di ripetere gli stessi errori, tutti i casi trovati durante il pilota sono riflessi nei test automatizzati. La presenza di un gran numero di test automatici e unitari consente di effettuare test di regressione e di implementare hotfix nel giro di poche ore.<\/p>\n

Attualmente continuiamo a sviluppare e perfezionare la nostra piattaforma e ci troviamo costantemente di fronte a nuove sfide. Se siete interessati, saremo felici di condividere 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 delle categorie merceologiche.","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}]}}