In einer Vielzahl von Artikeln werden unter anderem Quellen-Microservices vorgestellt, um eine skalierbare Lösung zu erstellen. Schauen wir uns einige Beispiele an, warum dies nicht der Fall ist. Und wir werden auch versuchen, zur uralten Frage beizutragen:
Was ist besser: Monolith oder Microservice?
Schauen wir uns ein Beispiel an.
Angenommen, wir haben einen Microservice (Lambda) A
, der Autorisierungsanforderungen ausführt. "Hat der Benutzer das Recht, die Operation auszuführen?"
Da ein solcher Mikrodienst nicht isoliert existieren kann, existiert parallel dazu ein anderer Mikrodienst (Lambda) B
, der eine Liste von Benutzerrechtskorrespondenzen im Speicher speichert.
Ein ungefähres Diagramm der Mikrodienste (Lambdas) ist in der Abbildung dargestellt:
Beide Lambdas / Microservices bilden zusammen einen klassischen Entity-Microservice: Er kapselt die Arbeit mit der Entität "Benutzer".
Aufgrund von Änderungen der Benutzerdaten (Registrierung neuer Benutzer, Einschränkungen bestehender Benutzer usw.) B
"überwacht" der Mikrodienst die Relevanz der Daten im Speicher, die der Mikrodienst A
zur Erfüllung von Autorisierungsanforderungen verwendet.
Einfaches Diagramm. Es ist einfach angeordnet, es funktioniert zuverlässig.
, , , . "" ?
CPU
A
io-read/select
CPU
B
io-write
CPU . , :
, A
B
?
A
. RO- :
A
, .
: , B
master- , (io-write)?
. , . multi-master:
X
, , - ( - Y
), .
:
. .
, :
CPU
IO
, . , .
. - ( ).
.
:
, , . . , ( ) . , .
? , , ? .
, , , - .
: vs
/FaaS, :
, MVP . - MVP . , , .
- MVP. , , .
? : , :
, ( , )
( )
- " , , ".
Und basierend auf dem, was geschrieben wurde, sollte die Energie des ewigen Streits "Monolith vs Microservice" in der Projektstartphase auf die Entwicklung eines Data Warehouse mit einem anfänglichen Fokus auf Skalierung gerichtet werden. Und im Entwicklungsprozess werden der Monolith und der Mikroservice eine sehr ähnliche Architektur haben. So ähnlich, dass es schwierig sein wird, sie voneinander zu unterscheiden.