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

Hallo, Habr!<\/p>\n

<\/p>\n

In het licht van de huidige gebeurtenissen als gevolg van het coronavirus, hebben verschillende internetdiensten een increased belasting ontvangen. Bijvoorbeeld, een van de winkelketens in het Verenigd Koninkrijk heeft simpelweg de website voor online bestellingen stopgezet<\/a><\/noindex>, omdat de capaciteit niet voldoende was. En het is niet altijd mogelijk om een server te versnellen door simpelweg krachtigere hardware toe te voegen, maar je moet wel de klantverzoeken verwerken (anders gaan ze naar de concurrentie).<\/p>\n

<\/p>\n

In dit artikel geef ik een korte uiteenzetting van populaire praktijken die het mogelijk maken om een snelle en fouttolerante service te cre\u00ebren. Ik heb echter uit de mogelijke ontwikkelingsschema's alleen de geselecteerd die momenteel gemakkelijk te gebruiken zijn<\/strong>. Voor elk punt heeft u ofwel al bestaande bibliotheken, ofwel de mogelijkheid om dit probleem op te lossen via een cloudplatform.<\/p>\n

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

Horizontale schaalvergroting<\/h1>\n

<\/p>\n

Het meest eenvoudige en algemeen bekende punt. In wezen zijn er twee vaak voorkomende manieren van load balancing \u2014 horizontale en verticale schaalvergroting. In het eerste geval<\/a><\/noindex> staat u de services toe om parallel te werken, waardoor de belasting tussen hen wordt verdeeld. In het tweede geval<\/a><\/noindex> bestelt u krachtigere servers of optimaliseert u de code.<\/p>\n

<\/p>\n

Als voorbeeld neem ik een abstracte cloudopslag voor bestanden, dus een soortgelijke dienst als OwnCloud, OneDrive, enzovoort.<\/p>\n

<\/p>\n

De standaardillustratie van een dergelijk schema staat hieronder, maar het laat alleen de complexiteit van het systeem zien. We moeten immers op de een of andere manier de services synchroniseren. Wat gebeurt er als een gebruiker een bestand vanaf een tablet heeft opgeslagen en het vervolgens vanaf een telefoon wil bekijken?<\/p>\n

<\/p>\n

\"Convenient
\nHet verschil tussen de benaderingen: bij verticale schaalvergroting zijn we bereid om de prestaties van de knooppunten te verhogen, terwijl we bij horizontale schaalvergroting nieuwe knooppunten toevoegen om de belasting te verdelen.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> is een vrij belangrijk patroon, omdat het verschillende klanten in staat stelt niet alleen verbinding te maken met verschillende services, maar ook dezelfde event streams te ontvangen. De voordelen zijn niet zo voor de hand liggend voor een eenvoudige applicatie, maar het is van cruciaal belang (en eenvoudig) voor een zwaar belaste service. De essentie is: inkomende en uitgaande datastromen mogen elkaar niet overlappen. Dat betekent dat u geen verzoek kunt sturen en een antwoord kunt verwachten; in plaats daarvan stuurt u een verzoek naar service A, maar ontvangt u het antwoord in service B.<\/p>\n

<\/p>\n

De eerste bonus van deze aanpak is de mogelijkheid om de verbinding (in de brede zin van het woord) te verbreken tijdens een langlopende aanvraag. Laten we als voorbeeld een meer of minder standaard volgorde nemen:<\/p>\n

<\/p>\n

    \n
  1. De klant heeft een verzoek naar de server verzonden.<\/li>\n
  2. De server is begonnen met een langdurige verwerking.<\/li>\n
  3. De server heeft de klant een resultaat gegeven.<\/li>\n<\/ol>\n

    <\/p>\n

    Stel je voor dat er in punt 2 een verbindingsonderbreking heeft plaatsgevonden (of het netwerk is opnieuw verbonden, of de gebruiker is naar een andere pagina gegaan en heeft de verbinding verbroken). In dit geval zal het voor de server moeilijk zijn om de gebruiker een antwoord te sturen met de informatie over wat precies is verwerkt. Bij het toepassen van CQRS zal de volgorde iets anders zijn:<\/p>\n

    <\/p>\n

      \n
    1. De klant heeft zich ingeschreven voor updates.<\/li>\n
    2. De klant heeft een verzoek naar de server verzonden.<\/li>\n
    3. De server antwoordde met 'verzoek ontvangen'.<\/li>\n
    4. De server heeft het resultaat via het kanaal van punt \u20181\u2019 verzonden.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Convenient<\/p>\n

      <\/p>\n

      Zoals je kunt zien, is het schema iets complexer. Bovendien ontbreekt de intu\u00eftieve aanvraag-reactie aanpak hier. Maar zoals te zien is, zal een verbindingsonderbreking tijdens de verwerking van een aanvraag niet leiden tot een fout. Bovendien, als de gebruiker daadwerkelijk vanaf meerdere apparaten is verbonden met de service (bijvoorbeeld vanaf een mobiele telefoon en een tablet), is het mogelijk om ervoor te zorgen dat het antwoord op beide apparaten aankomt.<\/p>\n

      <\/p>\n

      Het interessante is dat de code voor het verwerken van inkomende berichten hetzelfde wordt (niet voor 100%) zowel voor gebeurtenissen die door de klant zelf zijn be\u00efnvloed als voor andere gebeurtenissen, inclusief die van andere klanten.<\/p>\n

      <\/p>\n

      In de praktijk krijgen we echter extra bonussen doordat de eenrichtingsstroom in functionele stijl kan worden verwerkt (met RX en soortgelijke methoden). Dit is al een serieuze pluspunt, aangezien de applicatie in wezen volledig reactief kan worden gemaakt, met inachtneming van een functionele aanpak. Voor zware programma's kan dit aanzienlijk middelen besparen voor ontwikkeling en ondersteuning.<\/p>\n

      <\/p>\n

      Als we deze aanpak combineren met horizontale schaalbaarheid, krijgen we als bonus de mogelijkheid om verzoeken naar \u00e9\u00e9n server te sturen en antwoorden van een andere te ontvangen. Op deze manier kan de klant zelf de service kiezen die het beste bij hem past, terwijl het systeem intern de gebeurtenissen correct kan verwerken.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Zoals u weet, is een van de belangrijkste kenmerken van een verdeeld systeem het ontbreken van een gemeenschappelijke tijd en een gemeenschappelijke kritieke sectie. Voor \u00e9\u00e9n proces kunt u synchronisatie toepassen (op dezelfde mutexen), waarbij u zeker weet dat niemand anders deze code uitvoert. Voor een verdeeld systeem is dit echter gevaarlijk, omdat het overhead met zich meebrengt en bovendien de schoonheid van schaalvergroting verloren gaat \u2014 toch zullen alle componenten op elkaar moeten wachten.<\/p>\n

      <\/p>\n

      Hieruit kunnen we een belangrijke conclusie trekken \u2014 een snelle verdeelde systeem kan niet worden gesynchroniseerd, omdat dit de prestaties zou verminderen. Aan de andere kant is er vaak behoefte aan bepaalde consistentie tussen componenten. En daarvoor kan de volgende benadering worden gebruikt. eventual consistency<\/a><\/noindex>, waar wordt gegarandeerd dat, in de afwezigheid van gegevenswijzigingen gedurende een bepaalde periode na de laatste update (\u2018uiteindelijk\u2019), alle verzoeken de laatst bijgewerkte waarde zullen teruggeven.<\/p>\n

      <\/p>\n

      Het is belangrijk te begrijpen dat voor klassieke databases vaak wordt toegepast. strikte consistentie<\/a><\/noindex>, waarbij elke knoop dezelfde informatie bezit (dit wordt vaak bereikt wanneer een transactie als bevestigd wordt beschouwd pas na een antwoord van de tweede server). Hier zijn er enkele verslappingen vanwege isolatieniveaus, maar de essentie blijft dezelfde \u2014 u kunt leven in een volledig consistente wereld.<\/p>\n

      <\/p>\n

      Laten we echter terugkeren naar de oorspronkelijke taak. Als een deel van het systeem kan worden opgebouwd met eventual consistency<\/a><\/noindex>, kan de volgende schema worden gebouwd.<\/p>\n

      <\/p>\n

      \"Convenient<\/p>\n

      <\/p>\n

      Belangrijke kenmerken van deze benadering:<\/p>\n

      <\/p>\n