nous avons la conception de micro-services et nous avons DocumentService et DocumentReportService .
DocumentsService - obtenir des documents, rechercher des documents dans ELK.
DocumentsReportsService - générer des rapports dans doc, exporter au format PDF et par ex. et je souhaite utiliser à nouveau ELK comme stockage.
Question: ELK pour DocumentsService et DocumentReportService c'est 1 instance ELK ou 2?
3 Réponses :
Je suppose que votre question est de savoir s'il faut utiliser le même cluster ES pour les deux services ou un cluster séparé pour chacun.
Dans l'architecture Microservice, il est considéré comme une mauvaise pratique de "partager la base de données" - en pratique, cela signifie que plusieurs services ne devraient pas accéder aux mêmes objets de base de données car cela entraînerait un couplage étroit entre eux. Il est tout à fait possible que plusieurs services utilisent toujours la même instance physique de la base de données.
Donc, dans votre cas, si les deux services utilisent un index et un mappage séparés dans ES, ils pourraient utiliser le même cluster. Ce que vous devez éviter, c'est que les deux services lisent et écrivent sur le même mappage car cela conduira à un couplage étroit.
Je connais les mauvaises pratiques de partage de base de données. Que faire si les deux services utilisent l'index SAME dans ES?
Lorsque nous disons que le partage de base de données entre les services est une mauvaise pratique, ce que l'on entend généralement en termes de SGBDR est de partager la même table. Dans ES, un index est l'équivalent d'une base de données et un mappage est une table. Partager la cartographie (comme je l'ai déjà écrit) conduira à un couplage étroit. Rien de mal en soi à partager un index. Mais cela devrait également être motivé par d'autres considérations ( voir
DocumentReportService doit utiliser DocumentService au lieu de son propre ES.
ELK est également Elasticsearch, Logstash, Kibana
Si votre question est de savoir s'il faut utiliser le même cluster ES pour les deux services ou un cluster séparé pour chaque alors-
Je préconiserais l'affirmation «il n'y a pas de mauvaise conception». La conception doit toujours compléter vos besoins et en même temps être suffisamment simple à comprendre. N'oubliez pas le principe de conception KISS .
Microservices prend en charge les deux modèles de base de données
Les deux ont leurs avantages et leurs inconvénients. Mais ce qui ne doit pas être laissé de côté ou négligé lors de la conception dans des microservices est le contexte limité .
Dans votre cas, je suppose qu'une version plus simple du design pourrait être de garder des limites bien définies:
Service de documents : assume la responsabilité principale de l'interaction avec le magasin de documents (dans votre cas, la recherche élastique). Ce sont les services qui récupèrent et si besoin stocke le document dans la banque de documents. Garder le service de documents le seul à interagir avec le magasin de documents vous donne un avantage de vos autres services, vous n'avez pas besoin de vous soucier de savoir comment et où les documents sont stockés. Les autres services ne connaissent qu'un seul service qui englobe la responsabilité de fournir et de stocker des documents. Si, à l'avenir, vous souhaitez modifier votre magasin de documents, il peut être facilement modifié sans affecter aucun autre service de votre paysage. (par rapport à lorsque de nombreux services interagissent avec votre magasin de données et si vous souhaitez modifier le magasin, tous ces services doivent intégrer les modifications). Ainsi, vous voyez comment la délimitation du contexte a rendu votre conception extensible.
Service de rapports : prend la responsabilité de générer un rapport. Il encapsule toute la logique métier de la création de rapports complets (générant uniquement). Ce service ne sait pas comment sont stockés les documents / rapports. ( Ce service se limite uniquement à la génération de rapports sans stockage de rapports )
voulez-vous vraiment dire ELK? ou vous vouliez dire par Recherche élastique (EL)