.png){kind=small}
.png){kind=small}
Este artículo cubre los principales temas que le ayudarán a tomar mejores decisiones sobre cómo crear microservicios y si su negocio realmente necesita esta arquitectura en este momento.
Cuando pensamos en los microservicios, lo primero que tenemos que considerar es: ¿Puedo dividir mi aplicación/solución/negocio en pequeñas partes? Esto significa pensar en muchas cosas, como por ejemplo si nuestra solución será capaz de trabajar sin dependencia, es decir, si cada servicio es independiente, ¿trabajará por separado y realizará una sola tarea?
Uno de los principios más importantes de los microservicios es que un servicio debe realizar una sola tarea. Si se rompe esta regla, pueden surgir problemas cuando haya que refactorizar el código. Nuestro objetivo es crear servicios que puedan trabajar por separado, sin ninguna agregación o acoplamiento. Esto significa que el servicio puede trabajar de forma independiente.
1-Sigue siendo independiente?
2-Sigue realizando una sola tarea?
Si puedes responder afirmativamente a estas dos preguntas, estás en el camino correcto hacia las mejores prácticas en microservicios. Pero puedes encontrarte con que en algunas situaciones es necesaria la comunicación entre dos o más microservicios u otros tipos de aplicaciones. A veces, necesitas devolver información que está en un contexto diferente y tu microservicio no tiene acceso directo.
Este tipo de situación no es ideal cuando trabajamos con microservicios. Si uno de los servicios no está disponible o no da la respuesta que esperabas, puedes tener problemas, como información incompleta o excepciones en tu código y normalmente, los datos son tan importantes que sin ellos, todo tu servicio puede ser incapaz de completar su tarea. En estas situaciones, tienes que crear artefactos que puedan hacer frente a ellas.
Para resolver este problema, tenemos que construir una solución que tenga en cuenta nuestros requisitos de negocio. Los requisitos funcionales son esenciales; definen el comportamiento del servicio, o lo que puede o no puede hacer. Al considerar la usabilidad, la escalabilidad, el rendimiento y otros requisitos no funcionales, también hay que tener en cuenta cómo va a funcionar el servicio, es decir, de forma sincrónica o asincrónica.
Si tienes un servicio síncrono que también tiene una dependencia de otro, y necesitas que este otro servicio entregue los datos en tiempo de ejecución, probablemente necesitarás un alto rendimiento entre estas dos peticiones, porque de lo contrario, esto podría resultar en una mala experiencia para tu usuario, o un timeout u otro tipo de excepción.
Cuando los servicios se desarrollan con mensajes, colas y temas, la comunicación entre ellos será asíncrona. Cuando un microservicio ha completado su parte del trabajo, publica su resultado en una cola o tema. Entonces otro microservicio, que estaba esperando, tomará este resultado y hará su parte del trabajo. De esta manera, podemos hacer que nuestra solución sea más independiente, para que no esté acoplada con todas las partes de nuestro sistema, como en una solución común o aplicación monolítica.
1-Solicitudes HTTP entre servicios;
2-Mensajes (colas y temas);
3-Comunicación basada en eventos;
Lo que hay que tener en cuenta al construir el servicio es: ¿el origen requiere la respuesta inmediatamente después de enviar la solicitud? (síncrono) o puede esperar a que el destino procese el mensaje, y luego responder publicando en otro mecanismo, como una cola? (asíncrono).
Puede que ahora te estés preguntando, ¿por qué debería considerar los microservicios como una solución para mi negocio?
La respuesta es: Los microservicios son útiles cuando se necesita construir un sistema que pueda funcionar fácilmente con un escalado flexible, un despliegue independiente, una entrega continua o varios equipos, o cuando se quiere ampliar el negocio de forma sencilla y fiable.
¿Te ha ayudado este contenido? Entonces comparte con tus amigos que también necesitan esa ayuda inicial con los microservicios.
