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

Hej, Habr!<\/p>\n

<\/p>\n

I ljuset av den aktuella situationen p\u00e5 grund av coronaviruset har ett antal internettj\u00e4nster f\u00e5tt en \u00f6kad belastning. Till exempel, en av detaljhandelskedjorna i Storbritannien st\u00e4ngde bara ner sin webbplats f\u00f6r onlinebest\u00e4llningar,<\/a><\/noindex>, eftersom kapaciteten inte r\u00e4ckte till. Och det \u00e4r l\u00e5ngt ifr\u00e5n alltid m\u00f6jligt att snabba upp en server genom att helt enkelt l\u00e4gga till kraftfullare utrustning, \u00e4nd\u00e5 m\u00e5ste vi bearbeta kundernas f\u00f6rfr\u00e5gningar (eller s\u00e5 g\u00e5r de till konkurrenterna).<\/p>\n

<\/p>\n

I den h\u00e4r artikeln kommer jag kort att ber\u00e4tta om popul\u00e4ra metoder som kan hj\u00e4lpa till att skapa en snabb och motst\u00e5ndskraftig tj\u00e4nst. Men bland de m\u00f6jliga utvecklingsscheman har jag valt ut bara de som \u00e4r l\u00e4tta att anv\u00e4nda.<\/strong>F\u00f6r varje punkt har du antingen redan f\u00e4rdiga bibliotek, eller s\u00e5 finns det m\u00f6jlighet att l\u00f6sa uppgiften med hj\u00e4lp av en molnplattform.<\/p>\n

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

Horisontell skalning<\/h1>\n

<\/p>\n

Det enklaste och mest k\u00e4nda punkten. I allm\u00e4nhet finns det tv\u00e5 vanliga s\u00e4tt att f\u00f6rdela belastningen \u2014 horisontell och vertikal skalning. I det f\u00f6rsta fallet<\/a><\/noindex> l\u00e5ter du tj\u00e4nster arbeta parallellt, vilket f\u00f6rdelar belastningen mellan dem. I det andra<\/a><\/noindex> best\u00e4ller du kraftfullare servrar eller optimerar koden.<\/p>\n

<\/p>\n

Som exempel tar jag ett abstrakt molnlagringssystem f\u00f6r filer, det vill s\u00e4ga en analog till OwnCloud, OneDrive och s\u00e5 vidare.<\/p>\n

<\/p>\n

Den standardiserade bilden av en s\u00e5dan struktur nedan visar bara systemets komplexitet. F\u00f6r vi m\u00e5ste p\u00e5 n\u00e5got s\u00e4tt synkronisera tj\u00e4nsterna. Vad h\u00e4nder om en anv\u00e4ndare sparar en fil fr\u00e5n sin surfplatta och sedan vill titta p\u00e5 den fr\u00e5n sin telefon?<\/p>\n

<\/p>\n

\"Praktiska
\nSkillnaden mellan metoderna: vid vertikal skalning \u00e4r vi beredda att \u00f6ka kapaciteten hos noderna, medan vi vid horisontell skalning l\u00e4gger till nya noder f\u00f6r att f\u00f6rdela belastningen.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> \u00e4r ett ganska viktigt m\u00f6nster eftersom det g\u00f6r det m\u00f6jligt f\u00f6r olika kunder att inte bara ansluta till olika tj\u00e4nster, utan ocks\u00e5 att f\u00e5 samma fl\u00f6den av h\u00e4ndelser. Dess f\u00f6rdelar \u00e4r inte s\u00e5 uppenbara f\u00f6r en enkel applikation, men den \u00e4r extremt viktig (och enkel) f\u00f6r en belastad tj\u00e4nst. K\u00e4rnan i detta \u00e4r att inkommande och utg\u00e5ende datastreamar inte b\u00f6r korsas. Det vill s\u00e4ga att du inte kan skicka en f\u00f6rfr\u00e5gan och f\u00f6rv\u00e4nta dig ett svar, ist\u00e4llet skickar du en f\u00f6rfr\u00e5gan till tj\u00e4nst A men f\u00e5r svaret i tj\u00e4nst B.<\/p>\n

<\/p>\n

Den f\u00f6rsta f\u00f6rdelen med detta tillv\u00e4gag\u00e5ngss\u00e4tt \u00e4r m\u00f6jligheten att avbryta anslutningen (i bred mening av ordet) under processen av ett l\u00e5ngvarigt beg\u00e4ran. Som exempel kan vi ta en mer eller mindre standardiserad sekvens:<\/p>\n

<\/p>\n

    \n
  1. Klienten skickade en beg\u00e4ran till servern.<\/li>\n
  2. Servern p\u00e5b\u00f6rjade en l\u00e5ngvarig bearbetning.<\/li>\n
  3. Servern svarade klienten med resultatet.<\/li>\n<\/ol>\n

    <\/p>\n

    T\u00e4nk dig att det i punkt 2 intr\u00e4ffade ett avbrott i kommunikationen (antingen \u00e5teransl\u00f6t n\u00e4tverket, eller s\u00e5 bytte anv\u00e4ndaren till en annan sida och avbr\u00f6t anslutningen). I detta fall kommer det att vara sv\u00e5rt f\u00f6r servern att skicka svar till anv\u00e4ndaren med information om vad som faktiskt har behandlats. Genom att anv\u00e4nda CQRS kommer sekvensen att vara n\u00e5got annorlunda:<\/p>\n

    <\/p>\n

      \n
    1. Klienten har prenumererat p\u00e5 uppdateringar.<\/li>\n
    2. Klienten skickade en beg\u00e4ran till servern.<\/li>\n
    3. Servern svarade 'beg\u00e4ran mottagen'.<\/li>\n
    4. Servern svarade med resultatet genom kanalen fr\u00e5n punkt '1'.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Praktiska<\/p>\n

      <\/p>\n

      Som man kan se \u00e4r schemat n\u00e5got mer komplext. Dessutom saknas det intuitiva tillv\u00e4gag\u00e5ngss\u00e4ttet request-response h\u00e4r. Men som man kan se kommer ett avbrott i kommunikationen under behandling av beg\u00e4ran inte att leda till ett fel. Dessutom, om anv\u00e4ndaren verkligen \u00e4r ansluten till tj\u00e4nsten med flera enheter (till exempel med en mobiltelefon och en surfplatta), kan man se till att svaret kommer till b\u00e5da enheterna.<\/p>\n

      <\/p>\n

      Det intressanta \u00e4r att koden f\u00f6r behandling av inkommande meddelanden blir densamma (inte till 100%) f\u00f6r b\u00e5de h\u00e4ndelser som p\u00e5verkats av sj\u00e4lva klienten och f\u00f6r andra h\u00e4ndelser, inklusive fr\u00e5n andra kunder.<\/p>\n

      <\/p>\n

      Men i praktiken f\u00e5r vi ytterligare f\u00f6rdelar eftersom den enkla str\u00f6mmen kan behandlas p\u00e5 funktionellt s\u00e4tt (med RX och liknande). Och det \u00e4r redan en stor f\u00f6rdel, eftersom applikationen i stort sett kan g\u00f6ras helt reaktiv, dessutom med hj\u00e4lp av ett funktionellt tillv\u00e4gag\u00e5ngss\u00e4tt. F\u00f6r mer omfattande program kan detta avsev\u00e4rt spara resurser vid utveckling och underh\u00e5ll.<\/p>\n

      <\/p>\n

      Om man kombinerar detta tillv\u00e4gag\u00e5ngss\u00e4tt med horisontell skalning f\u00e5r vi bonusen av att kunna skicka beg\u00e4rningar till en server och f\u00e5 svar fr\u00e5n en annan. P\u00e5 s\u00e5 s\u00e4tt kan klienten sj\u00e4lv v\u00e4lja en tj\u00e4nst som passar dem, och systemet kan p\u00e5 insidan \u00e4nd\u00e5 korrekt bearbeta h\u00e4ndelser.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Som ni vet \u00e4r en av de fr\u00e4msta egenskaperna hos ett distribuerat system avsaknaden av gemensam tid och gemensam kritisk sektion. F\u00f6r en enskild process kan du g\u00f6ra en synkronisering (p\u00e5 samma mutexar), d\u00e4r du \u00e4r s\u00e4ker p\u00e5 att ingen annan k\u00f6r den koden. Men f\u00f6r ett distribuerat system \u00e4r detta riskabelt eftersom det skulle inneb\u00e4ra overhead och d\u00f6da hela sk\u00f6nheten i skalbarhet \u2013 alla komponenter skulle \u00e4nd\u00e5 v\u00e4nta p\u00e5 varandra.<\/p>\n

      <\/p>\n

      H\u00e4r f\u00e5r vi en viktig insikt \u2013 en snabb distribuerad system kan inte synkroniseras, f\u00f6r d\u00e5 minskar vi prestandan. \u00c5 andra sidan beh\u00f6ver vi ofta viss koherens mellan komponenterna. F\u00f6r detta kan vi anv\u00e4nda en metod med eventuell konsistens<\/a><\/noindex>, d\u00e4r det garanteras att, i avsaknad av data\u00e4ndringar under en viss tidsperiod efter den senaste uppdateringen, kommer alla f\u00f6rfr\u00e5gningar att returnera det senaste uppdaterade v\u00e4rdet.<\/p>\n

      <\/p>\n

      Det \u00e4r viktigt att f\u00f6rst\u00e5 att strikt koherens<\/a><\/noindex>ofta till\u00e4mpas p\u00e5 klassiska databaser, d\u00e4r varje nod har identisk information (detta uppn\u00e5s ofta n\u00e4r en transaktion anses vara genomf\u00f6rd f\u00f6rst efter ett svar fr\u00e5n den andra servern). H\u00e4r finns vissa undantag p\u00e5 grund av isoleringsniv\u00e5er, men den \u00f6vergripande essensen f\u00f6rblir densamma \u2013 du kan leva i en helt koherent v\u00e4rld.<\/p>\n

      <\/p>\n

      Men l\u00e5t oss \u00e5terg\u00e5 till den ursprungliga uppgiften. Om en del av systemet kan byggas med eventuell konsistens<\/a><\/noindex>, s\u00e5 kan vi bygga f\u00f6ljande schema.<\/p>\n

      <\/p>\n

      \"Praktiska<\/p>\n

      <\/p>\n

      Viktiga egenskaper hos denna metod:<\/p>\n

      <\/p>\n