INTRODUCCION

La mayoría de las aplicaciones empresariales basadas en web siguen el mismo flujo de solicitud
general: una solicitud de un navegador llega al servidor web, luego a un servidor de
aplicaciones y finalmente al servidor de la base de datos. Aunque este patrón funciona muy
bien para un pequeño grupo de usuarios, los cuellos de botella comienzan a aparecer a medida
que aumenta la carga del usuario, primero en la capa del servidor web, luego en la capa del
servidor de aplicaciones y finalmente en la capa del servidor de la base de datos. La respuesta
habitual a los cuellos de botella basados en un aumento en la carga del usuario es escalar los
servidores web. Esto es relativamente fácil y económico, y algunas veces funciona para
abordar los problemas de cuello de botella. Sin embargo, en la mayoría de los casos de alta
carga de usuario, la ampliación de la capa del servidor web solo desplaza el cuello de botella
hacia el servidor de aplicaciones. Escalar los servidores de aplicaciones puede ser más
complejo y costoso que los servidores web y, por lo general, mueve el cuello de botella al
servidor de la base de datos, lo que es aún más difícil y costoso de escalar. Incluso si puede
escalar la base de datos, finalmente obtendrá una topología en forma de triángulo, con la
parte más ancha del triángulo como servidores web (más fácil de escalar) y la parte más
pequeña como base de datos (la más difícil de escalar).

En cualquier aplicación de gran volumen con una carga de usuarios simultáneos

extremadamente grande, la base de datos suele ser el factor final limitante en la cantidad de
transacciones que puede procesar al mismo tiempo. Si bien varias tecnologías de
almacenamiento en caché y productos de escalado de base de datos ayudan a abordar estos
problemas, el hecho es que ampliar una aplicación normal para cargas extremas es una
propuesta muy difícil.

El patrón de arquitectura basado en el espacio está específicamente diseñado para abordar y

resolver problemas de escalabilidad y concurrencia. También es un patrón de arquitectura útil
para aplicaciones que tienen volúmenes de usuarios concurrentes variables e impredecibles.
Resolver el problema de escalabilidad extrema y variable arquitectónicamente es a menudo un
mejor enfoque que tratar de escalar una base de datos o adaptar las tecnologías de
almacenamiento en caché en una arquitectura no escalable.

CONCEPTO WIKIPEDIA

La arquitectura basada en el espacio (SBA) es un patrón de arquitectura de software para

lograr la escalabilidad lineal de aplicaciones de alto rendimiento con estado usando el
paradigma del espacio de tuplas. Sigue muchos de los principios de la transferencia de estado
representacional (REST), la arquitectura orientada a servicios (SOA) y la arquitectura basada en
eventos (EDA), así como los elementos de la computación grid. Con una arquitectura basada
en el espacio, las aplicaciones se construyen a partir de un conjunto de unidades
autosuficientes, conocidas como unidades de procesamiento (PU). Estas unidades son
independientes entre sí, de modo que la aplicación puede escalar agregando más unidades. El
modelo de SBA está estrechamente relacionado con otros patrones que se han demostrado
exitosos al abordar el desafío de escalabilidad de la aplicación, como la arquitectura de nada
compartida (SN), utilizada por Google, Amazon.com y otras empresas conocidas. El modelo
también ha sido aplicado por muchas empresas de la industria de valores para implementar
aplicaciones escalables de negociación de valores electrónicos.

CONCEPTO LIBRO

El patrón basado en el espacio (también denominado a veces patrón de arquitectura de nube)

minimiza los factores que limitan la escala de la aplicación. Este patrón recibe su nombre del
concepto de espacio tuple, la idea de memoria compartida distribuida. Se logra una alta
escalabilidad eliminando la restricción central de la base de datos y utilizando en su lugar
cuadrículas de datos en memoria replicadas. Los datos de la aplicación se guardan en la
memoria y se replican entre todas las unidades de procesamiento activas. Las unidades de
procesamiento pueden iniciarse y cerrarse dinámicamente a medida que la carga del usuario
aumenta y disminuye, y de este modo se aborda la escalabilidad variable. Como no hay una
base de datos central, se elimina el cuello de botella de la base de datos, lo que proporciona
una escalabilidad casi infinita dentro de la aplicación.

RESUMEN DEL ANÁLISIS DE PATRONES

La Figura A-1 resume la puntuación del análisis de patrones para cada uno de los patrones de
arquitectura descritos en este informe. Este resumen lo ayudará a determinar qué patrón
podría ser mejor para su situación. Por ejemplo, si su principal preocupación arquitectónica es
la escalabilidad, puede mirar este gráfico y ver que el patrón controlado por eventos, el patrón
de microservicios y el patrón basado en el espacio son probablemente buenas opciones de
patrones de arquitectura. De manera similar, si elige el patrón de arquitectura en capas para
su aplicación, puede consultar la tabla para ver que la implementación, el rendimiento y la
escalabilidad pueden ser áreas de riesgo en su arquitectura.

FIGURA

Si bien este cuadro lo ayudará a elegir el patrón correcto, hay mucho más que considerar al
elegir un patrón de arquitectura. Debe analizar todos los aspectos de su entorno, incluido el
soporte de la infraestructura, el conjunto de habilidades del desarrollador, el presupuesto del
proyecto, los plazos del proyecto y el tamaño de la aplicación (por nombrar algunos). Elegir el
patrón de arquitectura correcto es crítico, porque una vez que una arquitectura está en su
lugar, es muy difícil (y costoso) cambiar.

PARTES DEL VIRTUAL MIDDLEWARE

Cuadrícula de mensajes

La cuadrícula de mensajes, que se muestra en la Figura 5-3, administra la solicitud de entrada y

la información de la sesión. Cuando una solicitud entra en el componente de middleware
virtualizado, el componente de la cuadrícula de mensajería determina qué componentes de
procesamiento activos están disponibles para recibir la solicitud y reenvía la solicitud a una de
esas unidades de procesamiento. La complejidad de la cuadrícula de mensajería puede variar
desde un simple algoritmo round-robin hasta un algoritmo next-available más complejo que
realiza un seguimiento de qué solicitud está siendo procesada por cada unidad de
procesamiento.

Cuadrícula de datos

El componente de la cuadrícula de datos es quizás el componente más importante y crucial en

este patrón. La cuadrícula de datos interactúa con el motor de replicación de datos en cada
unidad de procesamiento para administrar la replicación de datos entre las unidades de
procesamiento cuando se producen actualizaciones de datos. Como la cuadrícula de
mensajería puede reenviar una solicitud a cualquiera de las unidades de procesamiento
disponibles, es esencial que cada unidad de procesamiento contenga exactamente los mismos
datos en su cuadrícula de datos en memoria. Aunque la Figura 5-4 muestra una replicación de
datos síncrona entre unidades de procesamiento, en realidad esto se realiza en paralelo de
forma asíncrona y muy rápida, a veces completando la sincronización de datos en cuestión de
microsegundos (una millonésima de segundo).

Procesamiento de cuadrícula

La cuadrícula de procesamiento, ilustrada en la Figura 5-5, es un componente opcional dentro

del middleware virtualizado que administra el procesamiento de solicitud distribuida cuando
hay múltiples unidades de procesamiento, cada una de las cuales maneja una parte de la
aplicación. Si se recibe una solicitud que requiere coordinación entre los tipos de unidades de
procesamiento (por ejemplo, una unidad de procesamiento de pedidos y una unidad de
procesamiento de clientes), es la cuadrícula de procesamiento la que media y orquesta la
solicitud entre esas dos unidades de procesamiento.

Gerente de Despliegue

El componente deployment-manager gestiona el arranque y el apagado dinámicos de las

unidades de procesamiento en función de las condiciones de carga. Este componente
monitorea continuamente los tiempos de respuesta y las cargas de los usuarios, y pone en
marcha nuevas unidades de procesamiento cuando la carga aumenta, y apaga las unidades de
procesamiento cuando la carga disminuye. Es un componente crítico para lograr las
necesidades de escalabilidad variable dentro de una aplicación.

VENTAJAS DESVENTAJAS

La siguiente tabla contiene una clasificación y un análisis de las características de arquitectura

comunes para el patrón de arquitectura basado en el espacio. La calificación para cada
característica se basa en la tendencia natural de esa característica como una capacidad basada
en una implementación típica del patrón, así como en aquello por lo que generalmente se
conoce el patrón. Para una comparación lado a lado de cómo este patrón se relaciona con
otros patrones en este informe, consulte el Apéndice A al final de este informe.
Agilidad general

Calificación: Alta

Análisis: lagilidad general es la capacidad de responder rápidamente a un entorno en

constante cambio. Debido a que las unidades de procesamiento (instancias
desplegadas de la aplicación) se pueden subir y bajar rápidamente, las aplicaciones
responden bien a los cambios relacionados con un aumento o disminución en la carga
del usuario (cambios en el entorno). Las arquitecturas creadas usando este patrón
generalmente responden bien a los cambios de codificación debido al tamaño
pequeño de la aplicación y la naturaleza dinámica del patrón.

Facilidad de despliegue

Calificación: Alta

Análisis: aunque las arquitecturas basadas en el espacio generalmente no están

desacopladas y distribuidas, son dinámicas, y las sofisticadas herramientas basadas en
la nube permiten que las aplicaciones se "envíen" fácilmente a los servidores,
simplificando la implementación.

Testeabilidad

Calificación: baja

Análisis: Lograr cargas de usuarios muy elevadas en un entorno de prueba es costoso y

lento, por lo que es difícil probar los aspectos de escalabilidad de la aplicación.

Desempeño

Calificación: Alta

Análisis: El alto rendimiento se logra mediante el acceso a datos en memoria y los

mecanismos de almacenamiento en caché integrados en este patrón.

Escalabilidad

Calificación: Alta

Análisis: la alta escalabilidad proviene del hecho de que hay poca o ninguna
dependencia en una base de datos centralizada, por lo tanto, esencialmente se elimina
este cuello de botella limitante de la ecuación de escalabilidad.

desarrollo

Calificación: baja

Análisis: el sofisticado almacenamiento en caché y los productos de la cuadrícula de

datos en memoria hacen que este patrón sea relativamente complejo de desarrollar,
principalmente debido a la falta de familiaridad con las herramientas y los productos
utilizados para crear este tipo de arquitectura. Además, se debe tener especial cuidado
 al desarrollar este tipo de arquitecturas para asegurarse de que nada en el código
fuente afecte el rendimiento y la escalabilidad.

CARROS WASH

TIER BASED CAR WASH

el cph total es el cph mínimo

falla en cada almacén hace que el conjunto NEGOCIO fallan

para aumentar el rendimiento debe presupuestar los tres almacenes

personal con capacidades especializadas

TODO EN UN LAVADO DE COCHES

Para aumentar el CPH, simplemente agregue un nuevo almacén

una mejor utilización de los recursos

cada almacén es independiente

TWUITER

En Twitter, la relación principal entre las entidades es de muchos a muchos. Cada publicación
se envía a numerosos

seguidores del usuario que envió la publicación; al mismo tiempo, cada usuario puede seguir a
muchos otros usuarios. Esto causa

Twitter se comporta como un organismo vivo, creciendo inesperadamente en diferentes

direcciones.

Me centraré en lo que percibo como los mayores problemas de escalabilidad de Twitter:

 Crecimiento fluctuante: las redes de usuarios y seguidores crecen constantemente, el

tráfico tiende a fluctuar al azar.
 El efecto de multitud: la función de retweet, que permite a los usuarios volver a enviar
mensajes interesantes a su

propios seguidores, pueden conducir a una "tormenta perfecta". Un tweet particularmente

interesante puede provocar un repentino

aumento masivo e impredecible en el tráfico.

 SOLUCIÓN TRADICIONAL: ESCALAR AL AGREGAR CONTENEDORES WEB

La forma más común y obvia de escalar Twitter es hacer frente a la aplicación web con un
equilibrador de carga, que

desvía el tráfico a uno de varios servidores / contenedores web. Sin embargo, como muchos
de nosotros hemos llegado a saber, esto

enfoque tiene sus limitaciones.

Eliminación de cuellos de botella de la base de datos con cuadrícula de datos en memoria y

NoSQL

Como primer paso, colocar inmediatamente una grilla de datos en memoria entre el servidor
web y la base de datos

el cuello de botella de la base de datos. A medida que la aplicación crece, la cuadrícula de

datos en memoria se amplía y la base de datos se

utilizado en segundo plano, solo para almacenamiento a largo plazo. Esta es una solución
NoSQL porque el almacenamiento primario
el medio no es una base de datos.

Lograr escalabilidad lineal con particionamiento y colocación

El siguiente paso es agrupar la lectura y la publicación

servicios en una unidad de procesamiento, junto con

un espacio que proporciona una cuadrícula de datos en memoria

y otras capacidades.

Cada unidad de procesamiento es una partición que contiene

un subconjunto de los tweets que envían los usuarios. Un importante

pregunta es cómo dividir los tweets entre

particiones: hay algunos posibles enfoques,

el mejor parece ser la partición de

ID de usuario de Twitter. De esta manera, cada partición tiene

todos los tweets para un cierto número de usuarios.

Cuando la cantidad de usuarios crece, el

las unidades de procesamiento se pueden duplicar

veces como sea necesario, sin limitación.

Escala Lee y escribe

Para publicar un tweet, el servicio Writer simplemente lo "escribe" en el espacio, y se enruta al

instante al sitio apropiado.

dividir. Para leer todos los tweets, el servicio de Reader usa Map / Reduce - se recopilan tweets
de todas las particiones

y regresó al servicio en forma agregada.

DIAGRAMA DE AMAZON

drupal es una plataforma gratuita de gestión de contenido web de código abierto.

la comunidad drupal es una de las comunidades de código abierto más grandes del mundo con
más de 1 0000 000 desarrolladores apasionados, diseñadores, entrenadores, estrategas,
coordinadores, coordinadores, editores y patrocinadores. esta arquitectura de referencia le
permite implementar un sitio drupal escalable y altamente disponible en aws

1.- use amazon cloudfront para entregar contenido estático y dinámico

2.- use amazon s3 para almacenar contenido estático como archivos descargables de medios,
etc.

3.- conecte una puerta de enlace de Internet a su vpc para permitir la comunicación entre las
instancias de amazon ec2 en su vpc e internet

4.- utilice un equilibrador de carga de aplicaciones para distribuir el tráfico web a través de un
grupo de escalado automático de instancias de Amazon EC2 en múltiples zonas de
disponibilidad.

5.- crear una puerta de enlace nat en cada subred pública para enviar tráfico a la puerta de
enlace de Internet desde subredes privadas (aplicaciones y dat os) en su vpc

6.- ejecuta tu sitio drupal usando un grupo de escalado automático de instancias de Amazon
EC2. instale las últimas versiones de drupal, servidor web apache, php 7 y opcache. luego cree
una imagen de máquina amazónica que la configuración de inicio del grupo de escalamiento
automático pueda usar para iniciar nuevas instancias en el grupo.
7.- si los patrones de acceso a la base de datos son pesados, considere usar un plugin drupal
que aproveche una capa de caché como amazonche elasticache para memoria en memcache
en frente de la capa de la base de datos para almacenar en caché los datos a los que se accede
frecuentemente.

8.- ejecuta tu capa de base de datos en amazon rds usando aurora o mysql para simplificar tu
administración de databse

9.- después de crear un sistema de filmación de efs de Amazon, crea objetivos de mout. monte
el sistema de archivos en sus instancias drupal ammazon ec2 en cada zona de disponibilidad en
su vpc

10.- utiliza los efs de Amazon para instancias de Drupal para acceder a tus datos drupal no
estructurados compartidos, como archivos php, config, temas, complementos, etc.