{"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\/da\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye","title":{"rendered":"\u00abAt tr\u00e6de i mine sko\u00bb \u2014 vent, er de m\u00e6rkede?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Siden 2019 har der v\u00e6ret en lov i Rusland om obligatorisk m\u00e6rkning. Loven g\u00e6lder ikke for alle produktgrupper, og tidsplanen for indf\u00f8relsen af obligatorisk m\u00e6rkning varierer mellem forskellige produktgrupper. F\u00f8rst var tobaksprodukter, sko og medicin underlagt obligatorisk m\u00e6rkning, og senere vil andre varer som parfume, tekstiler og m\u00e6lk ogs\u00e5 blive omfattet. Denne lovgivning har f\u00f8rt til udviklingen af nye IT-l\u00f8sninger, der g\u00f8r det muligt at f\u00f8lge produktets livscyklus fra produktion til slutkunder, alle akt\u00f8rer i processen: b\u00e5de staten samt alle organisationer, der s\u00e6lger varer med obligatorisk m\u00e6rkning.<\/p>\n

I X5 har systemet, der vil spore m\u00e6rkede varer og udveksle data med staten og leverand\u00f8rer, f\u00e5et navnet \u201cMarkus\u201d. Lad os tage det trin for trin og se, hvem der har udviklet det, hvilket teknologisk stack det bruger, og hvorfor vi har grund til at v\u00e6re stolte.<\/p>\n

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

Virkelig HighLoad<\/h3>\n

\n\u201cMarkus\u201d l\u00f8ser mange opgaver, den prim\u00e6re er integreret samhandling mellem X5s information systemer og den statslige informationssystem for m\u00e6rkede produkter (GIS MP) for at spore bev\u00e6gelsen af m\u00e6rkede produkter. Desuden opbevarer platformen alle de ankomne m\u00e6rkningskoder og hele historikken for bev\u00e6gelsen af disse koder mellem objekter, hvilket hj\u00e6lper med at eliminere fejl i sortimentet af m\u00e6rkede produkter. For tobaksprodukter, som var de f\u00f8rste under obligatorisk m\u00e6rkning, indeholder en enkelt lastbil med cigaretter cirka 600.000 pakker, hvor hver pakke har sin egen unikke kode. Vores systems opgave er at spore og verificere lovligheden af hver s\u00e5dan pakke, der bev\u00e6ger sig mellem lagre og butikker, og til sidst bekr\u00e6fte muligheden for at s\u00e6lge dem til slutkunden. Vi registrerer omkring 125.000 kasseoperationer i timen, og det skal ogs\u00e5 registreres, hvordan hver pakke kom ind i butikken. Med alle bev\u00e6gelser mellem objekterne forventer vi derfor at h\u00e5ndtere tiotals milliarder poster \u00e5rligt.<\/p>\n

Team M<\/h3>\n

\nSelv om \"Markus\" betragtes som et H5-projekt, implementeres det med en produktorienteret tilgang. Teamet arbejder i Scrum. Projektets start var i sommeren sidste \u00e5r, men de f\u00f8rste resultater kom f\u00f8rst i oktober \u2014 et helt eget team blev oprettet, systemarkitekturen blev designet, og udstyr blev k\u00f8bt. I dag er teamet p\u00e5 16 personer, hvoraf seks arbejder med backend- og frontend-udvikling, og tre med systemanalyse. Seks personer besk\u00e6ftiger sig med manuel, belastnings- og automatiseret test samt produktsupport. Derudover har vi en SRE-specialist. <\/p>\n

Koden i vores team skrives ikke kun af udviklerne; stort set alle medarbejdere kan programmere og skriver automatiserede test, belastningsscripts og scripts til automatisering. Vi l\u00e6gger stor v\u00e6gt p\u00e5 dette, da selv produktsupport kr\u00e6ver et h\u00f8jt niveau af automatisering. Vi fors\u00f8ger altid at r\u00e5dgive og hj\u00e6lpe kolleger, der ikke tidligere har programmeret, ved at give dem sm\u00e5 opgaver.<\/p>\n

P\u00e5 grund af coronaviruspandemien har vi flyttet hele teamet til hjemmearbejde. Tilg\u00e6ngeligheden af alle v\u00e6rkt\u00f8jer til at styre udviklingen og det opbyggede workflow i Jira og GitLab gjorde det muligt at klare denne fase let. M\u00e5nederne p\u00e5 afstand viste, at teamets produktivitet ikke led under det, og for mange blev arbejdskomforten forbedret; det eneste, der manglede, var det personlige samv\u00e6r.<\/p>\n

Teamm\u00f8de f\u00f8r hjemmearbejde<\/h3>\n

\n\"\u00abAt
\n<\/p>\n

M\u00f8der under hjemmearbejde<\/h3>\n

\n\"\u00abAt
\n<\/p>\n

Den teknologiske stak for l\u00f8sningen<\/h3>\n

\nStandardlageret og CI\/CD-v\u00e6rkt\u00f8jet for H5 er GitLab. Vi bruger det til kodeopbevaring, kontinuerlig test og udrulning p\u00e5 test- og produktionsservere. Vi anvender ogs\u00e5 code review-praksis, hvor minimum to kolleger skal godkende \u00e6ndringerne, som udvikleren \u00f8nsker at gennemf\u00f8re i koden. Statisk kodeanalyse med SonarQube og JaCoCo hj\u00e6lper os med at holde koden ren og sikre det kr\u00e6vede niveau af enhedstestd\u00e6kning. Alle \u00e6ndringer i koden skal n\u00f8dvendigvis gennemg\u00e5 disse kontroller. Alle testscenarier, der k\u00f8res manuelt, automatiseres senere.<\/p>\n

For at kunne udf\u00f8re forretningsprocesserne i \"Markus\" var vi n\u00f8dt til at l\u00f8se en r\u00e6kke teknologiske udfordringer, som vi vil gennemg\u00e5 en ad gangen. <\/p>\n

Opgave 1. N\u00f8dvendigheden af horisontal skalerbarhed i systemet<\/b><\/p>\n

For at l\u00f8se denne opgave valgte vi en mikrotjeneste-arkitektur. Det var meget vigtigt at forst\u00e5 ansvarsomr\u00e5derne for tjenesterne. Vi fors\u00f8gte at opdele dem baseret p\u00e5 forretningsoperationer under hensyntagen til procespecifikationen. For eksempel er modtagelse p\u00e5 lageret en sj\u00e6lden, men meget omfattende operation, hvor man hurtigt skal indhente information fra myndighederne om de modtagne enheder, hvor antallet i \u00e9n levering kan n\u00e5 op p\u00e5 600.000, sikre, at modtagelse af varerne er tilladt og give al n\u00f8dvendig information til lagers automatiseringssystem. Til geng\u00e6ld har udskibning fra lagrene en meget h\u00f8jere intensitet, men opererer med mindre datam\u00e6ngder. <\/p>\n

Alle tjenester implementerer vi efter princippet om stateless, og selv interne operationer fors\u00f8ger vi at dele op i trin ved at bruge det, vi kalder, self-emner i Kafka. Det er, n\u00e5r en mikrotjeneste sender en meddelelse til sig selv, hvilket g\u00f8r det muligt at balancere belastningen ved mere ressourcekr\u00e6vende operationer og forenkler vedligeholdelse af produktet, men mere om det senere. <\/p>\n

Vi besluttede at adskille modulerne til interaktion med eksterne systemer i separate tjenester. Dette l\u00f8ste problemet med ofte \u00e6ndrede API\u2019er for eksterne systemer, n\u00e6sten uden at p\u00e5virke tjenesterne med forretningsfunktionalitet.<\/p>\n

\"\u00abAt
\n
\nAlle mikrotjenester implementeres i et OpenShift-klynge, som b\u00e5de l\u00f8ser problemet med skalerbarhed for hver mikrotjeneste og g\u00f8r det muligt for os at undg\u00e5 at bruge tredjeparts v\u00e6rkt\u00f8jer til service discovery.<\/p>\n

Opgave 2. Behovet for at opretholde h\u00f8j belastning og meget intensiv dataudveksling mellem platformens tjenester:<\/b> kun i projektets startfase udf\u00f8res der omkring 600 operationer pr. sekund. Vi forventer, at dette tal stiger til 5000 op\/s, efterh\u00e5nden som vi tilslutter handelsenheder til vores platform.<\/p>\n

Denne opgave blev l\u00f8st ved at implementere et Kafka-kluster og praktisk talt eliminere synkron interaktion mellem platformens mikrotjenester. Dette kr\u00e6ver en meget omhyggelig analyse af systemkravene, da ikke alle operationer kan v\u00e6re asynkrone. Samtidig sender vi ikke bare begivenheder via en broker, men overf\u00f8rer ogs\u00e5 al n\u00f8dvendig forretningsinformation i meddelelsen. P\u00e5 den m\u00e5de kan st\u00f8rrelsen p\u00e5 meddelelsen n\u00e5 op p\u00e5 flere hundrede kilobyte. Behandlingen af meddelelsesst\u00f8rrelser i Kafka kr\u00e6ver, at vi pr\u00e6cist forudsiger st\u00f8rrelsen p\u00e5 meddelelserne, og hvis n\u00f8dvendigt, deler vi dem, men delingen er logisk og relateret til forretningsoperationer.
\nFor eksempel, for varer ankommet med bil, deler vi dem efter kasser. Der er dedikerede mikrotjenester til synkrone operationer, og der udf\u00f8res grundig belastningstestning. Brugen af Kafka stillede os over for en anden udfordring \u2014 test af vores servicers funktionalitet under hensyntagen til integrationen med Kafka g\u00f8r alle vores enhedstest asynkrone. Denne udfordring l\u00f8ste vi ved at skrive vores egne utilities-methoder ved hj\u00e6lp af Embedded Kafka Broker. Dette annullerer ikke behovet for at skrive enhedstest for hver enkelt metode, men i komplekse tilf\u00e6lde foretr\u00e6kker vi at teste med Kafka.<\/p>\n

Vi har lagt stor v\u00e6gt p\u00e5 logtracering for at sikre, at TraceId ikke g\u00e5r tabt, n\u00e5r der opst\u00e5r undtagelser under drift af tjenesterne eller ved arbejde med Kafka batch. Og hvis der ikke var s\u00e6rlige sp\u00f8rgsm\u00e5l til det f\u00f8rste, s\u00e5 var vi i det andet tilf\u00e6lde n\u00f8dt til at registrere alle TraceId, som batch kom ind med, og v\u00e6lge \u00e9n til at forts\u00e6tte sporing. P\u00e5 den m\u00e5de kan brugeren let finde sporingen ved at s\u00f8ge p\u00e5 det oprindelige TraceId.<\/p>\n

Opgave 3. Behovet for at opbevare store m\u00e6ngder data: <\/b> over 1 milliard m\u00e6rkninger om \u00e5ret kun for tobaksprodukter modtages i X5. Disse kr\u00e6ver konstant og hurtig adgang. Systemet skal samle i alt omkring 10 milliarder poster om historikken for bev\u00e6gelsen af m\u00e6rkede varer.<\/p>\n

For at l\u00f8se den tredje opgave blev MongoDB NoSQL-database valgt. Vi har oprettet et sharded setup med 5 noder, og i hver node et Replica Set af 3 servere. Dette muligg\u00f8r horisontal skalering af systemet ved at tilf\u00f8je nye servere<\/a> til klyngen og sikre dens fejltolerance. Her st\u00f8dte vi p\u00e5 et andet problem \u2014 at sikre transaktionaliteten i Mongo-klyngen under hensyntagen til brugen af horisontalt skalerbare mikrotjenester. For eksempel er en af opgaverne i vores system at identificere fors\u00f8g p\u00e5 genudsalgs af varer med identiske m\u00e6rkningskoder. Her opst\u00e5r der problemer med fejlscanninger eller fejlagtige kasseoperationer. Vi har opdaget, at s\u00e5danne dubletter kan opst\u00e5 b\u00e5de inden for et enkelt behandlet Kafka-batch og mellem to parallelt behandlede batch. Derfor gav en tjek for dubletter via en databaseforesp\u00f8rgsel ikke noget resultat. For hver af mikrotjenesterne l\u00f8ste vi problemet separat baseret p\u00e5 forretningslogikken for den p\u00e5g\u00e6ldende tjeneste. For eksempel tilf\u00f8jede vi en kontrol inden for batch for kassekvitteringer og en separat behandling for dubletter ved inds\u00e6ttelse. <\/p>\n

For at brugernes arbejde med operationernes historik ikke skulle p\u00e5virke det vigtigste \u2014 funktionen af vores forretningsprocesser, har vi isoleret alle historiske data i en separat tjeneste med en s\u00e6rskilt database, som ogs\u00e5 modtager information gennem Kafka. P\u00e5 denne m\u00e5de arbejder brugerne med en isoleret tjeneste uden at p\u00e5virke de tjenester, der behandler data for aktuelle operationer.<\/p>\n

Opgave 4. Genbehandling af k\u00f8er og overv\u00e5gning:<\/b><\/p>\n

I distribuerede systemer opst\u00e5r der uundg\u00e5eligt problemer og fejl relateret til tilg\u00e6ngeligheden af databaser, k\u00f8er og eksterne datakilder. I tilf\u00e6lde af \"Markus\" er kilden til disse fejl integrationen med eksterne systemer. Det var n\u00f8dvendigt at finde en l\u00f8sning, der tillod gentagne anmodninger om fejlinformationer med en fastlagt timeout, uden at stoppe behandlingen af succesfulde anmodninger i den prim\u00e6re k\u00f8. Til dette blev den s\u00e5kaldte koncept \"topic based retry\" valgt. For hvert hovedemne oprettes en eller flere retry-emner, hvortil fejlinformationer sendes, samtidig med at der ikke introduceres en forsinkelse i behandlingen af beskeder fra den prim\u00e6re emne. Interaktionsskemaet \u2014 <\/p>\n

\"\u00abAt
\n
\nFor implementing such a scheme, we required the following \u2014 integrating this solution with Spring and avoiding code duplication. In the vastness of the internet, we came across a similar solution based on Spring BeanPostProcessor, but it seemed excessively cumbersome to us. Our team developed a simpler solution that allows integration into the Spring cycle for creating consumers and additionally adding Retry Consumers. We proposed a prototype of our solution to the Spring team, which can be viewed here. her<\/a><\/noindex>The number of Retry Consumers and the number of attempts for each consumer can be configured through parameters, depending on the needs of the business process, and to make everything work, it is only necessary to use the familiar annotation for all Spring developers: org.springframework.kafka.annotation.KafkaListener.<\/p>\n

In the event that a message could not be processed after all retry attempts, it goes into the DLT (dead letter topic) using the Spring DeadLetterPublishingRecoverer. At the request of the support team, we extended this functionality and created a separate service that allows viewing the messages that have ended up in the DLT, along with stack traces, trace IDs, and other useful information about them. Furthermore, monitoring and alerts have been added for all DLT topics, and now, essentially, the appearance of a message in a DLT topic serves as a reason for investigation and defect creation. This is very convenient \u2014 based on the topic name, we immediately understand at which step of the process the problem occurred, significantly speeding up the search for its root cause.<\/p>\n

\"\u00abAt
\n
\nRecently, we implemented an interface that allows our support team to resend messages after the reasons for their failure have been resolved (for instance, restoring the functionality of an external system) and, of course, recording the corresponding defect for analysis. Here, our self-topics came in handy; to avoid restarting a long processing chain, we can restart it from the desired step. <\/p>\n

\"\u00abAt
\n<\/p>\n

Platform Operation<\/h3>\n

\nThe platform is already in productive operation; we conduct deliveries and shipments daily, connecting new distribution centers and stores. As part of the pilot, the system is working with product groups \"Tobacco\" and \"Footwear.\" <\/p>\n

Our entire team participates in conducting pilots, analyzes emerging issues, and makes proposals for improving our product, from enhancing logs to changes in processes. <\/p>\n

For not repeating my mistakes, all cases found during the pilot are reflected in the automated tests. The presence of a large number of automated tests and unit tests allows for regression testing and implementing hotfixes literally within a few hours.<\/p>\n

Currently, we are continuing to develop and improve our platform, constantly facing new challenges. If you are interested, we will share our solutions in upcoming articles.
\n
Kilde: 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\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\u201cWalking in my shoes\u201d \u2014 wait, are they labeled? | ProHoster","description":"Since 2019, there has been a law in Russia regarding mandatory labeling. The law does not apply to all groups of goods, and the timelines for the implementation of mandatory labeling vary for different product groups.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/87372","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=87372"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/87372\/revisions"}],"predecessor-version":[{"id":157972,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/87372\/revisions\/157972"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/87373"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=87372"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=87372"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=87372"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}