{"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\/sv\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye","title":{"rendered":"\"Walking in my shoes\" \u2014 v\u00e4nta, \u00e4r de m\u00e4rkta?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sedan 2019 har det funnits en lag i Ryssland om obligatorisk m\u00e4rkning. Lagen g\u00e4ller inte alla varugrupper, och tidsramarna f\u00f6r inf\u00f6randet av obligatorisk m\u00e4rkning f\u00f6r olika varugrupper \u00e4r olika. De f\u00f6rsta produkterna som omfattas av obligatorisk m\u00e4rkning \u00e4r tobak, skor och l\u00e4kemedel; senare kommer \u00e4ven andra produkter som parfymer, textilier och mj\u00f6lk att l\u00e4ggas till. Denna lagstiftningsnyhet har lett till utvecklingen av nya IT-l\u00f6sningar som g\u00f6r det m\u00f6jligt att sp\u00e5ra hela livscykeln f\u00f6r en produkt fr\u00e5n produktion till k\u00f6p av slutanv\u00e4ndaren, b\u00e5de f\u00f6r staten och alla organisationer som s\u00e4ljer produkter med obligatorisk m\u00e4rkning.<\/p>\n

I X5 har systemet som ska sp\u00e5ra produkter med m\u00e4rkning och utbyta data med staten och leverant\u00f6rer f\u00e5tt namnet \u201cMarkus\u201d. Vi ber\u00e4ttar i tur och ordning hur och av vem det har utvecklats, vilken teknologistack det har och varf\u00f6r vi har anledning att vara stolta.<\/p>\n

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

Verklig HighLoad<\/h3>\n

\n\u201cMarkus\u201d l\u00f6ser m\u00e5nga uppgifter, den viktigaste av dem \u00e4r integrationsinteraktionen mellan informationssystemen hos X5 och statens informationssystem f\u00f6r m\u00e4rkta produkter (GIS MP) f\u00f6r att sp\u00e5ra r\u00f6relsen av m\u00e4rkta produkter. Plattformen lagrar ocks\u00e5 alla mottagna m\u00e4rkningkoder och hela historien om dessa koders r\u00f6relse mellan objekt, och hj\u00e4lper till att eliminera f\u00f6rv\u00e4xlingar med m\u00e4rkta produkter. Till exempel, med tobaksprodukter som ing\u00e5r i de f\u00f6rsta grupperna av m\u00e4rkta varor, inneh\u00e5ller endast en bil med cigaretter cirka 600 000 paket, som vart och ett har sin egen unika kod. V\u00e5r uppgift \u00e4r att sp\u00e5ra och verifiera lagligheten av flytten av varje s\u00e5dant paket mellan lager och butiker, och i slut\u00e4ndan verifiera m\u00f6jligheten att s\u00e4lja dem till slutkonsumenten. Vi registrerar cirka 125 000 kassatransaktioner i timmen, och vi m\u00e5ste \u00e4ven registrera hur varje paket kom in i butiken. Med tanke p\u00e5 alla flyttningar mellan objekt f\u00f6rv\u00e4ntar vi oss tiotals miljarder poster per \u00e5r.<\/p>\n

Team M<\/h3>\n

\nTrots att \"Markus\" betraktas som ett projekt inom X5, genomf\u00f6rs det utifr\u00e5n en produktansats. Teamet arbetar enligt Scrum. Projektet startade sommaren f\u00f6rra \u00e5ret, men de f\u00f6rsta resultaten kom f\u00f6rst i oktober - teamet sattes samman, systemarkitekturen utvecklades och utrustning k\u00f6ptes in. Idag best\u00e5r teamet av 16 personer, varav sex arbetar med backend- och frontendutveckling, tre med systemanalys. Ytterligare sex personer ansvarar f\u00f6r manuell, belastning, automatiserad testning och produktunderh\u00e5ll. Dessutom har vi en SRE-specialist. <\/p>\n

I v\u00e5rt team skriver inte bara utvecklare kod, n\u00e4stan alla i gruppen kan programmera och skriver automatiserade tester, belastningsskript och automatiseringsskript. Vi l\u00e4gger stor vikt vid detta, eftersom \u00e4ven produktunderh\u00e5ll kr\u00e4ver en h\u00f6g niv\u00e5 av automatisering. Vi f\u00f6rs\u00f6ker alltid hj\u00e4lpa kollegor som tidigare inte programmerat genom att ge dem sm\u00e5 uppgifter.<\/p>\n

Med anledning av coronaviruspandemin har vi \u00f6verg\u00e5tt till distansarbete. Tillsammans med v\u00e5r tillg\u00e5ng till alla verktyg f\u00f6r att hantera utvecklingen och den uppbyggda arbetsfl\u00f6det i Jira och GitLab, lyckades vi enkelt klara denna fas. De m\u00e5nader som spenderades p\u00e5 distans visade att teamets produktivitet inte p\u00e5verkades, f\u00f6r m\u00e5nga \u00f6kade komforten i arbetet, det enda som saknas \u00e4r det personliga m\u00f6tet.<\/p>\n

Teamets m\u00f6te f\u00f6re distansarbetet<\/h3>\n

\n\""Walking
\n<\/p>\n

M\u00f6ten under distansarbetet<\/h3>\n

\n\""Walking
\n<\/p>\n

Den tekniska stacken f\u00f6r l\u00f6sningen<\/h3>\n

\nDen standardrepository och CI\/CD-verktyget f\u00f6r X5 \u00e4r GitLab. Vi anv\u00e4nder det f\u00f6r att lagra koden, kontinuerlig testning, och distribution p\u00e5 test- och produktionsservrar. Vi till\u00e4mpar \u00e4ven en code review-praxis, d\u00e4r minst tv\u00e5 kollegor m\u00e5ste godk\u00e4nna de f\u00f6r\u00e4ndringar som utvecklaren gjort i koden. De statiska kodanalysatorerna SonarQube och JaCoCo hj\u00e4lper oss att h\u00e5lla koden ren och s\u00e4kerst\u00e4lla att den n\u00f6dv\u00e4ndiga niv\u00e5n av enhetstestning uppr\u00e4tth\u00e5lls. Alla kod\u00e4ndringar m\u00e5ste f\u00f6rst genomg\u00e5 dessa kontroller. Alla testscenarier som k\u00f6rs manuellt automatiseras senare.<\/p>\n

F\u00f6r att framg\u00e5ngsrikt genomf\u00f6ra aff\u00e4rsprocesserna med \"Markus\" var vi tvungna att l\u00f6sa ett antal tekniska utmaningar, en i taget. <\/p>\n

Uppgift 1. Behov av horisontell skalbarhet i systemet<\/b><\/p>\n

F\u00f6r att l\u00f6sa denna uppgift valde vi en mikrotj\u00e4nstarkitektur. Det var mycket viktigt att f\u00f6rst\u00e5 ansvarsomr\u00e5dena f\u00f6r tj\u00e4nsterna. Vi f\u00f6rs\u00f6kte dela upp dem utifr\u00e5n aff\u00e4rsoperationer med h\u00e4nsyn till processernas specifik. Till exempel, mottagningen p\u00e5 lagret \u00e4r en ovanlig, men mycket omfattande operation, d\u00e4r man snabbt m\u00e5ste f\u00e5 information fr\u00e5n myndigheterna om de mottagna varorna, d\u00e4r antalet i en leverans kan n\u00e5 upp till 600000, kontrollera om det \u00e4r till\u00e5tet att ta emot dessa varor p\u00e5 lagret och ge all n\u00f6dv\u00e4ndig information till lagrets automatiseringssystem. \u00c5 andra sidan har utfoutskick fr\u00e5n lagren en mycket h\u00f6gre intensitet, men arbetar med mindre datavolymer. <\/p>\n

Vi implementerar alla tj\u00e4nster enligt stateless-principen och f\u00f6rs\u00f6ker \u00e4ven dela upp interna operationer i steg, genom att anv\u00e4nda det vi kallar self-\u00e4mnen i Kafka. Detta inneb\u00e4r att mikrotj\u00e4nsten skickar meddelanden till sig sj\u00e4lv, vilket g\u00f6r att belastningen p\u00e5 mer resurskr\u00e4vande operationer kan f\u00f6rdelas och f\u00f6renklar produktunderh\u00e5ll, men mer om detta senare. <\/p>\n

Vi beslutade att separera modulerna f\u00f6r interaktion med externa system i egna tj\u00e4nster. Detta l\u00f6ste problemet med snabbt f\u00f6r\u00e4nderliga API:er i externa system, n\u00e4stan utan p\u00e5verkan p\u00e5 tj\u00e4nster med aff\u00e4rsfunktionalitet.<\/p>\n

\""Walking
\n
\nAlla mikrotj\u00e4nster distribueras i en OpenShift-kluster, vilket b\u00e5de hanterar problem med skalning av varje mikrotj\u00e4nst och g\u00f6r att vi kan undvika att anv\u00e4nda externa verktyg f\u00f6r Service Discovery.<\/p>\n

Uppgift 2. Behov av att st\u00f6dja h\u00f6g belastning och mycket intensiv datakommunikation mellan plattformens tj\u00e4nster:<\/b> bara i projektets startfas genomf\u00f6rs cirka 600 operationer per sekund. Vi f\u00f6rv\u00e4ntar oss att detta v\u00e4rde \u00f6kar till 5000 op\/s i takt med att handelsobjekten kopplas till v\u00e5r plattform.<\/p>\n

Denna uppgift l\u00f6stes genom att implementera en Kafka-kluster och praktiskt taget helt \u00f6verge synkron interaktion mellan plattformens mikrotj\u00e4nster. Detta kr\u00e4ver en mycket noggrann analys av systemets krav, eftersom inte alla operationer kan vara asynkrona. Vi skickar inte bara h\u00e4ndelser via en broker, utan \u00f6verf\u00f6r ocks\u00e5 all n\u00f6dv\u00e4ndig aff\u00e4rsinformation i meddelandet. D\u00e4rf\u00f6r kan storleken p\u00e5 meddelandet uppg\u00e5 till flera hundra kilobyte. Begr\u00e4nsningen av meddelandestorlek i Kafka kr\u00e4ver att vi exakt kan f\u00f6ruts\u00e4ga meddelandestorlekar, och vid behov delar vi upp dem, men uppdelningen \u00e4r logisk och relaterad till aff\u00e4rsoperationer.
\nTill exempel, f\u00f6r varor som anl\u00e4nder med bil delar vi upp dem i l\u00e5dor. F\u00f6r synkrona operationer avs\u00e4tts separata mikrotj\u00e4nster, och noggranna prestandatester utf\u00f6rs. Anv\u00e4ndningen av Kafka st\u00e4llde en annan utmaning f\u00f6r oss \u2014 att kontrollera hur v\u00e5r tj\u00e4nst fungerar med tanke p\u00e5 integrationen av Kafka g\u00f6r alla v\u00e5ra enhetstester asynkrona. Denna uppgift l\u00f6ste vi genom att skriva egna tillg\u00e4ngliga metoder med Embedded Kafka Broker. Detta avskaffar inte behovet av att skriva enhetstester f\u00f6r separata metoder, men f\u00f6r komplexa fall f\u00f6redrar vi att testa med Kafka.<\/p>\n

Vi har lagt mycket fokus p\u00e5 loggtracing s\u00e5 att deras TraceId inte g\u00e5r f\u00f6rlorade vid undantag i tj\u00e4nsternas drift eller vid hantering av Kafka-batchar. Om det f\u00f6rsta inte orsakade n\u00e5gra s\u00e4rskilda fr\u00e5gor, var vi i det andra fallet tvungna att logga alla TraceId som batchen kom med och v\u00e4lja ett f\u00f6r att forts\u00e4tta sp\u00e5rningen. D\u00e5 kan anv\u00e4ndaren enkelt hitta det ursprungliga TraceId och se vilket sp\u00e5rning som fortsatte.<\/p>\n

Uppgift 3. Behovet av att lagra stora m\u00e4ngder data: <\/b> mer \u00e4n 1 miljard m\u00e4rkningar per \u00e5r, bara f\u00f6r tobak, kommer in i X5. Dessa kr\u00e4ver st\u00e4ndig och snabb \u00e5tkomst. Totalt ska systemet hantera cirka 10 miljarder poster av datar\u00f6relser f\u00f6r m\u00e4rkta varor.<\/p>\n

F\u00f6r att l\u00f6sa den tredje uppgiften valdes NoSQL-databasen MongoDB. Vi har byggt ett sharded kluster med 5 noder, och i varje nod finns en Replica Set med 3 servrar. Detta m\u00f6jligg\u00f6r horisontell skalning av systemet genom att l\u00e4gga till nya servrar<\/a> i klustret och s\u00e4kerst\u00e4lla dess fel-tolerans. H\u00e4r st\u00f6tte vi p\u00e5 ett annat problem - att s\u00e4kerst\u00e4lla transaktionalitet i ett mongo-kluster med tanke p\u00e5 anv\u00e4ndningen av horisontellt skalbara mikrotj\u00e4nster. Till exempel \u00e4r en av v\u00e5ra systems uppgifter att uppt\u00e4cka f\u00f6rs\u00f6k till \u00e5terf\u00f6rs\u00e4ljning av varor med samma m\u00e4rkning. H\u00e4r uppst\u00e5r problem med felaktiga skanningar eller felaktiga kas\u00f6rer. Vi har uppt\u00e4ckt att s\u00e5dana dubbletter kan uppkomma b\u00e5de inom en behandlad Kafka-batch och inom tv\u00e5 parallellt behandlade batches. D\u00e4rf\u00f6r gav kontrollen av dubbletter genom en databasfr\u00e5ga ingenting. F\u00f6r varje mikrotj\u00e4nst hanterade vi problemet separat baserat p\u00e5 aff\u00e4rslogiken f\u00f6r den tj\u00e4nsten. Till exempel har vi f\u00f6r kvitton lagt till en kontroll inom batchen och en separat hantering f\u00f6r att uppt\u00e4cka dubbletter vid ins\u00e4ttning. <\/p>\n

F\u00f6r att anv\u00e4ndarnas arbete med transaktionshistorik inte skulle p\u00e5verka det mest centrala - funktionen av v\u00e5ra aff\u00e4rsprocesser, har vi separerat all historisk data i en s\u00e4rskild tj\u00e4nst med en s\u00e4rskild databas, som ocks\u00e5 f\u00e5r information genom Kafka. P\u00e5 s\u00e5 s\u00e4tt arbetar anv\u00e4ndarna med en isolerad tj\u00e4nst utan att p\u00e5verka de tj\u00e4nster som hanterar data om aktuella transaktioner.<\/p>\n

Uppgift 4. Ombehandling av k\u00f6er och \u00f6vervakning:<\/b><\/p>\n

I distribuerade system uppst\u00e5r oundvikligen problem och fel med tillg\u00e5ng till databaser, k\u00f6er och externa datak\u00e4llor. I fallet med \"Markus\" \u00e4r k\u00e4llan till s\u00e5dana fel integrationen med externa system. Det var n\u00f6dv\u00e4ndigt att hitta en l\u00f6sning som skulle m\u00f6jligg\u00f6ra omf\u00f6rfr\u00e5gningar vid felaktiga svar med en viss timeout, men utan att avbryta behandlingen av framg\u00e5ngsrika f\u00f6rfr\u00e5gningar i den prim\u00e4ra k\u00f6n. F\u00f6r detta valdes den s\u00e5 kallade konceptet \"topic based retry\". F\u00f6r varje huvudtopic skapas en eller flera retry-topics dit felaktiga meddelanden dirigeras, vilket samtidigt utesluter f\u00f6rdr\u00f6jning i behandlingen av meddelanden fr\u00e5n huvudtoppen. Kommunikationsschemat - <\/p>\n

\""Walking
\n
\nF\u00f6r att genomf\u00f6ra denna l\u00f6sning beh\u00f6vde vi integrera den med Spring och undvika kodduplicering. Vi st\u00f6tte p\u00e5 en liknande l\u00f6sning online, baserad p\u00e5 Spring BeanPostProcessor, men den verkade on\u00f6digt tungrodd. V\u00e5rt team skapade en enklare l\u00f6sning som g\u00f6r det m\u00f6jligt att integrera med Spring-cykeln f\u00f6r att skapa konsumenter och dessutom l\u00e4gga till Retry-konsumenter. Prototypen av v\u00e5r l\u00f6sning presenterade vi f\u00f6r Spring-teamet, den kan ses ). Ett typiskt exempel p\u00e5 anv\u00e4ndning:<\/a><\/noindex>. Antalet Retry-konsumenter och antalet f\u00f6rs\u00f6k f\u00f6r varje konsument kan konfigureras via parametrar, beroende p\u00e5 behov inom aff\u00e4rsprocessen, och f\u00f6r att allt ska fungera kr\u00e4vs bara den v\u00e4lk\u00e4nda annoteringen org.springframework.kafka.annotation.KafkaListener som alla Spring-utvecklare k\u00e4nner till.<\/p>\n

Om ett meddelande inte kunde bearbetas efter alla retry-f\u00f6rs\u00f6k g\u00e5r det till DLT (dead letter topic) med hj\u00e4lp av Spring DeadLetterPublishingRecoverer. P\u00e5 beg\u00e4ran av supporten utvidgade vi denna funktion och skapade en separat tj\u00e4nst som g\u00f6r det m\u00f6jligt att se meddelanden som hamnat i DLT, stackTrace, traceId och annan nyttig information om dem. Dessutom har \u00f6vervakning och larm p\u00e5 alla DLT-topiker lagts till, och i dagsl\u00e4get \u00e4r ett meddelande i DLT-topiken i stort sett en anledning till att g\u00f6ra en felanm\u00e4lan. Detta \u00e4r mycket praktiskt - genom topikens namn f\u00f6rst\u00e5r vi direkt vilket steg i processen problemet uppstod, vilket avsev\u00e4rt p\u00e5skyndar s\u00f6kandet efter dess rotorsak.<\/p>\n

\""Walking
\n
\nNyligen implementerade vi ett gr\u00e4nssnitt som g\u00f6r det m\u00f6jligt att \u00e5terigen skicka meddelanden med hj\u00e4lp av v\u00e5r support, efter att orsaken till problemen \u00e5tg\u00e4rdats (till exempel \u00e5terst\u00e4llande av den externa systemets funktionalitet) och givetvis g\u00f6r en motsvarande felanm\u00e4lan f\u00f6r analys. H\u00e4r kom v\u00e5ra self-topiker till nytta, f\u00f6r att inte beh\u00f6va starta om hela kedjan av bearbetning kan den startas om fr\u00e5n det \u00f6nskade steget. <\/p>\n

\""Walking
\n<\/p>\n

Drift av plattformen<\/h3>\n

\nPlattformen \u00e4r redan i produktiv drift, varje dag genomf\u00f6r vi leveranser och frakt, samt kopplar nya distributionscentra och butiker. Inom ramen f\u00f6r piloten fungerar systemet med produktgrupperna \"Tobak\" och \"Skor\". <\/p>\n

Hela v\u00e5rt team deltar i piloterna, analyserar de problem som uppst\u00e5r och kommer med f\u00f6rslag p\u00e5 f\u00f6rb\u00e4ttringar av v\u00e5r produkt, fr\u00e5n att f\u00f6rb\u00e4ttra loggar till f\u00f6r\u00e4ndringar i processerna. <\/p>\n

F\u00f6r att undvika att upprepa sina misstag \u00e5terspeglas alla fall som uppt\u00e4ckts under piloten i automatiserade tester. N\u00e4rvaron av ett stort antal automatiserade tester och enhetstester m\u00f6jligg\u00f6r regressionsprovning och att till\u00e4mpa en hotfix bokstavligt talat inom n\u00e5gra timmar.<\/p>\n

Just nu forts\u00e4tter vi att utveckla och f\u00f6rb\u00e4ttra v\u00e5r plattform och st\u00f6ter st\u00e4ndigt p\u00e5 nya utmaningar. Om du \u00e4r intresserad kan vi ber\u00e4tta om v\u00e5ra l\u00f6sningar i kommande artiklar.
\n
K\u00e4lla: 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\u00abWalking in my shoes\u00bb \u2014 stopp, \u00e4r de m\u00e4rkta?","description":"Sedan 2019 g\u00e4ller en lag i Ryssland om obligatorisk m\u00e4rkning. Lagen g\u00e4ller inte f\u00f6r alla varugrupper, och tidsramarna f\u00f6r n\u00e4r obligatorisk m\u00e4rkning tr\u00e4der i kraft varierar f\u00f6r olika varugrupper.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/87372","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=87372"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/87372\/revisions"}],"predecessor-version":[{"id":157972,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/87372\/revisions\/157972"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/87373"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=87372"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=87372"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=87372"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}