Y bienvenidos de nuevo a la Academia de retroceso en esta conferencia.
Voy a hablar sobre los saldos bajos de la aplicación, que son un
nuevo tipo de saldos bajos que hemos introducido y ofrece una serie de ventajas.
Así que hablaremos sobre las diferentes opciones que ahora están disponibles para nosotros con
bajo balance y luego hablaremos sobre cómo una aplicación de bajo balanceador puede proporcionarnos algunos
beneficios significativos cuando ejecutamos múltiples aplicaciones.
Hablaremos sobre el enrutamiento basado en rutas y cómo eso puede reducir la cantidad de saldos bajos que
necesitamos dentro de nuestra arquitectura.
También hablaremos sobre las diferentes opciones a las que podemos enrutar nuestra solicitud, podemos enrutar a
direcciones IP, podemos enrutar a micro servicios, podemos establecer rutas a diferentes contenedores que están en una sola instancia.
Tenemos múltiples objetivos y hablaremos sobre lo que eso significa y
las reglas de enrutamiento que podemos establecer que definen cómo se enrutan nuestras solicitudes de regreso a nuestro back-end. Las opciones de balanceador
de carga que tenemos disponibles incluyen el balanceador de carga clásico original.
Ahora que siempre ha funcionado en ambas capas, la capa cuatro y la capa siete, pero solo proporciona una
funcionalidad realmente limitada en la capa 7.
Por lo tanto, en el avance de capa nos ha estado ofreciendo un soporte TCT estándar,
pero también al menos siete, también nos está dando soporte para odiar TTP y HDTV, pero no es compatible con sockets web.
Y eso es obviamente una limitación en la funcionalidad de la Capa 7.
Es compatible con una VPC e instancias fáciles de clásicas.
Y la siguiente opción que tenemos es un equilibrador de carga de red, que es
otra opción nueva de bajo equilibrador para nosotros y operan específicamente en el nivel de conexión inferior o en la capa 4 del modelo ISI, por
lo que es compatible con T. S. Poppy y tiene paquetes de captura y reenvío
directo a nuestro back-end es de muy bajo nivel, pero también es compatible con zócalos web.
Ahora los sockets web son, de hecho, una funcionalidad de Capa 7, pero también es compatible con sockets web,
pero tampoco es compatible con la página TTP.
Por lo tanto, también tenemos soporte solo para VPC.
No es compatible con las antiguas dos instancias clásicas fáciles.
Y hay otra característica que tienen tanto los saldos bajos de la red como de
las aplicaciones y es que tiene protección de eliminación de balanceador de carga en caso de que elimine accidentalmente ese balanceador de carga.
Entonces, lo que vamos a ver en esta conferencia es
el balanceador de carga de la aplicación y que opera en el nivel de solicitud individual al menos siete del modelo
ISI y está trabajando muy de cerca con nuestra aplicación, está haciendo más que solo
tomar paquetes y reenviar está poniendo esos paquetes en un formato que nuestra aplicación pueda recibir.
Por lo tanto, va a ser compatible con Hage TTP Hage para mantenernos y también con el nuevo Hage
TTP, que proporcionará velocidades de carga de página muy buenas y también es compatible con los zócalos web que el equilibrador
de carga clásico no admite.
Solo admite las instancias de VPC, no admite E. C. dos instancias clásicas y de nuevo
proporciona protección de eliminación de equilibrio de carga si estamos buscando ejecutar múltiples aplicaciones si lo estamos haciendo con un equilibrio bajo clásico de Alexi, así
que lo que normalmente haríamos sería que nuestro servicio de nombres de dominio fuera
nuestra ruta 53 y separaríamos eso en dos dominios separados, así que en el lado izquierdo aquí puedes ver
que tenemos nuestras imágenes para nombrar y aquí tenemos nuestro after main.
Entonces, si tenemos nuestro dominio de imágenes, serviremos nuestras imágenes y nuestra funcionalidad de interfaz de
usuario y todo eso se servirá a través de nuestra aplicación, por lo que
si llega alguna solicitud de imágenes, obviamente entrará a través de este equilibrador de carga clásico aquí y luego se distribuye
a una de las instancias disponibles y de la misma manera para cualquier solicitud de la aplicación.
Entonces eso funciona.
Pero el problema es que esperamos duplicar lo que estamos haciendo aquí.
Así que básicamente tenemos un balanceador de carga elástico aquí y un segundo balanceador de carga elástica allá ahora con enrutamiento basado
en rutas que es una característica de la aplicación L. SI. en realidad podemos usar un balance
bajo elástico y podemos agregar el balance bajo elástico que distinguirá a dónde debe ir esa
solicitud dependiendo de cuál sea la ruta en esa solicitud.
Entonces, si tenemos mi dominio punto com, todos entrarán y luego la ruta de paso tiene imágenes que el
equilibrador de carga elástico sabrá automáticamente para enviar eso a este grupo objetivo de instancias
aquí si llega con una ruta de entonces el balanceador de carga elástico de la aplicación hará lo
mismo para una instancia disponible allí también.
Entonces, lo que eso significa es que solo estamos usando un balanceador de carga elástica de aplicación en lugar de usar múltiples
balances de carga elástica para cada una de esas aplicaciones que estamos ejecutando.
Por lo tanto, eso proporcionará una reducción significativa en los costos si tiene varias aplicaciones en
las que
está ejecutando otra característica de saldos bajos elásticos es que en realidad pueden enrutar a direcciones IP individuales que en
realidad no tienen que tener una instancia.
Todavía puede registrar una instancia con un equilibrador de carga elástico, pero también puede registrar una dirección IP para que
no pueda ser una dirección IP pública, por lo que no puede ir y obtener algo en su base de datos
local o lo que sea lo que puede hacer es que puede usar uno de los tipos de direcciones
IP privadas que he enumerado y puede usarlas para registrarse con el equilibrador de carga.
Entonces, lo que sucederá es que cuando recibamos nuestro at o solicitud para nuestra aplicación, ingresarán a través
del equilibrador de carga de la aplicación y pasarán a esa dirección IP para esa instancia.
Ahora no solo podemos tener múltiples aplicaciones ejecutándose a través de un solo balanceador de carga de aplicaciones,
también podemos tener múltiples aplicaciones ejecutándose en la misma instancia y podemos registrar una combinación de
instancia y puerto para esa aplicación.
Entonces, eso significa que si tenemos nuestra aplicación aquí.
Entonces, nuestra solicitud para nuestra aplicación podemos hacer que se ejecute en un micro servicio en una instancia aquí
y luego podemos configurar nuestros balances de carga elástica para que pueda recibir una
solicitud de la aplicación y reenviarlos directamente al puerto individual o la aplicación que se
ejecuta en ese puerto de esa instancia.
Y luego podemos hacer lo mismo con otra instancia.
Entonces, eso significa que si, por ejemplo, nuestras imágenes no están tan ocupadas como nuestra aplicación o
viceversa, todavía estamos distribuyendo la carga de manera muy uniforme en estos casos.
Por lo tanto, no vamos a tener un lado de esta infraestructura que estará
muy ocupado y el otro lado no, por lo que creará algunas muy buenas ventajas para la confiabilidad y la eficiencia también.
Otra característica muy buena del equilibrio de carga de la aplicación es que en realidad puede ejecutar múltiples contenedores en
una instancia y enrutar o un balance bajo a través de eso, de manera similar que tendríamos múltiples aplicaciones y
registraríamos una combinación de puerto y una instancia Podemos hacer lo mismo con un contenedor que se está ejecutando
o con varios contenedores que se ejecutan en una instancia individual.
De nuevo, tendríamos nuestra aplicación aquí y si mi dominio tiene una aplicación en su camino, esas solicitudes
llegarán y serán tan fáciles como el contenedor que ejecuta la aplicación y la
combinación de puertos para eso.
Si está utilizando el servicio s para hacerlo, es bastante bueno porque el servicio más
fácil gestionará todo eso por usted, asignará el puerto y lo registrará con el
equilibrador de carga de la aplicación.
Entonces, con saldos bajos elásticos todavía tenemos oyentes como lo hemos hecho antes con un equilibrio
bajo clásico, por lo que tendríamos un oyente del puerto 80 y un oyente del puerto 443 si estamos buscando cada
TTP y HP para facilitar el tráfico y eso nuevamente define un protocolo y puerto para esas conexiones entrantes, pero también tenemos
lo que llamamos objetivos y grupos objetivo, por lo que un objetivo puede ser cualquier cosa, puede ser cualquier combinación de una
instancia.
Podría ser un micro servicio o una combinación de una instancia y un puerto, podría ser un contenedor.
Podríamos ser una de esas direcciones IP privadas a las que puede reenviar la solicitud.
Entonces, lo que haríamos sería establecer un grupo objetivo con objetivos dentro de él y luego lo registraríamos
con nuestra aplicación de balanceador bajo.
De acuerdo con ese camino.
Entonces, si tenemos nuestro camino aquí para las imágenes que se registrarían con ese grupo objetivo.
Por lo tanto, todo lo que venga por imágenes se
reenviará a ese grupo objetivo si tenemos oyentes y tenemos grupos objetivo que recibirán esas solicitudes reenviadas.
Necesitamos establecer reglas y esas reglas se definirán en el oyente.
Y así, si tenemos, por ejemplo, tenemos nuestro puerto 80 oyente.
Podemos establecer una regla que para cualquier solicitud que llegue al puerto 80 que tenga la ruta de las imágenes.
Así que aquí tenemos imágenes que podemos tener esa regla.
Tome una decisión para que el equilibrador de carga elástico envíe esas solicitudes o reenvíe esas solicitudes
a un objetivo disponible dentro de ese grupo objetivo.
Del mismo modo, también podemos tener otra regla configurada para hacer lo mismo para la ruta de la aplicación.
Entonces, eso es todo lo que necesito discutir por ahora sobre los saldos bajos de las aplicaciones.
Vamos a tener una lección práctica ahora y nos vemos en la próxima.