, El dominio de primer problema
nginx, lvs, keepalived, f5, polling DNS, a menudo se hace referencia a estas técnicas, varios problemas se discuten a menudo en la capa de acceso:
1) Disponibilidad : cualquier máquina de colgar, el servicio no se verá afectado por el
2) Escalabilidad : máquina Can aumentando el rendimiento de la expansión del sistema
3) Proxy inverso y equilibrio de carga : la solicitud se asigna uniformemente a la parte trasera de la unidad de operación realizada
En segundo lugar, ¿por qué son superiores a los de los sustantivos
Desde el fondo y el conocimiento técnico de cada persona de dominio, los de arriba término abreviado (O & M estudiantes familiarizados con él), o tomar 1 minuto para explicar brevemente (en detalle su propio "Baidu"):
. 1) Nginx : un servidor web y de alto rendimiento proxy inverso modalidad de software
2) LVS : Linux Virtual Server, el uso de la tecnología de agrupación para lograr un alto nivel de rendimiento en el sistema operativo Linux, alta disponibilidad, balanceo de carga del servidor
3) keepalived : un servicio utilizado para detectar el estado de viabilidad de software, a menudo se utiliza para una alta disponibilidad
4) F5 : un alto rendimiento, alta disponibilidad, dispositivos de carga de hardware de equilibrio similares (y la función sonidos LVS)?
. 5) el sondeo del DNS : al proporcionar una pluralidad de nombres de dominio de análisis ip en el servidor DNS, balanceo de carga técnica para ampliar la aplicación de servidor web y el rendimiento
En tercer lugar, la evolución de la tecnología de capa de acceso
[Era Streaking (0) sola arquitectura]
Trazar rayas época anterior:
1) los resuelve navegador para IP del servidor DNS, Domain Name
2) el navegador para acceder al servidor web a través de IP
desventajas :
1) la falta de disponibilidad, el servidor web vinculado al sistema colgó
2) pobre escalabilidad, cuando el límite de rendimiento de servidor web, no expansión
Nota: independiente no implica el equilibrio de carga
[Esquema de expansión simple (1) de sondeo DNS]
Asumir Tomcat rendimiento es de 1000 veces por segundo, cuando el sistema total de rendimiento de 3000, cómo la expansión es el primer problema que hay que resolver, la votación DNS es un muy fácil pensar en el programa:
En este momento, el anterior diagrama de arquitectura:
1) Multi-implementar varios servidor web, 1 Tomcat contra º 1000, será capaz de desplegar un anti-Tomcat 3 3000
2) en el nivel DNS-servidor, el nombre de dominio se resuelve en una IP diferente cada vez
ventajas :
1) coste cero: En el servidor DNS-IP y más con una función lata pocos sin cargo
2) Fácil de implementar: desplegar más de unos pocos servidor web a la arquitectura del sistema original no requiere ninguna alteración
3) El equilibrio de carga: convertirse en un multi-máquina, pero se equilibra la carga básica
desventajas :
1) La falta de disponibilidad: el DNS-Server es responsable solamente de IP de DNS, IP correspondiente a este servicio está disponible, el servidor DNS no está garantizada , asumiendo que no se colgó, se verán afectados algunos servicios de un servidor web
2) la expansión de la no-tiempo real: DNS para resolver un periodo validado
3) La exposición a un exceso de IP de la red externa
[Esquema de expansión simple (2) nginx]
Tomcat bajo rendimiento, sino como una actuación nginx proxy inverso es mucho más fuerte, se supone que ir 1w en línea, es 10 veces mayor que Tomcat, puede utilizar esta función para hacer la expansión:
En este momento, el anterior diagrama de arquitectura:
1) la adición de una capa proxy inverso entre el navegador y la capa de nivel de sitio, el uso de un alto rendimiento proxy inverso no nginx
2) nginx http solicitud a la pluralidad backend de servidor web distribuido
ventajas :
1) no tienen necesidad de mover servidores DNS
2) El equilibrio de carga: garantizado por nginx
3) exponer solamente una IP de la red externa, nginx-> Uso de la red de acceso entre tomcat
4) la expansión de tiempo real: control interno nginx, en cualquier servidor web incremento de tiempo en cualquier expansión en tiempo real tiempo
5) para asegurar la disponibilidad de las capas sitio: Cualquiera Tomcat colgó, nginx puede migrar a otra Tomcat tráfico
desventajas :
1) + retardo aumenta arquitectura más compleja: un pago proxy inverso capas más intermedios
2) reverse proxy de capa se convierte en un punto único, la no disponibilidad: Tomcat colgó sin afectar el servicio, nginx colgó cómo hacerlo?
[Programa de Alta Disponibilidad (3) keepalived]
Para resolver el problema de la alta disponibilidad, Keepalived jugado (artículo anterior, " Uso de sombras maestro para asegurar la disponibilidad del sistema " detalles también):
En este caso:
1) una composición hecha de implementación de clúster dos nginx Keepalived respectivamente, conjunto a la misma IP virtual, asegurando que la disponibilidad nginx
2) Cuando un nginx Hung, keepalived capaz de detectar, y el flujo automático nginx migrar a otro, todo el proceso de la persona que llama transparente
ventajas :
1) para resolver el problema de la alta disponibilidad
desventajas :
1) la tasa de utilización de recursos de sólo el 50%
2) nginx es todavía un único punto de acceso, el límite de rendimiento de nginx si el acceso rendimiento de más de cómo hacer, por ejemplo, alcanzó 50.000 QPS manta?
[Escala hasta programa de expansión (4) lvs / f5]
Nginx, después de todo, el software, el rendimiento es mejor que Tomcat, pero siempre hay un límite, más allá del límite superior, o no se pudo realizar.
LVS no es el caso, se implementa a nivel de sistema operativo; f5 y un mejor rendimiento, se implementa a nivel de hardware, su rendimiento es mucho mejor que nginx, por ejemplo, anti-10w por segundo, por lo que se pueden utilizar para la expansión, común gráfico como sigue:
En este caso:
1) Si una pluralidad de los mismos se puede extender por Tomcat nginx, puede extenderse por una pluralidad de LVS nginx
2) regímenes de VIP + keepalived puede garantizar la disponibilidad
99,9999% de la empresa sea capaz de resolver este acceso básico paso plantas disponibles, escalabilidad, balanceo de carga problema.
Esto es lo más perfecto? Hay posibles problemas con él?
Bueno, si el uso de LVS f5, se trata de la escala de los programas, fundamentalmente, LVS / f5 todavía tienen un límite de potencia, suponiendo que 10w por segundo puede manejar la petición, un día sólo podemos manejar 8,0 mil millones de petición (10w seg transmisión * 8w segundos), en caso de que los sistemas fotovoltaicos días más de 8 mil millones de cómo hacerlo? (Bueno, muchas empresas no tienen que considerar esta cuestión)
[Escala a cabo el programa de expansión (5) de sondeo DNS]
Como el artículo anterior, la expansión horizontal, es la raíz del problema de rendimiento programa de resolución, sólo puede tener la mejor escalabilidad mediante la adición de máquinas para ampliar el rendimiento del programa.
facebook, Google, baidu de PV es de no más de 8 mil millones de ello, sus nombres corresponde solamente a una ip Mody, el fin es el punto de partida, todavía tiene que ser llevado a cabo por el sondeo de expansión DNS :
En este caso:
1) mediante un DNS entrada de sondeo lineal de escalabilidad lvs capa
2) para asegurar una alta disponibilidad a través de keepalived
3) para extenderse a través de la pluralidad nginx lvs
4) por nginx para hacer balance de carga, enrutamiento de negocios de siete
conclusiones
Hablar tanto, un poco de hacer un resumen breve:
1) capa de acceso de la arquitectura Ámbito del problema se ha de considerar : alta disponibilidad, la escalabilidad, la expansión de ecualización inversa de proxy +
2) nginx, Keepalived, lvs, f5 pueden resolver alta disponibilidad, escalabilidad, proxy inverso y expansión equilibrada problema
3) se extienden horizontalmente escalar es una solución fundamental al problema de escalabilidad, la interrogación DNS no puede ser completamente sustituido por nginx / lvs / f5 de
