{"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\/de\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye","title":{"rendered":"\u201eWalking in my shoes\u201c \u2013 halt, sind die gekennzeichnet?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Seit 2019 gilt in Russland das Gesetz zur obligatorischen Kennzeichnung. Das Gesetz erstreckt sich nicht auf alle Warengruppen, und die Fristen f\u00fcr das Inkrafttreten der obligatorischen Kennzeichnung variieren je nach Warengruppe. Zun\u00e4chst fallen Tabak, Schuhe, Arzneimittel unter die obligatorische Kennzeichnung, sp\u00e4ter werden weitere Waren wie Parfums, Textilien und Milch hinzukommen. Diese gesetzliche Neuerung hat zur Entwicklung neuer IT-L\u00f6sungen gef\u00fchrt, die es erm\u00f6glichen, die gesamte Lebensdauer eines Produkts vom Herstellungsprozess bis zum Kauf durch den Endverbraucher f\u00fcr alle Beteiligten im Prozess zu verfolgen: sowohl f\u00fcr den Staat als auch f\u00fcr alle Organisationen, die Produkte mit obligatorischer Kennzeichnung vertreiben.<\/p>\n

Im H5-System wurde die L\u00f6sung, die die gekennzeichneten Produkte verfolgt und Daten mit dem Staat und den Lieferanten austauscht, \"Markus\" genannt. Lassen Sie uns Schritt f\u00fcr Schritt erkl\u00e4ren, wie und von wem sie entwickelt wurde, welcher Technologiestack verwendet wird und warum wir darauf stolz sein k\u00f6nnen.<\/p>\n

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

Echtzeit-HighLoad<\/h3>\n

\n\"Markus\" l\u00f6st eine Vielzahl von Aufgaben, die wichtigste ist die Integrationsinteraktion zwischen den Informationssystemen von H5 und dem staatlichen Informationssystem der gekennzeichneten Produkte (GIS MP) zur Nachverfolgung der Lieferung der gekennzeichneten Produkte. Die Plattform speichert alle Codes der Kennzeichnung, die bei uns eingegangen sind, sowie die gesamte Historie der Bewegung dieser Codes zwischen den Objekten und hilft, Missverst\u00e4ndnisse bei gekennzeichneten Produkten zu vermeiden. Beispielsweise enth\u00e4lt bereits ein Lkw mit Zigaretten etwa 600.000 Packungen, von denen jede ihren eigenen einzigartigen Code hat. Die Aufgabe unseres Systems besteht darin, die legalen Bewegungen jeder einzelnen Packung zwischen Lagern und Gesch\u00e4ften nachzuvollziehen und letztlich die Zul\u00e4ssigkeit ihres Verkaufs an den Endverbraucher zu \u00fcberpr\u00fcfen. Dabei erfassen wir etwa 125.000 Kassentransaktionen pro Stunde und m\u00fcssen zudem dokumentieren, wie jede dieser Packungen ins Gesch\u00e4ft gelangt ist. Somit erwarten wir, unter Ber\u00fccksichtigung aller Bewegungen zwischen den Objekten, j\u00e4hrlich Milliarden von Datens\u00e4tzen.<\/p>\n

Das Team M<\/h3>\n

\nObwohl \u201eMarkus\u201c im Rahmen von X5 als Projekt gilt, wird es nach einem produktorientierten Ansatz umgesetzt. Das Team arbeitet nach Scrum. Der Projektstart war im Sommer des letzten Jahres, aber die ersten Ergebnisse kamen erst im Oktober \u2013 es wurde ein eigenes Team vollst\u00e4ndig zusammengestellt, die Systemarchitektur entworfen und die Hardware gekauft. Momentan besteht das Team aus 16 Personen, von denen sechs die Backend- und Frontend-Entwicklung \u00fcbernehmen, w\u00e4hrend drei sich mit der Systemanalyse besch\u00e4ftigen. Sechs weitere Personen k\u00fcmmern sich um manuelle, Last- und automatisierte Tests sowie um die Produktbetreuung. Dar\u00fcber hinaus haben wir einen SRE-Spezialisten. <\/p>\n

In unserem Team schreiben nicht nur die Entwickler Code, praktisch alle Kollegen k\u00f6nnen programmieren und erstellen automatisierte Tests, Lastscripts und Automatisierungsskripte. Wir legen besonderen Wert darauf, da selbst die Produktunterst\u00fctzung ein hohes Ma\u00df an Automatisierung erfordert. Wir bem\u00fchen uns, Kollegen, die vorher nicht programmiert haben, zu unterst\u00fctzen und ihnen kleine Aufgaben zu geben.<\/p>\n

Im Zusammenhang mit der Coronavirus-Pandemie haben wir das gesamte Team auf Remote-Arbeit umgestellt. Das Vorhandensein aller Werkzeuge f\u00fcr das Management der Entwicklung sowie der Workflow in Jira und GitLab haben es erm\u00f6glicht, diesen Schritt problemlos zu bew\u00e4ltigen. Die Monate im Homeoffice haben gezeigt, dass die Produktivit\u00e4t des Teams nicht darunter gelitten hat, f\u00fcr viele hat sich der Arbeitskomfort erh\u00f6ht, das Einzige, was fehlt, ist pers\u00f6nliche Kommunikation.<\/p>\n

Teammeeting vor dem Remote-Arbeiten<\/h3>\n

\n\"\u201eWalking
\n<\/p>\n

Meetings w\u00e4hrend des Remote-Arbeitens<\/h3>\n

\n\"\u201eWalking
\n<\/p>\n

Technologischer Stack der L\u00f6sung<\/h3>\n

\nDas standardm\u00e4\u00dfige Repository und das CI\/CD-Tool f\u00fcr X5 ist GitLab. Wir verwenden es zur Speicherung des Codes, f\u00fcr kontinuierliches Testen sowie f\u00fcr die Bereitstellung auf Test- und Produktionsservern. Zudem nutzen wir die Praxis des Code-Reviews, bei dem mindestens zwei Kollegen die vom Entwickler vorgenommenen \u00c4nderungen im Code genehmigen m\u00fcssen. Die statischen Code-Analysetools SonarQube und JaCoCo helfen uns, den Code sauber zu halten und den erforderlichen Grad der Abdeckung durch Unit-Tests sicherzustellen. Alle \u00c4nderungen im Code m\u00fcssen unbedingt diese Pr\u00fcfungen bestehen. Alle Testf\u00e4lle, die manuell durchgef\u00fchrt werden, werden anschlie\u00dfend automatisiert.<\/p>\n

Um die Gesch\u00e4ftsprozesse von \u201eMarkus\u201c erfolgreich umzusetzen, mussten wir eine Reihe technologischer Aufgaben l\u00f6sen, von denen wir jede einzeln betrachten. <\/p>\n

Aufgabe 1. Die Notwendigkeit der horizontalen Skalierbarkeit des Systems<\/b><\/p>\n

Um diese Aufgabe zu l\u00f6sen, haben wir einen mikroskopischen Ansatz f\u00fcr die Architektur gew\u00e4hlt. Dabei war es wichtig, die Verantwortungsbereiche der Dienste zu verstehen. Wir haben versucht, diese nach Gesch\u00e4ftsoperationen zu unterteilen, wobei wir die spezifischen Abl\u00e4ufe ber\u00fccksichtigt haben. Zum Beispiel ist die Wareneingangskontrolle im Lager keine sehr h\u00e4ufige, aber eine sehr umfangreiche Operation, bei der man so schnell wie m\u00f6glich Informationen \u00fcber die angenommenen Produkte vom staatlichen Regulierungsbeh\u00f6rde einholen muss, wobei die Menge in einer Lieferung bis zu 600.000 Einheiten erreichen kann, sowie die Zul\u00e4ssigkeit der Annahme dieser Waren im Lager \u00fcberpr\u00fcft und alle notwendigen Informationen dem Lagerautomatisierungssystem \u00fcbermittelt werden m\u00fcssen. Im Gegensatz dazu hat die Auslieferung aus den Lagern eine deutlich h\u00f6here Intensit\u00e4t, jedoch bearbeitet sie kleinere Datenmengen. <\/p>\n

Alle unsere Dienste implementieren wir nach dem stateless Prinzip, und selbst interne Abl\u00e4ufe versuchen wir in Schritte zu unterteilen, indem wir, wie wir sie nennen, self-Topics in Kafka verwenden. Das bedeutet, dass ein Mikrodienst eine Nachricht an sich selbst sendet, was es erm\u00f6glicht, die Last bei ressourcenintensiveren Operationen zu verteilen und die Wartung des Produkts zu vereinfachen, aber dazu sp\u00e4ter mehr. <\/p>\n

Wir haben beschlossen, Module, die mit externen Systemen interagieren, in separate Dienste auszulagern. Das hat es uns erm\u00f6glicht, das Problem h\u00e4ufig wechselnder APIs externer Systeme nahezu ohne Einfluss auf Dienste mit Gesch\u00e4fts-Funktionalit\u00e4t zu l\u00f6sen.<\/p>\n

\"\u201eWalking
\n
\nAlle Mikrodienste werden im OpenShift-Cluster bereitgestellt, das sowohl das Problem der Skalierung jedes Mikrodienstes l\u00f6st als auch die Verwendung von Drittanbieter-Tools zur Service-Entdeckung unn\u00f6tig macht.<\/p>\n

Aufgabe 2. Die Notwendigkeit, hohe Last und sehr intensiven Datenaustausch zwischen den Diensten der Plattform aufrechtzuerhalten:<\/b> nur in der Startphase des Projekts werden etwa 600 Operationen pro Sekunde durchgef\u00fchrt. Wir erwarten, dass dieser Wert auf 5000 Op\/Sek ansteigt, wenn Handelsobjekte mit unserer Plattform verbunden werden.<\/p>\n

Diese Aufgabe wurde durch den Einsatz eines Kafka-Clusters und nahezu vollst\u00e4ndigen Verzicht auf synchrone Interaktion zwischen den Microservices der Plattform gel\u00f6st. Dies erfordert eine sehr sorgf\u00e4ltige Analyse der Systemanforderungen, da nicht alle Operationen asynchron sein k\u00f6nnen. Dabei \u00fcbermitteln wir nicht nur Ereignisse \u00fcber den Broker, sondern auch alle erforderlichen Gesch\u00e4ftsinformationen in der Nachricht. Somit kann die Nachrichtenl\u00e4nge mehrere hundert Kilobyte erreichen. Die Einschr\u00e4nkung der Nachrichtenvolumina in Kafka erfordert von uns eine genaue Vorhersage der Nachrichtenl\u00e4ngen, und falls erforderlich, teilen wir sie auf, wobei diese Aufteilung logisch und mit den Gesch\u00e4ftsoperationen verbunden ist.
\nZum Beispiel teilen wir die Ware, die mit dem Fahrzeug angekommen ist, nach Kisten. F\u00fcr synchrone Vorg\u00e4nge werden separate Microservices bereitgestellt und es wird umfassendes Lasttesting durchgef\u00fchrt. Der Einsatz von Kafka hat uns vor eine neue Herausforderung gestellt: Die Funktionspr\u00fcfung unseres Dienstes in Bezug auf die Integration mit Kafka macht alle unsere Unit-Tests asynchron. Diese Aufgabe haben wir durch das Schreiben eigener Hilfsfunktionen unter Verwendung von Embedded Kafka Broker gel\u00f6st. Dies mindert nicht die Notwendigkeit, Unit-Tests f\u00fcr einzelne Methoden zu schreiben, aber komplexe F\u00e4lle testen wir lieber mit Kafka.<\/p>\n

Wir haben sehr viel Wert auf die Protokollverfolgung gelegt, damit ihre TraceId bei Auftreten von Ausnahmen w\u00e4hrend des Betriebs der Dienste oder beim Arbeiten mit Kafka-Batch nicht verloren gehen. W\u00e4hrend bei ersterem keine besonderen Fragen auftauchten, mussten wir im zweiten Fall alle TraceIds, mit denen das Batch kam, in das Protokoll schreiben und eine f\u00fcr die Fortsetzung der Verfolgung ausw\u00e4hlen. So kann der Benutzer bei der Suche nach der urspr\u00fcnglichen TraceId leicht herausfinden, mit welcher die Verfolgung fortgesetzt wurde.<\/p>\n

Aufgabe 3. Die Notwendigkeit, eine gro\u00dfe Menge an Daten zu speichern: <\/b> \u00dcber 1 Milliarde Kennzeichnungen pro Jahr nur f\u00fcr Tabak gehen bei X5 ein. Diese erfordern einen st\u00e4ndigen und schnellen Zugriff. Insgesamt sollte das System etwa 10 Milliarden Datens\u00e4tze zur Historie der Bewegungen der gekennzeichneten Waren verarbeiten.<\/p>\n

Zur L\u00f6sung der dritten Aufgabe wurde die NoSQL-Datenbank MongoDB gew\u00e4hlt. Wir haben einen Shard aus 5 Knoten aufgebaut und in jedem Knoten ein Replica Set aus 3 Servern. Dies erm\u00f6glicht es, das System horizontal zu skalieren, indem man hinzuf\u00fcgt. neue Server<\/a> in einem Cluster, und seine Ausfallsicherheit zu gew\u00e4hrleisten. Hierbei stehen wir vor einem weiteren Problem \u2013 die Gew\u00e4hrleistung der Transaktionsf\u00e4higkeit im Mongo-Cluster unter Ber\u00fccksichtigung der Nutzung horizontal skalierbarer Mikrodienste. Zum Beispiel ist eine der Aufgaben unseres Systems, Versuche zum Wiederverkauf von Waren mit identischen Kennzeichnungscodes zu identifizieren. Hierbei treten Probleme mit fehlerhaften Scans oder fehlerhaften Kassenoperationen auf. Wir haben festgestellt, dass solche Duplikate sowohl innerhalb eines verarbeiteten Kafka-Batches als auch innerhalb von zwei parallel verarbeiteten Batches auftreten k\u00f6nnen. Somit brachte die \u00dcberpr\u00fcfung auf Duplikate durch Anfragen an die Datenbank keine Ergebnisse. F\u00fcr jeden der Mikrodienste haben wir das Problem individuell gem\u00e4\u00df der Gesch\u00e4ftslogik dieses Dienstes gel\u00f6st. Beispielsweise haben wir f\u00fcr Belege eine \u00dcberpr\u00fcfung innerhalb des Batches hinzugef\u00fcgt und eine separate Verarbeitung zur Identifizierung von Duplikaten bei der Einf\u00fcgung implementiert. <\/p>\n

Damit die Nutzung der Transaktionshistorie durch die Benutzer keinen Einfluss auf das Wichtigste hat \u2013 die Funktionsf\u00e4higkeit unserer Gesch\u00e4ftsprozesse, haben wir alle historischen Daten in einen separaten Dienst mit einer eigenen Datenbank ausgelagert, der ebenfalls Informationen \u00fcber Kafka erh\u00e4lt. So arbeiten die Nutzer mit einem isolierten Dienst, ohne Einfluss auf die Dienste, die die Daten zu aktuellen Operationen verarbeiten.<\/p>\n

Aufgabe 4. Wiederverarbeitung von Warteschlangen und Monitoring:<\/b><\/p>\n

In verteilten Systemen treten unvermeidbar Probleme und Verf\u00fcgbarkeitsfehler von Datenbanken, Warteschlangen und externen Datenquellen auf. Im Fall von 'Markus' ist eine Quelle solcher Fehler die Integration mit externen Systemen. Es war notwendig, eine L\u00f6sung zu finden, die es erm\u00f6glicht, fehlerhafte Antworten nach einer bestimmten Timeout-Zeit erneut anzufragen, ohne dabei die Verarbeitung erfolgreicher Anfragen in der Hauptwarteschlange zu unterbrechen. Daher wurde das sogenannte Konzept des 'topic based retry' gew\u00e4hlt. F\u00fcr jedes Haupt-Topic wird ein oder mehrere Retry-Topics erstellt, in die fehlerhafte Nachrichten geleitet werden, wobei eine Verz\u00f6gerung bei der Verarbeitung von Nachrichten aus dem Haupt-Topic ausgeschlossen wird. Das Interaktionsschema ist \u2013 <\/p>\n

\"\u201eWalking
\n
\nUm ein solches Schema umzusetzen, ben\u00f6tigten wir Folgendes \u2013 diese L\u00f6sung mit Spring zu integrieren und Code-Duplikate zu vermeiden. Im Internet stie\u00dfen wir auf eine \u00e4hnliche L\u00f6sung, die auf Spring BeanPostProcessor basierte, aber sie schien uns zu umst\u00e4ndlich. Unser Team entwickelte eine einfachere L\u00f6sung, die es erm\u00f6glicht, sich in den Spring-Zyklus zur Erstellung von Consumer einzuf\u00fcgen und zus\u00e4tzlich Retry-Consumer hinzuzuf\u00fcgen. Ein Prototyp unserer L\u00f6sung wurde dem Spring-Team angeboten, den man sich ansehen kann. hier<\/a><\/noindex>. Die Anzahl der Retry-Consumer und die Anzahl der Versuche jedes Consumers werden \u00fcber Parameter konfiguriert, abh\u00e4ngig von den Anforderungen des Gesch\u00e4ftsprozesses, und damit alles funktioniert, bleibt nur noch die bekannte Annotation org.springframework.kafka.annotation.KafkaListener zu setzen.<\/p>\n

Falls eine Nachricht nach allen Retry-Versuchen nicht verarbeitet werden konnte, gelangt sie mit Hilfe des Spring DeadLetterPublishingRecoverer in das DLT (Dead Letter Topic). Auf Wunsch des Supports haben wir diese Funktionalit\u00e4t erweitert und einen separaten Dienst erstellt, der es erm\u00f6glicht, Nachrichten, die im DLT gelandet sind, sowie Stacktraces, traceId und weitere n\u00fctzliche Informationen einzusehen. Au\u00dferdem wurden \u00dcberwachungen und Alarme f\u00fcr alle DLT-Topics hinzugef\u00fcgt, so dass das Auftreten einer Nachricht im DLT-Topic im Grunde Anlass zur Untersuchung und zur Erstellung eines Defekts ist. Das ist sehr praktisch \u2013 an der Bezeichnung des Topics erkennen wir sofort, an welcher Stelle im Prozess das Problem aufgetreten ist, was die Suche nach der zugrunde liegenden Ursache erheblich beschleunigt.<\/p>\n

\"\u201eWalking
\n
\nNeulich haben wir eine Schnittstelle umgesetzt, die es unserer Unterst\u00fctzung erm\u00f6glicht, Nachrichten nach der Beseitigung ihrer Ursachen (zum Beispiel Wiederherstellung der Funktionsf\u00e4higkeit eines externen Systems) erneut zu senden und nat\u00fcrlich einen entsprechenden Defekt zur Analyse anzulegen. Hier kamen unsere Self-Topics ins Spiel: Um eine lange Verarbeitungskette nicht neu zu starten, kann man sie ab dem ben\u00f6tigten Schritt neu starten. <\/p>\n

\"\u201eWalking
\n<\/p>\n

Betrieb der Plattform<\/h3>\n

\nDie Plattform ist bereits im produktiven Einsatz, t\u00e4glich f\u00fchren wir Lieferungen und Verladungen durch, binden neue Verteilzentren und Gesch\u00e4fte an. Im Rahmen des Piloten arbeitet das System mit den Warengruppen 'Tabak' und 'Schuhe'. <\/p>\n

Unser gesamtes Team ist an der Durchf\u00fchrung von Piloten beteiligt, analysiert aufkommende Probleme und macht Vorschl\u00e4ge zur Verbesserung unseres Produkts, von der Optimierung der Protokolle bis hin zu \u00c4nderungen der Prozesse. <\/p>\n

Um meine Fehler nicht zu wiederholen, spiegeln sich alle im Rahmen des Piloten gefundenen F\u00e4lle in den automatisierten Tests wider. Eine Vielzahl von automatisierten Tests und Unit-Tests erm\u00f6glicht es, Regressionstests durchzuf\u00fchren und Hotfixes buchst\u00e4blich innerhalb weniger Stunden bereitzustellen.<\/p>\n

Derzeit entwickeln und verbessern wir unsere Plattform weiter und stehen st\u00e4ndig neuen Herausforderungen gegen\u00fcber. Wenn Sie interessiert sind, erz\u00e4hlen wir in den kommenden Artikeln von unseren L\u00f6sungen.
\n
Quelle: 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\u201eWalking in my shoes\u201c \u2014 Halt, sind die gekennzeichnet?","description":"Seit 2019 gilt in Russland das Gesetz zur verpflichtenden Kennzeichnung. Das Gesetz gilt nicht f\u00fcr alle Produktgruppen, und die Fristen f\u00fcr das Inkrafttreten der verpflichtenden Kennzeichnung variieren je nach Produktgruppe.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/walking-in-my-shoes-stop-a-oni-markirovannye","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/87372","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=87372"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/87372\/revisions"}],"predecessor-version":[{"id":157972,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/87372\/revisions\/157972"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/87373"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=87372"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=87372"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=87372"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}