Problemas comunes de código en microservicios

Hola a todos!

Recientemente, en una conferencia de PGConf en Moscú, uno de los oradores demostró una arquitectura de "microservicio", mencionando de paso que todos los microservicios heredan de una clase base común. Aunque no hubo explicaciones para la implementación, parecía que en esta compañía el término "microservicios" no se entendía de la misma manera que los clásicos parecían enseñarnos. Hoy trataremos uno de los problemas interesantes: cuál puede ser el código común en los microservicios y si puede serlo.

¿Qué es un microservicio? Esta es una aplicación independiente. No es un módulo, no es un proceso, no es algo que simplemente se implementa por separado, sino una aplicación independiente, real y completa. Tiene su propia función principal, su propio repositorio en el git, sus propias pruebas, su propia API, su propio servidor web, su propio archivo README, su propia base de datos, su propia versión, sus propios desarrolladores.

Al igual que los contenedores, los microservicios comenzaron a usarse cuando la potencia informática de HW y la confiabilidad de las redes alcanzaron un nivel tal que puede permitirse una llamada de función que dura 100 veces más que antes, puede permitirse el consumo de memoria 100 veces más alto, puede permitirse el lujo para establecer a cada "abuela" no solo en un "departamento" separado, sino en una "casa" separada. Al igual que cualquier solución arquitectónica, la arquitectura de microservicios una vez más sacrifica el rendimiento, ganando en la mantenibilidad del código para los desarrolladores. Pero dado que la persona y la velocidad de su reacción permanecieron iguales, los sistemas continúan satisfaciendo los requisitos.

¿Por qué dividirse en aplicaciones separadas? Porque distribuimos parte de la complejidad del sistema ya a nivel de arquitectura del sistema. El proceso de programación generalmente habla de un "corte" gradual de la gran "pieza de complejidad" inicial, y la descomposición (en clases, módulos, funciones y, en nuestro caso, aplicaciones completas) es la implementación de parte de esta complejidad en forma de estructura. Cuando dividimos el sistema en microservicios, tomamos una decisión arquitectónica (exitosa o no), que los desarrolladores ya no necesitan tomar en el futuro al implementar partes específicas de la funcionalidad. Se sabe que este microservicio en particular es responsable del envío de correos electrónicos, y este, para autorización, ya se ha establecido, por lo que todas mis nuevas funciones "caen" en este patrón sin discusión.

Un aspecto clave de los microservicios es la mala conectividad. Los microservicios deben ser independientes de la palabra "completamente". No tienen estructuras de datos comunes, y cada microservicio puede / debe tener su propia arquitectura, tecnología, método de ensamblaje (y así sucesivamente). Por definición Porque es una aplicación independiente. Los cambios en el código de un microservicio no deberían afectar a los demás de ninguna manera, a menos que la API se vea afectada. Si tengo N microservicios escritos en Java, entonces no debería haber ningún factor limitante para no escribir el microservicio N + 1st en Python, si esto es repentinamente rentable por alguna razón. Están poco acoplados y, por lo tanto, un desarrollador que comienza a trabajar con un microservicio específico:

a) Supervisa de manera muy sensible su API, porque es el único componente visible desde el exterior;
b) Se siente completamente libre en la refactorización;
c) Comprender el propósito del microservicio (aquí recordamos acerca de SRP) e implementa una nueva función en consecuencia;
d) Selecciona el método de persistencia más adecuado;
etc.

Todo esto es bueno y suena lógico y armonioso, como muchas ideologías y teorías (y aquí el teórico ideológico pone fin y se va a cenar), pero estamos practicando. El código no tiene que estar escrito en martinfowler.com . Y tarde o temprano nos enfrentamos al hecho de que todos los microservicios:

• información de registro;
• contener autorización;
• Acceda a los corredores de mensajes
• devolver los mensajes de error correctos;
• debe comprender de alguna manera las entidades generales del sistema, si las hay;
• debe funcionar con un formato de mensaje común (y protocolo);

y hazlo de manera idéntica.

Y en algún momento, el arquitecto ideológico viene a trabajar por la mañana y descubre que por la noche apareció una "biblioteca" en el sistema, un nuevo repositorio con un código común que se utiliza en muchos microservicios. ¿Debería un arquitecto estar horrorizado?

Depende

Para evaluar correctamente la situación, debemos volver a la idea principal: los microservicios son una colección de aplicaciones independientes que interactúan entre sí a través de una API (de red). En esto vemos la principal ventaja y simplicidad de la arquitectura. Y no queremos perder esta ventaja bajo ninguna circunstancia. ¿El código general que se colocó en la "biblioteca" interfiere con esto? Veamos algunos ejemplos.

1. La clase de usuario (o alguna otra entidad comercial) vive en la biblioteca.

• es decir una entidad comercial no está encapsulada en un microservicio, sino que se distribuye de manera diferente (de lo contrario, ¿por qué ponerla en una biblioteca de código compartido?);
• es decir los microservicios se conectan a través de esta entidad comercial; cambiar la lógica de trabajar con una entidad afectará a varios microservicios;
• es malo, muy malo, no son microservicios en absoluto, aunque no es "una gran bola de lodo", pero muy rápidamente la visión del mundo del equipo dará lugar a una "gran bola de lodo distribuido";
• pero los microservicios en el sistema funcionan con los mismos conceptos, y los conceptos son a menudo entidades, o simplemente estructuras con campos, ¿qué debo hacer? lea DDD, se trata exactamente de cómo encapsular entidades dentro de microservicios para que no "vuelen" a través de la API.

Desafortunadamente, cualquier lógica de negocios colocada en una biblioteca compartida tendrá tal efecto. Las bibliotecas de códigos generales tienden a crecer, lo que da como resultado que el medio del sistema forme un "tumor" lógico que no pertenece a ningún microservicio en particular, y la arquitectura se bloquea. El "centro de gravedad lógica" del sistema comienza a moverse a un repositorio con un código común, y obtenemos una mezcla infernal de monolitos y microservicios, y no necesitamos ir allí en absoluto.

2. El código de análisis para el formato del mensaje se coloca en la biblioteca.

• El código es más probable en Java si todos los microservicios están escritos en Java;
• Si mañana escribo un servicio en Python, no podré usar el analizador, pero parece que no es un problema en absoluto, escribiré una versión de Python;
• Punto clave: si estoy escribiendo un nuevo microservicio en Java, ¿debo usar este analizador? Si, probablemente no. Quizás no estoy obligado, aunque, como desarrollador de microservicios, puede ser muy útil. Bueno, como si encontrara algo útil en el repositorio de Maven.

Un analizador de mensajes, o un registrador mejorado, o un cliente envuelto para enviar datos a RabbitMQ, es como ayudantes, componentes auxiliares. Están a la par con las bibliotecas estándar de NuGet, Maven o NPM. El desarrollador de microservicios es siempre el rey; decide si usar la biblioteca estándar, o hacer su propio código nuevo, o usar el código de la biblioteca auxiliar compartida. Cómo será más conveniente para él, porque escribe una APLICACIÓN SEPARADA E INDEPENDIENTE. ¿Puede un ayudante particular evolucionar? Tal vez probablemente tenga versiones. Deje que el desarrollador consulte una versión específica en su servicio, nadie lo obliga a actualizar el servicio, al actualizar los ayudantes, esta es una pregunta para quién apoya el servicio.

3. Interfaz Java, clase base abstracta, rasgo.

• O otra pieza de la categoría de "código roto";
• Es decir Estoy aquí, independiente e independiente, y una parte de mi hígado yace en otro lugar;
• Aquí aparece la coherencia de los microservicios a nivel de código, por lo que no lo recomendaremos;
• En las etapas iniciales, esto probablemente no traerá ningún problema tangible, pero la esencia del diseño arquitectónico es la garantía de comodidad (o incomodidad) en los años venideros.

El equipo que comienza a trabajar en un nuevo producto sienta las bases para la arquitectura y tiene la mayor influencia en las tendencias que tendrá el producto. Si los principios de SRP, descomposición exitosa, baja conectividad, etc. se incorporan inicialmente en el sistema, entonces tiene la oportunidad de continuar desarrollándose correctamente. De lo contrario, la aceleración centrífuga de los "factores de tiempo" (otro equipo, poco tiempo, parches urgentes, falta de documentación) arrojará este sistema más al margen más rápido de lo que parece.

La cuestión de un código común en microservicios sigue siendo difícil porque está asociada con algún tipo de compensación: sopesamos lo que será más rentable en el futuro: el grado de independencia de los microservicios, menos repeticiones en el código, las calificaciones de los ingenieros, la simplicidad del sistema, etc. Cada vez se trata de reflexiones y debates, que pueden conducir a diferentes decisiones arquitectónicas específicas. Sin embargo, resumamos algunas de las recomendaciones:

Recomendación 0: No llame a los microservicios cualquier cosa que se rompa en partes existentes de forma independiente. No todas las tablas con columnas son una matriz, usemos los términos correctamente.

Recomendación 1: es altamente deseable que los microservicios no tengan ningún código común.

Recomendación 2: si todavía hay un código común, que sea una colección (biblioteca) de "ayudantes" opcionales. El desarrollador del servicio decide si usarlos o escribir su propio código.

Recomendación 3: bajo ninguna circunstancia debe haber lógica de negocios en el código común. Toda la lógica de negocios está encapsulada en microservicios.

Recomendación 4: deje que la biblioteca de código común se diseñe como un paquete estándar (NuGet, Maven, NPM, etc.), con la opción de versionar (o, mejor aún, varios paquetes separados).

Recomendación 5: El "centro de gravedad lógica" del sistema siempre debe permanecer en los microservicios mismos, y no en el código común.

Recomendación 6: Si planea escribir en el formato de microservicios, concilie de antemano que el código entre ellos a veces se duplicará. Hasta cierto punto, nuestro "instinto SECO" natural debe ser suprimido.

Gracias por su atención y microservicios exitosos.