Cuando sus microservicios comienzan a "tartamudear", tal vez el problema esté oculto en algún lugar invisible.

Imagínese esto: ha creado un sistema bastante bueno, con una clara división del trabajo entre microservicios, y debería funcionar tan fluidamente como una sinfonía bien orquestada. Pero no sé cuándo la velocidad de respuesta comenzó a disminuir, la carga de la página siguió dando vueltas y ocasionalmente aparecían varios errores de tiempo de espera. Verificó el código y amplió las especificaciones del contenedor, pero el problema era como una niebla que se dispersaba por un tiempo y luego volvía a reunirse.

En este momento, ¿alguna vez pensó que el cuello de botella puede no ser el cálculo, sino los datos que van y vienen?

Almacenamiento en caché: no es una decoración opcional, sino el motor oculto del rendimiento

En el mundo de los microservicios, los servicios frecuentemente se comunican entre sí. Una solicitud de usuario puede requerir que cinco o seis servicios se soliciten entre sí para explicar la respuesta. Cada consulta es un viaje por la red, una consulta a la base de datos. Cuando el tráfico aumenta, la carretera se congestiona.

Lo que hace el caché es en realidad muy simple: almacenar temporalmente las respuestas más frecuentes en un lugar más cercano al solicitante. La próxima vez que alguien haga la misma pregunta, el sistema ya no tendrá que viajar largas distancias para comprobarlo, simplemente podrá dar la respuesta anterior. Es como tener un bloc de notas público en una oficina ocupada. Quien necesite buscar un número de uso frecuente puede simplemente echar un vistazo al bloc de notas sin tener que buscar los archivos cada vez.

Pero el almacenamiento en caché en microservicios es mucho más que simplemente "poner un bloc de notas". Tiene que decidir qué se debe registrar, cuánto tiempo recordarlo, cuándo actualizarlo y también garantizar que los datos vistos por múltiples servicios sean consistentes. Bien hecho, es un acelerador; Si se hace de manera descuidada, se convierte en una fuente de caos de datos.

¿Por qué su solución de almacenamiento en caché podría no funcionar tan bien como debería?

Inicialmente, mucha gente pensó que para el almacenamiento en caché, ¿no sería suficiente agregar Redis o Memcached? Pero cuando realmente lo usé, me di cuenta de que las cosas no eran tan sencillas.

Por ejemplo, "penetración de caché": alguien sigue consultando datos que no existen en absoluto y no están en el caché. La solicitud llega a la base de datos subyacente cada vez, abrumando la base de datos. Otro ejemplo es la "avalancha de caché": una gran cantidad de cachés fallan al mismo tiempo, todas las solicitudes llegan instantáneamente a la base de datos y el sistema puede paralizarse en el acto. También existe un problema de "coherencia de datos" más sutil: el servicio A actualiza los datos, pero el caché del servicio B sigue siendo una versión antigua y la información vista por el usuario es inconsistente.

Detrás de estos problemas, a menudo se debe a que la estrategia de almacenamiento en caché se trata como un parche agregado posteriormente, en lugar de un componente central diseñado desde el principio.

Una idea de diseño más integrada en la textura.

En lugar de tratar el almacenamiento en caché como un complemento independiente, debería ser parte de la forma en que los servicios se comunican entre sí. Para algunas solicitudes, los resultados no cambiarán en el corto plazo, así que no dude en almacenarlos en caché; para algunos datos, es aceptable un pequeño retraso, luego actualice de forma asincrónica. La clave es dejar claro durante el diseño de la arquitectura qué datos son adecuados para el almacenamiento en caché, con qué granularidad y cómo invalidarlos y sincronizarlos correctamente.

Esto requiere el apoyo de herramientas, pero también requiere un cambio de mentalidad. Las herramientas deberían ayudarle a implementar esta idea, no añadir nueva complejidad.

¿Cómo funciona en un escenario de la vida real?

Veamos un escenario común: una página de detalles de un producto necesita llamar a servicios de usuario, servicios de inventario, servicios de precios, servicios de evaluación, etc. Si no se realiza ningún procesamiento, será necesario recorrer esta cadena de llamadas cada vez que se abra la página.

¿Qué pasa si se introduce una capa de almacenamiento en caché razonable? La información del usuario puede almacenarse en caché durante 12 horas, el estado del inventario durante 30 segundos y los precios y reseñas durante 5 minutos. Diferentes tiempos de vencimiento corresponden a diferentes frecuencias de cambio de datos. El tiempo de carga de la página se puede reducir de cientos de milisegundos a decenas de milisegundos. Detrás de este cambio hay una reducción significativa en la presión de la base de datos y una mejora en la flexibilidad general del sistema.

Por supuesto, esto requiere un ajuste fino: ¿qué datos vale la pena almacenar en caché? ¿Cuánto tiempo se almacena en caché? ¿Cómo se activa el mecanismo de actualización? Estas decisiones se basan en una comprensión profunda de la lógica empresarial, no solo de la configuración técnica.

A la hora de elegir, ¿hacia dónde deben mirar tus ojos?

Debe ser lo suficientemente liviano para que el proceso de inserción no pueda convertirse en un nuevo desastre de ingeniería. Es mejor encajar de forma natural en los procesos de desarrollo existentes en lugar de que el equipo aprenda un nuevo conjunto de conceptos complejos desde cero.

Es menos intrusivo para el código comercial. Los ingenieros deben centrarse en la lógica empresarial en sí en lugar de gastar mucha energía en gestionar manualmente cada regla de caché. En este caso son especialmente importantes los mecanismos de invalidación y actualización automatizados e inteligentes.

Además, la observabilidad es esencial. Debe poder ver claramente cuál es la tasa de aciertos de la caché, cuántas solicitudes se guardan y qué estrategias de almacenamiento en caché son más efectivas. La transparencia puede aportar un control real.

Debe resistir la prueba del tráfico real. La solución en sí no puede convertirse en un nuevo punto único de falla. Debe tener un diseño de alta disponibilidad y poder permanecer estable bajo presión.

dar un paso adelante

Cuando el sistema se ralentiza, la gente instintivamente quiere actualizar el hardware y el código. Esto es ciertamente cierto. Pero a veces, la palanca más eficaz se esconde en el modelo de comunicación de la arquitectura. Al ahorrar datos de viajes innecesarios y reducir la duplicación de trabajo entre servicios, el potencial del sistema puede liberarse más allá de sus expectativas.

No se trata de agregar un componente tecnológico interesante, sino de reexaminar la eficiencia del flujo de datos. Cuando se empieza a pensar en el almacenamiento en caché no sólo como una opción tecnológica, sino como una filosofía de diseño, es posible que surjan de forma natural las respuestas a muchos cuellos de botella.

En el mundo de los microservicios, la velocidad a menudo no depende de qué tan rápido se ejecuta un solo servicio, sino de qué tan inteligentemente colaboran. La estrategia de almacenamiento en caché adecuada es la parte que hace que esta colaboración sea más inteligente y menos laboriosa. No es ruidoso, pero es vital.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en la tecnología de accionamiento modular,kpotenciaintegra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas.kpotenciaha entregado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.