Adicional

Recursos
4 formas fáciles de aprender más y mantenerse actualizado

Boletín de programación
Reciba semanalmente noticias y contenido relacionado con la programación en su bandeja de entrada.

oreilly.com/programming/newsletter

Serie FreeWebcast
Obtenga información sobre temas de programación populares de parte de expertos en vivo, en línea.

webcasts.oreilly.com

Radar O'Reilly
Lea más información y análisis sobre tecnologías emergentes.

radar.oreilly.com

Conferencias
Sumérjase en el aprendizaje en una próxima conferencia de O'Reilly.

conferencias.oreilly.com

© 2015 O'Reilly Media, Inc. El logotipo de O'Reilly es una marca comercial registrada de O'Reilly Media, Inc. # 15305
 Arquitectura de software
Patrones
Comprensión de la arquitectura común
Patrones y cuándo usarlos

Mark Richards
Patrones de arquitectura de software
por Mark Richards

Copyright © 2015 O'Reilly Media, Inc. Todos los derechos reservados. Impreso en

los Estados Unidos de América.

Publicado por O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472.

Los libros de O'Reilly se pueden comprar con fines educativos, comerciales o promocionales de ventas. Las ediciones en línea

también están disponibles para la mayoría de los títulos ( http://safaribooksonline.com ). Para obtener más información,

comuníquese con nuestro departamento de ventas corporativo / institucional: 800-998-9938 o corporate@oreilly.com.

Editor: Heather Scherer Diseñador de interiores: David Futato

Editor de producción: Colleen Lobner Diseñador de la portada: Ellie Volckhausen

Editor de copia: Amanda Kersey Ilustrador: Rebecca Demarest

Febrero de 2015: Primera edición

Historial de revisiones de la primera edición

2015-02-24: Primera versión
2015-03-30: segundo lanzamiento

El logotipo de O'Reilly es una marca registrada de O'Reilly Media, Inc. Patrones de arquitectura de software, la imagen de
portada y la imagen comercial relacionada son marcas comerciales de O'Reilly Media, Inc.

Si bien el editor y el autor han realizado esfuerzos de buena fe para garantizar que la información y las
instrucciones contenidas en este trabajo sean precisas, el editor y el autor renuncian a toda responsabilidad
por errores u omisiones, incluida, sin limitación, la responsabilidad por daños resultantes del uso. de o
confianza en este trabajo. El uso de la información y las instrucciones contenidas en este trabajo es bajo su
propio riesgo. Si alguna muestra de código u otra tecnología que este trabajo contiene o describe está sujeta a
licencias de código abierto o derechos de propiedad intelectual de otros, es su responsabilidad asegurarse de
que su uso cumpla con dichas licencias y / o derechos.

978-1-491-92424-2

[LSI]
 Tabla de contenido

Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

1. Arquitectura en capas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Descripción del patrón 1
Conceptos clave 3
Ejemplo de patrón 5
Consideraciones 7
Análisis de patrones 8

2. Arquitectura basada en eventos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Topología del mediador 11
Topología del agente 14
Consideraciones 17
Análisis de patrones 18

3. Arquitectura de microkernel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Descripción del patrón 21
Ejemplos de patrones 23
Consideraciones 24
Análisis de patrones 25

4. Patrón de Arquitectura de Microservicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Descripción del patrón 27
Topologías de patrones 29
Evite las dependencias y la orquestación 32
Consideraciones 33
Análisis de patrones 34

iii
5. Arquitectura basada en el espacio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Descripción del patrón 38
Dinámica de patrones 39
Consideraciones 42
Análisis de patrones 43

A. Resumen de análisis de patrones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

iv | Tabla de contenido
 Introducción

Es muy común que los desarrolladores comiencen a codificar una aplicación sin una
arquitectura formal establecida. Sin una arquitectura clara y bien definida, la mayoría de los
desarrolladores y arquitectos recurrirán al patrón de arquitectura en capas tradicional
estándar de facto (también llamado arquitectura de n niveles), creando capas implícitas al
separar los módulos de código fuente en paquetes. Desafortunadamente, lo que a menudo
resulta de esta práctica es una colección de módulos de código fuente desorganizados que
carecen de roles, responsabilidades y relaciones claras entre sí. Esto se conoce
comúnmente como el gran bola de barro

arquitectura anti-patrón.

Las aplicaciones que carecen de una arquitectura formal suelen estar estrechamente
acopladas, frágiles, difíciles de cambiar y sin una visión o una dirección claras. Como
resultado, es muy difícil determinar las características arquitectónicas de la aplicación sin
comprender completamente el funcionamiento interno de cada componente y módulo del
sistema. Las preguntas básicas sobre implementación y mantenimiento son difíciles de
responder: ¿Se escala la arquitectura? ¿Cuáles son las características de rendimiento de
la aplicación? ¿Con qué facilidad responde la aplicación al cambio? ¿Cuáles son las
características de implementación de la aplicación? ¿Qué tan receptiva es la arquitectura?

Los patrones de arquitectura ayudan a definir las características básicas y el

comportamiento de una aplicación. Por ejemplo, algunos patrones de arquitectura se
prestan naturalmente a aplicaciones altamente escalables, mientras que otros patrones
de arquitectura se prestan naturalmente a aplicaciones que son muy ágiles. Es
necesario conocer las características, fortalezas y debilidades de cada patrón de
arquitectura

v
sary para elegir el que se adapte a sus necesidades y objetivos comerciales específicos.

Como arquitecto, siempre debe justificar sus decisiones de arquitectura, especialmente

cuando se trata de elegir un patrón o enfoque de arquitectura en particular. El objetivo de
este informe es brindarle suficiente información para tomar y justificar esa decisión.

vi | Introducción
 CAPÍTULO 1

Arquitectura en capas

El patrón de arquitectura más común es el patrón de arquitectura en capas, también conocido como

patrón de arquitectura de n niveles. Este patrón es el estándar de facto para la mayoría de las

aplicaciones Java EE y, por lo tanto, es ampliamente conocido por la mayoría de arquitectos,

diseñadores y desarrolladores. El patrón de arquitectura en capas coincide estrechamente con las

estructuras organizativas y de comunicación de TI tradicionales que se encuentran en la mayoría de las

empresas, por lo que es una opción natural para la mayoría de los esfuerzos de desarrollo de

aplicaciones empresariales.

Descripción del patrón

Los componentes dentro del patrón de arquitectura en capas están organizados en capas
horizontales, cada capa desempeña un papel específico dentro de la aplicación (por ejemplo,
lógica de presentación o lógica de negocios). Aunque el patrón de arquitectura en capas no
especifica el número y los tipos de capas que deben existir en el patrón, la mayoría de las
arquitecturas en capas constan de cuatro capas estándar: presentación, negocio, persistencia y
base de datos ( Figura 1-1 ). En algunos casos, la capa empresarial y la capa de persistencia se
combinan en una única capa empresarial, en particular cuando la lógica de persistencia (p. Ej.,
SQL o HSQL) está incorporada dentro de los componentes de la capa empresarial. Por lo tanto,
las aplicaciones más pequeñas pueden tener solo tres capas, mientras que las aplicaciones
comerciales más grandes y complejas pueden contener cinco o más capas.

Cada capa del patrón de arquitectura en capas tiene un rol y una responsabilidad
específicos dentro de la aplicación. Por ejemplo, una capa de presentación sería
responsable de manejar toda la interfaz de usuario y

1
lógica de comunicación del navegador, mientras que una capa empresarial sería
responsable de ejecutar reglas empresariales específicas asociadas con la solicitud. Cada
capa de la arquitectura forma una abstracción en torno al trabajo que debe realizarse para
satisfacer una solicitud comercial en particular. Por ejemplo, la capa de presentación no
necesita saber ni preocuparse por cómo para obtener datos del cliente; solo necesita
mostrar esa información en una pantalla en un formato particular. De manera similar, la
capa empresarial no necesita preocuparse por cómo formatear los datos del cliente para
mostrarlos en una pantalla o incluso de dónde provienen los datos del cliente; solo necesita
obtener los datos de la capa de persistencia, realizar la lógica empresarial contra los datos
(por ejemplo, calcular valores o agregar datos) y pasar esa información a la capa de
presentación.

Figura 1-1. Patrón de arquitectura en capas

Una de las poderosas características del patrón de arquitectura en capas es la separación de

intereses entre componentes. Los componentes dentro de una capa específica tratan solo con la
lógica que pertenece a esa capa. Por ejemplo, los componentes de la capa de presentación solo se
ocupan de la lógica de presentación, mientras que los componentes que residen en la capa
empresarial solo se ocupan de la lógica empresarial. Este tipo de clasificación de componentes
facilita la creación de roles y modelos de responsabilidad efectivos en su arquitectura, y también
facilita el desarrollo, la prueba, el control y el mantenimiento de aplicaciones que utilizan este
patrón de arquitectura debido a las interfaces de componentes bien definidas y el alcance limitado
de los componentes.

2 | Capítulo 1: Arquitectura en capas

Conceptos clave
Aviso en Figura 1-2 que cada una de las capas de la arquitectura está marcada como cerrado. Este
es un concepto muy importante en el patrón de arquitectura en capas. Una capa cerrada significa
que a medida que una solicitud se mueve de una capa a otra, debe atravesar la capa que está
justo debajo para llegar a la siguiente capa debajo de esa. Por ejemplo, una solicitud que se
origina en la capa de presentación debe pasar primero por la capa de negocios y luego por la
capa de persistencia antes de llegar finalmente a la capa de base de datos.

Figura 1-2. Capas cerradas y solicitud de acceso

Entonces, ¿por qué no permitir que la capa de presentación acceda directamente a la capa de persistencia

o la capa de base de datos? Después de todo, el acceso directo a la base de datos desde la capa de

presentación es mucho más rápido que atravesar un montón de capas innecesarias solo para recuperar o

guardar información de la base de datos. La respuesta a esta pregunta radica en un concepto clave

conocido como capas de aislamiento.

El concepto de capas de aislamiento significa que los cambios realizados en una capa de la
arquitectura generalmente no afectan ni afectan a los componentes de otras capas: el cambio
se aísla a los componentes dentro de esa capa y posiblemente a otra capa asociada (como
una capa de persistencia que contenga SQL). Si permite que la capa de presentación acceda
directamente a la capa de persistencia, los cambios realizados en SQL dentro del

Conceptos clave | 3
La capa de persistencia afectaría tanto a la capa empresarial como a la capa de
presentación, produciendo así una aplicación muy estrechamente acoplada con muchas
interdependencias entre los componentes. Este tipo de arquitectura se vuelve muy difícil y
costoso de cambiar.

El concepto de capas de aislamiento también significa que cada capa es independiente de las
otras capas, por lo que tiene poco o ningún conocimiento del funcionamiento interno de otras
capas en la arquitectura. Para comprender el poder y la importancia de este concepto,
considere un gran esfuerzo de refactorización para convertir el marco de presentación de JSP
(Java Server Pages) a JSF (Java Server Faces). Suponiendo que los contratos (p. Ej., Modelo)
utilizados entre la capa de presentación y la capa empresarial siguen siendo los mismos, la
capa empresarial no se ve afectada por la refabricación y permanece completamente
independiente del tipo de marco de interfaz de usuario utilizado por la capa de presentación .

Si bien las capas cerradas facilitan las capas de aislamiento y, por lo tanto, ayudan a aislar el
cambio dentro de la arquitectura, hay ocasiones en las que tiene sentido que ciertas capas estén
abiertas. Por ejemplo, suponga que desea agregar una capa de servicios compartidos a una
arquitectura que contiene componentes de servicios comunes a los que acceden los
componentes dentro de la capa empresarial (por ejemplo, clases de servicios de datos y cadenas
o clases de auditoría y registro). Crear una capa de servicios suele ser una buena idea en este
caso porque arquitectónicamente restringe el acceso a los servicios compartidos a la capa
empresarial (y no a la capa de presentación). Sin una capa separada, no hay nada
arquitectónicamente que restrinja el acceso de la capa de presentación a estos servicios
comunes, lo que dificulta el control de esta restricción de acceso.

En este ejemplo, la nueva capa de servicios probablemente residiría abajo la capa empresarial
para indicar que los componentes de esta capa de servicios no son accesibles desde la capa
de presentación. Sin embargo, esto presenta un problema, ya que ahora se requiere que la
capa empresarial pase por la capa de servicios para llegar a la capa de persistencia, lo que no
tiene ningún sentido. Este es un viejo problema con la arquitectura en capas y se resuelve
creando capas abiertas dentro de la arquitectura.

Como se ilustra en Figura 1-3 , la capa de servicios en este caso está marcada como abierta, lo
que significa que las solicitudes pueden omitir esta capa abierta e ir directamente a la capa
debajo de ella. En el siguiente ejemplo, dado que la capa de servicios está abierta, la capa
empresarial ahora puede omitirla e ir directamente a la capa de persistencia, lo que tiene mucho
sentido.

4 | Capítulo 1: Arquitectura en capas

Figura 1-3. Capas abiertas y flujo de solicitudes

Aprovechar el concepto de capas abiertas y cerradas ayuda a definir la relación entre las capas
de la arquitectura y los flujos de solicitud y también proporciona a los diseñadores y
desarrolladores la información necesaria para comprender las diversas restricciones de acceso a
las capas dentro de la arquitectura. No documentar o comunicar correctamente qué capas de la
arquitectura están abiertas y cerradas (y por qué) generalmente da como resultado arquitecturas
frágiles y estrechamente acopladas que son muy difíciles de probar, mantener e implementar.

Ejemplo de patrón
Para ilustrar cómo funciona la arquitectura en capas, considere una solicitud de un usuario
empresarial para recuperar la información del cliente de un individuo en particular, como se
ilustra en Figura 1-4 . Las flechas negras muestran la solicitud fluyendo hacia la base de
datos para recuperar los datos del cliente, y las flechas rojas muestran la respuesta fluyendo
de regreso a la pantalla para mostrar los datos. En este ejemplo, la información del cliente
consta de datos del cliente y datos del pedido (pedidos realizados por el cliente).

Ejemplo de patrón | 5
los pantalla del cliente es responsable de aceptar la solicitud y mostrar la información
del cliente. No sabe dónde están los datos, cómo se recuperan o cuántas tablas de la
base de datos deben ser consultas para obtener los datos. Una vez que la pantalla del
cliente recibe una solicitud para obtener información del cliente para un individuo en
particular, reenvía esa solicitud al delegado del cliente módulo. Este módulo es
responsable de saber qué módulos de la capa empresarial pueden procesar esa
solicitud y también cómo llegar a ese módulo y qué datos necesita (el contrato). los objeto
del cliente en la capa empresarial es responsable de agregar toda la información
necesaria para la solicitud empresarial (en este caso, para obtener información del
cliente). Este módulo llama a la dao del cliente objeto de acceso a datos) en la capa de
persistencia para obtener datos del cliente, y también el orden dao

módulo para obtener información sobre el pedido. Estos módulos, a su vez, ejecutan
declaraciones SQL para recuperar los datos correspondientes y devolverlos al objeto del
cliente en la capa empresarial. Una vez que el objeto del cliente recibe los datos, agrega
los datos y pasa esa información de vuelta al delegado del cliente, que luego pasa esos
datos a la pantalla del cliente para ser presentados al usuario.

Figura 1-4. Ejemplo de arquitectura en capas

Desde una perspectiva tecnológica, hay literalmente decenas de formas en que estos módulos
se pueden implementar. Por ejemplo, en la plataforma Java, la pantalla del cliente puede ser
una pantalla (JSF) Java Server Faces

6 | Capítulo 1: Arquitectura en capas

junto con el delegado del cliente como componente de bean gestionado. El objeto de cliente en
la capa empresarial puede ser un bean Spring local o un bean EJB3 remoto. Los objetos de
acceso a datos ilustrados en el ejemplo anterior se pueden implementar como simples POJO
(Plain Old Java Objects), archivos MyBatis XML Mapper o incluso objetos que encapsulan
llamadas JDBC sin procesar o consultas de Hibernate. Desde la perspectiva de la plataforma
Micro‐ soft, la pantalla del cliente puede ser un módulo ASP (páginas activas del servidor) que
utiliza el marco .NET para acceder a los módulos C # en la capa empresarial, con los módulos
de acceso a los datos del cliente y del pedido implementados como ADO (ActiveX Objetos de
datos).

Consideraciones
El patrón de arquitectura en capas es un patrón sólido de uso general, lo que lo convierte en un
buen punto de partida para la mayoría de las aplicaciones, especialmente cuando no está
seguro de qué patrón de arquitectura es el más adecuado para su aplicación. Sin embargo, hay
un par de cosas a considerar desde el punto de vista de la arquitectura al elegir este patrón.

Lo primero que hay que tener en cuenta es lo que se conoce como arquitectura anti-patrón
de sumidero. Este anti-patrón describe la situación en la que las solicitudes fluyen a través
de múltiples capas de la arquitectura como un simple procesamiento de paso con poca o
ninguna lógica realizada dentro de cada capa. Por ejemplo, suponga que la capa de
presentación responde a una solicitud del usuario para recuperar datos del cliente. La capa
de presentación pasa la solicitud a la capa empresarial, que simplemente pasa la solicitud a
la capa de persistencia, que luego realiza una simple llamada SQL a la capa de base de
datos para recuperar los datos del cliente. Luego, los datos se devuelven a la pila sin ningún
procesamiento o lógica adicional para agregar, calcular o transformar los datos.

Cada arquitectura en capas tendrá al menos algunos escenarios que caen en el anti-patrón
de sumidero de arquitectura. Sin embargo, la clave es analizar el porcentaje de solicitudes
que entran en esta categoría. La regla 80-20 suele ser una buena práctica a seguir para
determinar si está experimentando o no el antipatrón de sumidero de arquitectura. Es típico
tener alrededor del 20 por ciento de las solicitudes como procesamiento simple de paso y el
80 por ciento de las solicitudes con alguna lógica de negocios asociada con la solicitud. Sin
embargo, si encuentra que esta proporción se invierte y la mayoría de sus solicitudes son
un simple procesamiento de transferencia, es posible que desee considerar hacer algunas
de las

Consideraciones | 7
Las capas de arquitectura se abren, teniendo en cuenta que será más difícil controlar el cambio
debido a la falta de aislamiento de capas.

Otra consideración con el patrón de arquitectura en capas es que tiende a prestarse a

aplicaciones monolíticas, incluso si divide la capa de presentación y las capas comerciales
en unidades desplegables separadas. Si bien esto puede no ser una preocupación para
algunas aplicaciones, plantea algunos problemas potenciales en términos de
implementación, solidez y confiabilidad general, rendimiento y escalabilidad.

Análisis de patrones
La siguiente tabla contiene una calificación y un análisis de las características de
arquitectura comunes para el patrón de arquitectura en capas. La calificación de 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 lo que generalmente se
conoce al patrón. Para obtener una comparación en paralelo de cómo se relaciona este
patrón con otros patrones de este informe, consulte Apéndice A al final de este informe.

Agilidad general
Clasificación: Bajo

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

constante cambio. Si bien el cambio puede aislarse a través de las capas de característica de
aislamiento de este patrón, sigue siendo engorroso y requiere mucho tiempo realizar cambios
en este patrón de arquitectura debido a la naturaleza monolítica de la mayoría de las
implementaciones, así como al estrecho acoplamiento de los componentes que generalmente
se encuentran con este patrón.

Facilidad de implementación

Clasificación: Bajo

Análisis: Dependiendo de cómo implemente este patrón, la implementación puede

convertirse en un problema, particularmente para aplicaciones más grandes. Un pequeño
cambio en un componente puede requerir la reimplementación de toda la aplicación (o
una gran parte de la aplicación), lo que da como resultado implementaciones que deben
planificarse, programarse y ejecutarse fuera del horario laboral o los fines de semana.
Como tal, este patrón no se presta fácilmente a un flujo de entrega continuo, lo que
reduce aún más la calificación general para la implementación.

8 | Capítulo 1: Arquitectura en capas

Probabilidad

Clasificación: Alto

Análisis: Debido a que los componentes pertenecen a capas específicas en la arquitectura, otras
capas se pueden simular o eliminar, por lo que este patrón es relativamente fácil de probar. Un

desarrollador puede simular un componente de presentación o una pantalla para aislar las

pruebas dentro de un componente empresarial, así como simular la capa empresarial para

probar determinadas funciones de la pantalla.

Actuación
Clasificación: Bajo

Análisis: Si bien es cierto que algunas arquitecturas en capas pueden funcionar bien,
el patrón no se presta a aplicaciones de alto rendimiento debido a las ineficiencias
de tener que pasar por múltiples capas de la arquitectura para cumplir con una
solicitud comercial.

Escalabilidad

Clasificación: Bajo

Análisis: Debido a la tendencia hacia implementaciones monolíticas y estrechamente

acopladas de este patrón, las aplicaciones construidas con este patrón de arquitectura son
generalmente difíciles de escalar. Puede escalar una arquitectura en capas dividiendo las
capas en implementaciones físicas separadas o replicando la aplicación completa en
varios nodos, pero en general la granularidad es demasiado amplia, lo que hace que sea
costoso escalar.

Facilidad de desarrollo
Clasificación: Alto

Análisis: La facilidad de desarrollo obtiene una puntuación relativamente alta, principalmente

porque este patrón es muy conocido y no es demasiado complejo de implementar. Debido a
que la mayoría de las empresas desarrollan aplicaciones separando conjuntos de habilidades
por capas (presentación, negocios, base de datos), este patrón se convierte en una opción
natural para la mayoría del desarrollo de aplicaciones comerciales. La conexión entre la
estructura de comunicación y organización de una empresa y la forma en que se desarrolla el
software se describe es lo que se llama Ley de Conway. Puede buscar en Google la "ley de
Conway" para obtener más información sobre esta fascinante correlación.

Análisis de patrones | 9
 CAPITULO 2

Arquitectura impulsada por eventos

El patrón de arquitectura impulsada por eventos es un patrón de arquitectura asíncrona

distribuida popular que se utiliza para producir aplicaciones altamente escalables. También es
altamente adaptable y se puede utilizar para aplicaciones pequeñas y grandes y complejas. La
arquitectura impulsada por eventos se compone de componentes de procesamiento de eventos
de propósito único y altamente desacoplados que reciben y procesan eventos de forma
asincrónica.

El patrón de arquitectura impulsado por eventos consta de dos topologías principales, el

mediador y el intermediario. La topología de mediador se usa comúnmente cuando
necesita orquestar varios pasos dentro de un evento a través de un mediador central,
mientras que la topología de intermediario se usa cuando desea encadenar eventos sin el
uso de un mediador central. Debido a que las características de la arquitectura y las
estrategias de implementación difieren entre estas dos topologías, es importante
comprender cada una para saber cuál es la más adecuada para su situación particular.

Topología del mediador

La topología del mediador es útil para eventos que tienen varios pasos y requieren algún nivel
de orquestación para procesar el evento. Por ejemplo, un solo evento para realizar una
operación de acciones puede requerir que primero valide la operación, luego verifique el
cumplimiento de esa operación de acciones con varias reglas de cumplimiento, asigne la
operación a un corredor, calcule la comisión y finalmente coloque la operación. comercia con
ese corredor. Todos estos pasos requerirían cierto nivel de orquestación para disuadir

11
mía el orden de los pasos y cuáles se pueden hacer en serie y en paralelo.

Hay cuatro tipos principales de componentes de arquitectura dentro de la topología del

mediador: colas de eventos, un mediador de eventos, canales de eventos y procesadores de
eventos. El flujo de eventos comienza con un cliente que envía un evento a un cola de
eventos, que se utiliza para transportar el evento al mediador del evento. los mediador de
eventos recibe el evento inicial y lo organiza enviando eventos asincrónicos adicionales a canales
de eventos para ejecutar cada paso del proceso. Procesos de eventos, que escuchan en los
canales de eventos, reciben el evento del mediador del evento y ejecutan una lógica
empresarial específica para procesar el evento. Figura 2-1 ilustra la topología de mediador
general del patrón de arquitectura dirigida por eventos.

Figura 2-1. Topología del mediador de arquitectura dirigida por eventos

Es común tener entre una docena y varios cientos de colas de eventos en una arquitectura
impulsada por eventos. El patrón no especifica la implementación del componente de cola
de eventos; puede ser una cola de mensajes, un punto final de servicio web o cualquier
combinación de los mismos.

Hay dos tipos de eventos dentro de este patrón: un evento inicial y un evento de
procesamiento. El evento inicial es el evento original recibido por

12 | Capítulo 2: Arquitectura impulsada por eventos

el mediador, mientras que los eventos de procesamiento son aquellos que son generados por el
mediador y recibidos por los componentes de procesamiento de eventos.

El componente mediador de eventos es responsable de orquestar los pasos contenidos en

el evento inicial. Para cada paso del evento inicial, el mediador de eventos envía un
evento de procesamiento específico a un canal de eventos, que luego es recibido y
procesado por el procesador de eventos. Es importante tener en cuenta que el mediador
de eventos en realidad no realiza la lógica empresarial necesaria para procesar el evento
inicial; más bien, conoce los pasos necesarios para procesar el evento inicial.

Los canales de eventos son utilizados por el mediador de eventos para pasar de forma asincrónica eventos

de procesamiento específicos relacionados con cada paso en el evento inicial a los procesadores de

eventos. Los canales de eventos pueden ser colas de mensajes o temas de mensajes, aunque los temas de

mensajes se utilizan más ampliamente con la topología de mediador, de modo que los eventos de

procesamiento pueden ser procesados por múltiples procesadores de eventos (cada uno de ellos

realizando una tarea diferente según el evento de procesamiento recibido).

Los componentes del procesador de eventos contienen la lógica empresarial de la aplicación necesaria
para procesar el evento de procesamiento. Los procesadores de eventos son componentes de
arquitectura autónomos, independientes y altamente desacoplados que realizan una tarea específica
en la aplicación o el sistema. Si bien la granularidad del componente del procesador de eventos puede
variar de detallada (por ejemplo, calcular el impuesto sobre las ventas en un pedido) a granularidad
(por ejemplo, procesar una reclamación de seguro), es importante tener en cuenta que, en general,
cada El componente procesador de eventos debe realizar una sola tarea comercial y no depender de
otros procesadores de eventos para completar su tarea específica.

El mediador de eventos se puede implementar de varias formas. Como arquitecto, debe

comprender cada una de estas opciones de implementación para asegurarse de que la
solución que elija para el mediador de eventos se ajuste a sus necesidades y requisitos.

La implementación más simple y común del mediador de eventos es a través de centros de

integración de código abierto como Spring Integration, Apache Camel o Mule ESB. Los flujos
de eventos en estos centros de integración de código abierto generalmente se implementan
mediante código Java o un DSL (lenguaje específico del dominio). Para una mediación y una
orquestación más sofisticadas, puede utilizar BPEL (lenguaje de ejecución de procesos de
negocio) junto con un motor BPEL como el de código abierto.

Topología del mediador | 13

Apache ODE. BPEL es un lenguaje estándar similar a XML que describe los datos y los pasos
necesarios para procesar un evento inicial. Para aplicaciones muy grandes que requieren una
orquestación mucho más sofisticada (incluidos los pasos que involucran interacciones humanas),
puede implementar el mediador de eventos utilizando un administrador de procesos de negocios
(BPM) como jBPM.

Comprender sus necesidades y adaptarlas a la implementación correcta del mediador de eventos es

fundamental para el éxito de cualquier arquitectura impulsada por eventos que utilice esta topología. El
uso de un centro de integración de código abierto para realizar una orquestación de gestión de
procesos de negocios muy compleja es una receta para el fracaso, al igual que implementar una
solución BPM para realizar una lógica de enrutamiento simple.

Para ilustrar cómo funciona la topología del mediador, suponga que está asegurado a través de una
compañía de seguros y decide mudarse. En este caso, el evento inicial podría llamarse algo como evento
de reubicación. Los pasos involucrados en el procesamiento de un evento de reubicación están
contenidos dentro del mediador de eventos como se muestra en Figura 2-2 . Para cada paso del
evento inicial, el mediador del evento crea un evento de procesamiento (por ejemplo,

cambiar dirección, recalcar cotización, etc.), envía ese evento de procesamiento al canal de eventos y
espera a que el evento de procesamiento sea procesado por el procesador de eventos
correspondiente (por ejemplo, proceso del cliente, proceso de cotización, etc.). Este proceso continúa
hasta que se hayan procesado todos los pasos del evento inicial. La barra única sobre los pasos de
cotización recalc y actualización de reclamos en el mediador de eventos indica que estos pasos se
pueden ejecutar al mismo tiempo.

Topología del agente

La topología del intermediario se diferencia de la topología del mediador en que no hay un
mediador de eventos central; más bien, el flujo de mensajes se distribuye a través de los
componentes del procesador de eventos en forma de cadena a través de un intermediario de
mensajes ligero (por ejemplo, ActiveMQ, HornetQ, etc.). Esta topología es útil cuando tiene un
flujo de procesamiento de eventos relativamente simple y no desea (o necesita) una
orquestación central de eventos.

Hay dos tipos principales de componentes de arquitectura dentro de la topología del intermediario:
a corredor componente y un procesador de eventos componente. El componente de intermediario
se puede centralizar o federar y contiene todos los canales de eventos que se utilizan dentro del
flujo de eventos.

14 | Capítulo 2: Arquitectura impulsada por eventos

Los canales de eventos contenidos en el componente de intermediario pueden ser colas de mensajes,

temas de mensajes o una combinación de ambos.

Figura 2-2. Ejemplo de topología de mediador

Esta topología se ilustra en Figura 2-3 . Como puede ver en el diagrama, no hay un
componente central de evento-mediador que controle y orquesta el evento inicial; más bien,
cada componente del procesador de eventos es responsable de procesar un evento y
publicar un nuevo evento que indica la acción que acaba de realizar. Por ejemplo, un
procesador de eventos que equilibra una cartera de acciones puede recibir un evento inicial
llamado división de acciones. Basado en ese evento inicial, el procesador de eventos puede
hacer un reequilibrio de la cartera y luego publicar un nuevo evento para el corredor llamado reequilibrar
la cartera, que luego sería recogido por un procesador de eventos diferente. Tenga en cuenta
que puede haber ocasiones en las que un procesador de eventos publique un evento, pero
ningún otro procesador de eventos lo recoja. Esto es común cuando está desarrollando una
aplicación o proporcionando funcionalidades y extensiones futuras.

Topología del corredor | 15

Figura 2-3. Topología del agente de arquitectura basada en eventos

Para ilustrar cómo funciona la topología del corredor, usaremos el mismo ejemplo que en la
topología del mediador (una persona asegurada se muda). Dado que no hay un mediador de
eventos central para recibir el evento inicial en la topología del corredor, el componente de
proceso del cliente recibe el evento directamente, cambia la dirección del cliente y envía un
evento diciendo que cambió la dirección de un cliente (por ejemplo, cambiar dirección evento). En
este ejemplo, hay dos procesadores de eventos que están interesados en el cambiar dirección evento:
el proceso de cotización y el proceso de reclamaciones. El componente del procesador de
cotizaciones vuelve a calcular las nuevas tarifas de seguro de automóvil en función del cambio de
dirección y publica un evento al resto del sistema que indica lo que hizo (por ejemplo, cita recalc

evento). El componente de procesamiento de reclamos, por otro lado, recibe el mismo cambiar
dirección evento, pero en este caso, actualiza una reclamación de seguro pendiente y publica
un evento en el sistema como un actualizar reclamo evento. Estos nuevos eventos son luego
recogidos por otros componentes del procesador de eventos, y la cadena de eventos continúa
a través del sistema hasta que no se publican más eventos para ese evento de inicio en
particular.

16 | Capítulo 2: Arquitectura impulsada por eventos

Figura 2-4. Ejemplo de topología de intermediario

Como puedes ver en Figura 2-4 , la topología del corredor se trata del encadenamiento de eventos
para realizar una función comercial. La mejor manera de comprender la topología del corredor es
pensar en ella como una carrera de relevos. En una carrera de relevos, los corredores sostienen un
testigo y corren una cierta distancia, luego entregan el testigo al siguiente corredor y así
sucesivamente hasta que el último corredor cruza la línea de meta. En las carreras de relevos, una
vez que un corredor entrega el testigo, termina la carrera. Esto también es cierto con la topología
del intermediario: una vez que un procesador de eventos entrega el evento, ya no está involucrado
en el procesamiento de ese evento específico.

Consideraciones
El patrón de arquitectura impulsada por eventos es un patrón relativamente complejo de
implementar, principalmente debido a su naturaleza distribuida asincrónica. Al implementar este
patrón, debe abordar varios problemas de arquitectura distribuida, como la disponibilidad de
procesos remotos, la falta de capacidad de respuesta y la lógica de reconexión del intermediario
en caso de falla de un intermediario o mediador.

Consideraciones | 17
Una consideración a tener en cuenta al elegir este patrón de arquitectura es la falta de
transacciones atómicas para un solo proceso empresarial. Debido a que los componentes
del procesador de eventos están altamente desacoplados y distribuidos, es muy difícil
mantener una unidad de trabajo transaccional entre ellos. Por esta razón, al diseñar su
aplicación utilizando este patrón, debe pensar continuamente en qué eventos pueden y no
pueden ejecutarse de forma independiente y planificar la granularidad de sus procesadores
de eventos en consecuencia. Si encuentra que necesita dividir una sola unidad de trabajo
entre procesadores de eventos, es decir, si está usando procesadores separados para algo
que debería ser una transacción no dividida, probablemente este no sea el patrón correcto
para su aplicación.

Quizás uno de los aspectos más difíciles del patrón de arquitectura impulsada por eventos es la
creación, el mantenimiento y la gobernanza de los contratos de los componentes del procesador de
eventos. Cada evento suele tener un contrato específico asociado (por ejemplo, los valores de los
datos y el formato de los datos que se pasan al procesador de eventos). Al utilizar este patrón, es
de vital importancia establecer un formato de datos estándar (por ejemplo, XML, JSON, Java
Object, etc.) y establecer una política de control de versiones del contrato desde el principio.

Análisis de patrones
La siguiente tabla contiene una calificación y análisis de las características de la arquitectura
común para el patrón de arquitectura impulsada por eventos. La calificación de 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 lo que generalmente se
conoce al patrón. Para obtener una comparación en paralelo de cómo se relaciona este
patrón con otros patrones de este informe, consulte Apéndice A al final de este informe.

Agilidad general
Clasificación: Alto

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

constante cambio. Dado que los componentes del procesador de eventos son de un solo
propósito y están completamente desacoplados de otros componentes del procesador de
eventos, los cambios generalmente se aíslan en uno o unos pocos procesadores de eventos y
se pueden realizar rápidamente sin afectar a otros componentes.

18 | Capítulo 2: Arquitectura impulsada por eventos

Facilidad de implementación

Clasificación: Alto

Análisis: En general, este patrón es relativamente fácil de implementar debido a la naturaleza

desacoplada de los componentes del procesador de eventos. La topología del intermediario tiende

a ser más fácil de implementar que la topología del mediador, principalmente porque el

componente del mediador de eventos está estrechamente acoplado a los procesadores de

eventos: un cambio en un componente del procesador de eventos también puede requerir un

cambio en el mediador de eventos, requiriendo ambos para ser implementado para cualquier

cambio dado.

Probabilidad

Clasificación: Bajo

Análisis: Si bien la prueba de unidad individual no es demasiado difícil, requiere algún tipo
de cliente de prueba especializado o herramienta de prueba para generar eventos. Las
pruebas también se complican por la naturaleza asincrónica de este patrón.

Actuación
Clasificación: Alto

Análisis: Aunque ciertamente es posible implementar una arquitectura impulsada

por eventos que no funciona bien debido a toda la infraestructura de mensajería
involucrada, en general, el patrón logra un alto rendimiento a través de sus
capacidades asincrónicas; en otras palabras, la capacidad de realizar operaciones
asincrónicas paralelas y desacopladas supera el costo de poner en cola y retirar
los mensajes.

Escalabilidad

Clasificación: Alto

Análisis: La escalabilidad se logra naturalmente en este patrón a través de procesadores de

eventos altamente independientes y desacoplados. Cada procesador de eventos se puede escalar

por separado, lo que permite una escalabilidad detallada.

Facilidad de desarrollo
Clasificación: Bajo

Análisis: El desarrollo puede ser algo complicado debido a la naturaleza asincrónica

del patrón, así como a la creación del contrato y la necesidad de condiciones de
manejo de errores más avanzadas dentro del código para procesadores de eventos
que no responden y corredores fallidos.

Análisis de patrones | 19
 CAPÍTULO 3

Arquitectura de microkernel

El patrón de arquitectura de microkernel (a veces denominado patrón de arquitectura de

complemento) es un patrón natural para implementar aplicaciones basadas en productos. Una
aplicación basada en productos es aquella que está empaquetada y disponible para su descarga
en versiones como un producto típico de terceros. Sin embargo, muchas empresas también
desarrollan y lanzan sus aplicaciones comerciales internas, como productos de software, con
versiones, notas de lanzamiento y funciones conectables. Estos también son un ajuste natural
para este patrón. El patrón de arquitectura de microkernel le permite agregar funciones de
aplicación adicionales como complementos a la aplicación principal, proporcionando
extensibilidad, así como separación y aislamiento de funciones.

Descripción del patrón

El patrón de arquitectura de microkernel consta de dos tipos de componentes de arquitectura: un sistema
central y módulos enchufables. La lógica de la aplicación se divide entre módulos enchufables
independientes y el sistema central básico, lo que proporciona extensibilidad, flexibilidad y
aislamiento de las funciones de la aplicación y lógica de procesamiento personalizada. Figura 3-1 ilustra
el patrón básico de arquitectura del microkernel.

El sistema central del patrón de arquitectura de microkernel contiene tradicionalmente solo

la funcionalidad mínima requerida para que el sistema sea operativo. Muchos sistemas
operativos implementan el patrón de arquitectura de micro-kernel, de ahí el origen del
nombre de este patrón. Desde la perspectiva de una aplicación empresarial, el sistema
central suele

21
definida como la lógica empresarial general sin código personalizado para casos especiales, reglas

especiales o procesamiento condicional complejo.

Figura 3-1. Patrón de arquitectura de microkernel

Los módulos enchufables son componentes independientes e independientes que contienen

procesamiento especializado, características adicionales y código personalizado destinado a mejorar
o ampliar el sistema central para producir capacidades comerciales adicionales. Por lo general, los
módulos enchufables deben ser independientes de otros módulos enchufables, pero ciertamente
puede diseñar complementos que requieran la presencia de otros complementos. De cualquier
manera, es importante mantener la comunicación entre los complementos al mínimo para evitar
problemas de dependencia.

El sistema central necesita saber qué módulos enchufables están disponibles y cómo acceder
a ellos. Una forma común de implementar esto es a través de algún tipo de registro de
complementos. Este registro contiene información sobre cada módulo de complemento,
incluidos aspectos como su nombre, contrato de datos y detalles del protocolo de acceso
remoto (dependiendo de cómo esté conectado el complemento al sistema central). Por
ejemplo, un complemento para software fiscal que marca elementos de auditoría fiscal de alto
riesgo puede tener una entrada de registro que contenga el nombre del servicio
(AuditChecker), el contrato de datos (datos de entrada y datos de salida) y el contrato. formato
(XML). También puede contener un WSDL (lenguaje de definición de servicios web) si se
accede al complemento a través de SOAP.

Los módulos enchufables se pueden conectar al sistema central a través de una variedad de
formas, incluyendo OSGi (iniciativa de puerta de enlace de servicio abierto), mensajería, servicios
web o incluso enlace directo punto a punto (es decir, instanciación de objetos). El tipo de conexión
que utiliza depende del tipo de aplicación que está creando (producto pequeño o aplicación de
gran empresa) y sus necesidades específicas (p. Ej., Implementación única o distribución

22 | Capítulo 3: Arquitectura de microkernel

despliegue tributo). El patrón de arquitectura en sí mismo no especifica ninguno de
estos detalles de implementación, solo que los módulos enchufables deben permanecer
independientes entre sí.

Los contratos entre los módulos enchufables y el sistema central pueden variar desde contratos
estándar hasta personalizados. Los contratos personalizados se encuentran típicamente en
situaciones en las que los componentes del complemento son desarrollados por un tercero
donde usted no tiene control sobre el contrato utilizado por el complemento. En tales casos, es
común crear un adaptador entre el contacto del complemento y su contrato estándar para que
el sistema central no necesite un código especializado para cada complemento. Al crear
contratos estándar (generalmente implementados a través de XML o un mapa de Java), es
importante recordar crear una estrategia de control de versiones desde el principio.

Ejemplos de patrones
Quizás el mejor ejemplo de la arquitectura de microkernel es el IDE de Eclipse. La descarga del
producto básico de Eclipse le proporciona poco más que un editor elegante. Sin embargo, una
vez que comience a agregar complementos, se convertirá en un producto altamente
personalizable y útil. Los navegadores de Internet son otro ejemplo de producto común que utiliza
la arquitectura de microkernel: los visores y otros complementos agregan capacidades adicionales
que de otro modo no se encuentran en el navegador básico (es decir, el sistema central).

Los ejemplos son infinitos para el software basado en productos, pero ¿qué pasa con las grandes
aplicaciones empresariales? La arquitectura del microkernel también se aplica a estas
situaciones. Para ilustrar este punto, usemos otro ejemplo de compañía de seguros, pero esta
vez uno que involucra el procesamiento de reclamos de seguros.

El procesamiento de reclamaciones es un proceso muy complicado. Cada estado tiene diferentes

reglas y regulaciones sobre lo que está y no está permitido en un reclamo de seguro. Por ejemplo,
algunos estados permiten el reemplazo gratuito del parabrisas si su parabrisas está dañado por una
roca, mientras que otros estados no. Esto crea un conjunto casi infinito de condiciones para un
proceso de reclamaciones estándar.

No es sorprendente que la mayoría de las aplicaciones de reclamaciones de seguros aprovechen motores

de reglas grandes y complejos para manejar gran parte de esta complejidad. Sin embargo, estos motores de

reglas pueden convertirse en una gran bola de barro compleja donde el cambio de una regla impacta otras

reglas, o la creación de una

Ejemplos de patrones | 23
El simple cambio de reglas requiere un ejército de analistas, desarrolladores y evaluadores. El uso del

patrón de arquitectura de microkernel puede resolver muchos de estos problemas.

La pila de carpetas que ves en Figura 3-2 representa el sistema central para el procesamiento de

reclamaciones. Contiene la lógica empresarial básica requerida por la compañía de seguros para

procesar un reclamo, excepto sin ningún procesamiento personalizado. Cada módulo de complemento

contiene las reglas específicas para ese estado. En este ejemplo, los módulos de complemento se

pueden implementar utilizando código fuente personalizado o instancias de motor de reglas separadas.

Independientemente de la implementación, el punto clave es que las reglas y el procesamiento

específicos del estado están separados del sistema de reclamos central y se pueden agregar, eliminar y

cambiar con poco o ningún efecto en el resto del sistema central u otros módulos complementarios. .

Figura 3-2. Ejemplo de arquitectura de microkernel

Consideraciones
Una gran cosa sobre el patrón de arquitectura de microkernel es que se puede incrustar o
usar como parte de otro patrón de arquitectura. Por ejemplo, si este patrón resuelve un
problema particular que tiene con un área volátil específica de la aplicación, es posible que
no pueda implementar el todo arquitectura usando este patrón. En este caso, puede
incrustar el patrón de arquitectura de microservicios en otro patrón que esté utilizando (por
ejemplo, arquitectura en capas). De manera similar, los componentes del procesador de
eventos descritos en la sección anterior sobre arquitectura dirigida por eventos podrían
implementarse utilizando el patrón de arquitectura de microservicios.

El patrón de arquitectura de microservicios proporciona un gran soporte para el diseño

evolutivo y el desarrollo incremental. Primero puede producir un sistema de núcleo sólido y, a
medida que la aplicación evoluciona, aumenta

24 | Capítulo 3: Arquitectura de microkernel

mentalmente, agregue características y funcionalidades sin tener que realizar cambios significativos
en el sistema central.

Para las aplicaciones basadas en productos, el patrón de arquitectura de microkernel

siempre debe ser su primera opción como arquitectura inicial, particularmente para
aquellos productos en los que lanzará funciones adicionales con el tiempo y desea
controlar qué usuarios obtienen qué funciones. Si con el tiempo descubre que el
patrón no satisface todos sus requisitos, siempre puede refactorizar su aplicación a
otro patrón de arquitectura que se adapte mejor a sus requisitos específicos.

Análisis de patrones
La siguiente tabla contiene una calificación y un análisis de las características de la
arquitectura común para el patrón de arquitectura del microkernel. La calificación de 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 lo que generalmente se
conoce al patrón. Para obtener una comparación en paralelo de cómo se relaciona este
patrón con otros patrones de este informe, consulte Apéndice A al final de este informe.

Agilidad general
Clasificación: Alto

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

constante cambio. Los cambios pueden aislarse en gran medida e implementarse rápidamente
a través de módulos enchufables acoplados libremente. En general, el sistema central de la
mayoría de las arquitecturas de microkernel tiende a estabilizarse rápidamente y, como tal, es
bastante robusto y requiere pocos cambios con el tiempo.

Facilidad de implementación

Clasificación: Alto

Análisis: Dependiendo de cómo se implemente el patrón, los módulos enchufables se pueden

agregar dinámicamente al sistema central en tiempo de ejecución (p. Ej., Implementación en

caliente), minimizando el tiempo de inactividad durante la implementación.

Análisis de patrones | 25
Probabilidad

Clasificación: Alto

Análisis: Los módulos enchufables se pueden probar de forma aislada y el sistema central puede

burlarse fácilmente de ellos para demostrar o crear un prototipo de una característica en particular

con poco o ningún cambio en el sistema central.

Actuación
Clasificación: Alto

Análisis: Si bien el patrón de microkernel no se presta naturalmente a aplicaciones de alto

rendimiento, en general, la mayoría de las aplicaciones creadas con el patrón de
arquitectura de microkernel funcionan bien porque puede personalizar y optimizar las
aplicaciones para que solo incluyan las características que necesita. El servidor de
aplicaciones JBoss es un buen ejemplo de esto: con su arquitectura de complementos,
puede reducir el servidor de aplicaciones a solo aquellas características que necesita,
eliminando características costosas no utilizadas como acceso remoto, mensajería y
almacenamiento en caché que consumen memoria. , CPU y subprocesos y ralentiza el
servidor de aplicaciones.

Escalabilidad

Clasificación: Bajo

Análisis: Debido a que la mayoría de las implementaciones de arquitectura de microkernel se

basan en productos y generalmente son de menor tamaño, se implementan como unidades

individuales y, por lo tanto, no son altamente escalables. Dependiendo de cómo implemente los

módulos de complemento, a veces puede proporcionar escalabilidad en el nivel de la característica

de complemento, pero en general este patrón no es conocido por producir aplicaciones altamente

escalables.

Facilidad de desarrollo
Clasificación: Bajo

Análisis: La arquitectura del microkernel requiere un diseño cuidadoso y una gobernanza del
contrato, lo que la hace bastante compleja de implementar. El control de versiones de los

contratos, los registros internos de complementos, la granularidad de los complementos y las

amplias opciones disponibles para la conectividad de los complementos contribuyen a la

complejidad que implica la implementación de este patrón.

26 | Capítulo 3: Arquitectura de microkernel

 CAPÍTULO 4

Patrón de arquitectura de microservicios

El patrón de arquitectura de microservicios está ganando terreno rápidamente en la

industria como una alternativa viable a las aplicaciones monolíticas y las arquitecturas
orientadas a servicios. Debido a que este patrón de arquitectura aún está evolucionando,
hay mucha confusión en la industria sobre de qué se trata este patrón y cómo se
implementa. Esta sección del informe le proporcionará los conceptos clave y el
conocimiento básico necesario para comprender los beneficios (y las compensaciones)
de este importante patrón de arquitectura y si es el patrón correcto para su aplicación.

Descripción del patrón

Independientemente de la topología o el estilo de implementación que elija, existen varios
conceptos básicos comunes que se aplican al patrón de arquitectura general. El primero de estos
conceptos es la noción de Unidades desplegadas por separado. Como se ilustra en Figura 4-1 ,
cada componente de la arquitectura de microservicios se implementa como una unidad separada,
lo que permite una implementación más sencilla a través de un canal de entrega eficaz y
optimizado, una mayor escalabilidad y un alto grado de desacoplamiento de aplicaciones y
componentes dentro de su aplicación.

Quizás el concepto más importante de entender con este patrón es la noción de componente
de servicio. En lugar de pensar en servicios dentro de una arquitectura de microservicios,
es mejor pensar en componentes de servicio, que pueden variar en granularidad desde un
solo módulo hasta una gran parte de la aplicación. Los componentes del servicio contienen
uno o más módulos (por ejemplo, clases de Java) que representan

27
una función de propósito único (p. ej., proporcionar el clima para una ciudad o pueblo específico)
o una parte independiente de una aplicación comercial grande (p. ej., colocación de acciones o
determinación de tarifas de seguros de automóviles). Diseñar el nivel correcto de granularidad de
los componentes del servicio es uno de los mayores desafíos dentro de una arquitectura de
microservicios. Este desafío se analiza con más detalle en la siguiente subsección de
orquestación de componentes de servicio.

Figura 4-1. Patrón de arquitectura básica de microservicios

Otro concepto clave dentro del patrón de arquitectura de microservicios es que es un repartido arquitectura,
lo que significa que todos los componentes dentro de la arquitectura están completamente
desacoplados entre sí y se accede a ellos a través de algún tipo de protocolo de acceso
remoto (por ejemplo, JMS, AMQP, REST, SOAP, RMI, etc.). La naturaleza distribuida de este
patrón de arquitectura es cómo logra algunas de sus características superiores de
escalabilidad y despliegue.

Una de las cosas interesantes de la arquitectura de microservicios es que evolucionó a partir de

problemas asociados con otros patrones de arquitectura comunes, en lugar de crearse como
una solución a la espera de que ocurra un problema. El estilo de la arquitectura de
microservicios evolucionó naturalmente a partir de dos fuentes principales: aplicaciones
monolíticas desarrolladas utilizando el patrón de arquitectura en capas y aplicaciones
distribuidas desarrolladas a través del patrón de arquitectura orientada a servicios.

El camino evolutivo de las aplicaciones monolíticas a un estilo de arquitectura de

microservicios fue impulsado principalmente por el desarrollo de la entrega
continua, la noción de un

28 | Capítulo 4: Patrón de arquitectura de microservicios

canalización de implementación desde el desarrollo hasta la producción que agiliza la
implementación de aplicaciones. Las aplicaciones monolíticas suelen constar de componentes
estrechamente acoplados que forman parte de una única unidad desplegable, lo que hace que
sea engorroso y difícil cambiar, probar e implementar la aplicación (de ahí el aumento de los
ciclos comunes de "implementación mensual" que se encuentran típicamente en la mayoría de los
grandes TI tiendas). Estos factores comúnmente conducen a aplicaciones frágiles que se rompen
cada vez que se implementa algo nuevo. El patrón de arquitectura de microservicios aborda estos
problemas al separar la aplicación en múltiples unidades desplegables (componentes de servicio)
que se pueden desarrollar, probar y desplegar individualmente independientemente de otros
componentes de servicio.

El otro camino evolutivo que conduce al patrón de arquitectura de microservicios proviene de

los problemas encontrados con las aplicaciones que implementan el patrón de arquitectura
orientada a servicios (SOA). Si bien el patrón SOA es muy poderoso y ofrece niveles
incomparables de abstracción, conectividad heterogénea, orquestación de servicios y la
promesa de alinear los objetivos comerciales con las capacidades de TI, es sin embargo
complejo, costoso, ubicuo, difícil de entender e implementar. y suele ser excesivo para la
mayoría de las aplicaciones. El estilo de la arquitectura de microservicios aborda esta
complejidad simplificando la noción de servicio, eliminando las necesidades de orquestación
y simplificando la conectividad y el acceso a los componentes del servicio.

Topologías de patrones
Si bien hay literalmente docenas de formas de implementar un patrón de arquitectura de
microservicios, tres topologías principales se destacan como las más comunes y populares: la Basado
en API REST topología, aplicación basada en REST topología, y la mensajería centralizada topología.

los Basado en API REST La topología es útil para sitios web que exponen servicios
individuales pequeños e independientes a través de algún tipo de API (interfaz de
programación de aplicaciones). Esta topología, que se ilustra en Figura 4-2 , consta de
componentes de servicio muy detallados (de ahí el nombre microservicios) que contienen
uno o dos módulos que realizan funciones comerciales específicas independientes del
resto de servicios. En esta topología, normalmente se accede a estos componentes de
servicio detallados mediante una interfaz basada en REST implementada a través de una
capa de API basada en web implementada por separado. Ejemplos de esta topología
incluyen algunos de los

Topologías de patrones | 29
servicios web RESTful basados en la nube de propósito encontrados por Yahoo, Google y Amazon.

Figura 4-2. Topología basada en API REST

La topología basada en REST de la aplicación difiere del enfoque basado en API REST en que
las solicitudes de los clientes se reciben a través de pantallas de aplicaciones comerciales
tradicionales basadas en web o de clientes pesados en lugar de a través de una simple capa de
API. Como se ilustra en Figura 4-3 , la capa de interfaz de usuario de la aplicación se implementa
como una aplicación web separada que accede de forma remota a componentes de servicio
implementados por separado (funcionalidad empresarial) a través de interfaces simples basadas
en REST. Los componentes de servicio en esta topología difieren de los de la topología basada
en API-REST en que estos componentes de servicio tienden a ser más grandes, más detallados y
representan una pequeña porción de la aplicación empresarial general en lugar de una sola
servicios de acción. Esta topología es común para aplicaciones de empresas pequeñas y
medianas que tienen un grado de complejidad relativamente bajo.

30 | Capítulo 4: Patrón de arquitectura de microservicios

Figura 4-3. Topología basada en REST de aplicaciones

Otro enfoque común dentro del patrón de arquitectura de microservicios es la topología de

mensajería centralizada. Esta topología (ilustrada en Figura 4-4 ) es similar a la topología
basada en REST de la aplicación anterior, excepto que en lugar de utilizar REST para el
acceso remoto, esta topología utiliza un intermediario de mensajes centralizado ligero (por
ejemplo, ActiveMQ, HornetQ, etc.). Al observar esta topología, es de vital importancia no
confundirla con el patrón de arquitectura orientada a servicios o considerarla "SOA-Lite". El
intermediario de mensajes ligero que se encuentra en esta topología no realiza ninguna
orquestación, transformación ni enrutamiento complejo. ; más bien, es solo un transporte
ligero para acceder a componentes de servicio remoto.

La topología de mensajería centralizada se encuentra típicamente en aplicaciones de negocios más

grandes o en aplicaciones que requieren un control más sofisticado sobre la capa de transporte entre
la interfaz de usuario y los componentes del servicio. Los beneficios de esta topología sobre la
topología simple basada en REST discutida anteriormente son mecanismos avanzados de puesta en
cola, mensajería asincrónica, monitoreo, manejo de errores y mejor balanceo y escalabilidad de carga
general. El punto único de falla y los problemas de cuello de botella de la arquitectura que
generalmente se asocian con un intermediario centralizado se abordan mediante la agrupación en
clústeres de intermediarios y la federación de intermediarios (dividiendo una única instancia de
intermediario en varias instancias de intermediario para dividir la carga de procesamiento de
mensajes según las áreas funcionales del sistema).

Topologías de patrones | 31
Figura 4-4. Topología de mensajería centralizada

Evite las dependencias y la orquestación

Uno de los principales desafíos del patrón de arquitectura de microservicios es determinar el nivel
correcto de granularidad para los componentes del servicio. Si los componentes del servicio son
demasiado generales, es posible que no se dé cuenta de los beneficios que conlleva este patrón de
arquitectura (implementación, escalabilidad, capacidad de prueba y acoplamiento flexible). Sin
embargo, los componentes de servicio que son demasiado finos conducirán a requisitos de
orquestación de servicios, que convertirán rápidamente su arquitectura de microservicios ajustada
en una arquitectura orientada a servicios de peso pesado, completa con toda la complejidad,
confusión, gastos y tonterías típicas encontrado con aplicaciones basadas en SOA.

Si descubre que necesita orquestar sus componentes de servicio desde la interfaz de usuario
o la capa de API de la aplicación, es posible que sus componentes de servicio sean
demasiado precisos. De manera similar, si encuentra que necesita realizar una comunicación
entre servicios entre componentes de servicio para procesar una sola solicitud, es probable
que sus componentes de servicio sean demasiado detallados o no estén divididos
correctamente desde el punto de vista de la funcionalidad empresarial.

La comunicación entre servicios, que podría forzar acoplamientos no deseados entre

componentes, se puede manejar en su lugar a través de un

32 | Capítulo 4: Patrón de arquitectura de microservicios

base de datos compartida. Por ejemplo, si un componente de servicio que entrega pedidos por
Internet necesita información del cliente, puede ir a la base de datos para recuperar los datos
necesarios en lugar de invocar la funcionalidad dentro del componente de servicio al cliente.

La base de datos compartida puede manejar las necesidades de información, pero ¿qué pasa con
la funcionalidad compartida? Si un componente de servicio necesita una funcionalidad contenida
en otro componente de servicio o común a todos los componentes de servicio, a veces puede
copiar la funcionalidad compartida entre los componentes de servicio (violando así el principio
DRY: no lo repita). Esta es una práctica bastante común en la mayoría de las aplicaciones
empresariales que implementan el patrón de arquitectura de microservicios, y se compensa la
redundancia de repetir pequeñas porciones de la lógica empresarial con el fin de mantener
independientes los componentes del servicio y separar su implementación. Las pequeñas clases
de servicios públicos pueden caer en esta categoría de código repetido.

Si descubre que, independientemente del nivel de granularidad de los componentes del

servicio, aún no puede evitar la orquestación de los componentes del servicio, es una
buena señal de que este podría no ser el patrón de arquitectura adecuado para su
aplicación. Debido a la naturaleza distribuida de este patrón, es muy difícil mantener una
sola unidad transaccional de trabajo entre (y entre) los componentes del servicio. Tal
práctica requeriría algún tipo de marco de compensación de transacciones para revertir
transacciones, lo que agrega una complejidad significativa a este patrón de arquitectura
relativamente simple y elegante.

Consideraciones
El patrón de arquitectura de microservicios resuelve muchos de los problemas comunes que se

encuentran tanto en aplicaciones monolíticas como en arquitecturas orientadas a servicios. Dado que

los principales componentes de las aplicaciones se dividen en unidades más pequeñas que se

implementan por separado, las aplicaciones creadas utilizando el patrón de arquitectura de

microservicios son generalmente más robustas, brindan una mejor escalabilidad y pueden admitir más

fácilmente la entrega continua.

Otra ventaja de este patrón es que proporciona la capacidad de realizar implementaciones de

producción en tiempo real, lo que reduce significativamente la necesidad de las implementaciones
de producción tradicionales mensuales o de fin de semana "big bang". Dado que el cambio
generalmente se aísla a componentes de servicio específicos, solo es necesario implementar los
componentes de servicio que cambian. Si solo tiene una instancia de un servicio com‐

Consideraciones | 33
componente, puede escribir código especializado en la aplicación de interfaz de usuario para detectar
una implementación en caliente activa y redirigir a los usuarios a una página de error o página de
espera. Alternativamente, puede intercambiar múltiples instancias de un componente de servicio
dentro y fuera durante una implementación en tiempo real, lo que permite una disponibilidad continua
durante los ciclos de implementación (algo que es muy difícil de hacer con el patrón de arquitectura en
capas).

Una última consideración a tener en cuenta es que, dado que el patrón de arquitectura de
microservicios es una arquitectura distribuida, comparte algunos de los mismos problemas
complejos que se encuentran en el patrón de arquitectura impulsada por eventos, incluida la
creación de contratos, el mantenimiento y el gobierno. , disponibilidad del sistema remoto y
autenticación y autorización de acceso remoto.

Análisis de patrones
La siguiente tabla contiene una calificación y análisis de las características de la
arquitectura común para el patrón de arquitectura de microservicios. La calificación de
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 por lo que el patrón
es generalmente conocido. Para obtener una comparación en paralelo de cómo se
relaciona este patrón con otros patrones de este informe, consulte Apéndice A al final de
este informe.

Agilidad general
Clasificación: Alto

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

constante cambio. Debido a la noción de unidades desplegadas por separado, el cambio
generalmente se aísla a los componentes de servicio individuales, lo que permite una
implementación rápida y sencilla. Además, las aplicaciones creadas con este patrón tienden
a estar muy poco acopladas, lo que también ayuda a facilitar el cambio.

Facilidad de implementación

Clasificación: Alto

Análisis: En general, este patrón es relativamente fácil de implementar debido a la naturaleza

desacoplada de los componentes del procesador de eventos. La topología del intermediario tiende

a ser más fácil de implementar que la topología del mediador, principalmente porque el

componente del mediador de eventos está estrechamente acoplado a los procesadores de eventos:

un cambio en un componente del procesador de eventos también puede requerir un cambio en

34 | Capítulo 4: Patrón de arquitectura de microservicios

 el mediador de eventos, requiriendo que ambos se implementen para cualquier cambio dado.

Probabilidad

Clasificación: Alto

Análisis: Debido a la separación y el aislamiento de la funcionalidad empresarial en

aplicaciones independientes, las pruebas pueden tener un alcance, lo que permite
esfuerzos de prueba más específicos. La prueba de regresión para un componente de
servicio en particular es mucho más fácil y más factible que la prueba de regresión para una
aplicación monolítica completa. Además, dado que los componentes de servicio en este
patrón están débilmente acoplados, hay muchas menos posibilidades desde una
perspectiva de desarrollo de realizar un cambio que rompa otra parte de la aplicación,
aliviando la carga de prueba de tener que probar toda la aplicación para un pequeño
cambio.

Actuación
Clasificación: Bajo

Análisis: Si bien puede crear aplicaciones implementadas a partir de este patrón que
funcionan muy bien, en general, este patrón no se presta naturalmente a aplicaciones
de alto rendimiento debido a la naturaleza distribuida del patrón de arquitectura de
microservicios.

Escalabilidad

Clasificación: Alto

Análisis: Debido a que la aplicación se divide en unidades implementadas por separado, cada
componente de servicio se puede escalar individualmente, lo que permite un escalado preciso de la

aplicación. Por ejemplo, es posible que el área de administración de una aplicación de comercio de

acciones no necesite escalar debido a los bajos volúmenes de usuarios para esa funcionalidad,

pero el componente de servicio de colocación de comercio puede necesitar escalar debido al alto

rendimiento que necesitan la mayoría de las aplicaciones de comercio para esto. funcionalidad.

Facilidad de desarrollo
Clasificación: Alto

Análisis: Debido a que la funcionalidad está aislada en componentes de servicio

separados y distintos, el desarrollo se vuelve más fácil debido al alcance más pequeño
y aislado. Hay muchas menos posibilidades de que un desarrollador haga un cambio en
un componente del servicio que afecte a otros componentes del servicio, reduciendo
así la coordinación necesaria entre desarrolladores o equipos de desarrollo.

Análisis de patrones | 35
 CAPÍTULO 5

Arquitectura basada en el espacio

La mayoría de las aplicaciones comerciales basadas en web siguen el mismo flujo de solicitudes

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. Si bien este patrón funciona muy bien para un grupo pequeño

de usuarios, comienzan a aparecer cuellos de botella a medida que aumenta la carga de usuarios,

primero en la capa del servidor web, luego en la capa del servidor de aplicaciones y finalmente en la

capa del servidor de base de datos. La respuesta habitual a los cuellos de botella basados en un

aumento en la carga de usuarios es escalar los servidores web. Esto es relativamente fácil y económico

y, a veces, funciona para solucionar los problemas de cuello de botella. Sin embargo, en la mayoría de

los casos de alta carga de usuarios, la ampliación de la capa del servidor web solo mueve el cuello de

botella al servidor de aplicaciones. El escalado de los servidores de aplicaciones puede ser más

complejo y costoso que los servidores web y, por lo general, solo mueve el cuello de botella al servidor

de la base de datos, que es aún más difícil y costoso de escalar. Incluso si puede escalar la base de

datos, lo que finalmente obtendrá es una topología en forma de triángulo, con la parte más ancha del

triángulo siendo los servidores web (más fácil de escalar) y la parte más pequeña es la base de datos

(más difícil de escalar).

En cualquier aplicación de gran volumen con una carga de usuarios concurrentes extremadamente

grande, la base de datos generalmente será el factor limitante final en la cantidad de transacciones que

puede procesar simultáneamente. Si bien varias tecnologías de almacenamiento en caché y productos

de escalado de bases de datos ayudan a abordar estos problemas, el hecho es que escalar una

aplicación normal para cargas extremas es una propuesta muy difícil.

37
El patrón de arquitectura basada en el espacio está diseñado específicamente 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.
Resolviendo el problema de escalabilidad extrema y variable arquitectónicamente Suele ser un
método mejor que intentar escalar una base de datos o adaptar tecnologías de almacenamiento en
caché a una arquitectura no escalable.

Descripción del patrón

El patrón basado en el espacio (también denominado a veces patrón de arquitectura en la nube)
minimiza los factores que limitan el escalado de la aplicación. Este patrón recibe su nombre del
concepto de espacio de tupla, la idea de memoria compartida distribuida. La alta escalabilidad se
logra eliminando la restricción de la base de datos central 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 apagarse dinámicamente a medida que la carga de usuarios aumenta y disminuye, abordando así
la escalabilidad variable. Debido a que 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.

La mayoría de las aplicaciones que se ajustan a este patrón son sitios web estándar que reciben una
solicitud de un navegador y realizan algún tipo de acción. Un sitio de subastas de ofertas es un buen
ejemplo de esto. El sitio recibe continuamente ofertas de los usuarios de Internet a través de una
solicitud del navegador. La aplicación recibiría una oferta por un artículo en particular, registraría esa
oferta con una marca de tiempo y actualizaría la información de la oferta más reciente para el artículo,
y enviaría la información al navegador.

Hay dos componentes principales dentro de este patrón de arquitectura: un unidad de

procesamiento y middleware virtualizado. Figura 5-1 ilustra el patrón de arquitectura básica
basada en el espacio y sus componentes de arquitectura primarios.

El componente de la unidad de procesamiento contiene los componentes de la aplicación (o partes

de los componentes de la aplicación). Esto incluye componentes basados en web, así como
lógica empresarial de backend. El contenido de la unidad de procesamiento varía según el tipo de
aplicación; es probable que las aplicaciones web más pequeñas se implementen en una sola
unidad de procesamiento, mientras que las aplicaciones más grandes pueden dividir la
funcionalidad de la aplicación en múltiples unidades de procesamiento según la áreas funcionales
de la aplicación. La unidad de procesamiento normalmente

38 | Capítulo 5: Arquitectura basada en el espacio

contiene los módulos de la aplicación, junto con una cuadrícula de datos en memoria y un almacén

persistente asíncrono opcional para la conmutación por error. También contiene un motor de replicación

que utiliza el software intermedio virtualizado para replicar los cambios de datos realizados por una

unidad de procesamiento a otras unidades de procesamiento activas.

Figura 5-1. Patrón de arquitectura basada en el espacio

El componente de middleware virtualizado se encarga de la limpieza y las comunicaciones.

Contiene componentes que controlan varios aspectos de la sincronización de datos y el manejo
de solicitudes. En el middleware virtualizado se incluyen la cuadrícula de mensajería, la
cuadrícula de datos, la cuadrícula de procesamiento y el administrador de implementación. Estos
componentes, que se describen en detalle en la siguiente sección, se pueden personalizar o
comprar como productos de terceros.

Dinámica de patrones
La magia del patrón de arquitectura basada en el espacio radica en los componentes de middleware

virtualizados y la cuadrícula de datos en memoria contenida dentro de cada unidad de procesamiento. Figura

5-2 muestra la arquitectura típica de la unidad de procesamiento que contiene los módulos de la aplicación,

la cuadrícula de datos en memoria, el almacenamiento de persistencia asíncrono opcional para la

conmutación por error y el motor de replicación de datos.

El middleware virtualizado es esencialmente el controlador de la arquitectura y administra las

solicitudes, las sesiones, la replicación de datos, el procesamiento de solicitudes distribuidas y la
implementación de la unidad de proceso. Hay cuatro componentes de arquitectura principales en
el middleware virtualizado:

Dinámica de patrones | 39
la cuadrícula de mensajería, la cuadrícula de datos, la cuadrícula de procesamiento y el administrador de

implementación.

Figura 5-2. Componente de unidad de procesamiento

Cuadrícula de mensajería

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

información de la sesión. Cuando llega una solicitud al componente de middleware virtualizado, el
componente de cuadrícula de mensajería determina qué componentes de procesamiento activo 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 de operación por
turnos hasta un algoritmo más complejo de próxima disponibilidad que realiza un seguimiento de qué
solicitud está siendo procesada por qué unidad de procesamiento.

Cuadrícula de datos

El componente de cuadrícula de datos es quizás el componente más importante y crucial de 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 ocurren

actualizaciones de datos. Dado que la cuadrícula de mensajes 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. A pesar de que Figura 5-4 muestra una

replicación de datos sincrónica entre unidades de procesamiento, en realidad esto se hace en paralelo de

forma asincrónica y muy rápidamente, a veces completando la sincronización de datos en cuestión de

microsegundos (una millonésima de segundo).

40 | Capítulo 5: Arquitectura basada en el espacio

Figura 5-3. Componente Messaging-grid

Figura 5-4. Componente de cuadrícula de datos

Rejilla de procesamiento

La rejilla de procesamiento, ilustrada en Figura 5-5 , es un componente opcional dentro del

middleware virtualizado que gestiona el procesamiento de solicitudes distribuidas cuando hay varias
unidades de procesamiento, cada una de las cuales maneja una parte de la aplicación. Si llega 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 el

Dinámica de patrones | 41
cuadrícula que media y orquesta la solicitud entre esas dos unidades de procesamiento.

Figura 5-5. Componente de rejilla de procesamiento

Gerente de implementación

El componente del gestor de despliegue gestiona el inicio 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 aumenta la carga y apaga las unidades de procesamiento cuando la carga disminuye. Es un

componente crítico para lograr necesidades de escalabilidad variable dentro de una aplicación.

Consideraciones
El patrón de arquitectura basada en el espacio es un patrón complejo y costoso de implementar.
Es una buena opción de arquitectura para aplicaciones web más pequeñas con carga variable
(por ejemplo, sitios de redes sociales, sitios de licitación y subastas). Sin embargo, no es
adecuado para aplicaciones tradicionales de bases de datos relacionales a gran escala con
grandes cantidades de datos operativos.

Aunque el patrón de arquitectura basada en el espacio no requiere un almacén de datos centralizado,

comúnmente se incluye uno para realizar la carga inicial de la cuadrícula de datos en memoria y las

actualizaciones de datos persistentes de forma asíncrona realizadas por las unidades de

procesamiento. También es una práctica común crear particiones separadas que aíslen volátiles y

ampliamente utilizados

42 | Capítulo 5: Arquitectura basada en el espacio

datos transaccionales de datos no activos, con el fin de reducir la huella de memoria de la
cuadrícula de datos en memoria dentro de cada unidad de procesamiento.

Es importante señalar que, si bien el nombre alternativo de este patrón es arquitectura basada
en la nube, las unidades de procesamiento (así como el middleware virtualizado) no tienen que
residir en servicios alojados en la nube o PaaS (plataforma como Servicio). Puede residir
fácilmente en servidores locales, que es una de las razones por las que prefiero el nombre
"arquitectura basada en el espacio".

Desde la perspectiva de la implementación del producto, puede implementar muchos de los

componentes de la arquitectura en este patrón a través de productos de terceros como
GemFire, JavaSpaces, GigaSpaces, IBM Object Grid, nCache y Oracle Coherence. Debido a
que la implementación de este patrón varía mucho en términos de costo y capacidades
(particularmente tiempos de replicación de datos), como arquitecto, primero debe establecer
cuáles son sus objetivos y necesidades específicos antes de hacer cualquier selección de
producto.

Análisis de patrones
La siguiente tabla contiene una clasificación y un análisis de las características de la
arquitectura común para el patrón de arquitectura basada en el espacio. La calificación de
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 lo que
generalmente se conoce al patrón. Para obtener una comparación en paralelo de cómo se
relaciona este patrón con otros patrones de este informe, consulte Apéndice A al final de este
informe.

Agilidad general
Clasificación: Alto

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

constante cambio. Debido a que las unidades de procesamiento (instancias implementadas de
la aplicación) se pueden activar y desactivar rápidamente, las aplicaciones responden bien a los
cambios relacionados con un aumento o disminución en la carga de usuarios (cambios de
entorno). Las arquitecturas creadas con 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.

Análisis de patrones | 43
Facilidad de implementación

Clasificación: Alto

Análisis: Aunque las arquitecturas basadas en el espacio generalmente no están desacopladas ni

distribuidas, son herramientas dinámicas y sofisticadas basadas en la nube que permiten que las

aplicaciones se “envíen” fácilmente a los servidores, lo que simplifica la implementación.

Probabilidad

Clasificación: Bajo

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

requiere mucho tiempo, lo que dificulta probar los aspectos de escalabilidad de la
aplicación.

Actuación
Clasificación: Alto

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

Clasificación: Alto

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

Facilidad de desarrollo
Clasificación: Bajo

Análisis: El almacenamiento en caché sofisticado y los productos de 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.

44 | Capítulo 0: Arquitectura basada en el espacio

 APÉNDICE A

Resumen de análisis de patrones

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 observar 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 el gráfico para ver que la implementación, el rendimiento y la
escalabilidad pueden ser áreas de riesgo en su arquitectura.

45
Figura A-1. Resumen de análisis de patrones

Si bien este cuadro le 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 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 fundamental, porque una vez que una arquitectura está en
su lugar, es muy difícil (y costoso) cambiarla.

46 | Apéndice A: Resumen del análisis de patrones

Sobre el Autor
Mark Richards es un arquitecto de software con experiencia y práctica involucrado en
la arquitectura, el diseño y la implementación de arquitecturas de microservicios,
arquitecturas orientadas a servicios y sistemas distribuidos en J2EE y otras
tecnologías. Ha estado en la industria del software desde 1983 y tiene una gran
experiencia y conocimientos en aplicaciones, integración y arquitectura empresarial.
Mark se desempeñó como presidente del Grupo de usuarios de Java de Nueva
Inglaterra desde 1999 hasta 2003. Es autor de numerosos libros y videos técnicos,
incluidos Fundamentos de la arquitectura de software ( O'Reilly video), Mensajería
empresarial ( O'Reilly video), Java

Servicio de mensajes, segunda edición ( O'Reilly) y autor colaborador de 97 cosas que

todo arquitecto de software debe saber ( O'Reilly). Mark tiene una maestría en
informática y numerosas certificaciones de arquitecto y desarrollador de IBM, Sun, The
Open Group y BEA. Es un orador habitual de conferencias en la serie de simposios No
Fluff Just Stuff (NFJS) y ha hablado en más de 100 conferencias y grupos de usuarios
en todo el mundo sobre una variedad de temas técnicos relacionados con la empresa.
Cuando no está trabajando, generalmente se puede encontrar a Mark caminando en
las Montañas Blancas o en el sendero de los Apalaches.