Diario del arquitecto - Software de alta disponibilidad Practique esas cosas

Autor: JD Retail Liu Huiqing

I. Introducción

La alta disponibilidad de software es un tema común. "High Availability" (Alta disponibilidad) generalmente describe un sistema que ha sido especialmente diseñado para reducir el tiempo de inactividad mientras mantiene una alta disponibilidad de sus servicios. La fórmula de cálculo es: tasa de disponibilidad = ( tiempo total - tiempo no disponible ) / tiempo total.

Este artículo se centra en la perspectiva de la práctica de implementación como punto de entrada y lleva a todos a mostrar los pasos de implementación y los detalles de implementación de alta disponibilidad desde los aspectos de eficiencia de colaboración, implementación de tecnología y especificaciones de operación. Para facilitar la comprensión, primero unifiquemos el lenguaje y el vocabulario, y veamos las distintas etapas del proceso de entrega de software, como se muestra en la siguiente figura:



 

¿Por qué dice que la alta disponibilidad del software enfrenta muchos desafíos?

◦Desde el punto de vista del vínculo de entrega de demanda, para completar la entrega objetivo se requiere la estrecha cooperación de múltiples partes interesadas, como producto, I+D, pruebas, operación y mantenimiento, y operaciones. Para algunos requisitos del proyecto, a veces hay cientos de colaboradores, cada persona tiene diferentes responsabilidades, pero cooperan entre sí y se apoyan entre sí, si hay un error en algún enlace, la tasa de disponibilidad puede verse afectada;

◦Desde la perspectiva del tiempo, si desea lograr una tasa de disponibilidad anual del 99,99 %, significa que el tiempo permitido para fallas en un año es: 365*24*60*(100 %-99,99 %)=52 minutos, si Para lograr una tasa de disponibilidad de 5 nueves, el tiempo de falla permitido es de solo 5 minutos, que es casi el tiempo que se tarda en reiniciar la aplicación después de que encontramos el problema;

◦Desde la perspectiva de la eficiencia de la iteración, si no hay iteración ni en línea, la probabilidad de problemas será mucho menor. Existe una correlación negativa entre la eficiencia de la iteración del software y la disponibilidad. Equilibrar la relación entre los dos también enfrentará desafíos considerables.

En resumen, los problemas específicos a los que nos enfrentamos son los siguientes:

◦¿Cómo resolver el problema de muchos colaboradores y enlaces largos relacionados con la entrega de la demanda?

◦¿Cómo lidiar con el problema de la baja tolerancia al tiempo de inactividad?

◦ ¿ Cómo evitar que la tasa de disponibilidad se vea muy afectada en la situación actual de iteraciones frecuentes de la demanda?

2. Garantía de Eficiencia de la Colaboración

Malentendido cognitivo

De todo el enlace de entrega de demanda, podemos encontrar que a medida que el enlace aumenta paso a paso, habrá más ramas del enlace de transmisión de información y más profundo será el nivel de transmisión. Esto provoca dos problemas:

1. Se reduce la eficiencia de la transmisión de información;

2. La precisión de la información empeora.

El resultado final de estos dos problemas es la reducción de la eficiencia de la colaboración.





 

Un estudiante sin experiencia práctica a menudo pensará que aumentar el número de personas mejorará la eficiencia de la entrega de la demanda. De hecho, esta idea no es del todo correcta.Para la relación específica, consulte la siguiente figura:





 

Es como construir un edificio, si una persona lo construye paso a paso, tardará 100 días en completarse. Si se invita a 100 personas a ayudar, ¿se puede construir la casa en 1 día? la respuesta es negativa.

Hay costos de colaboración, tales como: comprensión del equipo (diseñadores, albañiles, albañiles, plomeros), emparejamiento de trabajos, control de riesgos;

Hay dependencias de proceso, por ejemplo: la construcción depende del diseño, y la decoración suave siempre viene después de la decoración dura;

Hay presupuestos de costos, tales como: gradiente de talento y escala de toda la organización (contratistas, agentes, contratistas);

Todo lo anterior no se resuelve simplemente colocando mano de obra.

Especificación del proceso

La lógica subyacente de mejorar la eficiencia de la colaboración es reducir el nivel del enlace de entrega y acortar el enlace de transmisión de información, asegurando así la precisión y la eficiencia de transmisión de la información. (Aquí no se ampliará el contenido del nivel de construcción organizacional)

Esto requiere la capacidad de hacer el trabajo de hoy y completar el trabajo de hoy. A nivel organizacional esto se denomina especificación de procesos, ya nivel personal se denomina métodos de trabajo y sentido de responsabilidad.

Trate de evitar retrasar el asunto actual al siguiente enlace, de lo contrario, afectará la programación y la eficiencia de entrega de los enlaces posteriores, e incluso puede ocurrir una repetición del trabajo en casos extremos. En resumen, piensa con claridad y no entierres el agujero. Los requisitos del producto son para I + D, el diseño de I + D es para pruebas y los casos de prueba son para cada nodo de entrega, como productos. Los entregables deben ser confiables.

Garantía de aterrizaje de tres tecnologías

En el ciclo de respuesta a la demanda, la implementación de alta calidad del diseño de arquitectura, implementación de codificación, lanzamiento seguro, implementación y operación y otras etapas de producción es la premisa y la base para la implementación de software de alta disponibilidad.

diseño arquitectónico

El diseño de la arquitectura a menudo afecta el costo de implementación inicial (ROI) del sistema y la dificultad de la operación y el mantenimiento posteriores. Pertenece al diseño de nivel superior del software, que incluye tanto el esquema de diseño macro como las restricciones de paradigma en los detalles de implementación. .

• Garantía de proceso

Invitar a los arquitectos a participar: invitar a los arquitectos a participar en los nodos de transacciones centrales y los principales cambios en la demanda, que es la forma más directa y efectiva de cerrar el tajo;

Énfasis en los documentos de diseño: una descripción clara del esquema y la aprobación de las partes interesadas relevantes son los requisitos previos para caminar por el camino correcto.

• Garantía de diseño

Diseño de recuperación ante desastres: es necesario reservar una salida, pensar claramente de antemano y hacer un buen trabajo en el diseño de recuperación ante desastres. Es posible revertir, fusionar, reintentar y degradar.

Diseño robusto: diseño sin estado, diseño antipesado, diseño idempotente, diseño de consistencia de datos

Implementación de codificación

Si el diseño arquitectónico es el esqueleto, la implementación del código son los nervios, los vasos sanguíneos y los músculos. El primero determina qué tan estable y cuánto tiempo puede caminar, mientras que el segundo determina qué tan rápido y qué tan lejos puede llegar. Implementado a nivel de codificación, es el grado de envejecimiento y corrupción del código.

• Especificación del proceso

Mecanismo de revisión de código: la revisión de código no es tan simple como encontrar problemas en el sistema. Es un comportamiento de largo plazo y una forma y vehículo para la implementación y herencia de la cultura organizacional. Durante el proceso de revisión, se aclararon los límites de las responsabilidades comerciales, el consenso de diseño y codificación, y el excelente consenso de investigación y desarrollo orientado a estándares. Equivale a dar orientaciones específicas a través de casos concretos, que son los pilares para asegurar la eficacia combativa del equipo.

Muchos problemas en el proceso de I+D se pueden descubrir y resolver a través del mecanismo de revisión de código, como:

◦ ¿ Cómo abordar el diseño y realización de requisitos temporales?

◦¿Qué opinas de la escritura de “Hello World!” en N?

◦ ¿Cómo entender los patrones de diseño y los límites de la ingeniería excesiva?

◦¿Cómo evaluar los entregables de la etapa actual?

◦ ¿Es necesario introducir pruebas unitarias?

• Estándares de codificación

◦¿Hay algún manejo de errores? Para los servicios externos llamados, ¿se verifican los valores de retorno o se manejan las excepciones?

◦ ¿ El diseño sigue un patrón de diseño conocido o un patrón comúnmente utilizado en el proyecto?

◦ ¿ Se puede implementar el nuevo código escrito por el desarrollador con las funciones del SDK/Framework existente? ¿Hay una función similar en este proyecto que pueda llamar sin volver a implementarlo todo?

◦ ¿ Se introducen en el proyecto funciones inútiles, duplicadas o dependencias de paquetes jar de diferentes versiones? (biblioteca json, varias utilidades)

◦¿Hay algún código inútil que se pueda eliminar?

◦ ¿ Qué tan legible es el código? ¿Hay suficientes comentarios?

◦ ¿ Hay algún error en el paso de parámetros, y hay alguna afirmación (Assert) o juicio para garantizar que las condiciones que creemos que son invariantes se cumplan realmente?

◦ ¿ Cómo se manejan las condiciones de contorno? ¿Cómo se maneja la rama predeterminada de la instrucción switch? ¿Es posible que el bucle tenga un bucle infinito?

◦¿Dónde se solicitan y liberan los recursos? ¿Existen posibles fugas de recursos (incluidos tiempos de espera, memoria, archivos, referencias a objetos, objetos grandes, cantidad de subprocesos, etc.)? ¿Hay espacio para la optimización?

◦ ¿ Qué tan efectivo es el código? ¿Cuál es el peor de los casos?

◦ En el código, especialmente en el bucle, ¿hay alguna parte obvia que se pueda optimizar (se pueden optimizar las operaciones de cadena con StringBuilder)?

◦ ¿ Se agotarán las llamadas al sistema y la red? ¿Como lidiar con?

◦ ¿ El código es fácil de probar (el número de líneas de método, la complejidad ciclomática y si la definición de los parámetros de entrada y salida es razonable)?

◦ ¿ El cambio afecta la versión anterior, los datos históricos y la compatibilidad ascendente?

◦ ¿ El diseño de la interfaz considera problemas como la idempotencia, la concurrencia, el alcance excesivo y la degradación?

◦ ¿ Hay problemas de almacenamiento en caché, rendimiento de la base de datos y problemas de coherencia de datos de múltiples fuentes de datos?

◦ ¿ El plan en línea considera el plan en escala de grises y el estado de datos inconsistentes?

seguro en línea

El 70% de las fallas en línea se desencadenan por algún tipo de cambio, y una proporción considerable de ellas son causadas por una conexión irregular. Por lo tanto, conectarse en línea de manera segura es muy importante.

• Especificación del proceso

◦ Está estrictamente prohibido conectarse a Internet con frecuencia: por ejemplo, no más de 2 veces por semana;

◦Está estrictamente prohibido conectarse en línea durante el período pico: reducir el alcance del problema;

◦ Está estrictamente prohibido conectarse en línea sin permiso: si hay un cambio, debe pasar la verificación de prueba y la confirmación de devolución del producto;

• Especificación del proceso

◦ Recoger tráfico: seleccione el primer lote de máquinas jsf fuera de línea/np para recoger tráfico (elija como modo de espera en frío);

◦ Mire el registro: observe el registro para confirmar que no hay tráfico en la máquina eliminada;

◦ Precalentamiento del servicio : confirme que la máquina se haya iniciado correctamente y que la interfaz comercial central debe precalentarse;

◦ Tráfico colgante: monte el tráfico de la máquina en línea;

◦ Mire los indicadores: observe si los indicadores mdc de la máquina en línea son anormales (cpu, memoria, carga) y si los registros son anormales

operación de despliegue

Un medio muy importante para lograr una alta disponibilidad es la redundancia de capacidad. La dirección y las ideas se dan a continuación, así como los detalles y estrategias de implementación específicos, que pueden ampliarse de acuerdo con situaciones específicas.

• red

◦A nivel de operador, China Unicom, China Telecom, China Mobile, etc.;

◦ Nodos de enlace , VIP, CDN, enrutador/conmutador, proxy inverso, cliente, navegador, etc.;

• almacenamiento

◦ Ya sea una arquitectura maestro-esclavo de base de datos o una arquitectura de copia de ES, es un medio para lograr una alta disponibilidad de almacenamiento, y los datos importantes deben hacer un buen uso de las características relevantes;

◦ Al diseñar la estructura de datos, también es necesario hacer un buen trabajo de estrategia de derivación, planificación de capacidad, división de datos o heterogeneidad. Por ejemplo: evite el almacenamiento en caché de teclas de acceso rápido, cuellos de botella en el rendimiento de la tabla de la base de datos, limitaciones en la cantidad de conexiones de la base de datos y otros problemas que afectan la alta disponibilidad.

• Servicio

◦Expansión horizontal : es muy importante que los servicios aseguren que la capacidad se pueda expandir agregando recursos;

◦ Agrupación de servicios : según las partes comerciales o los escenarios de uso, los servicios se aíslan en diferentes granularidades para evitar que situaciones extremas se afecten entre sí;

◦Estrategia extrema : Es principalmente una estrategia de defensa en situaciones anormales extremas, el propósito es mantener la confiabilidad del servicio tanto como sea posible después de que ocurra un accidente. Por ejemplo: límite de corriente, fusible, reintento, fallo rápido, etc.;

◦Estrategia de escala de grises : cuando se lanzan nuevas funciones, es más probable que ocurran problemas Tener capacidades maduras de tráfico en escala de grises es la clave para controlar el alcance de los problemas;

Garantía estándar de cuatro operaciones

Especificaciones de funcionamiento

1. Puede monitorear : estado de funcionamiento del sistema

2. Puede llamar a la policía : la situación anormal puede notificar al personal relevante del sistema

3. Se puede ubicar : después de que ocurre un problema, la causa del problema se puede ubicar rápidamente

4. Reparable : en caso de una situación anormal, el problema se puede reparar a la primera;

Plan de emergencia

La alta disponibilidad significa poca tolerancia para el tiempo de inactividad, significa que no hay tiempo para solucionar problemas y reparar, y no hay tiempo para abrir el código para solucionar problemas de vulnerabilidad. Esto requiere que tengamos un conjunto completo de planes de emergencia, que pueden resolver la mayoría de los problemas de fallas previsibles.

• Especificación del proceso

◦ reanudar la producción primero;

◦ Segunda solución de problemas;

Para obtener el manual detallado de manejo de emergencias de accidentes, consulte la siguiente figura:





 

• Especificación del proceso

◦Desarrolle planes correspondientes en tres dimensiones: red, servicio y almacenamiento, y complete la lista de planes de emergencia (nombre de archivo: lista de verificación) en su propia base de código para mantener el contenido heredado y actualizado;

◦ Previsibilidad , es decir, los escenarios desencadenantes de problemas deben escribirse claramente. Ejemplo: De acuerdo con el progreso actual (10.000/día), con el aumento de los datos de la base de datos, se estima que después de 10 meses aparecerán consultas lentas en la tabla de la base de datos (nombre de la tabla xxx);

◦ Alcanzabilidad , la capacidad de eliminar soluciones a los problemas. Ejemplo: inicie la tarea de archivo de datos históricos (xxxWorker) y transfiera los datos históricos a la base de datos de archivo;

Cumplimiento estándar

Por muy buenos que sean el proceso y las normas, debe haber un mecanismo correspondiente para implementarlas, de lo contrario, será una flor en el espejo, una luna en el agua, que se ve hermosa pero en realidad no sirve para nada. Ejecutable y medible son los requisitos previos para mejorar de acuerdo con los objetivos. Así que aquí hay una herramienta llamada "Tabla de autoinspección periódica de alta disponibilidad y cumplimiento" para ayudar en la implementación de la especificación.

cinco resumen

Este artículo aborda la pregunta "¿Por qué existe un gran desafío en la alta disponibilidad?", enfatiza la importancia de la eficiencia de la colaboración en el proceso de entrega de la demanda y señala por qué es necesario seguir el principio de trabajo de "El trabajo de hoy, el trabajo de hoy". ". Desde los aspectos de diseño de arquitectura, implementación de codificación, lanzamiento seguro, implementación y operación, etc., presenta en detalle las pautas y los detalles de implementación relacionados con la garantía de implementación de tecnología. Finalmente, desde la perspectiva de la operación posterior al lanzamiento, brinda herramientas prácticas de garantía de operación, como un plan de emergencia, una tabla de autocontrol regular, etc. Espero que pueda ayudar a los lectores.

{{o.nombre}}

{{m.nombre}}