{"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\/da\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Praktiske arkitekturmodeller","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hello, Habr!<\/p>\n

<\/p>\n

I lyset af de nuv\u00e6rende omst\u00e6ndigheder p\u00e5 grund af coronaviruset har en r\u00e6kke internettjenester oplevet \u00f8get belastning. For eksempel har et af supermarkederne i Storbritannien simpelthen stoppet sin online bestillingstjeneste,<\/a><\/noindex>fordi kapaciteten ikke var tilstr\u00e6kkelig. Det er ikke altid muligt at hurtigere servere ved blot at tilf\u00f8je mere kraftfuldt udstyr, men kundeforesp\u00f8rgsler skal behandles (ellers vil de tage til konkurrenterne).<\/p>\n

<\/p>\n

I denne artikel vil jeg kort gennemg\u00e5 popul\u00e6re praksisser, der kan skabe en hurtig og fejltolerant service. Jeg har dog kun udvalgt de udviklingsskemaer, som man i \u00f8jeblikket let kan bruge.<\/strong>For hvert punkt har du enten allerede eksisterende biblioteker eller muligheder for at l\u00f8se opgaven med en cloud-platform.<\/p>\n

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

Horiskontalt skalerings<\/h1>\n

<\/p>\n

Den mest enkle og velkendte tilgang. Betinget m\u00f8des der oftest to strategier for belastningsfordeling - horisontal og vertikal skalerings. I det f\u00f8rste tilf\u00e6lde<\/a><\/noindex> giver du tjenesterne mulighed for at arbejde parallelt, hvilket fordeler belastningen mellem dem. I det andet<\/a><\/noindex> bestiller du mere kraftfulde servere eller optimerer koden.<\/p>\n

<\/p>\n

For eksempel vil jeg tage en abstrakt cloud-lagringstjeneste, som er en analog til OwnCloud, OneDrive og s\u00e5 videre.<\/p>\n

<\/p>\n

Det standardbillede af et s\u00e5dant system er nedenfor, men det viser kun systemets kompleksitet. For vi skal finde en m\u00e5de at synkronisere tjenesterne p\u00e5. Hvad sker der, hvis en bruger gemmer en fil fra sin tablet, og derefter \u00f8nsker at se den p\u00e5 sin telefon?<\/p>\n

<\/p>\n

\"Praktiske
\nForskellen mellem metoderne: i vertikal skalerings er vi villige til at \u00f8ge kapaciteten af noderne, mens vi i horisontal skalering tilf\u00f8jer nye noder for at fordele belastningen.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> er et ret vigtigt m\u00f8nster, da det g\u00f8r det muligt for forskellige klienter ikke kun at tilslutte sig forskellige tjenester, men ogs\u00e5 at modtage de samme str\u00f8mme af begivenheder. Dets fordele er ikke s\u00e5 \u00e5benlyse for en simpel applikation, men det er ekstremt vigtigt (og enkelt) for en overbelastet service. Dets essens er: indg\u00e5ende og udg\u00e5ende datastreams m\u00e5 ikke krydse hinanden. Det vil sige, du kan ikke sende en foresp\u00f8rgsel og forvente et svar, i stedet sender du en foresp\u00f8rgsel til tjeneste A, men modtager svaret i tjeneste B.<\/p>\n

<\/p>\n

Den f\u00f8rste fordel ved denne tilgang er muligheden for at afbryde forbindelsen (i ordets brede forstand) under udf\u00f8relsen af en lang anmodning. Lad os tage en mere eller mindre standard sekvens som eksempel:<\/p>\n

<\/p>\n

    \n
  1. Klienten har sendt en anmodning til serveren.<\/li>\n
  2. Serveren har startet en lang behandling.<\/li>\n
  3. Serveren svarede klienten med resultatet.<\/li>\n<\/ol>\n

    <\/p>\n

    Forestill dig, at der i punkt 2 opstod et forbindelsesbrud (eller netv\u00e6rket genoprettede forbindelsen, eller brugeren gik til en anden side og afbr\u00f8d forbindelsen). I dette tilf\u00e6lde vil det v\u00e6re sv\u00e6rt for serveren at sende et svar til brugeren med oplysninger om, hvad der blev behandlet. Ved at anvende CQRS vil sekvensen v\u00e6re lidt anderledes:<\/p>\n

    <\/p>\n

      \n
    1. Klienten har tilmeldt sig opdateringer.<\/li>\n
    2. Klienten har sendt en anmodning til serveren.<\/li>\n
    3. Serveren svarede: \u00abAnmodning modtaget\u00bb.<\/li>\n
    4. Serveren svarede med resultatet gennem kanalen fra punkt \u00ab1\u00bb.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Praktiske<\/p>\n

      <\/p>\n

      Som det fremg\u00e5r, er skemaet lidt mere komplekst. Desuden er den intuitive anmodnings-svar tilgang frav\u00e6rende her. Men som det ses, vil et forbindelsesbrud under behandlingen af anmodningen ikke f\u00f8re til en fejl. Mere end det, hvis brugeren faktisk er tilsluttet tjenesten fra flere enheder (f.eks. fra en mobiltelefon og en tablet), kan man s\u00f8rge for, at svaret kommer til begge enheder.<\/p>\n

      <\/p>\n

      Det interessante er, at koden til behandling af indkommende meddelelser bliver ensartet (ikke 100%) b\u00e5de for de begivenheder, som kunden selv har p\u00e5virket, samt for de \u00f8vrige begivenheder, herunder dem fra andre kunder.<\/p>\n

      <\/p>\n

      Men i praksis f\u00e5r vi yderligere fordele, da den envejskommunikation kan behandles funktionelt (ved hj\u00e6lp af RX og lignende). Og dette er allerede en betydelig fordel, da applikationen i princippet kan g\u00f8res helt reaktiv, og endda anvende en funktionel tilgang. For st\u00f8rre programmer kan dette betydeligt spare ressourcer p\u00e5 udvikling og vedligeholdelse.<\/p>\n

      <\/p>\n

      Hvis man kombinerer denne tilgang med horisontal skalering, f\u00e5r vi muligheden for at sende anmodninger til \u00e9n server, men modtage svar fra en anden. P\u00e5 den m\u00e5de kan klienten selv v\u00e6lge den tjeneste, der er mest praktisk for dem, og systemet kan stadig korrekt behandle begivenhederne internt.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Som du ved, er en af de centrale egenskaber ved et distribueret system frav\u00e6ret af en f\u00e6lles tid og en f\u00e6lles kritisk sektion. For en enkelt proces kan du lave synkronisering (p\u00e5 de samme mutexer), hvor du er sikker p\u00e5, at ingen andre udf\u00f8rer denne kode. Men for et distribueret system er det farligt, da det vil kr\u00e6ve overhead, og hele sk\u00f8nheden ved skalerbarhed vil g\u00e5 tabt \u2014 alle komponenter vil stadig vente p\u00e5 den samme.<\/p>\n

      <\/p>\n

      Derfor f\u00e5r vi en vigtig konklusion \u2014 det er ikke muligt at synkronisere et hurtigt distribueret system, for da vil vi reducere ydeevnen. P\u00e5 den anden side har vi ofte brug for en vis konsistens mellem komponenterne. Og til dette kan vi anvende en tilgang med eventuel konsistens<\/a><\/noindex>, hvor det garanteres, at i frav\u00e6r af data\u00e6ndringer over en vis periode efter den seneste opdatering (\"i sidste ende\") vil alle foresp\u00f8rgsler returnere den senest opdaterede v\u00e6rdi.<\/p>\n

      <\/p>\n

      Det er vigtigt at forst\u00e5, at der ofte anvendes striks konsistens<\/a><\/noindex>, hvor hver node ejer den samme information (dette opn\u00e5s ofte, n\u00e5r en transaktion kun betragtes som bekr\u00e6ftet efter et svar fra den anden server). Der er dog nogle lempelser p\u00e5 grund af isolationsniveauer, men den overordnede id\u00e9 forbliver den samme \u2014 du kan leve i en helt konsistent verden.<\/p>\n

      <\/p>\n

      Men lad os vende tilbage til det oprindelige problem. Hvis en del af systemet kan bygges med eventuel konsistens<\/a><\/noindex>, kan vi bygge f\u00f8lgende skema.<\/p>\n

      <\/p>\n

      \"Praktiske<\/p>\n

      <\/p>\n

      Vigtige egenskaber ved denne tilgang:<\/p>\n

      <\/p>\n