El tamaño y la escala del sistema juegan un papel importante en el registro de microservicios. Siga estas mejores prácticas para desarrollar una estrategia de registro sólida dentro de una arquitectura de microservicios.
por Bob Reselman
Una estrategia de registro de microservicios eficaz puede depender del tamaño y la escala del sistema en cuestión. Por ejemplo, una arquitectura orientada a microservicios compuesta por 20 microservicios es una carga de registro menor en comparación con una compuesta por 200 microservicios.
Los desarrolladores que esperan introducir una estrategia de registro de microservicios exitosa deben elaborar un plan que establezca dónde se lleva a cabo el registro y cómo afecta a otras áreas del sistema. El registro típico puede estresar un sistema de tres maneras: E / S, almacenamiento y cálculo analítico en la CPU.
Antes de que un equipo implemente una estrategia de registro de microservicios, debe considerar las tensiones potenciales en el sistema y lo que podría significar para el desarrollo adicional. Examinemos formas de aliviar las tensiones del sistema y algunas alternativas a las estrategias tradicionales de registro de microservicios.
Registrar datos en la máquina
La forma más sencilla de introducir el registro en una arquitectura orientada a microservicios es hacer que cada microservicio recopile y almacene sus datos de registro en la máquina donde se ejecuta. Este es probablemente el enfoque más fácil y simple para la tala, pero también está plagado de peligros.
El almacenamiento en una máquina local reduce significativamente la latencia de E / S porque toda la actividad tiene lugar en una ubicación única. Hay pocos viajes a la red, si es que hay alguno. Si bien el registro de datos en la máquina local ayuda a mejorar el rendimiento, existe una compensación.
El mayor almacenamiento coloca una carga significativamente mayor en la CPU de la máquina host. Los niveles más altos de actividad dan como resultado más registro, lo que a su vez crea más datos de registro almacenados en el sistema y aumenta los niveles de utilización de la CPU. Una máquina host se puede maximizar en poco tiempo en este escenario.
Afortunadamente, existen alternativas a esta estrategia de registro de microservicios.
Servicios de registro
Un servicio de registro puede ayudar a aliviar las preocupaciones sobre la utilización de la CPU y la reducción de la latencia de E / S.
El principal beneficio de un sistema de registro es que el almacenamiento y el trabajo se trasladan fuera del sistema a recursos de terceros. Todo lo que debe hacer el microservicio es realizar un viaje a la red para enviar entradas de registro.
Si bien esto no parece un gran problema en arquitecturas más pequeñas, puede ser problemático si hay 200 microservicios que se ejecutan en un entorno de múltiples réplicas de alta disponibilidad . En una situación como esta, muchos viajes a la red desde muchos orígenes pueden causar un cuello de botella y detener la comunicación de otras redes .
En este caso, existe otra alternativa que los equipos de desarrolladores deberían considerar.
La estrategia del coleccionista
Una estrategia de recopilador esencialmente cambia la forma en que las entradas de registro se envían dentro y fuera de la red.
En lugar de enviar cada entrada de registro a un servicio de registro, se envían a un recopilador central que reside en una máquina en otro lugar. En la mayoría de los casos, esta máquina se encuentra al menos en el mismo centro de datos de la arquitectura orientada a microservicios. En el mejor de los casos, la máquina está ubicada en el mismo bastidor del centro de datos que aloja los otros componentes de microservicios.
Los usuarios de microservicios alojados en la nube deberán consultar con su proveedor para identificar el mejor lugar para alojar el recopilador.
El coleccionista hace lo que su nombre indica. Recopila todas las entradas de registro emitidas por la arquitectura y luego las reenvía a un servicio de registro en un intervalo prescrito. Una vez que llegan las entradas, el recopilador descarga las entradas de registro antiguas del sistema al almacenamiento de respaldo.
Un beneficio importante de esta estrategia de registro de microservicios es que el recopilador absorbe la latencia de red en la que se incurre cuando envía las entradas de registro al servicio de registro. Además, debido a que el recopilador está cerca de los otros componentes de la arquitectura orientada a microservicios, reduce la latencia entre la arquitectura y el recopilador.
Sin embargo, todavía existen riesgos asociados con un recopilador de registros. Por ejemplo, si el recopilador de registros central falla, toda la actividad de registro se detiene.
Entonces, ¿cómo pueden los desarrolladores evitar este riesgo?
Clústeres de recopiladores
Los desarrolladores pueden crear un grupo de recopiladores que resida detrás de un equilibrador de carga común para aliviar las preocupaciones de los recopiladores de registros centrales fallidos.
Una ventaja de la estrategia del recopilador de registros con equilibrio de carga es que si un recopilador falla, los otros permanecerán operativos y permitirán que continúe el registro. Pero hay una compensación.
Esta estrategia requiere que un equipo apoye a un conjunto de recolectores en su red y, a su vez, agrega más gastos relacionados con el aumento de máquinas virtuales. Además, el entorno de registro se vuelve más complejo y requiere más trabajo preliminar de otros microservicios en el entorno.
En general, el quid principal del enigma del registro de microservicios es la escala. Si ejecuta una arquitectura más pequeña sin mucho registro, mantenga la actividad de registro en los mismos elementos de microservicios. Sin embargo, si ejecuta una arquitectura con muchos microservicios, una estrategia de registro más sofisticada tiene más sentido, a pesar de algunos posibles inconvenientes relacionados con el costo y el almacenamiento.
Fuente: https://www.theserverside.com/answer/What-makes-an-effective-microservices-logging-strategy
