Prefacio
Me gusta antes de verlo, ten buenos hábitos
Casi todas las aplicaciones a gran escala parten de una aplicación pequeña. Los buenos productos de Internet se operan lentamente, no se desarrollan al principio, por lo que en este artículo hablaremos sobre la evolución de la arquitectura de aplicaciones.
¿Cómo crear una aplicación de alta disponibilidad, alto rendimiento y fácilmente escalable? En primer lugar, entendemos las características de las aplicaciones a gran escala:
- Alta disponibilidad: el sistema debe proporcionar servicios ininterrumpidos sin un solo punto de falla
- Alta concurrencia: bajo el impacto de un gran tráfico, el sistema aún brinda servicios de manera estable
- Big data: la aplicación genera una gran cantidad de datos todos los días, que deben almacenarse y administrarse bien
La arquitectura más sencilla
Al principio, la aplicación no tenía mucho tráfico, por lo que solo se necesita un servidor. La arquitectura en este momento es la siguiente:
Las aplicaciones, archivos y bases de datos a menudo se implementan en un servidor. La aplicación se puede desarrollar en Java e implementar en el servidor Tomcat, y la base de datos puede usar MySQL de código abierto
Separación de aplicaciones y servicios de datos
A medida que el negocio de la aplicación se vuelve cada vez más complejo, la cantidad de visitas a la aplicación aumenta, lo que resulta en un peor rendimiento y una grave escasez de espacio de almacenamiento. En este momento, consideramos aumentar el servicio a tres (los problemas que se pueden resolver agregando máquinas no son Pregunta); separe el servidor de aplicaciones, el servidor de base de datos y el servidor de archivos.
- El servidor de aplicaciones necesita manejar una gran cantidad de acceso, por lo que necesita una mejor CPU
- El servidor de la base de datos necesita almacenar una gran cantidad de datos y una recuperación rápida, por lo que la velocidad de recuperación del disco debe ser más rápida y el espacio de almacenamiento es grande.
- Los servidores de archivos necesitan almacenar archivos cargados y necesitan discos más grandes; hoy en día, generalmente se seleccionan los servicios de almacenamiento de terceros
Según el escenario correspondiente a cada servidor, el rendimiento de la aplicación se puede mejorar enormemente una vez configurado el servidor, lo que apoya mejor el desarrollo del negocio. Sin embargo, con el desarrollo de los negocios y el aumento de las visitas, esta arquitectura enfrentará nuevamente desafíos, la potencia de procesamiento de los servidores de aplicaciones disminuirá y el espacio de almacenamiento será insuficiente.
Clúster de servidor de aplicaciones
En el caso de alta concurrencia y gran tráfico, un servidor definitivamente no podrá manejarlo. En este momento, agregue servidores e implemente clústeres para brindar servicios para compartir la presión de cada servidor. Otra ventaja de implementar clústeres es la escalabilidad. Por ejemplo, cuando se encuentra con un escenario de gran tráfico en Double 11, puede aumentar el tráfico de asignación de servidores. Después de Double 11, reduzca los servidores para ahorrar costos. La estructura es la siguiente:
Si el servidor de aplicaciones es Tomcat, entonces se puede implementar un clúster de Tomcat y un equilibrador de carga se puede implementar externamente. Se pueden usar algoritmos aleatorios, rotatorios o hash consistentes para distribuir las solicitudes de los usuarios a diferentes clústeres de servicios de aplicaciones; generalmente de forma gratuita El equilibrador de carga es nginx. Bajo esta arquitectura, la carga del servidor de aplicaciones no será el cuello de botella de toda la aplicación;
Aunque la velocidad de procesamiento de la aplicación se ha mejorado mucho con esta arquitectura, se expondrá otro problema: la presión sobre la base de datos aumenta considerablemente, lo que provoca un retraso en la respuesta de acceso y afecta el rendimiento de toda la aplicación.
Hay otro problema con esta arquitectura. Por lo general, la aplicación tiene estado y necesita registrar la información de inicio de sesión del usuario. Si la solicitud de cada usuario se enruta aleatoriamente al servidor de aplicaciones back-end, la sesión del usuario se perderá; dos soluciones a este problema Planes:
- Utilice hash coherente para enrutar las solicitudes de los usuarios al mismo Tomcat. Si un servidor se arrodilla, la información del usuario en este servidor se perderá
- Al configurar la replicación de sesiones entre clústeres de Tomcat para lograr compartir, esta solución es menos eficiente
Ninguno de los planes es muy bueno, entonces, ¿hay algún otro plan? por favor mira la siguiente parte
Cache
Según el principio 28, el 80% del negocio se centra en acceder al 20% de los datos. Este 20% de los datos se suele denominar hot data, pero la memoria ocupada por el 20% de los datos no será pequeña. Si cada servidor de aplicaciones tiene Almacenar una copia desperdiciará espacio de almacenamiento, por lo que debe considerar agregar un servidor de caché distribuido (generalmente Redis); cuando se introduce el servidor de caché distribuido, el problema de la solución anterior se puede resolver y el usuario La sesión se almacena en el servidor de caché, no solo para evitar la pérdida de datos del usuario, sino que además la eficiencia no es baja; el diagrama de arquitectura es el siguiente:
Después de todo, el servidor de caché distribuido se almacena de forma remota y necesita pasar por la red, por lo que lleva un tiempo recuperar los datos; la velocidad de acceso a la caché local es más rápida, pero el espacio de memoria es limitado y habrá competencia por los recursos con la aplicación; entonces esta arquitectura Está equipado con caché distribuido y caché local. El caché local almacena una pequeña cantidad de datos activos de uso común. Cuando no hay ningún hit en el caché local, el
Después de la introducción del almacenamiento en caché, la presión de acceso a la base de datos se puede aliviar hasta cierto punto
Separación de lectura y escritura de la base de datos
Aunque después de agregar el caché, algunos datos se pueden almacenar directamente en caché sin acceder a la base de datos, pero aún habrá algunas solicitudes que accederán a la base de datos, como: invalidación de caché, falta de caché; cuando el tráfico es pesado, la cantidad de acceso a la base de datos No pequeño. En este momento, debemos considerar la creación de un clúster de base de datos con separación de lectura y escritura
Cuando el servidor de aplicaciones tiene una operación de escritura, acceda a la biblioteca principal, cuando la aplicación tenga una operación de lectura, acceda a la biblioteca esclava; la mayoría de las aplicaciones tienen operaciones de lectura mucho mayores que las operaciones de escritura, por lo que puede configurar la base de datos para compartir la base de datos con un maestro y varios esclavos Para que la aplicación desconozca la biblioteca principal y la biblioteca esclava, generalmente es necesario introducir algunos marcos que separen la lectura y la escritura para hacer un módulo de acceso a datos unificado.
Un problema sobre el que esta arquitectura generalmente debe estar atenta es el retraso maestro-esclavo. En un escenario de alta concurrencia, la base de datos maestra se acaba de escribir correctamente y la base de datos no ha sincronizado correctamente la base de datos esclava. En este momento, entra otra solicitud para leer los datos y descubre que no existe; El esquema de liberación es establecer una consulta de base de datos principal obligatoria en escenarios de alta concurrencia en la aplicación
Hermanos, por favor no utilicen prostitutas por nada, por favor denme primero un pulgar hacia arriba
Proxy inverso y CDN
Si a medida que el negocio continúa expandiéndose, nuestras aplicaciones serán utilizadas en todo el país. Debido a las diferentes condiciones de la red en cada región, algunas personas solicitan una velocidad de respuesta rápida, y algunas personas solicitan una velocidad de respuesta lenta, lo que afectará seriamente a los usuarios. Experiencia. Para mejorar la velocidad de respuesta, es necesario introducir proxy inverso y CDN; tanto CDN como proxy inverso son cachés que se utilizan para:
- Presentar datos a los usuarios lo más rápido posible
- Reducir la presión sobre el servidor back-end
El diagrama de arquitectura es el siguiente:
CDN: Implementado en la sala de computación del proveedor de la red. Cuando el usuario viene de visita, los datos se devuelven desde el servidor más cercano al usuario y se presentan al usuario lo antes posible; generalmente, los recursos estáticos (html, js, css) se almacenan en caché en el CDN. Para lograr la separación de dinámica y estática; pero a veces cuando se visitan particularmente algunos datos, el backend generará recursos estáticos y los pondrá en el CDN, como la página de inicio del centro comercial, y la página que cada usuario necesita visitar al ingresar. Todos ingresan al backend, entonces la presión sobre el servidor ciertamente no es pequeña, en este caso, los archivos estáticos generados en la página de inicio se almacenarán en caché en el CDN y el servidor proxy inverso
Proxy inverso: implementado en la sala de computadoras central de la aplicación, generalmente es un recurso estático almacenado en caché. Cuando el usuario no solicita los datos requeridos a través de la CDN, primero ingrese el servidor proxy inverso. Si hay datos almacenados en caché a los que accede el usuario, estos se devuelven directamente al usuario ; Hay circunstancias especiales aquí. Para los datos calientes en algunos escenarios, se obtienen del servidor de caché distribuida según la solicitud del usuario y se devuelven directamente cuando están disponibles.
Esta arquitectura ha alcanzado el nivel 4 de caché
- Nivel 1: recursos estáticos de almacenamiento en caché de CDN
- Nivel 2: el proxy inverso almacena en caché recursos estáticos y algunos datos importantes
- Nivel 3: caché local del servidor de aplicaciones
- Nivel 4: servidor de caché distribuido
Por lo general, después de estos 4 niveles de caché, no hay muchas solicitudes que puedan ingresar a la base de datos, lo que alivia la presión sobre la base de datos.
Motor de búsqueda y NoSQL
Con la expansión continua del negocio, los requisitos de almacenamiento y consulta de datos se vuelven cada vez más complejos. Por lo general, necesitamos introducir bases de datos no relacionales, como motores de búsqueda y bases de datos NoSQL.
A veces, nuestros escenarios de consulta son muy complicados y es necesario consultar muchas tablas de datos, que se pueden completar después de una serie de cálculos. En este momento, podemos considerar el uso de herramientas de sincronización de datos (como canal) para extraer datos a la plataforma de big data y utilizar el marco de procesamiento por lotes para el cálculo sin conexión. El resultado de salida se almacena en un motor de búsqueda o en una base de datos NoSQL, y el programa de aplicación consulta y calcula directamente el resultado y lo devuelve al usuario. También es posible que necesitemos resumir los datos de varias tablas para hacer una tabla amplia para facilitar la consulta de la aplicación.
Debido al aumento en los métodos de almacenamiento de datos introducidos, para reducir el problema de administrar múltiples fuentes de datos para aplicaciones, es necesario encapsular un módulo de acceso a datos unificado. Si está utilizando Java, puede considerar spring-data
División vertical empresarial
El propósito habitual de las empresas de Internet es iterar y ejecutar en pequeños pasos. Cuando la empresa es lo suficientemente grande, es difícil que una sola aplicación logre este propósito. Con el desarrollo de la empresa, el programa de aplicaciones es cada vez más grande, la investigación y el desarrollo, Los costos de mantenimiento y liberación también están aumentando. En este momento, es necesario considerar dividir una sola aplicación en múltiples servicios según el negocio. Los servicios pueden usar llamadas remotas RPC y colas de mensajes para completar las solicitudes de los usuarios juntos.
Debido a la división del negocio, la base de datos generalmente se dividirá en consecuencia para lograr el estado ideal de un servicio correspondiente a una base de datos.
Los beneficios de presentar MQ:
- Mejorar la disponibilidad del sistema: cuando el servidor del consumidor no puede enviar, el mensaje todavía está en la cola de mensajes y los datos no se perderán
- Acelerar la respuesta de la solicitud: Cuando la solicitud del usuario llega al servidor, los datos que se pueden procesar de forma asíncrona en la solicitud se colocan en MQ, de manera que el sistema consume uno a uno sin que el usuario espere, lo que acelera la respuesta.
- Recorte de picos y llenado de valles: cuando una gran cantidad de solicitudes ingresan al sistema al mismo tiempo, todas se colocarán en la cola de mensajes y el sistema consumirá una por una sin causar un gran impacto en el sistema
para resumir
Existe otra situación que no se ha mencionado, es decir, la división horizontal de la base de datos, que también es el último recurso para la división de la base de datos. Se utiliza solo cuando los datos de una sola tabla son demasiado grandes para satisfacer las necesidades del negocio. El más utilizado es dividir el negocio de la base de datos verticalmente y colocar los datos de diferentes negocios en la base de datos en diferentes servidores físicos.
La arquitectura a elegir para la aplicación actual debe seleccionarse de manera flexible en función de las necesidades comerciales reales. La principal fuerza impulsora para el desarrollo de la arquitectura técnica sigue siendo el desarrollo comercial, no la tecnología por el bien de la tecnología.
Escribir al final
- Primero que nada, gracias a todos por su paciencia para leer aquí. Presta atención, no te pierdas
- Por supuesto, puede haber más o menos deficiencias y errores en el artículo, si tiene sugerencias u opiniones, puede comentar e intercambiar.
- Por último, no es bueno para las prostitutas y no es fácil de crear . Espero que a los amigos les guste, comenten y sigan a Sanlian, porque estas son todas las fuentes de motivación para compartir.
El original no es fácil de reimprimir, indique la fuente: https://silently9527.cn/archives/64
Materiales de referencia "Arquitectura técnica de grandes sitios web"