Escribir un blog de microservicios - Parte 1 "Descripción general"

En este artículo quiero compartir nuestra experiencia con SergeyMaslov para resolver problemas típicos usando la arquitectura de microservicios usando el ejemplo de la tarea "crear un blog" (con la esperanza de que el lector pueda imaginar cómo está organizado el blog y esto no debería plantear preguntas sobre la funcionalidad :)

Por lo tanto, nuestro blog constará de 5 microservicios escritos en golang:

• Gateway API (api-gw): responsable del enrutamiento, autenticación, registro y rastreo de solicitudes
• Usuarios (usuario): registro / autenticación de usuarios, registro, seguimiento de solicitudes
• Artículos (publicación): crear / leer / modificar / eliminar artículos (CRUD), registro, seguimiento y autorización de solicitudes
• Comentarios: crear / leer / modificar / eliminar comentarios (CRUD), registro, seguimiento y autorización de solicitudes
• Categorías (categoría): creación / lectura / cambio / eliminación de categorías (CRUD), registro, seguimiento y autorización de solicitudes

La aplicación cliente (web / frontend) se implementará en vue.js e interactuará con microservicios a través de la API REST, y los microservicios en sí interactuarán entre sí a través de gRPC.

Como almacenamiento usaremos MongoDB.

Mostraremos con una guinda separada sobre el pastel cómo mantener actualizada la documentación de la API (en formato swagger) en un proyecto en desarrollo activo con una mano de obra mínima.

Diagrama de componentes del blog

Cada microservicio se implementará en un contenedor Docker separado, y el proyecto se lanzará usando docker-compose.

Inmediatamente haga una reserva en el ejemplo, para simplificar el proceso de desarrollo, usaré dos supuestos que no deberían usarse en la producción.

• La base de datos se implementa en un contenedor acoplable. Este enfoque reduce la confiabilidad del almacenamiento (con la excepción del esquema discutido en HighLoad 2018).
• Todo el proyecto está alojado en un repositorio git. Este enfoque contradice uno de los principios básicos de la arquitectura de microservicios: el aislamiento y aumenta la probabilidad de conectividad entre componentes.

Puede ver la demostración del proyecto aquí , y el código fuente aquí .

Estructura del proyecto

Cómo se construirá el proceso de desarrollo

Como dije anteriormente, la interacción entre microservicios se construirá sobre la base de gRPC. En pocas palabras, gRPC es un marco de alto rendimiento desarrollado por Google para llamar a procedimientos remotos (RPC): funciona sobre HTTP / 2. GRPC se basa en el llamado protofile (ver ejemplo a continuación), cuya tarea principal es declarar dos cosas en una forma compacta:

• dar una lista completa de interfaces de servicio (análogas de interfaces API);
• describa lo que se alimenta a la entrada de cada interfaz y lo que obtenemos en la salida.

A continuación, como ejemplo, se proporciona el protofile del servicio Categoría.

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; } 

Ahora que hemos descubierto en términos generales por qué se necesita un protofile, veamos cómo se verá el proceso de desarrollo de nuestros microservicios:

1. Describimos la estructura del servicio en el protofile;
2. Iniciamos el generador de código (./bin/protogen.sh), generará la parte principal del código del servidor para nosotros + creará código de cliente, por ejemplo, para API Gateway + creará documentación actualizada en formato swagger;
3. Todo lo que tenemos que hacer con nuestras propias manos es escribir el código para la implementación de las interfaces en un archivo especial /protobuf/functions.go.

Además, si queremos realizar cambios en uno de nuestros microservicios, procedemos de acuerdo con el algoritmo anterior: editamos el protofile, ejecutamos el protogen, editamos la implementación en functions.go, y los cambios "se irán" automáticamente a la documentación y a los clientes.

Continúa en el artículo "Escribir un blog en microservicios, parte 2 de Gateway API" .