{"id":31137,"date":"2019-10-31T21:39:40","date_gmt":"2019-10-31T18:39:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ignite-service-grid-perezagruzka\/"},"modified":"2019-10-31T21:39:40","modified_gmt":"2019-10-31T18:39:40","slug":"ignite-service-grid-perezagruzka","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/ignite-service-grid-perezagruzka","title":{"rendered":"Ignite Service Grid \u2014 omstart","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

26. februar hadde vi meet-up om Apache Ignite GreenSource, hvor bidragsytere fra open source-prosjektet talte. Apache Ignite<\/a><\/noindex>. Et viktig arrangement for dette fellesskapet var ombyggingen av komponenten Ignite Service Grid<\/a><\/noindex>, som lar deg rulle ut brukertilpassede mikrotjenester direkte i Ignite-klyngen. Om denne krevende prosessen snakket Vyacheslav Daradur<\/a><\/noindex>, programvareingeni\u00f8r og bidragsyter til Apache Ignite i over to \u00e5r.<\/p>\n

\"Ignite
\n<\/a><\/noindex>
\nLa oss begynne med hva Apache Ignite egentlig er. Dette er en database som fungerer som et distribuert n\u00f8kkel\/verdi-lager med st\u00f8tte for SQL, transaksjoner og caching. I tillegg lar Ignite deg rulle ut tilpassede tjenester direkte i Ignite-klyngen. Utviklere f\u00e5r tilgang til alle verkt\u00f8yene som Ignite tilbyr \u2014 distribuerte datastrukturer, Messaging, Streaming, Compute og Data Grid. For eksempel, ved bruk av Data Grid forsvinner problemet med administrering av en separat infrastruktur for datalagring og de p\u00e5f\u00f8lgende kostnadene som f\u00f8lger med det.<\/p>\n

\"Ignite
\n
\nVed \u00e5 bruke API Service Grid kan du distribuere en tjeneste ved enkelt \u00e5 spesifisere distribusjonsskjemaet i konfigurasjonen samt selve tjenesten.<\/p>\n

Normalt er distribusjonsskjemaet en indikasjon p\u00e5 hvor mange instanser som skal distribueres p\u00e5 klyngeknutene. Det finnes to typiske distribusjonsskjemaer. Den f\u00f8rste er Cluster Singleton: til enhver tid vil det garantert v\u00e6re \u00e9n instans av brukertjenesten tilgjengelig i klyngen. Den andre er Node Singleton: p\u00e5 hver knute i klyngen er det rullet ut \u00e9n instans av tjenesten. <\/p>\n

\"Ignite
\n
\nBrukeren kan ogs\u00e5 spesifisere antallet instanser av tjenesten i hele klyngen og definere et predikat for \u00e5 filtrere relevante noder. I et slikt scenario vil Service Grid selv beregne optimal distribusjon for distribusjon av tjenester.<\/p>\n

I tillegg finnes det en funksjon som heter Affinity Service. Affinity er en funksjon som definerer forholdet mellom n\u00f8kler og partisjoner, samt forholdet mellom partisjoner og noder i topologien. Gjennom n\u00f8kkelen kan man bestemme primary-node der dataene lagres. P\u00e5 denne m\u00e5ten kan du assosiere din egen tjeneste med n\u00f8kkelen og cache-funksjonen. Ved endring av cache-funksjonen vil det skje en automatisk redesployering. Slik vil tjenesten alltid bli plassert n\u00e6r dataene den skal manipulere, og dermed redusere kostnadene ved tilgang til informasjon. Dette kan kalles en form for kolokalisert databehandling.<\/p>\n

N\u00e5 som vi har g\u00e5tt gjennom hva som er flott med Service Grid, vil vi fortelle om dens utviklingshistorie.<\/p>\n

Hva var tidligere<\/h2>\n

\nDen forrige implementeringen av Service Grid var basert p\u00e5 et transaksjonsreplikerende systemcache kalt Ignite. Med ordet \"cache\" i Ignite refereres det til et lagringsystem. Det er alts\u00e5 ikke noe midlertidig, som man kanskje ville tro. Selv om cachen er replikert og hver node inneholder hele datasettet, har cachen en partisjonert fremstilling. Dette er relatert til optimalisering av lagring. <\/p>\n

\"Ignite
\n
\nHva skjedde n\u00e5r en bruker \u00f8nsket \u00e5 deployere en tjeneste?<\/p>\n