-
Notifications
You must be signed in to change notification settings - Fork 0
3. Aspectos principales de los microservicios
Cuando en la llamada a una aplicación se requiere de la intervención de uno o mas microservicios es necesario emplear mecanismos que permitan conservar el estado de la sesión entre cada llamada y así poder aplicar la logica apropiada a cada una de estas. Similar a lo que ocurre con los ESBs y los servicios WEB SOAP con WS-Choreography, los microservicios en su mayoria construidos con interfaces REST utilizan también protocolos para orquestar estos flujos pero mucho menos complejos como es el caso Restish.
El riesgo de falla es una constante para los microservicios, ya que los clientes, el API Gateway y los servicios corren en procesos independientes es posible que el tiempo de respuesta a las llamadas no sea el apropiado debido a que el servicio no está disponible, esta sobre cargado o halla sobrepasado las capacidades de computo en ese instante. Para prevenir esos problemas los microservicios implementan las siguientes estrategias:
Network timeouts: esto permite que nunca se bloquee o espere indefinidamente, esto garantiza que los recursos no están bloqueados indefinidamente incluyendo los recursos del cliente. Limitar el número de peticiones: al imponer este límite se obliga al servicio que cuando se supera dicho valor, no se acepten más peticiones (devolviendo de inmediato un código de falla) y conservando la buena salud en los recursos para las llamadas en curso. Circuit breaker pattern: este mecanismo realiza un seguimiento al número de llamadas exitosas y fallidas. Si la rata de error para un servicio supera el valor de permitido de fallas, un interruptor se abre y dispara de forma automática para que las nuevas llamadas fallen de forma inmediata. Pasado un tiempo se permiten ciertas llamadas y si tienen éxito el interruptor se cierra el servicio regresa a un estado disponible.
Las aplicaciones basadas en microservicios son sistemas distribuidos, los cuales deben utilizar mecanismos de comunicación entre procesos. Una opción es utilizar un mecanismo asincrono basado en mensajería. Algunas implementaciones usan JMS, AMQP, Zeromq o Brokerless. La otra opcion es utilizar un mecanismo sincrono como HTTP o Thrift. Generalmente un API Gateway debe implementar las dos opciones debido a que las aplicaciones utilizan ambos mecanismos para multiples funciones.
Comunicación asíncrona (Comunicaciones basadas en mensajes): cuando un cliente envían un mensaje al servicio, si el servicio está activo este procesa el llamado y retorna una respuesta. En este modelo el cliente no se bloquea cuando espera la respuesta y el servicio no debe estar disponible el 100% del tiempo ya que quien garantiza la comunicación es el sistema de mensajería. Existen dos canales point-to-point y publish-subscribe el primero entrega el mensaje a exactamente un consumidor (microservicio) y el segundo entrega el mensaje a un grupo de consumidores (microservicios) que previamente se han subscrito al canal de modo durable o no durable (recibe todos los mensajes incluso los que se envíen durante un periodo en que el microservicio esta desconectado y solo recibe los mensaje durante el periodo en el que el microservicio está activo).
La comunicación síncrona: cuando un cliente envía un mensaje este se bloquea hasta que recibe la respuesta por parte del servicio, por lo que se asume que los tiempos de respuesta del microservicio son aceptables para el cliente. Existen dos protocolos REST y Thrift que son los más populares.
Para que los clientes de los servicios en la mayoría de los casos el enrutador conozcan que servicios están disponibles y cuál es su ubicación se implementa una base de datos de lo servicios donde se registran las instancias disponibles de un servicios.
En este caso cada instancia de un microservicio por sí misma es responsable de registrarse ante el Service Registry, este debe periódicamente renovar su subscripción para que el Service Registry sepa si el microservicio sigue disponible y además en caso de que se apague este debe retirar el registro del Service Registry.