Un article sur une mauvaise décision courante lors de la migration vers des microservices. Alors que Microsoft et d'autres entreprises envisagent de créer des services d'entité dans leurs didacticiels, il y a tout lieu de le considérer comme un anti-modèle. Ensuite, nous parlerons de ce qu'est un service d'entité et de ses propriétés pour le système final dans son ensemble.
Entity Service - qu'est-ce que c'est? Et comment naît l'idée de le créer?
Tout le monde a entendu dire que diviser un monolithe en microservices présente de nombreux avantages. Augmente la flexibilité, la simplicité, l'évolutivité, la tolérance aux pannes, etc. Cependant, on peut également entendre des critiques de l'approche microservice pour la complexité d'assurer la cohérence des données, car il est impossible de partager une transaction entre plusieurs microservices - ils communiquent via http. Et le système lui-même dans son ensemble devient complexe - il est beaucoup plus facile de supprimer les appels http et de tout combiner en un monolithe avec des appels ordinaires du code.
Cela suggère qu'il ne suffit pas de simplement briser le monolithe en plusieurs composants. Vous devez le faire correctement. Un monolithe typique fonctionne avec une base de données et contient plusieurs instances pour améliorer les performances et la tolérance aux pannes.
Supposons que notre monolithe soit une boutique en ligne. Il contient une liste de produits, vous pouvez vous inscrire en tant qu'utilisateur, passer une commande, payer et organiser la livraison. Une idée semble couper le monolithe en microservices. Il y a déjà des entités à l'intérieur du code monolithique - commande, produit, utilisateur, livraison, etc. Il est plus facile de les isoler en tant que microservices séparés. Il suffit de remplacer les appels dans le code par des appels via http, copier le code entité dans un nouveau service, faire une façade API, etc. En conséquence, nous obtiendrons un service pour les commandes, les utilisateurs, les marchandises, la livraison, etc.
Dans la figure, l'enregistrement des commandes et la planification de la livraison sont restés à l'intérieur de la façade, mais ils peuvent être déplacés vers des services distincts - dans notre exemple, ce n'est pas la chose la plus importante.
- Entity Service. , CRUD .
, ( ) entity . . .
:
. , ( ). , .
. - , . , . , - , - .
. , . Jaeger Jaeger: open source, end-to-end distributed tracing.
. , .
Microsoft : Creating a simple data-driven CRUD microservice
Entity Service?
entity service . ( ). :
;
, ;
, . , - ;
( , );
;
.
Entity Service :
API , . , - . , . . , .
entity service. , . , -, - :
- . - . - . , . , . . , , , . . .
. . , , . , , - - . . .
, , . - (immutability). - , . :
.
-.
-.
, .. .
(eventual consistency).
. , .
:
.
.
- . . , .
Une autre option à laquelle il convient de prêter attention est l'allocation de microservices par sous-domaines. Modèle: Décomposer par sous-domaine Il existe plus d'options pour la division en microservices selon le lien ci-dessus, mais il est logique de considérer les deux ci-dessus en premier lieu.
Les deux options vont bien ensemble - vous pouvez facilement les combiner. L'essentiel est d'éviter tous les inconvénients du service d'entité .
Avez-vous déjà rencontré cet anti-pattern dans votre pratique? Comment suggéreriez-vous de refactoriser les systèmes là où ils existent déjà? Posez des questions, exprimez vos pensées dans les commentaires. Votre avis est intéressant!