{"id":80035,"date":"2020-05-02T13:42:54","date_gmt":"2020-05-02T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny"},"modified":"2020-05-02T13:42:54","modified_gmt":"2020-05-02T11:42:54","slug":"udobnye-arhitekturnye-patterny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Praktiske arkitekturm\u00f8nstre","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hei, Habr!<\/p>\n

<\/p>\n

I lys av de n\u00e5v\u00e6rende hendelsene p\u00e5 grunn av coronaviruset har flere internetttjenester begynt \u00e5 oppleve \u00f8kt belastning. For eksempel, en av detaljhandelskjeden i Storbritannia stoppet bare nettsiden for online bestillinger,<\/a><\/noindex>, fordi de ikke hadde nok kapasitet. Og det er langt fra alltid mulig \u00e5 \u00f8ke serverens ytelse bare ved \u00e5 legge til kraftigere utstyr, men foresp\u00f8rslene fra kundene m\u00e5 h\u00e5ndteres (eller s\u00e5 g\u00e5r de til konkurrentene).<\/p>\n

<\/p>\n

I denne artikkelen vil jeg kort fortelle om popul\u00e6re praksiser som kan gj\u00f8re tjenesten rask og robust. Men av de mulige utviklingsskjemaene har jeg bare valgt de som n\u00e5 er lette \u00e5 bruke.<\/strong>For hvert punkt har du enten eksisterende biblioteker eller muligheten til \u00e5 l\u00f8se oppgaven ved hjelp av en skyplattform.<\/p>\n

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

Horiskontal skalering<\/h1>\n

<\/p>\n

Det enkleste og mest kjente punktet. Man kan grovt sett si at de to mest brukte lastbalanseringsskjemaene er horiskontal og vertikal skalering. I det f\u00f8rste tilfellet<\/a><\/noindex> lar du tjenestene jobbe samtidig, og dermed fordeler du belastningen mellom dem. I det andre<\/a><\/noindex> bestiller du kraftigere servere eller optimaliserer koden.<\/p>\n

<\/p>\n

Som eksempel tar jeg en abstrakt skyfilerlagring, det vil si en slags analog av OwnCloud, OneDrive osv.<\/p>\n

<\/p>\n

Standardbildet av et slikt skjema er nedenfor, men det viser bare kompleksiteten i systemet. For vi m\u00e5 p\u00e5 en eller annen m\u00e5te synkronisere tjenestene. Hva skjer hvis brukeren lagret en fil fra nettbrettet og deretter \u00f8nsker \u00e5 se den fra telefonen?<\/p>\n

<\/p>\n

\"Praktiske
\nForskjellen mellom tiln\u00e6rmingene: i vertikal skalering er vi klare til \u00e5 \u00f8ke kraften i nodene, mens i horiskontal skalering legger vi til nye noder for \u00e5 fordele belastningen.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> er et ganske viktig m\u00f8nster, siden det lar forskjellige kunder ikke bare koble til forskjellige tjenester, men ogs\u00e5 motta lignende hendelsesstr\u00f8mmer. Dets fordeler er ikke s\u00e5 \u00e5penbare for en enkel applikasjon, men det er ekstremt viktig (og enkelt) for en tung belastes tjeneste. Dets essens: innkommende og utg\u00e5ende datastreamer skal ikke krysse hverandre. Det vil si at du ikke kan sende en foresp\u00f8rsel og forvente et svar, i stedet sender du en foresp\u00f8rsel til tjeneste A, men f\u00e5r svar i tjeneste B.<\/p>\n

<\/p>\n

Den f\u00f8rste fordelen med denne tiln\u00e6rmingen er muligheten til \u00e5 bryte forbindelsen (i vid forstand av ordet) under behandling av en lang foresp\u00f8rsel. La oss ta et mer eller mindre standard forl\u00f8p som eksempel:<\/p>\n

<\/p>\n

    \n
  1. Klienten sendte en foresp\u00f8rsel til serveren.<\/li>\n
  2. Serveren startet en lang behandling.<\/li>\n
  3. Serveren svarte klienten med resultatet.<\/li>\n<\/ol>\n

    <\/p>\n

    La oss anta at det skjedde en avbrudd i forbindelsen i punkt 2 (enten nettverket koblet fra igjen, eller brukeren gikk til en annen side og br\u00f8t forbindelsen). I s\u00e5 fall vil det bli vanskelig for serveren \u00e5 sende svaret til brukeren med informasjonen om hva som ble behandlet. Ved \u00e5 bruke CQRS vil forl\u00f8pet v\u00e6re litt annerledes:<\/p>\n

    <\/p>\n

      \n
    1. Klienten abonnerte p\u00e5 oppdateringer.<\/li>\n
    2. Klienten sendte en foresp\u00f8rsel til serveren.<\/li>\n
    3. Serveren svarte 'foresp\u00f8rsel mottatt'.<\/li>\n
    4. Serveren svarte med resultatet gjennom kanalen fra punkt '1'.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Praktiske<\/p>\n

      <\/p>\n

      Som vi kan se, er oppsettet litt mer komplisert. Videre er den intuitive request-response-tiln\u00e6rmingen frav\u00e6rende her. Men som vi kan se, vil et avbrudd i forbindelsen under behandlingen av foresp\u00f8rselen ikke f\u00f8re til en feil. Dessuten, hvis brukeren faktisk er koblet til tjenesten fra flere enheter (for eksempel fra mobiltelefon og nettbrett), kan vi s\u00f8rge for at svaret kommer til begge enheter.<\/p>\n

      <\/p>\n

      Det interessante er at koden for h\u00e5ndtering av innkommende meldinger blir lik (ikke 100%) for b\u00e5de hendelser p\u00e5virket av klienten selv og for andre hendelser, inkludert fra andre kunder.<\/p>\n

      <\/p>\n

      Imidlertid f\u00e5r vi i praksis ytterligere fordeler ved at den \u00e9nveis str\u00f8mmen kan behandles p\u00e5 funksjonell m\u00e5te (ved hjelp av RX og lignende). Og dette er allerede en stor fordel, for i prinsippet kan applikasjonen gj\u00f8res helt reaktiv, samtidig som man bruker en funksjonell tiln\u00e6rming. For store programmer kan dette betydelig spare ressurser til utvikling og vedlikehold.<\/p>\n

      <\/p>\n

      Hvis vi kombinerer denne tiln\u00e6rmingen med horisontal skalering, f\u00e5r vi muligheten til \u00e5 sende foresp\u00f8rslene til \u00e9n server, men motta svar fra en annen. Dermed kan klienten selv velge den tjenesten som passer ham best, mens systemet internt fortsatt vil kunne h\u00e5ndtere hendelsene korrekt.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Som du vet, er en av hovedtrekkene ved et distribuert system frav\u00e6ret av felles tid og felles kritisk seksjon. For \u00e9n prosess kan du oppn\u00e5 synkronisering (med de samme mutexene), hvor du er trygg p\u00e5 at ingen andre utf\u00f8rer denne koden. Men for et distribuert system er dette risikabelt, da det vil kreve overhead, og alt det fantastiske med skalering blir \u00f8delagt \u2013 alle komponenter m\u00e5 vente p\u00e5 \u00e9n.<\/p>\n

      <\/p>\n

      Her f\u00e5r vi en viktig faktum \u2013 en rask distribuert system kan ikke synkroniseres, for da vil vi redusere ytelsen. P\u00e5 den annen side er det ofte n\u00f8dvendig med en bestemt konsistens av komponentene. Og for dette kan vi bruke tiln\u00e6rmingen med eventuell konsistens<\/a><\/noindex>, hvor det garanteres at, dersom det ikke skjer noen datamessige endringer over en viss periode etter den siste oppdateringen (\u00abtil slutt\u00bb), vil alle foresp\u00f8rslene returnere den siste oppdaterte verdien.<\/p>\n

      <\/p>\n

      Det er viktig \u00e5 forst\u00e5 at for klassiske databaser, benyttes ofte streng konsistens<\/a><\/noindex>, hvor hver node har identisk informasjon (dette oppn\u00e5s ofte n\u00e5r en transaksjon anses \u00e5 v\u00e6re etablert f\u00f8rst etter svar fra den andre serveren). Her finnes det noen lettelser p\u00e5 grunn av isolasjonsniv\u00e5er, men den generelle essensen forblir den samme \u2013 du kan leve i en helt konsistent verden.<\/p>\n

      <\/p>\n

      Men la oss g\u00e5 tilbake til den opprinnelige oppgaven. Hvis en del av systemet kan bygges med eventuell konsistens<\/a><\/noindex>, kan vi konstruere f\u00f8lgende skjema.<\/p>\n

      <\/p>\n

      \"Praktiske<\/p>\n

      <\/p>\n

      Viktige trekk ved denne tiln\u00e6rmingen:<\/p>\n

      <\/p>\n