Dans un grand nombre d'articles, les microservices sources, entre autres, sont présentés comme un moyen de construire une solution évolutive. Regardons quelques exemples des raisons pour lesquelles ce n'est pas le cas. Et nous essaierons également de contribuer à la question séculaire:
Quel est le meilleur: monolithe ou microservice?
Regardons un exemple.
Disons que nous avons un microservice (lambda) A
qui effectue les demandes d'autorisation "L'utilisateur a-t-il le droit d'effectuer l'opération?"
Étant donné qu'un tel microservice ne peut pas exister isolément, un autre microservice (lambda) existe en tandem avec lui B
, qui stocke une liste de correspondances de droits d'utilisateur dans le stockage.
Un diagramme approximatif des microservices (lambdas) est présenté dans la figure:
Les deux lambdas / microservices forment ensemble un microservice d'entité classique: qui encapsule le travail avec l'entité «utilisateurs».
Suite à des changements dans les données des utilisateurs (enregistrement de nouveaux utilisateurs, restrictions sur les utilisateurs existants, etc.), le microservice B
«surveille» la pertinence des données dans le stockage, que le microservice utilise A
pour répondre aux demandes d'autorisation.
Diagramme simple. Il est simplement arrangé, il fonctionne de manière fiable.
, , , . "" ?
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. , , .
? : , :
, ( , )
( )
- " , , ".
Et, sur la base de ce qui a été écrit, l'énergie de l'éternel différend «monolithe vs microservice» au stade du lancement du projet devrait être orientée vers le développement d'un entrepôt de données avec un accent initial sur la mise à l'échelle. Et en cours de développement, le monolithe et le microservice auront une architecture très similaire. Si similaires qu'il sera difficile de les distinguer les uns des autres.