Microservicios. Conceptos Básicos

Cuales son las ventajas de utilizar la arquitectura monolítica en proyectos

Las muchas ventajas de usar la arquitectura de microservicios

Los motivos por los cuales no deberia usar microservicios en un proyecto que recae en el grupo de desventajas

Para que un programa cumpla con los requisitos de ser un verdadero microservicio, debe cumplir 6 principios de diseño de software

El contenido y la funcionalidad de los microservicios en términos de entrada y salida deben ser coherentes. Básicamente, debe tener un enfoque único, y lo que hace debería hacerlo bien con ese enfoque único. esta idea de un microservicio que tiene un solo enfoque o una sola responsabilidad en realidad se toma de los principios de codificación SOLID, y el principio de responsabilidad única básicamente establece que una clase solo puede cambiar por una razón, y este mismo principio se aplica a los microservicios. Es un principio útil porque nos permite controlar el tamaño del servicio y no crearemos accidentalmente un servicio monolítico adjuntando otros comportamientos en el microservicio que en realidad no están relacionados.

Los microservicios también deben ser autónomos. Por autónomo nos referimos a que un microservicio no debe estar sujeto a cambios debido a un sistema externo con el que interactúa o un sistema externo que interactúa con él. Básicamente, estamos diciendo que debería haber un acoplamiento flexible entre los microservicios y entre los microservicios y los clientes que usan los microservicios, y por acoplamiento flexible, queremos decir que un cambio en un microservicio no debería obligar a otros microservicios a cambiar oa otros clientes a cambiar. . Esto significa que los microservicios deben respetar los contratos y las interfaces con otros servicios y otros clientes, lo que básicamente significa que la forma en que se formatean las entradas y salidas para un microservicio no debe cambiar entre versiones porque eso podría romper cualquier otro servicio que intente interactuar con ese microservicio utilizando esas entradas. y salidas

Un microservicio también debe estar centrado en el dominio empresarial, y con esto, queremos decir que un servicio debe representar una función empresarial. La idea general es que un microservicio represente una función comercial o un dominio comercial, es decir, una parte de la organización, porque esto ayuda a determinar el alcance del servicio y controlar el tamaño del servicio. Esta es una idea que se toma del diseño impulsado por dominios. Básicamente, define un contexto delimitado, que básicamente contiene toda la funcionalidad que está relacionada con una parte específica del negocio a un dominio de negocio o una función de negocio, y define el contexto delimitado definiendo límites y uniones dentro del código. Básicamente, resalta las áreas donde existe la funcionalidad relacionada.

Otro principio de diseño clave para los microservicios es la resiliencia. Básicamente, necesitamos aceptar el fracaso cuando sucede. La falla puede deberse a que otro servicio no responde a su servicio, o puede ser una línea de conexión a otro sistema que se ha caído, o puede ser un sistema de terceros que no responde. Cualquiera que sea el tipo de falla, nuestro microservicio debe aceptar esa falla degradando la funcionalidad dentro de nuestro microservicio o utilizando la funcionalidad predeterminada.

Otro principio de diseño clave que debemos incorporar en nuestra arquitectura de microservicios es la idea de que nuestro sistema sea observable. Necesitamos una forma de poder observar la salud de nuestro sistema en términos de estado del sistema, en términos de registros, es decir, una actividad que está sucediendo actualmente en el sistema y los errores que están sucediendo actualmente en el sistema. Y este tipo de monitoreo y registro debe estar centralizado para que haya un lugar al que debemos ir para ver esta información sobre el estado del sistema, y ​​necesitamos este nivel de monitoreo y registro en un lugar centralizado porque ahora tener transacciones distribuidas.

También necesitamos incluir automatización en nuestra arquitectura de microservicios, automatización en forma de herramientas, por ejemplo, herramientas para reducir las pruebas. Las pruebas automatizadas reducirán la cantidad de tiempo necesario para las pruebas de regresión manual y el tiempo necesario para probar la integración entre los servicios y los clientes, y también el tiempo necesario para configurar los entornos de prueba. Recuerde, en una arquitectura de microservicios, nuestro sistema se compone de varias partes móviles y, por lo tanto, las pruebas pueden ser bastante complejas, y aquí es donde necesitamos herramientas de prueba para automatizar algunas de esas pruebas.

Dicho todo en pocas palabras y como repaso para memorizar