Introducción al análisis de requisitos: hablando de arquitectura (3) Temas de usabilidad

El artículo anterior introdujo varios indicadores de requisitos no funcionales y algunos estándares de la industria. Existe una confiabilidad
en los requisitos no funcionales , y un indicador asociado a ella se llama usabilidad.Este artículo hace algunas descripciones detalladas de la disponibilidad y confiabilidad en los requisitos no funcionales.

concepto

Cuando nos encontramos con proveedores de servicios en la nube en Internet, a menudo vemos este tipo de palabras en las presentaciones de productos: La disponibilidad de nuestro servicio alcanza el 99,99% ¿
Qué significa esta disponibilidad?

• Definición:
  Se refiere a la proporción de tiempo que el sistema funciona normalmente y puede usarse normalmente dentro de un período de tiempo.
  Por ejemplo, si un sistema opera normalmente durante 364 días dentro de un año y el tiempo de falla acumulado es de 1 día, entonces la disponibilidad es364/365 ≈ 99.7%
• La diferencia con la confiabilidad:
  la confiabilidad es el intervalo promedio entre dos fallas.
• Por lo general, los dos están relacionados, es decir, una buena confiabilidad generalmente tiene una alta disponibilidad.
  Sin embargo, hay excepciones, como la comparación de los dos escenarios siguientes:
  • Alta disponibilidad pero poca confiabilidad.
    Habrá un tiempo de inactividad cada minuto y volverá a la normalidad en 1 segundo. La disponibilidad es relativamente buena, ≈ 98.3%
    pero la probabilidad de falla es alta. El tiempo de servicio normal continuo es de solo 59 segundos, por lo que el la confiabilidad es pobre.
  • La confiabilidad es buena pero la disponibilidad no es alta. El
    tiempo de inactividad es una vez al día durante 2 horas cada vez. La disponibilidad es peor que el escenario anterior. ≈ 91.7%
    Pero la confiabilidad es mejor que el escenario anterior. Su tiempo de servicio normal continuo es de 22 horas.

medida

Por lo general, hay dos formas de medir la disponibilidad de un sistema de software:

basado en el tiempo

Uptime / (Uptime+Downtime)
es el tiempo de trabajo normal, dividido por el tiempo total

basado en la solicitud

Éxito/Total
es el número de respuestas exitosas, dividido por el número total de solicitudes

En las siguientes dos imágenes, el lado izquierdo enumera el tiempo de falla promedio de un sistema cuando se logra la disponibilidad, y el lado derecho muestra la disponibilidad de los compromisos comunes de servicios en la nube: En la imagen de arriba, podemos ver que

:

• Cuanto menor sea la disponibilidad, mayor será el impacto en los usuarios, y mientras más fallas, mayor será la probabilidad de quejas, quejas y pérdidas de los usuarios.
• La disponibilidad prometida por los proveedores de servicios en la nube no es alta. Al diseñar su sistema, también debe considerar el impacto de las fallas de los proveedores de servicios en la nube.
  Referencia:
  • Declaración de acuerdo de nivel de servicio de Alibaba Cloud SLA: https://help.aliyun.com/document_detail/56773.htm
    La disponibilidad del servicio de SMS solo promete ser del 95%, y la disponibilidad de almacenamiento puede alcanzar el 99,995%
  • Nube de Microsoft Azure: https://azure.microsoft.com/zh-cn/support/legal/sla/

Digresión:

• Cuando un proveedor de la nube falla, siempre que la duración no exceda la disponibilidad prometida, es básicamente una disculpa; incluso si excede, generalmente solo se compensa por la duración correspondiente de la falla, como 1 hora de falla, compensación por sus 3 horas de tiempo de uso del servicio en la nube, nada más.
  Por lo tanto, si sus datos se pierden, si no hay un gran problema, generalmente tiene que encontrar una solución por sí mismo.
  Se puede buscar: en 2018, el incidente de pérdida de datos CNC fronterizo ocurrió en Tencent Cloud, y el reclamo fue de decenas de millones, pero solo se pagaron 130,000.

• El servicio SaaS de mi empresa anterior se implementó en Alibaba Cloud. Cuando el servicio falló, el personal de marketing primero le dijo al usuario: Alibaba Cloud estaba inactivo nuevamente y luego se quejó con el jefe sobre el personal de I + D.

• La disponibilidad de la mayoría de los servicios web es 3 9 o inferior

Cómo mejorar la usabilidad

analisis de CASO

Supongamos que un sistema tiene una solicitud de inicio de sesión y necesita acceder a 4 bases de datos de base de datos (mysql/mongodb/cassandra/redis), se sabe que la disponibilidad de cada base de datos es del 99,9 %, como se muestra en la figura: ¿Cuál es la disponibilidad de esta solicitud?

?
La disponibilidad real de este sistema serial solicita: 99,9% a la 4ª potencia = 99,6%, lo que significa:
una sola DB está disponible al 99,9%, es decir, habrá 8,76 horas de indisponibilidad a lo largo del año;
pero después de 4 DB hacer serial solicitudes, dejando de estar disponible durante 35,04 horas a lo largo del año, y la probabilidad de fallo se ha cuadriplicado.

Además, hay otros servidores y redes en la figura. Suponiendo que la red es inestable y la disponibilidad de cada base de datos se reduce al 99,5 %, entonces: la disponibilidad de esta solicitud del sistema en serie se reduce a: 99,5 % a la 4ª potencia
= 98%
es equivalente a todo el año Hay 175.2 horas de indisponibilidad, un promedio de 14.6 horas de inactividad por mes

Formas de mejorar la usabilidad

Del caso anterior, se puede concluir que cuantos más módulos (microservicios) y middleware (base de datos, cola de mensajes, etc.) estén involucrados en un sistema, menor será la disponibilidad.
Entonces, ¿cómo mejorar la usabilidad?
La única respuesta es usar conexión paralela, es decir, redundancia de servicio, que es lo que solemos llamar balanceo de carga;

• Cálculo de disponibilidad del sistema en serie (2 nodos): A = p1 * p2
  Si la disponibilidad de ambos nodos es del 99 %, entonces A = 99 % * 99 % = 98,01 %
• Cálculo de disponibilidad de sistema paralelo (2 nodos): A = 1-(1-p1)*(1-p2)
  Si la disponibilidad de ambos nodos es del 99%, entonces A = 1-(1-99%) * ( 1- 99%) = 99,99%
  un nodo redundante, la disponibilidad es suficiente 从99%提升到99.99%, desde年故障87.6小时，降低到52分钟

Cómo realizar la conexión paralela del sistema:

• Para cada servicio, se implementa en múltiples servidores independientes;
• Hay una puerta de enlace en el front-end, que recibe la solicitud y la envía al nodo saludable según el estado de cada nodo del servicio.
• La puerta de enlace en sí también debe ser redundante. Por lo general, se utiliza un conjunto de mecanismos de elección para garantizar el estado de salud de la propia puerta de enlace. Los mecanismos de elección comunes incluyen el algoritmo Paxos y el algoritmo Raft, que se pueden buscar por sí mismos.

Dificultades:

• El diseño de la arquitectura es complejo e involucra la transformación de sistemas antiguos, algunos sistemas no soportan conexión paralela, como usar caché de memoria, usar Sesión, etc.;
• Para duplicar el costo, es necesario considerar integralmente el mercado del producto y los costos de desarrollo, los costos de implementación y los costos posteriores de operación y mantenimiento;
• Al usar contenedores, como K8S, debe prestar atención al hecho de que se deben implementar varias instancias (Pods) del mismo servicio en diferentes nodos de trabajo;
  encontré dos pods de un servicio en el mismo nodo y el resultado de este nodo se cae y todo el servicio no está disponible.

Identificar objetivos de optimización

Para mejorar la disponibilidad del sistema, en lugar de agregar ciegamente procesamiento paralelo a cada servicio y cada middleware, se deben seguir ciertos pasos:

• 1. Determinar los objetivos de usabilidad apropiados
  • Investigar las expectativas de los usuarios
  • Determinar los objetivos comerciales de la empresa (al menos el 99,9% de los productos ToB)
  • Consulte la escala y el nivel de servicio de los productos de la competencia.
• 2. Medir nuestro sistema
  Mediciones comunes, determinar indicadores, realizar puntos enterrados y recopilación de datos (como Proetheus), y luego realizar cálculos estadísticos, resultados estadísticos:
  avg, max, min, dev (diferencia promedio (∑|xx'|)÷ n ), cola larga (95, 99)

epílogo de usabilidad

Consulte la figura a continuación, que indica las tres etapas de la operación de un producto:

A través de esta figura, quiero decir:
no importa cuán asombrosos sean la arquitectura y el middleware de X, evolucionan gradualmente y se precipitan paso a paso. es muy humano . .

Refactorización continua...

En el próximo artículo, presentaré conceptos relacionados con el rendimiento y algunos métodos para encontrar problemas de rendimiento.