Les instances d'un microservice mis à l'échelle horizontalement doivent-elles partager la base de données ?

Question

Dans le cas d'un microservice qui possède une base de données relationnelle et qui doit évoluer horizontalement, je vois deux approches pour le provisionnement du serveur de base de données :

• fournir à chaque instance du service sa propre instance de serveur de BD avec un cycle de vie de processus couplé

OU

• faire en sorte que les instances se connectent à un serveur de données indépendant partagé (par des instances identiques du même service) ou à un cluster.

Avec une architecture orientée événements et la première approche, chaque instance du microservice devrait traiter chaque événement et prendre les mesures appropriées pour modifier son propre état isolé. Cela semble inefficace.

Avec cette dernière approche, une seule instance doit traiter l'événement pour obtenir le même effet, mais sous la forme d'une mutation de l'état partagé. On doit s'assurer que chaque événement est traité par une seule instance du microservice donné (est-ce trivial ?) pour éviter les conflits.

Y a-t-il un consensus sur l'approche préférée ici ? Quelles leçons votre expérience vous a-t-elle enseignées à ce sujet ?

Answer 1

J'opterais pour la première approche, une base de données locale de service. Chaque instance a sa propre instance de BD. Cela permet de changer la couche de persistance entre les versions du service. Changer le modèle ER autrement entraînerait des conflits. Cette approche vous permet également de passer facilement à une solution NoSQL.

Grâce à la conception axée sur les événements, je peux recommander ce livre : Conception de systèmes pilotés par événements

Comme je le vois, un service reçoit une requête qui mène à un événement. Cet événement est consommé par les autres instances du service, donc la requête n'a pas besoin d'être traitée à nouveau, mais le résultat doit être copié dans l'état des instances.