Experiencia de optimización y registro de evolución de arquitectura de proyecto de complemento de máscara de alta concurrencia
Piedra Makihara
Autor: Yang Mu original (apodo original, cría de animales), expertos en tecnología de la nube de Ali, años de experiencia en depuración de aplicaciones y sistemas operativos, profundo conocimiento teórico, experiencia práctica. Actualmente se centra en el ajuste del rendimiento de Linux, los clústeres de contenedores y las redes de sistemas.
Este artículo ha sido autorizado por el autor original para ser publicado en la cuenta pública "Program Ape Stone", con ligeros cambios en base al texto original.
antecedentes
Al inicio de la epidemia, el gobierno de un lugar determinado decidió entregar un lote de máscaras gratis a los ciudadanos de la ciudad, y los ciudadanos de esta ciudad pueden hacer una cita para la recolección de forma gratuita. El horario de la cita es de 9 am a 12 am. Por lo tanto, esta escena es una escena de compras urgentes por tiempo limitado y enfrentará un tiempo muy grande. Para el problema del gran tráfico y la gran concurrencia, durante la implementación del proyecto, se hicieron algunos registros y reflexiones sobre la evolución de la arquitectura involucrada.
Diagrama de arquitectura y análisis-V1
Ilustración y análisis de la arquitectura original (Arquitectura original alrededor de las 22:00 p.m. 
del 2 de febrero ) Arquitectura original alrededor de las 22:00 p.m. del 2 de febrero
- El cliente usa el protocolo HTTPS para acceder directamente a ECS;
- Use Nginx en ECS para monitorear el puerto HTTPS 443;
- Nginx invierte Tomcat, Nginx procesa archivos estáticos y Tomcat procesa solicitudes dinámicas;
- El programa primero va a Redis para verificar la caché, si hay una falla, va a la base de datos para consultar los datos, al mismo tiempo, la sincronización de datos entre Redis y Mysql es controlada por el programa.
Este diseño de arquitectura:
- Ventajas: fácil de administrar, fácil de implementar;
- Desventajas: bajo rendimiento, sin escalabilidad y un solo punto de riesgo; el
resultado: resulta que la aplicación se colgó inmediatamente tan pronto como se conectó y la página de citas se filtró por razones desconocidas, lo que provocó que el servicio colgar antes de la hora de la cita.
Diagrama y análisis de arquitectura-V2
Luego intervenimos y ajustamos la arquitectura. Nos pedimos alrededor de las 24:00 para iniciar el servicio a las 9 a.m. El tiempo es demasiado ajustado, la tarea es demasiado pesada y el programa no se puede mover. Cómo hacer la arquitectura concurrente de ¿cientos de miles?
La arquitectura alrededor de las 9 am del 3 de febrero, y la arquitectura fue restaurada el 4) La arquitectura 
alrededor de las 9 am del 3 de febrero
- Conéctese a SLB, amplíe la capacidad de carga horizontalmente a través del espejo;
- Acceso a la arquitectura de la base de datos de separación de lectura y escritura, separación automática de lectura y escritura a través de la base de datos de Alibaba Cloud y sincronización automática de datos;
- Ajuste el protocolo Nginx;
- El clúster en espera de la misma arquitectura está habilitado (se crean dos registros A para la resolución de nombres de dominio);
- Al analizar el registro de acceso, se encontró que el motivo del error estaba en el punto de obtener el SMS, iniciar sesión e inicializar la cookie.
Este diseño de arquitectura:
- Ventajas: mayor disponibilidad y mayor capacidad de carga;
- Desventajas: Estimación de tráfico insuficiente, las páginas estáticas también están en ECS, por lo que el ancho de banda de salida de SLB una vez alcanzó el valor máximo de 5.XG, y la concurrencia fue tan alta como 22w +.
Resultado: el usuario no pudo abrir la página por un tiempo debido a demasiado tráfico. Al mismo tiempo, debido a la restricción del proveedor de servicios de nombres de dominio XX, el cliente no pudo agregar resoluciones por sí mismo y el servicio al cliente de El proveedor de servicios de nombres de dominio no pudo ser contactado esa noche, lo que provocó que el plan CDN quedara varado.Diagrama de arquitectura y análisis-V3
Arquitectura el 5 de febrero
- Acceso a CDN para descargar un ancho de banda ultra grande;
- Cancelar el proxy Nginx;
- Desarrollé un plan de conmutación de recuperación de desastres para que el nuevo programa no pudiera conectarse a tiempo (no esperaba que se usara);
- Utilice un grupo de servidores virtuales para cambiar entre programas nuevos y antiguos, pero la desventaja es que un backend SLB de supervisión de siete capas solo puede colgar 200 máquinas, y no más SLB pueden retenerlo, lo que hace que el programa antiguo se cuelgue de nuevo cuando se acaba tomado;
- El día 5, utilicé esta arquitectura para conectarme en línea. El inventario se agotó en 7 minutos y la experiencia fue extremadamente fluida. El nuevo programa desarrollado por estudiantes saludables es realmente genial.
Este diseño de arquitectura:
- Ventajas: CDN carga el tráfico de recursos estáticos, lo que reduce el ancho de banda de salida de SLB, y el efecto de las pruebas de estrés también es muy ideal;
- Desventajas: Requiere un nombre de dominio independiente adicional en la página, lo que implica un dominio cruzado. Cuando se abrió la prueba el día 4, se encontró que el almacenamiento y los SMS reservados regresaban distorsionados y se cambiaba urgentemente al programa anterior. , es decir, la arquitectura de segunda generación.
Diagrama y análisis de arquitectura ideal-V4
Arquitectura ideal
- CDN de acceso al nombre de dominio principal;
- CDN configura los protocolos Http y Https back-to-source para acceder a los diferentes monitoreos del SLB para cambiar entre los programas nuevos y antiguos La implementación específica es la correspondencia del protocolo back-to-source. Los diferentes monitores corresponden a diferentes programas.
Este diseño de arquitectura:
- Ventajas: la aceleración estática reduce el ancho de banda SLB, retorno dinámico a la fuente, sin problemas de dominio cruzado, conmutación conveniente;
- Desventajas: aún debe configurarse manualmente y es inconveniente implementar ecs mediante la duplicación. Si hay suficiente tiempo, es muy bueno poder usar directamente la arquitectura del contenedor. Una escala se puede expandir a docenas o cientos de pods y nodos también se pueden expandir automáticamente.
para resumir
El tiempo es escaso y la tarea es pesada, y me he encontrado con muchos pozos:
- cuota de compra de vcpu;
- Cuota de montaje de back-end de SLB;
- Si el saldo del cliente es insuficiente, los atrasos se detendrán;
- La resolución del proveedor de servicios de nombres de dominio debe comunicarse con el servicio al cliente para agregar;
- Los problemas entre dominios no se consideraron cuando se consideró por primera vez la arquitectura CDN;
- Durante el desarrollo del nuevo programa, la biblioteca principal no estaba conectada a la prueba, lo que provocó la falla en línea (biblioteca principal distorsionada);
- La primera vez (No. 3) se suspendió, solo se trató del tráfico de SLB y no se analizaron en detalle los enlaces con más fallas;
- Falta la prueba de presión antes de conectarse, basándose únicamente en la función de prueba manual;
- La prueba de presión se basa en un Jmeter (PTS se introdujo en la tarde del 4 a la mañana del 5 para medir la presión);
- De repente recordó que el programa original del cliente se colocó en Windows, y el rendimiento de Windows + programa malo era realmente pobre;
- Este "pequeño proyecto" realmente costó unos pequeños cien mil antes y después, si lo hacemos por nosotros desde el principio, debería poder reducir el costo a la mitad.
Las estadísticas de resultados finales (análisis de muestreo, los datos reales son más grandes que esto): las últimas tres generaciones de las
estadísticas de resultados (análisis de muestreo) se
pusieron en línea, se utilizaron 150 máquinas con fines de seguro, pero basadas en observaciones durante el evento y los resultados de la prueba de presión Se estima que 50 máquinas deberían poder resistir. Desde fallar durante 5 horas y ser regañado por los usuarios finales, hasta los elogios de los líderes que se agotaron en 7 minutos, incluso después de 3 batallas nocturnas, todavía puedo sentir vagamente, el cuerpo y la mente se subliman.Varias notas de optimización
Optimización de parámetros
- Sintonización de red
net.ipv4.tcp_max_tw_buckets = 5000 --> 50000
net.ipv4.tcp_max_syn_backlog = 1024 --> 4096
net.core.somaxconn = 128 --> 4096
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1(5和6同时开启可能会导致nat上网环境建联概率失败)
net.ipv4.tcp_tw_recycle = 1- /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535- Optimización de parámetros de Nginx
worker_connections 1024-->10240;
worker_processes 1-->16;（根据实际情况设置，可以设置成auto）
worker_rlimit_nofile 1024-->102400;
listen 80 backlog 511-->65533；En algunos escenarios, también puede considerar nginx para abrir conexiones largas para optimizar la sobrecarga causada por enlaces cortos
Optimización de la arquitectura
- Expanda el número de ECS de backend SLB y la configuración de ECS se unificará;
- Eliminación de puertos no válidos ascendentes de backend de generación inversa Nginx;
- Cloud Assistant procesa por lotes servicios de procesamiento, optimiza parámetros y agrega identificadores de instancia; (para enfocarse, si usa ECS en lotes, puede considerar usar Cloud Assistant)
- Monitoreo de la nube y monitoreo del mercado, ECS, SLB, DCDN, Redis, etc .;
- Ajuste el SLB al modo de monitoreo de capa 7. Si cierra la sesión para las primeras 7 y las últimas 4, el estado de inicio de sesión dejará de ser válido.
Optimización del programa
Agregue el registro de GC, capture los problemas de análisis de GC y configure la memoria del proceso;
/usr/bin/java -server -Xmx8g -verbose:gc -XX:+PrintGCDetails -Xloggc:/var/log/xxxx.gc.log -Dserver.port=xxxx -jar /home/app/we.*****.com/serverboot-0.0.1-SNAPSHOT.jar- Optimice la lógica de envío de SMS, primero consulte la Sesión no registrada de Redis al iniciar sesión y luego permita el envío del código de verificación de SMS sin la Sesión no registrada (reduzca la cantidad de mensajes cortos y optimice la experiencia de inicio de sesión);
- optimización del grupo de conexiones jedis;
maxTotal 8-->20
acceptcount优化（对标somaxconn）- Error: la fuga de conexión de Redis de jedis 2.9.1 con springboot 1.5 hizo que el proceso de Tomcat 800 esperara indefinidamente la conexión de Redis después de agotarse. Más tarde, una investigación más profunda encontró que este problema se ha solucionado en 2.10.2, y 2.10.2 es compatible con versiones anteriores de 2.9.1.
Optimización de la base de datos
- La dirección de red pública de Redis se cambia a una dirección de red interna;
- La configuración del tiempo de espera de la sesión de Redis se acorta para liberar la conexión de Redis;
- Optimización lenta de SQL (CloudDBA de RDS es muy fácil de usar);
- Agregue una instancia de solo lectura, separación automática de lectura y escritura;
- Optimice la acumulación;
- Sume el número de instancias de separación de lectura y escritura.
Al final
ECS Operation and Maintenance Guide for Linux System Diagnosis
Este artículo está extraído de "ECS Operation and Maintenance Guide for Linux System Diagnosis". La "ECS Operation and Maintenance Guide for Linux System Diagnosis" es un trabajo minucioso de Makihara. No solo se refina el contenido, pero el autor del código también pasó un tiempo menos pensativo. También puede iniciar sesión directamente en la comunidad de desarrolladores de Alibaba Cloud para descargar el libro "ECS Operation and Maintenance Guide-Linux System Diagnosis", o responder directamente a la palabra clave "ecs" en el backstage de la cuenta oficial para obtener esta colección.
Hay muchos artículos técnicos de alta calidad en la comunidad de desarrolladores de Alibaba Cloud. Puede ir a observar y aprender. Muchos libros están disponibles directamente para su descarga gratuita.
Si cree que el contenido de este artículo es inspirador y gratificante, ayúdeme a hacer clic en "Estoy mirando" o reenviarlo y compartirlo para que lo vean más amigos.