Por razones de confidencialidad, el nombre del sistema no se revela aquí.
fondo
Hay dos sistemas A y B. La entidad central entidad A del sistema A y la entidad central entidad B del sistema B tienen una relación de uno a muchos, a saber: entidad A : entidad B ~ 1 : N
Había un problema
- El número de solicitudes de los servicios A y B sigue siendo anormalmente elevado
- El tráfico de estos dos servicios fue más alto de lo habitual, y no hubo actividades comerciales especiales en ese momento que mejorarían significativamente la UV.
- La presión sobre la base de datos sigue aumentando y, finalmente, el número de conexiones mantenidas y el número de conexiones activas alcanzan el 100 %.
Comprobación y resolución de problemas
- Para los microservicios que mantienen una cantidad anormalmente alta de conexiones a la base de datos, realice un fusible para aliviar temporalmente la presión sobre la base de datos y estabilizar el funcionamiento normal de otros microservicios.
- De acuerdo con la lógica antiverificación anormal del microservicio, se encuentra el problema de la dependencia circular
- Extrajo aleatoriamente el id de rastreo de registro (id de rastreo) de una interfaz con el problema de dependencia circular antes mencionado, y encontró que el id de rastreo registró simultáneamente registros de solicitud en múltiples puntos de tiempo diferentes (brecha de milisegundos) para las dos interfaces, lo que indica que la solicitud fue efectivamente Dependencia circular entre estas dos interfaces
- publicar actualización
- Restauración de servicios rotos
¿Por qué aparece la alarma de tiempo de espera de la interfaz hasta que se llena la presión de la base de datos?
Si hay una dependencia circular, ¿debería haberse encontrado que la solicitud de interfaz falló durante la fase de prueba?
hay dos razones
- La configuración del tiempo de espera de la interfaz web es de 5 minutos y la configuración del tiempo de espera de la interfaz rpc es de 1 s.
- Tanto el sistema a como el sistema b tienen mecanismos tolerantes a fallas para errores en las interfaces dependientes correspondientes y devolverán automáticamente otra información normalmente cargada
solucion de largo plazo
- A nivel de lógica de negocios, trate de evitar la interdependencia de los dos sistemas, aquí es necesario combinar la lógica de negocios para analizar y resolver en detalle.
- Si dos microservicios dependen el uno del otro, considere si es más razonable fusionar los dos microservicios
- Si no se puede fusionar (por ejemplo, los dos sistemas no pertenecen a un límite de dominio; no pertenecen a la gestión de un equipo), la lógica del flujo inverso (la lógica que no se ajusta al flujo de datos principal ) se considerará lógica asíncrona y se acoplará libremente con el código central. Aquí, combinado con lógica de negocios, análisis específicos y soluciones específicas
- Es necesario revisar continuamente la arquitectura del microservicio , descubrir dependencias circulares a tiempo y tratarlas de acuerdo a la situación específica.
- En función de la capacidad de colorear el tráfico existente del marco, se agrega la lógica de conteo de rutas a nivel del marco y se emite una alarma cuando el conteo supera un cierto umbral (el umbral específico depende de la situación)
- Consulte la detección de bucle invertido del enrutador aquí
- Para las interfaces que dependen de servicios externos, realice una prueba de presión completa antes de conectarse para verificar qué reacciones en cadena ocurrirán en un entorno de alta presión. ¿Tiene efecto el disyuntor de degradación?
- La interfaz rpc para otros microservicios y el lado web deben definirse por separado. Para otras interfaces de microservicios, la capa inferior debe tratar de no depender de otros microservicios , de lo contrario, habrá una dependencia circular con enlaces mayores o iguales a 3 (un depende de b, b depende de c , c depende de a) es difícil de encontrar
pensar
En la arquitectura de microservicios, diferentes desarrolladores e incluso diferentes equipos son responsables de diferentes microservicios. Para los estudiantes de producto, apenas prestan atención a los problemas que generan las dependencias circulares, para ellos la forma correcta de pensar es cómo facilitar a los usuarios obtener información y operar procesos desde la perspectiva de los usuarios. Por lo tanto, es necesario que los estudiantes de I+D detecten y eviten los posibles riesgos de manera oportuna durante el proceso de desarrollo.
Por ejemplo, el esquema 5 anterior se utiliza como principio, por lo que incluso si el esquema técnico no se revisa deliberadamente, la mayoría de las dependencias circulares se pueden evitar.
Nota complementaria
De hecho, esta vez el problema también provocó el problema de la consulta lenta, lo que provocó que la presión de la base de datos esclava permaneciera al 100 %. Descubrimos y resolvimos el problema de la dependencia circular antes de descubrirlo, reduciendo la presión sobre la base de datos a tiempo. Teniendo en cuenta que este problema es relativamente fácil de encontrar (supervisión de consultas lentas de la base de datos), y para facilitar la discusión por separado del problema de dependencia circular, no se describe anteriormente.