Rédaction d'un blog sur les microservices - Partie 1 «Description générale»

Dans cet article, je veux partager notre expérience avec SergeyMaslov pour résoudre des problèmes typiques en utilisant une architecture de microservices en utilisant l'exemple de la tâche «créer un blog» (dans l'espoir que le lecteur puisse imaginer comment le blog est organisé et cela ne devrait pas soulever de questions sur la fonctionnalité :)

Ainsi, notre blog sera composé de 5 microservices écrits en golang:

• API de passerelle (api-gw) - responsable du routage, de l'authentification, de la journalisation et du suivi des demandes
• Utilisateurs (utilisateur) - enregistrement / authentification des utilisateurs, journalisation, suivi des demandes
• Articles (post) - créer / lire / modifier / supprimer des articles (CRUD), journalisation, traçage et autorisation des demandes
• Commentaires - créer / lire / modifier / supprimer des commentaires (CRUD), journalisation, traçage et autorisation des demandes
• Catégories (catégorie) - création / lecture / modification / suppression de catégories (CRUD), journalisation, traçage et autorisation des demandes

L'application client (web / frontend) sera implémentée sur vue.js et interagira avec les microservices via l'API REST, et les microservices eux-mêmes interagiront entre eux via gRPC.

Comme stockage, nous utiliserons MongoDB.

Nous montrerons avec une cerise sur le gâteau comment garder la documentation de l'API (au format swagger) à jour dans un projet en développement actif avec un minimum de travail.

Diagramme des composants du blog

Chaque microservice sera implémenté dans un conteneur Docker distinct et le projet sera lancé à l'aide de docker-compose.

Faire immédiatement une réserve dans l'exemple, pour simplifier le processus de développement, je vais utiliser deux hypothèses qui ne devraient pas être utilisées en production.

• La base de données est déployée dans un conteneur Docker. Cette approche réduit la fiabilité du stockage (à l'exception du schéma discuté à HighLoad 2018).
• L'ensemble du projet est hébergé dans un référentiel git. Cette approche contredit l'un des principes de base de l'architecture de microservices - l'isolement, et augmente la probabilité de connectivité inter-composants.

Vous pouvez voir la démo du projet ici , et le code source ici .

Structure du projet

Comment sera construit le processus de développement

Comme je l'ai dit plus tôt, l'interaction entre les microservices sera basée sur gRPC. En résumé, gRPC est un cadre hautes performances développé par Google pour appeler des procédures distantes (RPC) - il fonctionne en plus de HTTP / 2. GRPC est basé sur le soi-disant protofile (voir l'exemple ci-dessous), dont la tâche principale est de déclarer deux choses sous une forme compacte:

• donner une liste complète des interfaces de service (analogiques des interfaces API);
• décrire ce qui alimente l'entrée de chaque interface et ce que nous obtenons à la sortie.

Ci-dessous, à titre d'exemple, le profil du service Category est donné.

syntax = "proto3"; package protobuf; import "google/api/annotations.proto"; //   Category service CategoryService { //  rpc Create (CreateCategoryRequest) returns (CreateCategoryResponse) { option (google.api.http) = { post: "/api/v1/category" }; } //  rpc Update (UpdateCategoryRequest) returns (UpdateCategoryResponse) { option (google.api.http) = { post: "/api/v1/category/{Slug}" }; } //  rpc Delete (DeleteCategoryRequest) returns (DeleteCategoryResponse) { option (google.api.http) = { delete: "/api/v1/category/{Slug}" }; } //   SLUG rpc Get (GetCategoryRequest) returns (GetCategoryResponse) { option (google.api.http) = { get: "/api/v1/category/{Slug}" }; } // rpc Find (FindCategoryRequest) returns (FindCategoryResponse) { option (google.api.http) = { get: "/api/v1/category" }; } } //------------------------------------------ // CREATE //------------------------------------------ message CreateCategoryRequest { string ParentId = 1; string Name = 2; string Path = 3; } message CreateCategoryResponse { Category Category = 1; } //------------------------------------------ // UPDATE //------------------------------------------ message UpdateCategoryRequest { string Slug = 1; string ParentId = 2; string Name = 4; string Path = 5; int32 Status = 6; } message UpdateCategoryResponse { int32 Status =1; } //------------------------------------------ // DELETE //------------------------------------------ message DeleteCategoryRequest { string Slug = 1; } message DeleteCategoryResponse { int32 Status =1; } //------------------------------------------ // GET //------------------------------------------ message GetCategoryRequest { string Slug = 1; } message GetCategoryResponse { Category Category = 1; } //------------------------------------------ // FIND //------------------------------------------ message FindCategoryRequest { string Slug = 1; } message FindCategoryResponse { repeated Category Categories = 1; } //------------------------------------------ // CATEGORY //------------------------------------------ message Category { string Slug = 1; string ParentId = 2; string Path = 3; string Name = 4; int32 Status = 5; } 

Maintenant que nous avons compris en termes généraux pourquoi un profil est nécessaire, voyons à quoi ressemblera le processus de développement de nos microservices:

1. Nous décrivons la structure du service dans le profil;
2. Nous démarrons le générateur de code (./bin/protogen.sh), il générera la partie principale du code serveur pour nous + il créera du code client, par exemple, pour l'API Gateway + il créera une documentation à jour au format swagger;
3. Tout ce que nous avons à faire de nos propres mains est d'écrire le code pour la mise en œuvre des interfaces dans un fichier spécial /protobuf/functions.go.

De plus, si nous voulons apporter des modifications à l'un de nos microservices, nous procédons selon l'algorithme ci-dessus: nous éditons le protofile, exécutons protogen, nous éditons l'implémentation dans functions.go, et les modifications «laisseront» automatiquement à la documentation et aux clients.

Suite dans l'article «Rédaction d'un blog sur les microservices, partie 2 de l'API de passerelle» .