Este repositorio tiene como fin documentar la arquitectura de Toures Balón para la materia de Proyecto de Implementación de la Arquitectura PUJ, en el presente documento encontrarála definición de la arquitectura propuesta por el equipo J4K de la Especialización Arquitectura Empresarial de Software.
Integrantes:
- Kattya Alexandra Peña Nieto
- Johann Fernando Trigos Niño
- Javier Alfonso Becerra Sanchez
- José Esteban Betin Diaz
- Johan Miguel Céspedes Ortega
- Estilo de arquitectura.
- Patrones y herramientas.
- Arquitectura
- Justificación de arquitectura.
- Artefactos.
- Referencias.
La arquitectura orientada a microservicios es un estilo arquitectónico que nos permite definir un conjunto de servicios de colaboración debilmente acoplados, esto favorece la rápida implementación de nuevos componentes, de manera rapida y sencilla, es posible distribuir resoponsabilidades entre servicios de aplicación lo cual reduce el acoplamiento y aumenta la cohesión, siendo esto un factor importante de la solución, los microservicios permitiran llevar a cabo una facil integración entre componentes independiente de la tecnologia que implementen, asi mismo puede llevarse a cabo desarrollo de manera incremental, rapida y continua de cada funcionalidad, los costes de mantenimiento y su impacto para el negocio serán menores, aunque su implementación demande mayor inversión al inicio, a futuro se podrá ver un amplio ahora respecto del mantenimiento y escalamiento
Es importante resaltar que la arquitectura propuesta por el equipo J4K presenta una solucion optima a los problemas tecnologicos y perdida de utilidades que viene presentado Toures Balón durante los últimos eventos, por tanto el estilo presetado a continuación evolucionara de manera natural, su gestión será más sencilla, utilizando los recursos disponibles con una minima invesión bajo el empleo de algunas herramientas descritas en adelante
PATRÓN NUCLEAR:
MICROSERVICIOS: Como se definió anteriormente, este patrón permitirá que todo el desarrollo se rija frente a la formación del proceso a través de la composición de los servicios propuestos de este comunicandose de diferentes maneras, dandole valor al negocio.
| Patrón | Descripción | Representación |
|---|---|---|
| Api-Gateway | Dado a la definición del primer patrón, es necesario una puerta de enlace hacia las interfaces de consumo, para acceder a este servicio. Para su aplicación se puede hacer uso de herramientas que cuentan frameworks tales como Spring Cloud Gateway, AWS Api Gateway, entre otros. |  |
| Broker | Es un patrón de arquitectura que se utiliza en sistemas de software distribuidos con servicios desacoplados que interactúan por invocaciones de servicios remotos. Será el responsable de coordinar la comunicación, tanto de enviar/reenviar las peticiones, así como de transmitir los resultados y las excepciones. |  |
| Server Side Discovery | Realiza solicitudes a través de un enrutador que se ejecuta en una ubicación conocida. El enrutador consulta un registro de servicios , que podría estar integrado en el enrutador, y reenvía la solicitud a una instancia de servicio disponible. |  |
| Circuit Breaker | Favorece el control de fallas cuando el número de fallas consecutivas cruza un umbral, el Circuit Braker se dispara y durante un período de tiempo de espera, todos los intentos de invocar el servicio remoto fallarán inmediatamente. Una vez que expira el tiempo de espera, el Circuit Braker permite el paso de un número limitado de solicitudes de prueba. Si esas solicitudes tienen éxito, el Circuit Braker reanuda el funcionamiento normal. De lo contrario, si hay una falla, el período de tiempo de espera comienza de nuevo. |  |
| Client-side service discovery | Al realizar una solicitud a un servicio, el cliente obtiene la ubicación de una instancia de servicio consultando un Registro de servicios , que conoce las ubicaciones de todas las instancias de servicio. |  |
| Anticorruption Layer | Capa de fachada o adaptador entre los diferentes subsistemas que no comparten la misma semántica. Esta capa traduce las solicitudes que un subsistema hace al otro subsistema. Use este patrón para asegurarse de que el diseño de la aplicación no se vea limitado por dependencias de subsistemas externos. |  |
| Publicador - Suscriptor | Por el uso de coreografía en el desarrollo del proyecto, es necesario pensar que el banco actuará como Publicador (Envío de transacciones) y Suscriptor (Recepción de las respuestas), por ello la importancia del uso de este patrón ya que permite el procesamiento de transacciones. Para su aplicación se puede hacer uso de herramientas como apache camel y kafka. |  |
Para la implementación de Arquitectura se implementarán las siguientes herramientas.
| Herramienta | Descripción |
|---|---|
| OpenAPI | Para el desarrollo de los contratos, este ofrece una herramienta de código abierto para su diseño. |
| Spring Boot | Spring Framework proporciona soporte fundamental para diferentes arquitecturas de aplicaciones, incluida la mensajería, los datos transaccionales y la persistencia, y la web. También incluye el marco web Spring MVC basado en Servlet y, en paralelo, el marco web reactivo Spring WebFlux. |
| Kafka | Debido a que su orientación mediante patrón de Publicador Suscriptor es una gran herramienta para actuar como coreógrafo del proceso. |
| Zuul | Con el fin de modelar el api-gateway, este ofrece grandes herramientas para ser la puerta de enlace para las interfaces. |
| Spring Cloud | Debido a que se debe interactuar entre varios componentes este framework ofrece funcionalidades para ambientes distribuidos como clientes de consumo sencillos hacia otros servicios. |
| Eureka | Para conocer los servicios de los proveedores, este actúa como el encargado de registrar los microservicios / servicios que compone el proceso. |
A continuación, se presenta en la figura 1 la vista de proceso ilustrada por un diagrama de Archi en la cual se presenta el flujo del proceso para proveedores de Toures Balón.
Figura 1: Cotización de plan turístico
Figura 2: Compra de plan turístico
Figura 3: Cancelación de plan turístico
Figura 4: Proveedores
La vista estructural se presenta por medio del diagrama de componentes. En este diagrama podemos describir algunos de los principales patrones y decisiones arquitectónicas que se tomaron, decisiones que explicaremos en la siguiente sección.
Figura 4: Diagrama de componentes
La arquitectura candidata pretende aportar a Toures Balón independencia en la gestión, reducir el acoplamiento en las operaciones que realiza su sistema, y tolerancia a fallos entre otros, por ello presentamos proveedores que se comunican a través de la capa anticorrupción por un adaptador cuya tarea con las interfaces de proveedor, será la de traducir los datos que provienen de terceros reduciendo la posibilidad de fallos por el empleo de diferentes tecnologias, de esta forma ser enviados por intermedio del servicio hacia el sistema de colas permanentes, esta lleva a cabo la composición de servicios para registrar proveedores, consultar reservas, realizar búsquedas y completar transacciones de pago y demás acciones requeridas por el negocio.
Estas últimas operaciones seran procesadas de cara al proveedor con ayuda de la capa Aticorrupcion quien con la implementación del adaptador de servicio registra los pagos en los proveedores. Es importante aclarar que se ha implementado un registro de servicios donde puedan persistir los end points de proveedores con los cuales el sistema se comunicará, asi mismo se cuenta con un api gateway como enlace hacia el interior de Toures Balón.
Se lleva a cabo la evaluación de atributos de calidad respecto de los requerimientos de Toures Balón, el equipo de evaluación y los stakeholders identifican y priorizan los atributos de calidad (Trade Off) de tal forma que puedan cumplirse con los objetivos de negocio con la calidad esperada
Figura 5: Interoperabilidad
Figura 6: Adaptabilidad
Figura 7: Modificabilidad
Figura 8: Mantenibilidad
Figura 9: Eficiencia de Rendimiento