{"id":30785,"date":"2019-10-31T21:37:25","date_gmt":"2019-10-31T18:37:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie\/"},"modified":"2019-10-31T21:37:25","modified_gmt":"2019-10-31T18:37:25","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie","title":{"rendered":"Byggeenheder til distribuerede applikationer. Nul tilgang","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Byggeenheder til distribuerede applikationer. Nul tilgang\" src=\"\/wp-content\/uploads\/2019\/04\/88d4e363538bdfc67690c8339dca790b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Verden st\u00e5r ikke stille. Fremskridt skaber nye teknologiske udfordringer. I takt med de \u00e6ndrede krav skal arkitekturen for informationssystemer ogs\u00e5 udvikle sig. I dag vil vi tale om begivenhedsorienteret arkitektur, konkurrence, parallelisme, asynkronitet, og hvordan man kan leve harmonisk med alt dette i Erlang.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"vvedenie\">Introduktion<\/h2>\n<p><\/p>\n<p>Afh\u00e6ngigt af st\u00f8rrelsen af det system, der designes, og kravene til det, v\u00e6lger vi som udviklere en metode til informationsudveksling i systemet. I de fleste tilf\u00e6lde kan en l\u00f8sning med en broker, eksempelvis baseret p\u00e5 RabbitMQ eller Kafka, v\u00e6re et praktisk valg til at organisere interaktionen mellem tjenester. Men nogle gange er str\u00f8mmen af begivenheder, SLA og niveauet for kontrol over systemet s\u00e5dan, at en f\u00e6rdig messaging-l\u00f8sning ikke er tilstr\u00e6kkelig. Selvf\u00f8lgelig kan man g\u00f8re systemet lidt mere komplekst ved at tage ansvar for transportlaget og dannelsen af klynger, for eksempel ved at bruge ZeroMQ eller nanomsg. Men hvis systemet er tilstr\u00e6kkeligt i forhold til kapacitet og mulighederne i det standard Erlang-klynge, kr\u00e6ver sp\u00f8rgsm\u00e5let om at tilf\u00f8je en yderligere enhed en grundig unders\u00f8gelse og \u00f8konomisk begrundelse.<\/p>\n<p><\/p>\n<p>Emnet om reaktive distribuerede applikationer er ret omfattende. For at holde os inden for rammerne af denne artikel vil dagens diskussion kun omfatte homogene milj\u00f8er bygget p\u00e5 Erlang\/Elixir. \u00d8kosystemet Erlang\/OTP giver mulighed for at implementere en reaktiv arkitektur med minimale arbejdsomkostninger. Men vi vil i hvert fald have brug for et lag til meddelelser. <\/p>\n<p><\/p>\n<h2 id=\"teoreticheskiy-bazis\">Teoretisk grundlag<\/h2>\n<p><\/p>\n<p>Designet begynder med at definere m\u00e5l og begr\u00e6nsninger. Hovedm\u00e5let ligger ikke p\u00e5 udvikling for udviklingens skyld. Vi har brug for at skabe et sikkert og skalerbart v\u00e6rkt\u00f8j, som kan bruges til at opbygge, og vigtigst af alt \u2013 udvikle moderne applikationer p\u00e5 forskelligt niveau: fra enserver applikationer, der betjener en lille m\u00e5lgruppe, som senere kan udvikles til klynger med 50-60 noder, til federationer af klynger. Dermed er hovedm\u00e5let maksimalisering af profit ved at reducere omkostningerne ved udvikling og ejerskab af det endelige system.<\/p>\n<p><\/p>\n<p>Lad os fremh\u00e6ve 4 hovedkrav til det endelige system:<\/p>\n<p><\/p>\n<ul>\n<li><strong>Med<\/strong>begivenhedsorientering.<br \/>\nSystemet er altid klar til at h\u00e5ndtere en str\u00f8m af begivenheder og udf\u00f8re de n\u00f8dvendige handlinger;<\/li>\n<li><strong>M<\/strong>uligheder for skalering.<br \/>\nSeparate blokke kan skaleres b\u00e5de vertikalt og horisontalt. Hele systemet skal kunne vokse horisontalt uden begr\u00e6nsning;<\/li>\n<li><strong>O<\/strong>ptimering af driftsikkerhed.<br \/>\nAlle niveauer og alle tjenester skal kunne genoprette sig automatisk ved fejl;<\/li>\n<li><strong>G<\/strong>aranteret svartid.<br \/>\nTid er v\u00e6rdifuld, og brugerne skal ikke vente for l\u00e6nge.<\/li>\n<\/ul>\n<p><\/p>\n<p>Husk det gamle eventyr om \u201cThe little engine that could\u201d, eller \u201cToget, der kunne\u201d? For at det system, vi designer, kan bev\u00e6ge sig fra prototype til en progressiv l\u00f8sning, skal fundamentet opfylde de minimale krav. <strong>KUNNE<\/strong>.<\/p>\n<p><\/p>\n<p>N\u00e5r messaging betragtes som et infrastrukturelt v\u00e6rkt\u00f8j og grundlag for alle tjenester, tilf\u00f8jes endnu et punkt: brugervenlighed for programm\u00f8rer.<\/p>\n<p><\/p>\n<h3 id=\"orientirovannost-na-sobytiya\">H\u00e6ndelsesorientering<\/h3>\n<p><\/p>\n<p>For at en applikation kan vokse fra en <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/da\/server\/dts-los-angeles\/\"   title=\"server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"3480\">server<\/a> til en klynge, skal dens arkitektur sikre l\u00f8s kobling. Denne betingelse opfyldes af en asynkron model. Her tager afsender og modtager sig af den information, der sendes i beskeden, og bekymrer sig ikke om transmissionen og routing internt i systemet.<\/p>\n<p><\/p>\n<h3 id=\"masshtabiruemost\">Skalering<\/h3>\n<p><\/p>\n<p>Skalering og effektivitet i systemet g\u00e5r h\u00e5nd i h\u00e5nd. Applikationens komponenter skal kunne udnytte alle tilg\u00e6ngelige ressourcer. Jo mere effektivt vi kan udnytte kapaciteten, og jo mere optimalt vores behandlingsmetoder er, jo mindre bruger vi p\u00e5 udstyr. <\/p>\n<p><\/p>\n<p>Inden for \u00e9n maskine skaber Erlang et h\u00f8jkonkurrencemilj\u00f8. Balance mellem konkurrence og parallelitet kan bestemmes ved at v\u00e6lge antallet af operativsystemtr\u00e5de tilg\u00e6ngelige for Erlang VM og antallet af planl\u00e6ggere, der udnytter disse tr\u00e5de.<br \/>\nErlang-processer har ikke en delt tilstand og arbejder i en ikke-blokerende tilstand. Dette sikrer relativt lav latenstid og h\u00f8jere gennemstr\u00f8mning end traditionelle applikationer, der er bygget p\u00e5 blokering og synkronisering. Erlang-planl\u00e6ggeren s\u00f8rger for en retf\u00e6rdig fordeling af CPU og IO, og frav\u00e6ret af blokeringer g\u00f8r det muligt for applikationen at svare selv under spidsbelastning eller nedbrud. <\/p>\n<p><\/p>\n<p>P\u00e5 klusterniveau findes der ogs\u00e5 et problem med ressourceudnyttelse. Det er vigtigt, at alle maskiner i klusteret er j\u00e6vnt belastede, og at netv\u00e6rket ikke er overbelastet. Forestil dig en situation: brugertraffik lander p\u00e5 de indkommende belastningsbalancer (haproxy, nginx osv.), som j\u00e6vnt fordeler foresp\u00f8rgslerne til behandling mellem et s\u00e6t tilg\u00e6ngelige backend-tjenester. Inden for applikationsinfrastrukturen er tjenesten, der implementerer det n\u00f8dvendige interface, kun den sidste mil, og den skal anmode om en r\u00e6kke andre tjenester for at kunne besvare den oprindelige foresp\u00f8rgsel. Interne foresp\u00f8rgsler kr\u00e6ver ogs\u00e5 rutefordeling og belastningsbalancering.<br \/>\nFor effektivt at administrere str\u00f8mmen af data skal messaging give udviklere et interface til at styre rutefordeling og belastningsfordeling. Takket v\u00e6re dette kan udviklere, ved at bruge mikrotjenestem\u00f8nstre (aggregator, proxy, k\u00e6de, gren osv.), tackle b\u00e5de standardopgaver og sj\u00e6ldent forekommende opgaver. <\/p>\n<p><\/p>\n<p>Set fra forretningsperspektiv er skalerbarhed et v\u00e6rkt\u00f8j til risikostyring. Det vigtigste er at opfylde kundernes foresp\u00f8rgsler ved optimalt at udnytte udstyret:<\/p>\n<p><\/p>\n<ul>\n<li>Ved at \u00f8ge kapaciteten af udstyret som f\u00f8lge af fremskridt. Det vil ikke st\u00e5 stille p\u00e5 grund af softwareimperfektioner. Erlang skalerer fremragende vertikalt og kan altid udnytte alle CPU-kerner og tilg\u00e6ngelig hukommelse;<\/li>\n<li>I skytjenester kan vi styre m\u00e6ngden af udstyr i forhold til den aktuelle eller forudsete belastning og garantere SLA.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"otkazoustoychivost\">Fejltolerance<\/h3>\n<p><\/p>\n<p>Lad os overveje to aksiomer: \"Fejl er uacceptable\" og \"Fejl vil altid forekomme\". For virksomheder er softwarefejl et tab af penge, og hvad der er v\u00e6rre \u2013 af omd\u00f8mme. Ved at balancere mellem mulige tab og omkostningerne ved at udvikle fejltolerant software, kan der ofte findes et kompromis.<\/p>\n<p><\/p>\n<p>I den korte sigt sparer arkitektur, der indbygger fejltolerance, penge p\u00e5 k\u00f8b af f\u00e6rdige klusterl\u00f8sninger. De er dyre, og de indeholder ogs\u00e5 fejl.<br \/>\nP\u00e5 lang sigt betaler en fejltolerant arkitektur sig mange gange tilbage p\u00e5 alle udviklingsfaser.<br \/>\nMessaging i kodebasen er stadig under udvikling og muligg\u00f8r en detaljeret gennemgang af interaktionen mellem systemkomponenterne. Dette letter opgaven med at reagere p\u00e5 og h\u00e5ndtere fejl, da de ansvarlige komponenter h\u00e5ndterer fejl, mens det endelige system ved, hvordan det automatisk kan vende tilbage til normal drift efter en fejl som designet.<\/p>\n<p><\/p>\n<h3 id=\"otzyvchivost\">Responsivitet<\/h3>\n<p><\/p>\n<p>Uanset nedbrud skal applikationen svare p\u00e5 anmodninger og overholde SLA. Reality er, at folk ikke \u00f8nsker at vente, og derfor skal virksomheder tilpasse sig. Man forventer i stigende grad h\u00f8j responsivitet fra flere applikationer.<br \/>\nResponsivitet applikationer fungerer i en n\u00e6sten realtid. Erlang VM opererer i en bl\u00f8d realtidstilstand. For nogle omr\u00e5der, s\u00e5som aktiehandel, medicin, og styring af industriel udstyr, er h\u00e5rd realtidstilstand vigtig.<br \/>\nResponsiv systemer forbedrer UX og er nyttige for virksomheden.<\/p>\n<p><\/p>\n<h2 id=\"predvaritelnyy-itog\">Forel\u00f8bigt resultat<\/h2>\n<p><\/p>\n<p>Da jeg planlagde denne artikel, \u00f8nskede jeg at dele erfaringer med at oprette en messaging-broker og opbygge komplekse systemer baseret p\u00e5 det. Men den teoretiske og motiverende del viste sig at v\u00e6re ret omfattende.<br \/>\nI den anden del af artiklen vil jeg tale om nuancerne ved implementeringen af \u200b\u200budvekslingspunkter, messaging-templates og deres anvendelse.<br \/>\nI den tredje del vil vi se p\u00e5 generelle sp\u00f8rgsm\u00e5l om organiseringen af \u200b\u200btjenester, routing og load balancing. Vi vil tale om den praktiske side af skalerbarhed og systems modstandsdygtighed.<\/p>\n<p><\/p>\n<p>Slutningen af den f\u00f8rste del.<\/p>\n<p><\/p>\n<p>Foto <noindex><a rel=\"nofollow\" href=\"https:\/\/unsplash.com\/photos\/SRjZtxsK3Os\">@lucabravo<\/a><\/noindex>.<\/p>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/446028\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u0438\u0440 \u043d\u0435 \u0441\u0442\u043e\u0438\u0442 \u043d\u0430 \u043c\u0435\u0441\u0442\u0435. \u041f\u0440\u043e\u0433\u0440\u0435\u0441\u0441 \u0441\u043e\u0437\u0434\u0430\u0435\u0442 \u043d\u043e\u0432\u044b\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u0432\u044b\u0437\u043e\u0432\u044b. \u0412 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0438\u0438 \u0441 \u0438\u0437\u043c\u0435\u043d\u0438\u0432\u0448\u0438\u043c\u0438\u0441\u044f \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u043c\u0438, \u0434\u043e\u043b\u0436\u043d\u0430 \u044d\u0432\u043e\u043b\u044e\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u0431\u0443\u0434\u0435\u043c \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u0441\u043e\u0431\u044b\u0442\u0438\u0439\u043d\u043e-\u043e\u0440\u0438\u0435\u043d\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435, \u043a\u043e\u043d\u043a\u0443\u0440\u0435\u043d\u0442\u043d\u043e\u0441\u0442\u0438, \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438, \u0430\u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u043e\u0441\u0442\u0438 \u0438 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0432 Erlang \u043c\u043e\u0436\u043d\u043e \u0441\u043e \u0432\u0441\u0435\u043c \u044d\u0442\u0438\u043c \u0436\u0438\u0442\u044c \u043c\u0438\u0440\u043d\u043e. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0412 \u0437\u0430\u0432\u0438\u0441\u0438\u043c\u043e\u0441\u0442\u0438 \u043e\u0442 \u0440\u0430\u0437\u043c\u0435\u0440\u043e\u0432 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u0443\u0435\u043c\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0438 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u0439 \u043a \u043d\u0435\u0439, \u043c\u044b, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":22770,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30785","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u0442\u0440\u043e\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u0431\u043b\u043e\u043a\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439. \u041d\u0443\u043b\u0435\u0432\u043e\u0435 \u043f\u0440\u0438\u0431\u043b\u0438\u0436\u0435\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:37:25+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:37:25+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Byggesten til distribuerede applikationer. F\u00f8rste tiln\u00e6rmelse | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie","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\u0421\u0442\u0440\u043e\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u0431\u043b\u043e\u043a\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439. \u041d\u0443\u043b\u0435\u0432\u043e\u0435 \u043f\u0440\u0438\u0431\u043b\u0438\u0436\u0435\u043d\u0438\u0435 | ProHoster","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie","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":"2019-10-31T18:37:25+00:00","article:modified_time":"2019-10-31T18:37:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30785","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":"2026-02-22 15:31:13","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:29:56","updated":"2026-02-22 15:31:13","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\/30785","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=30785"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30785\/revisions"}],"predecessor-version":[{"id":162006,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30785\/revisions\/162006"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/22770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=30785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=30785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=30785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}