Praktische Architekturmuster

Hallo Habr!


Angesichts der aktuellen Ereignisse wurde aufgrund des Coronavirus eine Reihe von Internetdiensten zunehmend ausgelastet. Beispielsweise hat eine der Einzelhandelsketten in Großbritannien die Website einfach mit Online-Bestellungen gestoppt , da nicht genügend Kapazität vorhanden war. Und es ist bei weitem nicht immer möglich, einen Server durch einfaches Hinzufügen leistungsfähigerer Geräte zu beschleunigen. Die Anforderungen der Kunden müssen jedoch bearbeitet werden (oder sie gehen an Wettbewerber).


In diesem Artikel werde ich kurz auf gängige Praktiken eingehen, mit denen Sie einen schnellen und fehlertoleranten Dienst leisten können. Aus den möglichen Entwicklungsschemata habe ich jedoch nur diejenigen ausgewählt, die jetzt einfach zu verwenden sind . Für jedes Element verfügen Sie entweder über vorgefertigte Bibliotheken oder Sie können das Problem mithilfe der Cloud-Plattform lösen.


Horizontale Skalierung


Das einfachste und bekannteste Produkt. Konventionell sind am häufigsten zwei Lastausgleichsschemata - horizontale und vertikale Skalierung. Im ersten Fall lassen Sie die Dienste parallel arbeiten und verteilen so die Last auf sie. Im zweiten Schritt bestellen Sie leistungsstärkere Server oder optimieren den Code.


Als Beispiel nehme ich einen abstrakten Cloud-Dateispeicher, dh ein Analogon zu OwnCloud, OneDrive und so weiter.


Das Standardbild eines solchen Schemas ist unten dargestellt, es zeigt jedoch nur die Komplexität des Systems. Schließlich müssen wir die Dienste irgendwie synchronisieren. Was passiert, wenn ein Benutzer eine Datei von einem Tablet speichert und sie dann von einem Telefon aus ansehen möchte?



: , — , .


CQRS


Command Query Responsibility Segregation , , . , ( ) . : . , A, .


— ( ) . - :


  1. .
  2. .
  3. .

, 2 ( , , ). , . CQRS, :


  1. .
  2. .
  3. « ».
  4. «1».


, . , request-response . , . , (, ), , .


, ( 100%) , , , .


, ( RX ). , , . .


, , . , , .


Event Sourcing


, , . ( ), , . , , — .


— , . , . eventual consistency, , - (« ») .


, , ( , ). - , — .


. eventual consistency, .



:


  • .
  • .
  • ( ).
  • "append only". .
  • FIFO ( ). , .

, . , , :



, . . : , .


(, , ):



:


  • . . , .
  • , . , «», . , , .
  • , . 1% , (. ), , .

:



, Event Sourcing CQRS. , , , , , . , . , , «», , « ». , , (, ). « ».


:


  • : « » : « » « ». , ( , ).
  • - , , , . : request-response, , . , , . : .

Sharding


, event sourcing . - . , :


  • . , / .
  • . - ,


, . , , , . « » , , , , :


  • Event Source ( — ). — id .
  • , ( — , , — , ). , , .
  • ( ).
  • (.. ), .

, , . eventual constistency, , (, , ). , , .


, , :


  • , . .
  • . , Enterprise ( ). sharding . , (, Azure self hosted).
  • — . ( ). — , . , .. , .

Static Content Hosting


, - . : , , , . , ( nginx , , Java-). CDN (Content Delivery Network) , .


— . — , CDN , .


- . ( ), . — , ( ), . — ( , , ) , -. , :


  • URL . file_id + key, key — - , .
  • nginx :
    • . , .
  • : . , , . : IO , . Java , - Rust/C++ . ( ), IO .


( -), . , , , ( ).


( ): Jenkins/TeamCity, , Java. Java-, , . , " / ". : , ( , ), . IO. , , -, . , nginx' ( ).


, :



, . -, . , API .. , , , . ( ), . , , ( ). (- ).


, - . . , . , « », « ». , : , .



. VK Static Content Hosting . - Sharding ( ). Event Sourcing . , , CQRS , . .


, , ( , ). Sharding , , . CQRS - , RX. 10 web . Event Sourcing Apache Kafka. 10 , . Static Content Hosting: - ( , ), .


, , . , , , , , ( ), (, ).


: , , , . , , 100 ( , ..).


All Articles