Examen Arquitectura 2 PDF

Primer patrón: Cliente-servidor
Tiene la variación de 3 capas
Cliente servidor también llamado de

dos capas, pero es un mal nombre.
3 capas
El cliente es “thin”/liviano porque solo

hace la interacción con el usuario.
Ejemplo: Un browser/navegador
Distribución de la
interfaz, la aplicación y
la base de datos en el
cliente y el servidor.
Cliente
Servidor
Three-tiers:
El cliente interactúa
con el application
server y el application
server interactúa con el
database server.
El app server es el que

tiene la responsabilidad
de la lógica de negocios
(básicamente lo que
permite la
funcionalidad del
programa).
Three-tiers:
El cliente tiene la
interfaz de usuario y el
servidor de database
tiene la base de datos.
Duh.
Ejemplo
Segundo patrón:
arquitectura de capas
En inglés: Layered
Ejemplo: Capas con distintos protocolos →
Dato: Se pueden comunicar de una capa a otra no

consiguiente/ de abajo? En la práctica se permite, pero
no debería ser la regla. No es la idea. Uso excepcional
(por buena performance a veces se usa).
Se puede modificar una capa sin tener que alterar

todas.
Uso excepcional:
Ejemplo: Cliente y el Servidor pueden cada uno tener capas.
Otro ejemplo de combinaciones: Tener 2 tier, pero en el server

tener un MVC (Modelo Vista Controlador)
Patrón 3: Arquitectura de servicios
En las palabras del profe: “La que la

lleva hoy en día.”
El servicio no corre en el proceso

de la aplicación sino en otro
propio, y se comunica con la
aplicación por medio de
protocolos estándar,
especialmente http.
La aplicación sigue funcionando si

se reemplaza el servicio, ya que
los servicios son independientes.
Esto no se cumple en otras
componentes que no sean
servicios.
Como está en el esquema →

Los servicios son todos independientes, incluso en diferentes lenguajes
Los acuerdos
son
independientes
Usa distintas
tecnologías en
distintos
servicios
Resiliencia: si se
cae parte de la
aplicación no se Escalamiento: monolítico tendríamos que hacer
cae todo copias de la aplicación completa. O hacerla de
nuevo. Sin estructure de servicios → monolítica
Esquema a la derecha: Se replican los servicios Todo contenido en un mismo lugar
necesarios al nivel que se requieren.
Primera aproximación formal a la Tienen mucha relación
estructura de servicios con las APIs: interfaz a un
servicio.
Tema siguiente
Pregunta: Se necesitan
adaptadores del lenguaje?
Respuesta: No. La gracia de

la estructura de servicios es
La interfaz de los que no necesitan
servicios está adaptadores.. Lo único que
acordada/definida importa es la interfaz, no
cómo están construidos los
servicios.
Un servicio web (en inglés, web

service o web services) es una
tecnología que utiliza un conjunto de
protocolos y estándares que sirven
para intercambiar datos entre
aplicaciones.
Enterprise
Service Bus
coordina todo
Web Services: Para que

una aplicación se
conecte con un servicio
necesitan ponerse de
acuerdo → protocolos
La comunicación es
standard
Los servicios
pueden
corresponder a
más de una
aplicación
Ventaja de
arquitectura de
servicios
Total de la lógica
a implementar
Aplicando
servicios a parte
del código se
ahorra un 15%
Aplicando
servicios a todo
el código se
ahora casi la
mitad.
Sin servicios:
Dos aplicaciones que

pueden estar escritas en
formas muy distintas se
podrían comunicar por
ejemplo mediante
compartir archivos con
información.
Es una mala práctica de

integración.
Con servicios se integran

naturalmente.
No son dos aplicaciones,

son servicios
comunicándose.
Derivando de servicios
SOAP es un protocolo
Ahora se usa REST

Decentralized microservice communications enable engineering teams
to do parallel work on different edges of the architecture without
breaking other components. If each microservice treats other services as
external resources with no differentiation between internal services and
third party resources, it means each microservice encapsulates its own
logic for formatting its outgoing responses or supplementing its
incoming requests. This allows teams to independently add features or
modify existing features without needing to modify a central bus. Scaling
the microservice communications is also decentralized so that each
service can have its own load balancer and scaling logic.
Se dividen servicios, no
se separa por
especialidad
Smart
endpoints y
dumb pipes.
Granularidad: tamaño
de cada unidad
➔ Dumb pipes!
Es una parte pequeña
Los microservicios interactúan unos con otros

Middleware
Servicios
API
Microservicios aparecen
accediendo cada uno a sus
propios datos
Enfoque
clásico
Microservicios
Transacción: Se asegura la integridad de la

base de datos.
Con microservicios, como son

independientes, pueden producirse
inconsistencias temporales, que se
solucionan luego.
El Gateway
transforma de un
protocolo a otro
Los servicios se registran como servicios públicos (Registry
Service) que pueden ser llamados por el API.
Ejemplo: Imprimir es un servicio. El API lo llama sin saber

quién proveerá el servicio. El driver de la impresora se
define como ejecutor del servicio y por lo tanto se registra
como tal en el Registry Service, que hace el contacto entre
los dos.
Si hay 5 computadores que

brindan el servicio A, se
reparten equitativamente para
no sobrecargarlos/balancear.
Si uno falla, redirige entre los

que quedan.
Microservicios
En sistemas de baja
complejidad,
microservicios agrega
complejidad
innecesaria.
Entrega continua:
Nueva tendencia: Cada

iteración se pone
inmediatamente a
producción. El ciclo ágil se
extiende hasta que está A veces no es
instalado, no solo hasta claro qué
desarrollo. servicio falló.
Tiempo en que
los múltiples
servicios se
comunican
Muchas versiones
de muchos
servicios
Complejidad:
muchos
elementos
interactuando
Transacción bancaria: Si hay una falla

en medio de la operación es más fácil
manejarla si el programa es
monolítico, en vez de estar dividido
en microservicios. Esto puede
provocar fallas en la consistencia. En
este caso, un error en la transacción y
pérdida de dinero.
No usar una base de datos común
Provee la estructura de
comunicación
Inventario de servicios existentes
SLA: System Level Agreement.

Acuerdo de calidad. Ejemplo: Mi
App se cae no más de 3 veces por
una hora al mes. Mala mi app.
market

Examen Arquitectura 2 PDF

Cargado por

Copyright:

Formatos disponibles

Examen Arquitectura 2 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Examen Arquitectura 2 PDF

Cargado por

Copyright:

Formatos disponibles

Primer patrón: Cliente-servidor

Tiene la variación de 3 capas

Cliente servidor también llamado de

El cliente es “thin”/liviano porque solo

El app server es el que

Ejemplo: Capas con distintos protocolos →

Dato: Se pueden comunicar de una capa a otra no

Se puede modificar una capa sin tener que alterar

Ejemplo: Cliente y el Servidor pueden cada uno tener capas.

Otro ejemplo de combinaciones: Tener 2 tier, pero en el server

En las palabras del profe: “La que la

El servicio no corre en el proceso

La aplicación sigue funcionando si

Como está en el esquema →

Respuesta: No. La gracia de

Un servicio web (en inglés, web

Web Services: Para que

Dos aplicaciones que

Es una mala práctica de

Con servicios se integran

No son dos aplicaciones,

Ahora se usa REST

Es una parte pequeña

Los microservicios interactúan unos con otros

Transacción: Se asegura la integridad de la

Con microservicios, como son

Ejemplo: Imprimir es un servicio. El API lo llama sin saber

Si hay 5 computadores que

Si uno falla, redirige entre los

Nueva tendencia: Cada

Transacción bancaria: Si hay una falla

Inventario de servicios existentes

SLA: System Level Agreement.

También podría gustarte