¿Cómo garantiza Alibaba Cloud RDS una alta disponibilidad?
Una aplicación grande y cargada puede ralentizar todo el proceso de desarrollo y dificultar la implementación. Por tanto, para solucionar este problema, es recomendable diseñar la aplicación como un programa de arquitectura de microservicios en las primeras etapas de desarrollo. Aunque puede mejorar la dificultad de comunicación entre programas, brinda la posibilidad de escalar libremente su aplicación en el futuro, ayudándole a resolver problemas de escalado en un desarrollo posterior.
Para aplicaciones que ya están en línea, los microservicios monolíticos pueden resultar muy difíciles. Después de todo, no se puede pedir a todo un equipo que vuelva a desarrollar un sistema. En este caso, también se podría separar el negocio principal y de alta demanda como un servicio, de modo que cada servicio se convierta en una pequeña pieza con una única responsabilidad y función, a fin de brindar mejor los servicios externos.
En segundo lugar, la estructura de recursos
En la era de la computación en la nube, la computación en la nube es muy popular y brinda soporte de potencia informática para todos los ámbitos de la vida y el uso adecuado de las capacidades proporcionadas por la computación en la nube. puede ayudarnos a hacer que las solicitudes sean más eficientes y más fáciles de obtener.
En términos generales, cada una de nuestras aplicaciones se puede dividir en cuatro capas: capa de entrada, capa empresarial, capa de caché y capa de base de datos. Cuando hacemos un buen trabajo optimizando cada capa, entonces nuestra aplicación evita posibles problemas.
Capa de entrada
La capa de entrada generalmente se refiere a cosas en Nginx, Apache y otros niveles, que son responsables de la entrada de la aplicación. Generalmente, orientaremos la aplicación a una determinada IP, por lo que si nuestra IP falla, el servicio no estará disponible. Por lo tanto, también podríamos utilizar el equilibrio de carga en la capa de ingreso. Podemos optar por crear nuestro propio balanceador de carga o utilizar un balanceador de carga proporcionado por un proveedor de servicios en la nube mediante evaluación de estrés, estimación de costos y dificultad de implementación técnica. En este caso, cuando el negocio detrás de nuestra capa de ingreso tiene un único punto de falla, podemos recurrir automáticamente a controles de estado y solicitar mecanismos de distribución de equilibrio de carga.
Nivel empresarial
La capa empresarial suele estar compuesta por códigos lógicos escritos en PHP, Java, Python, Go, etc. y necesita depender de la base de datos backend y algunas cosas a nivel de caché. ¿Cómo lograr alta disponibilidad en la capa empresarial? El núcleo es que la capa empresarial no debe tener estado, y el estado debe estar disperso en la capa de caché y la base de datos. En la actualidad, a la gente suele gustarle colocar los siguientes tipos de datos en la capa empresarial.
El primero es la sesión, que son datos relacionados con el inicio de sesión del usuario, pero es una buena práctica colocar la sesión en una base de datos o en un sistema de caché relativamente estable.
El segundo es el almacenamiento en caché. Al acceder a la base de datos, si una consulta es lenta, quiero poner temporalmente estos resultados en el proceso para que la siguiente consulta no tenga que acceder a la base de datos.
Un principio simple es que la capa empresarial no debe tener estado. Cuando la capa empresarial no tiene estado, Nginx/Apache enviará automáticamente todas las solicitudes a otro servidor de la capa empresarial después de que un servidor de la capa empresarial se desconecte. Como no hay estado, no hay diferencia entre los dos servidores, por lo que el usuario no puede sentirlo en absoluto. Si la sesión se coloca en la capa empresarial, el problema es que el usuario ha iniciado sesión en una máquina. Una vez finalizado el proceso, el usuario cerrará la sesión.
Capa de almacenamiento en caché
En una arquitectura muy simple no existe el concepto de almacenamiento en caché. Sin embargo, una vez que el tráfico aumenta, las bases de datos como MySQL no pueden sostenerlo. Por ejemplo, cuando MySQL se ejecuta en un disco SATA y el QPS alcanza 200, 300 o incluso 500, el rendimiento de MySQL caerá drásticamente. En este momento, puede considerar utilizar la capa de caché para bloquear la mayoría de las solicitudes de servicio y aumentar la capacidad general del sistema.
Si la capa de caché desea lograr una arquitectura de alta disponibilidad, la mejor solución es dividir la capa de caché en capas más pequeñas y utilizar las capacidades de caché distribuida o caché en la nube proporcionadas por los proveedores de servicios de computación en la nube para reducir la carga de trabajo. de la base de datos.
Capa de base de datos
Lograr una alta disponibilidad a nivel de base de datos generalmente se logra a nivel de software. Por ejemplo, MySQL tiene un modo maestro-esclavo que puede satisfacer las necesidades. MongoDB también tiene el concepto de ReplicaSet, que básicamente puede satisfacer las necesidades de todos.