ViucheMadroñeroJairo2019

Vista previa del material en texto

1
ANÁLISIS DEL RENDIMIENTO DE LA TRANSACCIONALIDAD EN UN
API GATEWAY DESARROLLADO CON EL PARADIGMA ORIENTADO A
OBJETOS FRENTE AL PARADIGMA REACTIVO
Autor
Jairo Edinson Viuche Madroñero
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenieŕıa
Especialización en Ingenieŕıa de Software
Bogotá, Colombia
Año 2019
2
ANÁLISIS DEL RENDIMIENTO DE LA TRANSACCIONALIDAD EN UN
API GATEWAY DESARROLLADO CON EL PARADIGMA ORIENTADO A
OBJETOS FRENTE AL PARADIGMA REACTIVO
Autor
Jairo Edinson Viuche Madroñero
Monograf́ıa de grado
Presentada como requisito para optar al t́ıtulo de
Especialista en Ingenieŕıa de Software
Director
Dr. Roberto Ferro Escobar
Revisor
Msc. John Freddy Parra
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenieŕıa
Especialización en Ingenieŕıa de Software
Bogotá, Colombia
Año 2019
Índice de figuras
1-1. Arquitectura microservicios con Api Gateway . . . . . . . . . . . . . . . . . 7
1-2. Ejemplo de composición de Api para un Api Gateway . . . . . . . . . . . . . 9
1-3. Arquitectura Api Gateway con múltiples clientes . . . . . . . . . . . . . . . . 10
1-4. Clasificación taxonómica de los vertebrados . . . . . . . . . . . . . . . . . . . 12
1-5. Caracteŕısticas de un sistema reactivo, y como se relacionan entre śı . . . . . 14
1-6. Relación en una implementación del flujo reactivo . . . . . . . . . . . . . . . 15
1-7. El zoo de los paradigmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1-8. Arquitectura en Api de Netflix . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2-1. Funciones del Api Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3-1. Diagrama de clases Api Gateway con paradigma orientado a objetos . . . . . 25
3-2. Diagrama de secuencia Api Gateway con paradigma orientado a objetos . . . 26
3-3. Diagrama de componentes Api Gateway con paradigma orientado a objetos . 26
3-4. Diagrama de flujo de datos f́ısico . . . . . . . . . . . . . . . . . . . . . . . . 27
3-5. Diagrama de secuencia Api Gateway con paradigma reactivo . . . . . . . . . 27
3-6. Concurrencia api reactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4-1. Plataforma Jhipster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4-2. Ejemplo modelo de entidades microservicio en JDL Studio . . . . . . . . . . 30
4-3. Ejemplo lenguaje JDL en modelo de entidades para microservicio . . . . . . 31
4-4. Contenedores docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4-5. Documentación Swagger para microservicio . . . . . . . . . . . . . . . . . . . 32
4-6. Documentación detallada Swagger para microservicio . . . . . . . . . . . . . 33
4-7. Archivo app.js, ejecución principal del Api Gateway . . . . . . . . . . . . . . 34
4-8. Archivo router.js, contenedor de los microservicios que se desean consumir . 35
4-9. Gateway adapter, cada microservicio realiza su uso . . . . . . . . . . . . . . 35
4-10.Configuración de enrutamiento para cada microservicio, por servicio . . . . . 36
4-11.Configuración de archivo pom.xml del servidor eureka . . . . . . . . . . . . . 37
4-12.Configuración general del servidor . . . . . . . . . . . . . . . . . . . . . . . . 37
4-13.Clase principal de Spring boot, servidor eureka . . . . . . . . . . . . . . . . . 38
4-14.Dependencias pom.xml Api Gateway con spring cloud . . . . . . . . . . . . 38
4-15.Otras dependencias pom.xml Api Gateway con spring cloud . . . . . . . . . 39
4-16.Gateway Routing con spring cloud . . . . . . . . . . . . . . . . . . . . . . . 39
4-17.Servicio web, punto de entrada Api Gateway . . . . . . . . . . . . . . . . . . 40
4 ÍNDICE DE FIGURAS
4-18.Acción para la optención de url . . . . . . . . . . . . . . . . . . . . . . . . . 41
4-19.Transformador de url a request . . . . . . . . . . . . . . . . . . . . . . . . . 41
4-20.Consumo de servicio RestFul, microservicio . . . . . . . . . . . . . . . . . . . 41
4-21.Diagrama de despliegue de componentes del análisis . . . . . . . . . . . . . . 42
5-1. Logo Jirka It Solutions SAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5-2. Metamodelo punto de vista de organización . . . . . . . . . . . . . . . . . . 45
5-3. Punto de vista de organización . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5-4. Metamodelo punto de vista cooperación de actor . . . . . . . . . . . . . . . . 45
5-5. Punto de vista cooperación de actor . . . . . . . . . . . . . . . . . . . . . . . 46
5-6. Metamodelo punto de vista de función de negocio . . . . . . . . . . . . . . . 46
5-7. Punto de vista de función de negocio . . . . . . . . . . . . . . . . . . . . . . 47
5-8. Metamodelo punto de vista de proceso de negocio . . . . . . . . . . . . . . . 47
5-9. Punto de vista de proceso de negocio . . . . . . . . . . . . . . . . . . . . . . 48
5-10.Metamodelo punto de vista de cooperación de proceso de negocio . . . . . . 48
5-11.Punto de vista de cooperación de proceso de negocio . . . . . . . . . . . . . 49
5-12.Metamodelo punto vista de producto . . . . . . . . . . . . . . . . . . . . . . 50
5-13.Punto vista de producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5-14.Metamodelo punto de vista de comportamiento de aplicación . . . . . . . . . 51
5-15.Punto de vista de comportamiento de aplicación . . . . . . . . . . . . . . . . 51
5-16.Metamodelo punto de vista de cooperación de aplicación . . . . . . . . . . . 52
5-17.Punto de vista de cooperación de aplicación . . . . . . . . . . . . . . . . . . 52
5-18.Metamodelo punto de vista de estructura de aplicación . . . . . . . . . . . . 53
5-19.Punto de vista de estructura de aplicación . . . . . . . . . . . . . . . . . . . 53
5-20.Metamodelo punto de vista de uso de aplicación . . . . . . . . . . . . . . . . 54
5-21.Punto de vista de uso de aplicación . . . . . . . . . . . . . . . . . . . . . . . 54
5-22.Metamodelo punto de vista de infraestructura . . . . . . . . . . . . . . . . . 55
5-23.Punto de vista de infraestructura . . . . . . . . . . . . . . . . . . . . . . . . 55
5-24.Metamodelo punto de vista de uso de infraestructura . . . . . . . . . . . . . 56
5-25.Punto de vista de uso de infraestructura . . . . . . . . . . . . . . . . . . . . 56
5-26.Metamodelo punto de vista de organización e implementación . . . . . . . . 57
5-27.Punto de vista de organización e implementación . . . . . . . . . . . . . . . 57
5-28.Metamodelo punto de vista de Estructura de Información . . . . . . . . . . . 58
5-29.Punto de vista de Estructura de Información . . . . . . . . . . . . . . . . . . 58
5-30.Metamodelo punto de vista de Realización del Servicio . . . . . . . . . . . . 59
5-31.Punto de vista de Realización del Servicio . . . . . . . . . . . . . . . . . . . 59
5-32.Punto de vista de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5-33.Metamodelo punto de vista de stakeholder . . . . . . . . . . . . . . . . . . . 61
5-34.Punto de vista de stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5-35.Metamodelo punto de vista de realización de objetivos . . . . . . . . . . . . 62
5-36.Punto de vista de realización de objetivos . . . . . . . . . . . . . . . . . . . . 62
5-37.Metamodelo punto de vista de contribución . . . . . . . . . . . . . . . . . . 63
5-38.Metamodelo punto de vista de contribución . . . . . . . . . . . . . . . . . . 63
5-39.Metamodelo punto de vista de principios . . . . . . . . . . . . . . . . . . . . 64
ÍNDICE DE FIGURAS 5
5-40.Ejemplo punto de vista de principios . . . . . . . . . . . . . . . . . . . . . . 64
5-41.Metamodelo punto de vista de realización de Requerimientos . . . . . . . . . 64
5-42.Ejemplo punto de vista de realización de requerimientos . . . . . . . . . . . . 65
5-43.Metamodelo punto de vista de motivación . . . . . . . . . . . . . . . . . . . 65
5-44.Ejemplo punto de vista de realización de requerimientos . . . . . . . . . . . . 66
5-45.Metamodelo punto de vista de proyecto . . . . . . . . . . . . . . . . . . . . . 665-46.Ejemplo punto de vista de proyecto . . . . . . . . . . . . . . . . . . . . . . . 67
5-47.Metamodelo punto de vista de migración . . . . . . . . . . . . . . . . . . . . 67
5-48.Ejemplo punto de vista de migración . . . . . . . . . . . . . . . . . . . . . . 68
5-49.Metamodelo punto de vista de migración e implementación . . . . . . . . . . 68
5-50.Punto de Vista de Migración e Implementación . . . . . . . . . . . . . . . . 69
6-1. Apache JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6-2. Respuesta de cada Api Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 72
6-3. Promedio tiempos de respuesta para 100 peticiones . . . . . . . . . . . . . . 73
6-4. Tiempos Mı́nimo de respuesta para 100 peticiones . . . . . . . . . . . . . . . 73
6-5. Tiempos Máximo de respuesta para 100 peticiones . . . . . . . . . . . . . . . 74
6-6. Respuesta de cada Api Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 75
6-7. Promedio tiempos de respuesta para 500 peticiones . . . . . . . . . . . . . . 75
6-8. Tiempos Mı́nimo de respuesta para 500 peticiones . . . . . . . . . . . . . . . 76
6-9. Tiempos Máximo de respuesta para 500 peticiones . . . . . . . . . . . . . . . 76
6-10.Respuesta de cada Api Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 77
6-11.Promedio tiempos de respuesta para 1.000 peticiones . . . . . . . . . . . . . 78
6-12.Tiempos Mı́nimo de respuesta para 1.000 peticiones . . . . . . . . . . . . . . 78
6-13.Tiempos Máximo de respuesta para 1.000 peticiones . . . . . . . . . . . . . . 79
6-14.Respuesta de cada Api Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 80
6-15.Promedio tiempos de respuesta para 5.000 peticiones . . . . . . . . . . . . . 81
6-16.Tiempos Mı́nimo de respuesta para 5.000 peticiones . . . . . . . . . . . . . . 81
6-17.Tiempos Máximo de respuesta para 5.000 peticiones . . . . . . . . . . . . . . 82
Índice de cuadros
6-1. Resumen de transaccionalidad para 100 peticiones http . . . . . . . . . . . . 72
6-2. Resumen de transaccionalidad para 500 peticiones http . . . . . . . . . . . . 74
6-3. Resumen de transaccionalidad para 1.000 peticiones http . . . . . . . . . . . 77
6-4. Resumen de transaccionalidad para 5.000 peticiones http . . . . . . . . . . . 80
Contenido
Introducción 2
I Contextualización de la investigación 3
1. Descripción de la investigación 4
1.1. Planteamiento/Identificación del problema . . . . . . . . . . . . . . . . . . . 4
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. Objetivos espećıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Justificación del trabajo/investigación . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Marco referencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1. Marco teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.2. Marco conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6. Metodoloǵıa de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7. Organización del trabajo de grado . . . . . . . . . . . . . . . . . . . . . . . . 18
1.8. Estudio de sistemas previos . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
II Desarrollo de la investigación 22
2. Análisis del sistema 23
2.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3. Diseño de Api Gateway 25
3.1. Paradigma orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Paradigma reactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4. Construcción e Implementación 29
4.1. Microservicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Api Gateway Reactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1. Api Gateway NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.2. Api Gateway Spring Cloud . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3. Api Gateway Orientado a Objetos . . . . . . . . . . . . . . . . . . . . . . . . 40
CONTENIDO 1
4.4. Despliegue final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5. ADM-Archimate 43
5.1. Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2. Punto de vista del negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3. Punto de vista de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4. Punto de vista tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5. Punto de vista motivacional . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.6. Punto de vista implementación y migración . . . . . . . . . . . . . . . . . . 66
III Cierre de la investigación 70
6. Resultados y discusión 71
7. Conclusiones 83
7.1. Verificación, contraste y evaluación de los objetivos . . . . . . . . . . . . . . 83
7.2. Śıntesis del modelo propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.3. Aportes originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8. Prospectiva del trabajo de grado 85
8.1. Ĺıneas de investigación futuras . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2. Trabajos de Investigación futuros . . . . . . . . . . . . . . . . . . . . . . . . 85
Bibliograf́ıa 87
Referencias web 89
2 CONTENIDO
Introducción
Este proyecto tiene como objetivo recabar información y formular una hipótesis acerca de la
transaccionalidad en el componente API Gateway desarrollado con el paradigma orientado
a objetos frente al paradigma reactivo. El componente Api Gateway es un patrón que bus-
ca solucionar la forma que los diferentes clientes tratan de acceder a los microservicios del
Banckend.
Las aplicaciones con arquitectura a microservicios, han optado por incluir este patrón en
su arquitectura y como es el caso de Netflix ha sido conveniente, puesto que ofrecen un API
de servicios para cada tipo de cliente, de esta manera tiene una alta disponibilidad, escala-
bilidad y rendimiento.
En el mundo y Colombia no es la excepción, las aplicaciones en su mayoŕıa usan la pro-
gramación orientada a objetos, brindando buenas soluciones para lo que fueron construidas.
Sin embargo, en los últimos años viene emergiendo el paradigma reactivo, el cual es una
buena alternativa por su manejo de recursos f́ısicos.
Según la literatura sobre arquitectura de software actual, es conveniente que para el desa-
rrollo de aplicación con una alta concurrencia, el paradigma elegido sea el reactivo, porque
que aśı cada flujo tiene un manejo independiente, lo que puede llevar a que haya un servicio
de atención mucho más rápido.
Con el presente análisis lo que se busca es encontrar diferencias entre uno de los para-
digma más usados, puede ser el más usado, y el paradigma que esta emergente y que en la
literatura recomienda, adicional a esto se realizará con diversas libreŕıas de programación
reactiva para dar peso a la conclusión.
Parte I
Contextualización de la investigación
Caṕıtulo 1
Descripción de la investigación
1.1. Planteamiento/Identificación del problema
El patrón Api Gateway ha demostrado ser conveniente para aplicaciones basadas en micro-
servicios. Si no se tiene un Api Gateway, las aplicaciones clientes deben enviar solicitudes
directamente a los microservicios y eso plantea problemas tales como: acoplamiento, dema-
siados viajes de ida y vuelta, temas de seguridad, inconvenientes transversales, entre otros
[2]. Por lo tanto, el api Gateway se encuentra entre: las aplicaciones clientes y los microser-
vicios. Actúa como un proxy inverso, enrutando las solicitudes de los clientes a los servicios.
También puede proporcionar caracteŕısticastransversales adicionales como autenticación,
terminación SSL y cache.
Por otro lado en los últimos años; el paradigma de la programación reactiva ha recibido
una mayor atención, ya que cada vez más aplicaciones se han vuelto impulsadas por eventos
[4, 1]. El paradigma gira en torno a la propagación del cambio para variables que vaŕıan
continuamente en el tiempo. En otras palabras, el paradigma gira en torno al procesamiento
aśıncrono de flujo de datos sin bloqueo. Este paradigma adopta un enfoque declarativo que
permite a los desarrolladores especificar qué hacer, pero está dejando el tiempo de ejecución
al lenguaje [4].
Al mismo tiempo, la programación orientada a objetos es un paradigma que posiblemen-
te sea el más ampliamente utilizados hoy en d́ıa, trata los datos como objetos con atributos
y métodos que pueden aplicarse a estos objetos y también ser heredados por otros objetos.
En la actualidad, hay afirmaciones que a las aplicaciones con paradigma orientado a objetos
cuando se les han realizado pruebas tanto de concepto como de carga, han evidenciado que a
pesar de tener una respuesta aceptable en una cantidad mediana de usuarios y operaciones
medianamente complejas, la capacidad del sistema se degrada de manera rápida al empezar
a tener más usuarios concurrentes (alrededor de 1000 usuarios al mismo tiempo) [Web17].
Es dif́ıcil encontrar documentación a cerca de un API Gateway haya sido desarrollado con
programación orientada a objetos, ¿a qué se debe este fenómeno?, las limitaciones que se
mencionaron anteriormente ¿impactan la atención de solicitudes en este componente?, ¿Qué
1.2 Objetivos 5
diferencias tiene la programación reactiva frente a la programación orientada a objetos?
Formulación del problema
Para un componente API Gateway de la arquitectura de microservicios desarrollado bajo
el paradigma orientado a objetos y el mismo componente desarrollado bajo el paradigma
reactivo, ¿Qué API tiene mayor ı́ndice de atención a las peticiones enviadas en un lapso de
tiempo dado?
Sistematización del problema
¿Cómo proveer los API Gateways que serán objetos de estudio, en donde se determinará
cuál tiene mayor rendimiento en su transaccionalidad?
¿Cómo se obtendrán los datos de la transaccionalidad de cada API Gateway para n
peticiones en un lapso de tiempo dado?
¿Cómo demostrar qué API Gateway tiene mayor ı́ndice de atención a sus peticiones
enviadas?
1.2. Objetivos
1.2.1. Objetivo General
Analizar el rendimiento de la transaccionalidad en un API Gateway desarrollado con el
paradigma orientado a objetos frente al paradigma reactivo, determinando qué paradigma
tiene mayor ı́ndice de atención.
1.2.2. Objetivos espećıficos
Desarrollar el API Gateway mediante las tecnoloǵıas Spring Cloud y NodeJS para el
paradigma Reactivo y por parte del paradigma orientado a objetos con Java; los cuales
serán objetos de estudio.
Obtener los datos de la transaccionalidad de cada API Gateway con la ayuda de la
herramienta: Apache JMeter; para n peticiones en un lapso de tiempo determinado,
en donde n está en unidades de mil; estos datos representan a cada paradigma usado
en el desarrollo del API.
Clasificar los paradigmas de acuerdo al nivel de transaccionalidad del API, determi-
nados por la comparación de resultados; el orden de la clasificación es el número de
peticiones atendidas en un tiempo dado, de mayor a menor.
6 1 Descripción de la investigación
1.3. Justificación del trabajo/investigación
En la actualidad las aplicaciones con arquitectura a microservicios están en su pleno auge,
esto se debe a que han solventado varios inconvenientes comunes que presentan las aplica-
ciones monoĺıticas. Entre algunas ventajas se tienen: Servicios pequeños e independientes
(principio de responsabilidad única), unidades de despliegue pequeñas, reducción en tiempos
de desarrollo, agilidad en hot fixes, multitecnoloǵıa, fácil escalado horizontal.
El patrón Api Gateway nace en respuesta a cómo debeŕıan los clientes de una aplicación
basada a microservicios acceder a los servicios individuales, porque estos sistemas necesi-
tan mucha información que se distribuye en varios servicios dentro del catálogo de servicios
[Web14]. Además, muchos tipos de clientes consumen los servicios del sistema, agregando
más complejidad a las soluciones finales; cuando comenzamos a pensar en la evolución de
esos servicios, respetando las comunicaciones y el intercambio de tamaño/formato de datos
para cada uno de esos clientes; de esta manera, los servicios deben poder ”hablarçon cada
uno de estos clientes (y ser fácilmente detectables) sin perder los requisitos no funcionales
de rendimiento, mantenimiento, escalabilidad, seguridad y disponibilidad necesarios para so-
portar estas soluciones distribuidas [Web14].
Las aplicaciones microservicios con el patrón API Gateway están orientadas para tener una
alta concurrencia, como es el caso de Netflix, por tal motivo la literatura se centra en un
enfoque reactivo, impulsado por eventos, ya que se considera que es mejor por si debe es-
calarse al manejo de altas cargas. En la JVM, las bibliotecas basadas en NIO como Netty,
Spring Reactor, etc. tienen sentido. NodeJS es otra opción.
Con la realización del análisis de la transaccionalidad en el Api Gateway bajo el para-
digma orientado a objetos frente al paradigma reactivo, lo que se pretende es determinar
qué paradigma tiene mejor atención de solicitudes. Este análisis es una contribución para las
aplicaciones basadas en arquitectura microservicios y por ende al desarrollo de software.
1.4 Hipótesis 7
1.4. Hipótesis
Con el análisis de la transaccionalidad en el API Gateway desarrollado bajo el paradigma
reactivo frente al paradigma orientado a objetos, para la funcionalidad de “mostrar regalo”
de la aplicación microservicios seloreglo.com; se determinará que para el alto número de
solicitudes concurrentes, el API Gateway desarrollado con programación reactiva responderá
mayor número de peticiones en un tiempo dado.
1.5. Marco referencial
1.5.1. Marco teórico
El patrón Api Gateway
Un API Gateway es un servicio que es el único punto de entrada para las solicitudes de
API en una aplicación desde fuera del firewall. Es similar al patrón de fachada del diseño
orientado a objetos. Como una fachada, un Api Gateway encapsula la arquitectura interna de
la aplicación y la proporciona a sus clientes. También podŕıa tener otras responsabilidades,
tales como autenticación, monitoreo y limitación de velocidad. La figura 1-1 muestra la
relación entre los clientes, el Api Gateway y los servicios [7].
Figura 1-1: Arquitectura microservicios con Api Gateway
El API Gateway es responsable del enrutamiento de solicitudes, la composición de API y
la traducción de protocolos. Todas las solicitudes de clientes externos primero van al API
8 1 Descripción de la investigación
Gateway. Este encamina algunas solicitudes al servicio apropiado y da manejo a otras solici-
tudes usando el patrón de composición de API e invocando múltiples servicios y agregando
los resultados. También actúa como traductor entre protocolos amigables para el cliente,
como HTTP y WebSockets, y los protocolos hostiles para el cliente que son utilizados por
los servicios [7].
Enrutamiento de solicitudes Una de las funciones clave de un API Gateway es el en-
rutamiento de solicitudes. Ya que implementa algunas operaciones de API al enrutar las
solicitudes al servicio correspondiente. Cuando recibe una solicitud, el API Gateway consul-
ta un mapa de enrutamiento que especifica a qué servicio enrutar la solicitud. Un mapa de
enrutamiento podŕıa, por ejemplo, asignar un método HTTP y una ruta a la URL HTTP
de un servicio. Esta función es idéntica a las funciones de proxy inverso proporcionadas por
servidores web como NGINX [7] .
Composición Api Un API Gateway normalmente hace más que un proxy inverso. Tam-
bién podŕıa implementar algunas operacionesde API utilizando la composición. Como se
muestra en la Figura 1-2, la aplicación móvil realiza una solicitud al API Gateway, que
obtiene los detalles del pedido de múltiples servicios.
Traducción del Protocolo Un API Gateway también puede realizar la traducción del
protocolo. Puede proporcionar una API RESTful a clientes externos, aunque los servicios
de la aplicación utilizan una combinación de protocolos que incluyen internamente REST y
gRPC. Cuando sea necesario, la implementación de algunas operaciones de API se traduce
entre la API externa RESTful y las API internas basadas en gRPC [7].
El API Gateway proporciona para cada cliente un API espećıfico Un API Ga-
teway podŕıa proporcionar una única API de talla única para todos (OSFA). El problema
con una única API es que los diferentes clientes a menudo tienen diferentes requisitos. Por
ejemplo, una aplicación de terceros puede requerire que la operación de obtención de detalles
de pedidos de la API devuelva los detalles completos de los pedidos, mientras que un cliente
móvil solo necesita un subconjunto de los datos. Una forma de resolver este problema es dar
a los clientes la opción de especificar en una solicitud qué campos y objetos relacionados
debe devolver el servidor. Este enfoque es adecuado para una API pública que debe servir
a una amplia gama de aplicaciones de terceros, pero a menudo no proporciona a los clientes
el control que necesitan [7].
Un mejor enfoque es que el API Gateway proporcione a cada cliente su propia API. Por
ejemplo, se podŕıa tener diferentes API para las aplicaciones móviles de Android e iPhone.
Arquitectura Api Gateway
Un API Gateway tiene una arquitectura modular en capas. Su arquitectura, que se muestra
en la Figura 1-3. Arquitectura API Gateway con múltiples clientes, consta de dos capas, la
capa API y una capa común.
1.5 Marco referencial 9
Figura 1-2: Ejemplo de composición de Api para un Api Gateway
La capa API consta de uno o más módulos independientes. Cada módulo implementa
una API para un cliente en particular. La capa común implementa una funcionalidad
compartida que incluye funciones de borde como la autenticación.
En este ejemplo, el API Gateway tiene tres módulos:
Mobile API: Implementa el Api de servicios para clientes Móviles.
Browser API: El cual implementa el API para aplicaciones Javascript ejecutadas por
un navegador.
Public API: Hace referencia al API de servicios para desarrolladores terceros.
Beneficios de un Api Gateway Una de las principales ventajas de utilizar un API
Gateway es que encapsula la estructura interna de la aplicación. En lugar de tener que
invocar servicios espećıficos, los clientes hablan con el API. Este proporciona a cada cliente
10 1 Descripción de la investigación
Figura 1-3: Arquitectura Api Gateway con múltiples clientes
una API espećıfica para cliente. Esto reduce el número de viajes de ida y vuelta entre el
cliente y la aplicación. También simplifica el código del cliente [7].
Inconvenientes de un Api Gateway El patrón API Gateway también tiene algunos
inconvenientes. Es otro componente altamente disponible que debe ser desarrollado, imple-
mentado y administrado. Esto crea el riesgo de que el componente se convierta en un cuello
de botella de desarrollo. Los desarrolladores deben actualizar el API Gateway para exponer
la API de sus servicios. Es importante que el proceso para actualizarlo sea lo más liviano po-
sible. De lo contrario, los desarrolladores se ven obligados a esperar en ĺınea para actualizar
el API Gateway [7].
Netflix como ejemplo de un API Gateway
Un gran ejemplo de un API Gateway es el API de Netflix. El servicio de transmisión de
Netflix está disponible en cientos de diferentes tipos de dispositivos, incluidos televisores, re-
productores de Blu-ray, teléfonos inteligentes, etc. Inicialmente, Netflix intentó tener un API
de estilo único para su servicio de transmisión. Desafortunadamente, pronto descubrieron
que no funcionaba bien debido a la amplia gama de dispositivos y sus diferentes necesidades.
Hoy en d́ıa, utilizan un API Gateway que implementa una API de servicios separada para
cada dispositivo.
En la primera versión del API Gateway de Netflix, cada equipo de clientes implementó
su API utilizando scripts Groovy que realizan enrutamiento y composición de API. Cada
secuencia de comandos invocó una o más API de servicio utilizando las bibliotecas de clien-
1.5 Marco referencial 11
te Java proporcionadas por los equipos de servicio. Por un lado, esto funciona bien y los
desarrolladores de clientes han escrito más de miles de scripts. El API Gateway de Netflix
maneja miles de millones de solicitudes por d́ıa; en promedio, cada API llama a los fanáticos
a seis o siete servicios de back-end. Netflix ha encontrado que esta arquitectura monoĺıtica
es algo incómoda.
Como resultado, Netflix ahora se está moviendo a una arquitectura de API Gateway que es
similar a los Backends para los patrones front-end. En esta nueva arquitectura, los equipos
de clientes escriben módulos API utilizando NodeJS. Cada módulo API ejecuta su propio
contenedor Docker. Los scripts no invocan los servicios directamente. En su lugar, invocan
un segundo “API Gateway”, que expone las API de servicio utilizando Netflix Falcor. Netflix
Falcor es una tecnoloǵıa de API que realiza una composición de API dinámica y declarativa,
y permite a un cliente invocar múltiples servicios utilizando una sola solicitud. Esta nueva
arquitectura tiene una serie de beneficios. Los módulos API están aislados entre śı, lo que
mejora la confiabilidad y la capacidad de observación. Además, el módulo API del cliente es
escalable de forma independiente.
Programación Orientada a Objetos
Un programa orientado a objetos (OOP) se ve como una colección de objetos interactivos,
a diferencia del modelo convencional en el que un programa se ve como una lista de tareas
(subrutinas) para realizar. En OOP, cada objeto es capaz de recibir mensajes, procesar
datos y enviar mensajes a otros objetos. Cada objeto puede verse como una “máquina”
independiente con una función o responsabilidad distinta. Las acciones o métodos en estos
objetos están estrechamente asociados con el objeto [6].
Clase Una clase, es simplemente una abstracción que hacemos de nuestra experiencia sen-
sible. El ser humano tiende a agrupar seres o cosas -objetos- con caracteŕısticas similares en
grupos -clases-. Aśı, aun cuando existen por ejemplo multitud de vasos diferentes, podemos
reconocer un vaso en cuanto lo vemos, incluso aun cuando ese modelo concreto de vaso no lo
hayamos visto nunca. El concepto de vaso es una abstracción de nuestra experiencia sensible.
Quizás el ejemplo más claro para exponer esto lo tengamos en las taxonomı́as; los biólogos
han dividido a todo ser (vivo o inerte) sobre la tierra en distintas clases [5] . Tomemos como
ejemplo una pequeña porción del inmenso árbol taxonómico: Ellos, llaman a cada una de
estas parcelas reino, tipo, clase, especie, orden, familia, género, etc.; sin embargo, nosotros
a todas las llamaremos del mismo modo: clase. Aśı, hablaremos de la clase animal, clase
vegetal y clase mineral, o de la clase félidos y de las clases leo (león) y tigris (tigre). Cada
clase posee unas cualidades que la diferencian de las otras. Aśı, por ejemplo, los vegetales se
diferencian de los minerales -entre otras muchas cosas- en que los primeros son seres vivos y
los minerales no. De los animales se diferencian en que las plantas son capaces de sintetizar
clorofila a partir de la luz solar y los animales no [5].
Objeto En OOP, un objeto es un conjunto de datos y métodos como imaginamos que
se habrá quedado igual, le vamos a dar más pistas [5].
12 1 Descripción de la investigación
Figura 1-4: Clasificación taxonómica de los vertebrados
Los datos son lo que antes hemos llamado caracteŕısticas o atributos, los métodos son los
comportamientos que pueden realizar [5].
Lo importantede un sistema OOP es que ambos, datos y métodos están tan intŕınseca-
mente ligados, que forman una misma unidad conceptual y operacional. En OOP, no se
pueden desligar los datos de los métodos de un objeto. Aśı es como ocurre en el mundo real
[5].
Herencia Esta es la cualidad más importante de un sistema OOP, la que nos dará mayor
potencia y productividad, permitiéndonos ahorrar horas y horas de codificación y de depu-
ración de errores.
Las cualidades comunes que comparten distintas clases, pueden y deben agruparse para
formar una clase padre -también llamada superclase-. Por ejemplo, usted podŕıa derivar las
clases presupuesto, albarán y factura de la superclase pedidos, ya que estas clases comparten
caracteŕısticas comunes. De este modo, la clase padre poseeŕıa los métodos comunes a todas
ellas y sólo tendŕıamos que añadir aquellos métodos propios de cada una de las subclases,
pudiendo reutilizar el código escrito en la superclase desde cada una de las clases deriva-
das. Aśı, si enseñamos a la clase padre a imprimirse, cada uno de los objetos de las clases
inferiores sabrá automáticamente y sin escribir ni una solo ĺınea más de código imprimirse
[5].
1.5 Marco referencial 13
Encapsulamiento Hay muchos datos que no tiene por qué conocerlo aquel que esté usan-
do la clase X; ya que son inherentes al objeto y solo controlan su funcionamiento interno.
Esto es la encapsulación u ocultación; hacer las variables que son innecesarias para el trata-
miento del objeto pero necesarias para su funcionamiento privadas, aśı como las funciones
que no necesitan interacción del usuario o que solo pueden ser llamadas por otras funciones
dentro del objeto (como por ejemplo, palpitar) [5].
La encapsulación es muy conveniente y nos permite colocar en funcionamiento nuestro ob-
jeto en cualquier tipo de sistema, de una manera modular y escalable (algunas de las reglas
de la ingenieria del software) [5].
Formas de encapsular:
Abierto: hace que el miembro de la clase pueda ser accedido desde el exterior de la
Clase cualquier parte del programa.
Protegido: solo es accesible desde la Clase y las clases que heredan (a cualquier nivel).
Cerrado: Solo es accesible desde la Clases.
Polimorfismo Por polimorfismo entendemos aquella cualidad que poseen los objetos para
responder de distinto modo ante el mismo mensaje.
Pongamos por ejemplo las clases hombre, vaca y perro, si a todos les damos la orden -
enviamos el mensaje- Come, cada uno de ellos sabe cómo hacerlo y realizará este comporta-
miento a su modo.
Veamos otro ejemplo algo más ilustrativo. Tomemos las clases barco, avión y coche, to-
das ellas derivadas de la clase padre veh́ıculo; si les enviamos el mensaje Desplázate, cada
una de ellas sabe cómo hacerlo.
Realmente, y para ser exactos, los mensaje no se env́ıan a las clases, sino a todos o algunos
de los objetos instanciados de las clases. Aśı, por ejemplo, podemos decirle a los objetos
Juan Sebastián el Cano y Kontiqui, de la clase barco que se desplacen, con los que el resto
de los objetos de esa clase permanecerán inmóviles.
Paradigma reactivo
Sistemas Reactivos
En 1985, Harel y Puneli propusieron dos categoŕıas de sistemas [3, 4]. Hicieron una distin-
ción entre sistemas transformacionales y reactivos. Un sistema de transformación se define
como un sistema que responde a la entrada transformándolo y luego produciendo salidas. La
naturaleza es que estos sistemas procesan la entrada y producen la salida de vez en cuando.
14 1 Descripción de la investigación
Sin embargo, los sistemas reactivos se definen como sistemas que responden continuamente
a las entradas. Harel y Puneli también señalan que los sistemas reactivos están presentes en
todas partes, desde automóviles hasta teléfonos. La reactividad puede ser incluida por soft-
ware o chips, por ejemplo. Tanto los sistemas transformacionales como los reactivos pueden
ser śıncronos o aśıncronos.
El centro de mayor atención para la programación reactiva está especialmente en combinar la
programación reactiva y la distribución. Buenos ejemplos para la combinación de programa-
ción reactiva y distribución son las aplicaciones web y las aplicaciones móviles distribuidas.
Un inconveniente conocido de la combinación de programación reactiva y distribución es
que puede provocar fallas [1, 4]. Evitar fallos es un factor a considerar cuando se utiliza la
programación reactiva. Es más dif́ıcil evitarlos en los sistemas distribuidos debido a los pro-
blemas de la red, como la latencia. La combinación de programación reactiva y distribución
a menudo se denomina programación reactiva distribuida o microservicios reactivos.
Figura 1-5: Caracteŕısticas de un sistema reactivo, y como se relacionan entre śı
Programación reactiva
En la comunidad Java, el paradigma de la programación reactiva ha logrado cada vez más
atención en los últimos años. Las bibliotecas reactivas como Project Reactor y RxJava y la
introducción de un estándar reactivo en la API de Java 9 han contribuido al mayor interés
en la programación reactiva en Java.
Esta programación se trata de flujos de datos y propagación de cambios. Para aplicaciones
dirigidas por eventos, este paradigma es adecuado. Sin embargo, centrándose principalmente
en el paradigma de la programación reactiva funcional [1, 4].
La programación reactiva reside dentro del paradigma de la programación declarativa. En
1.5 Marco referencial 15
contraste con la programación imperativa, donde el desarrollador usa declaraciones para
cambiar el estado de un programa, en la programación declarativa el desarrollador define
qué hacer, pero el tiempo de ejecución lo maneja el propio programa [1, 4].
Programación Reactiva vs Sistemas Reactivos
La diferencia entre la programación reactiva y los sistemas reactivos están en sus aplicaciones.
La programación reactiva se aplica a la lógica interna de los componentes, mientras que los
sistemas se aplican a nivel arquitectónico para los sistemas. Las aplicaciones que implementan
la programación reactiva son altamente controladas por eventos, lo que significa que son estos
los que impulsan la ejecución en lugar de un hilo de ejecución. La programación reactiva
facilita el desacoplamiento en el tiempo y, por lo tanto, la concurrencia. Los sistemas reactivos
son altamente impulsados por mensajes. Los sistemas facilitaron el acoplamiento en el espacio
y por lo tanto la distribución.
Figura 1-6: Relación en una implementación del flujo reactivo
La diferencia entre ser dirigido por eventos y por mensaje se define en el Reactivo Ma-
nifiesto [Web3]. En el manifiesto, el evento controlado se define como oŕıgenes de eventos
direccionables y el mensaje se define como destinatarios direccionables. Esto significa que los
suscriptores en un sistema controlado por eventos se adjuntan a los editores, mientras que
en un sistema dirigido por mensajes, los suscriptores esperan que los mensajes lleguen sin la
necesidad de adjuntarlos al editor.
1.5.2. Marco conceptual
Paradigma
Un paradigma de programación indica un método de realizar cómputos y la manera en que
se deben estructurar y organizar las tareas que debe llevar a cabo un programa [8].
Los paradigmas fundamentales están asociados a determinados modelos de cómputo.
16 1 Descripción de la investigación
Tambien se asocian a un determinado estilo de programación.
Los lenguajes de programación suelen implementar, a menudo de forma parcial, varios pa-
radigmas [8].
Figura 1-7: El zoo de los paradigmas
Patrón
Los patrones son disciplinas de la Ingenieŕıa de Software que facilitan la reutilización del
diseño y de la arquitectura. Son soluciones de problemas conocidos en la programación.
No es obligatorio usar patrones pero reinventar la rueda en situaciones similares facilitan
catálogos de elementos reusables, evitar reiteraciones, formular un vocabulario común entre
programadores, estandarizar el diseñoy facilitar el aprendizaje de los nuevos programadores
[Web2].
Arquitectura software
La arquitectura de software es un tema creciente de la ingenieŕıa de software para ayudar a
las personas a resolver problemas. Con él, los diseñadores o gerentes de proyectos tienen la
oportunidad de supervisar el estado del software en un alto nivel. Además, la arquitectura
del software puede reutilizarse, lo que permite ahorrar enormes costos y reducir los riesgos
dentro de los procesos de desarrollo y las actividades posteriores, incluido el diseño de mo-
delos, la implementación, las pruebas, la evaluación, el mantenimiento y la evolución [Web1].
1.6 Metodoloǵıa de la investigación 17
Sin embargo, el seguimiento de la arquitectura del software es dif́ıcil, porque siempre se
esconde detrás de lo que se puede tocar. Visualizarlo requiere un profundo conocimiento de
la información global de los sistemas, aśı como excelentes habilidades y métodos. Las per-
sonas de diferentes organizaciones o empresas utilizan diferentes estrategias para manejarlo,
pero la mayoŕıa de ellas tiene algo en común. El resumen y el sol de estas experiencias se han
convertido en la base de la ciencia de la arquitectura de software en la actualidad [Web1].
Servicio web
Un servicio web realiza una tarea espećıfica o un conjunto de tareas. La descripción de
servicio proporciona todos los detalles necesarios para interactuar con el servicio, incluidos
los formatos de mensaje (que detallan las operaciones), los protocolos de transporte y la
ubicación [Web6].
1.6. Metodoloǵıa de la investigación
Tipo de estudio
El nivel de profundidad que aborda este proyecto, es el tipo de confirmatorio. Ya que
la intención de este análisis es determinar qué paradigma tiene un mayor rendimiento en la
atención de solicitudes en un API Gateway para un tiempo determinado.
El nivel en la investigación hoĺıstica es la Integrativa y el holotipo de investigación es
confirmatoria . Porque se verificará y demostrará con datos la conclusión final del presente
trabajo.
Método de investigación
En aras de obtención de la respuesta planteada en la formulación del problema, es necesario
establecer un procedimiento riguroso de manera organizada. Por lo anterior, se define como
método de investigación el Método Cuantitativo, en donde a partir de diversas mediciones
en la transaccionalidad del API Gateway, se encontrarán diferencias entre paradigmas de
programación.
Fuentes y técnicas para recolección de la información
Las fuentes a los que se acudió para el marco referencial son:
Documentación: Se revisó literatura tanto internet, tesis online, sistema BDigital (Bi-
blioteca Digital) de la universidad Distrital Francisco José de Caldas, Trabajos de grado
expuestos en RIUD (Repositorio Institucional) de la universidad Distrital Francisco José de
Caldas.
18 1 Descripción de la investigación
1.7. Organización del trabajo de grado
El trabajo realizado para el presente proyecto inicia con la Contextualización de la in-
vestigación, en donde se puede identificar el planteamiento del problema, definición de la
justificación, los objetivos para la investigación, hipótesis, marco referencial, metodoloǵıa y
estudio de sistemas previos.
En una segunda parte, se puede econtrar el Desarrollo de la investigación, la cual la
compone los siguientes caṕıtulos:
Fase de Análisis: Se realizó identificación de tecnoloǵıas y requerimientos de un Api
Gateway.
Fase de diseño: Modelamiento de cada Api Gateway mediante UML, y se acompaña
el uso del componente en aplicaciones con microservicios mediante el uso de ADM-
Archimate.
Fase de construcción: Se muestra la implementación de cada uno de los Api Gateway
haciendo uso de los microservicios.
Fase de pruebas: Se realizan consumos de los servicios expuestos por cada Api Gateway
mediante herramientas de análisis de peticiones RestFul.
Para el cierre de la investigación, se presenta una muestreo de la recolección de datos para
cada Api Gateway, orientado a objetos y reactivo; se presenta el comportamiento de cada
Api Gateway mediante gráficas estad́ısticas y se realiza comparación de resultados en peti-
ciones atendidas en un lapso de tiempo.
Adicionalmente se discute a cerca de los resultados obtenidos, para finalmente concluir nues-
tra hipótesis planteada.
1.8. Estudio de sistemas previos
Hace aproximadamente un año, el equipo de API de Netflix comenzó a rediseñar la API para
mejorar el rendimiento y permitir que los equipos de ingenieŕıa de UI en Netflix optimicen las
aplicaciones de cliente para dispositivos espećıficos. Las filosof́ıas del rediseño se introdujeron
en una publicación anterior acerca de abarcar las diferencias entre los diferentes clientes y
dispositivos [Web5].
Netfilx además de: Disminuir el número de llamados, distribuir el desarrollo de la API,
mitigar los riesgos de implementación, Soporta múltiples idiomas, distribuir operaciones,
también presentó su arquitectura [Web5].
1.8 Estudio de sistemas previos 19
Arquitectura
Para lograr los objetivos por encima de nuestra arquitectura destilada en algunos puntos
clave:
Tiempo de ejecución poĺıglota dinámico.
capa de servicio totalmente aśıncrono.
Modelo de programación reactiva.
El siguiente diagrama, Figura 1-8 y las siguientes anotaciones explican la arquitectura:
Figura 1-8: Arquitectura en Api de Netflix
1. Endpoints dinámicos Todos los nuevos puntos finales de servicios web ahora se defi-
nen dinámicamente en tiempo de ejecución. Cada equipo cliente puede desarrollar, probar,
canarear e implementar nuevos puntos finales sin coordinación (a menos que dependan de la
nueva funcionalidad de la capa de servicio API subyacente que se muestra en el elemento 5,
en cuyo caso tendŕıan que esperar hasta que se implementen los cambios antes de presionar
su punto final) [Web5].
20 1 Descripción de la investigación
2. Administración y gestión de códigos Endpoint El código de punto final se publica
en un clúster multirregional de Cassandra (replicado globalmente) a través de una API
RESTful Endpoint Management utilizada por los equipos de clientes para administrar sus
puntos finales [Web5].
3. Lenguaje Runtime JVM poĺıglota dinámico Se puede admitir cualquier lenguaje
JVM para que cada equipo pueda utilizar el idioma que mejor se adapte a ellos. El len-
guaje Groovy JVM fue elegido como nuestro primer idioma compatible. La existencia de
funciones de primera clase (cierres), sintaxis de lista / diccionario, rendimiento y capacidad
de depuración fueron todos aspectos de nuestra decisión. Además, Groovy proporciona una
sintaxis cómoda para una amplia gama de desarrolladores, lo que ayuda a reducir la curva
de aprendizaje del primer idioma en la plataforma [Web5].
4 y 5 API Java Aśıncrona + modelo de programación reactiva Adoptar la concu-
rrencia fue un requisito clave para lograr mejoras de rendimiento, pero abstraer los detalles
de implementación de ejecución paralela y seguridad de subprocesos de los desarrolladores
clientes fue igualmente importante para reducir la complejidad y acelerar su tasa de inno-
vación. El primer paso fue hacer que la API de Java fuera totalmente aśıncrona, ya que
permite que las implementaciones de los métodos subyacentes controlen si algo se ejecuta
simultáneamente o no, sin que cambie el código del cliente. Elegimos un modelo de pro-
gramación reactivo con un estilo de programación funcional para manejar la composición y
los flujos condicionales de devoluciones de llamada aśıncronas. Nuestra implementación está
modelada a partir de Rx Observables [Web5].
6. Tolerancia a fallos de Hystrix Como hemos descrito en una publicación anterior,
todas las llamadas de servicio a los sistemas de back-end se realizan a través de la capa
de tolerancia a fallos Hystrix (que se abrió recientemente, junto con su panel de control)
que áısla los puntos finales dinámicos y la capa de servicio API de losinevitables fallos que
Ocurre mientras se ejecutan miles de millones de llamadas de red cada d́ıa desde la API a
los sistemas backend [Web5].
La capa Hystrix es intŕınsecamente multihilo debido a su uso de subprocesos para aislar
dependencias y, por lo tanto, se aprovecha para la ejecución simultánea de llamadas de blo-
queo a sistemas backend. Estas solicitudes aśıncronas se componen juntas a través del marco
reactivo [Web5].
7. Backend Services y Dependencias La Capa de servicios API abstrae todos los
servicios de fondo y dependencias detrás de las fachadas. Como resultado, el código de punto
final accede a la “funcionalidad” en lugar de a un “sistema”. Esto nos permite cambiar las
implementaciones y la arquitectura subyacentes sin impacto o con un impacto limitado en
el código que depende de la API. Por ejemplo, si un sistema backend se divide en 2 servicios
diferentes, o 3 se combinan en uno solo, o una llamada de red remota se optimiza en un
caché en memoria, ninguno de estos cambios debeŕıa afectar el código del punto final y, por
1.8 Estudio de sistemas previos 21
lo tanto, la capa de servicio API garantiza los modelos de objetos y otros acoplamientos
cerrados similares se abstraen y no se les permite “filtrarse” en el código del punto final
[Web5].
Parte II
Desarrollo de la investigación
Caṕıtulo 2
Análisis del sistema
En una arquitectura de microservicios, un cliente puede interactuar con más de un servicio de
frontEnd. Dado este hecho, ¿cómo sabe un cliente a qué puntos finales llamar? ¿Qué sucede
cuando se introducen nuevos servicios o se refactorizan los servicios existentes? ¿Cómo ma-
nejan los servicios la terminación SSL, la autenticación y otras inquietudes? El Api Gateway
que se propone a continuación puede ayudar a enfrentar estos desaf́ıos.
Figura 2-1: Funciones del Api Gateway
Un API Gateway se encuentra entre los clientes y los servicios. Actúa como un proxy inverso,
enrutando las solicitudes de los clientes a los servicios. También puede realizar varias tareas
transversales, como la autenticación, la terminación SSL y la limitación de velocidad. Si no
se despliega un API Gateway, los clientes deben enviar las solicitudes directamente a los
servicios.
24 2 Análisis del sistema
El Gateway ayuda a resolver estos problemas mediante el desacoplamiento de los clien-
tes de los servicios. Estos pueden realizar una serie de funciones diferentes, y es posible que
no las necesite todas. Las funciones que cumplirán cada Api desarrollado cumplen con los
siguientes patrones de diseño que serán los requerimientos:
2.1. Requerimientos
Gateway Routing Uso del Gateway como un proxy inverso para enrutar las solicitudes a
uno o más servicios de backEnd. La puerta de enlace proporciona un único punto final para
los clientes y ayuda a desvincular a los clientes de los servicios.
Gateway Aggregation Utiliza el Gateway para agregar varias solicitudes individuales
en una sola solicitud. Este patrón se aplica cuando una sola operación requiere llamadas
a múltiples servicios backend. El cliente env́ıa una solicitud al Gateway. El Gateway env́ıa
solicitudes a los diversos servicios de backEnd, y luego agrega los resultados y los env́ıa de
vuelta al cliente. Esto ayuda a reducir el chattiness entre el cliente y el backend.
Gateway Offloading Se usa el Gateway para descargar la funcionalidad de los servi-
cios individuales a el mismo, en particular las preocupaciones transversales. Puede ser útil
consolidar estas funciones en un solo lugar, en lugar de hacer que cada servicio sea responsa-
ble de implementarlas. Esto es particularmente cierto para las caracteŕısticas que requieren
habilidades especializadas para implementarse correctamente, como la autenticación y la au-
torización.
Estos son algunos ejemplos de la funcionalidad que se podŕıa descargar en un Gateway:
Terminación SSL.
Autenticación.
Caché de respuestas.
Caṕıtulo 3
Diseño de Api Gateway
En el presente caṕıtulo se presentan los diseños del API Gateway desarrollados bajo el
paradigma orientado a objetos y el reactivo respectivamente. Se hace uso de diagramas que
el autor considera representativos para la monograf́ıa.
3.1. Paradigma orientado a objetos
En función del desarrollo del Api Gateway usando el paradigma orientado a objetos se usan
los diagramas de clases, secuencia y componentes para resaltar su diseño.
Figura 3-1: Diagrama de clases Api Gateway con paradigma orientado a objetos
26 3 Diseño de Api Gateway
Diagrama de secuencia
Figura 3-2: Diagrama de secuencia Api Gateway con paradigma orientado a objetos
Diagrama de componentes
Figura 3-3: Diagrama de componentes Api Gateway con paradigma orientado a objetos
3.2 Paradigma reactivo 27
3.2. Paradigma reactivo
En función del desarrollo del Api Gateway usando el paradigma reactivo se usan los diagra-
mas flujos de datos, secuencia. En adición, la figura 3-6 muestra la concurrencia en el Api
Gateway reactivo, elemento que no tiene el Api bajo el paradigma orientado a objetos.
Figura 3-4: Diagrama de flujo de datos f́ısico
Figura 3-5: Diagrama de secuencia Api Gateway con paradigma reactivo
28 3 Diseño de Api Gateway
Figura 3-6: Concurrencia api reactivo
Caṕıtulo 4
Construcción e Implementación
4.1. Microservicios
Aunque los microservicios no hacen parte del análisis de transaccionalidad del presente tra-
bajo, son la fuente de datos para cada API Gateway desarrollados. Con el ánimo de conservar
la misma fuente de datos y la razón del patrón API Gateway se comenta a continuación su
desarrollo:
Construcción con JHipster
JHipster es una plataforma de desarrollo para generar, desarrollar e implementar aplicacio-
nes web Spring Boot + Angular / React / Vue y microservicios Spring [Web10].
El objetivo es generar para usted una aplicación web completa y moderna o una arquitectura
de microservicio, unificando:
Figura 4-1: Plataforma Jhipster
Un Stack de Java robusto y de alto rendimiento en el lado del servidor con Spring
Boot.
Un frontal moderno, elegante y moderno, con Angular, React y Bootstrap.
Una robusta arquitectura de microservicio con JHipster Registry, Netflix OSS, Elastic
Stack y Docker.
30 4 Construcción e Implementación
Una vez instalado, ver gúıa de instalación en [Web10]; se realizó modelo de entidades del
negocio del microservicio; Una caracteŕıtica de Jhipster es generar código a partir de este
modelo.
Figura 4-2: Ejemplo modelo de entidades microservicio en JDL Studio
En https://start.jhipster.tech/jdl-studio/ se puede realizar el archivo .jh, el cual es
de gran ayuda para la exposición de un Api RestFul.
Implementación con Docker
Un contenedor es una unidad estándar de software que empaqueta el código y todas sus
dependencias para que la aplicación se ejecute de forma rápida y confiable de un entorno
informático a otro. Una imagen de contenedor Docker es un paquete de software liviano,
independiente y ejecutable que incluye todo lo necesario para ejecutar una aplicación: códi-
go, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema y configuraciones
[Web9].
Una vez construido el microservicio, se despliega en una instancia de Jhipster aparte con la
intención de que cada microservicio sea modular mediante contenedores Docker.
https://start.jhipster.tech/jdl-studio/
4.1 Microservicios 31
Figura 4-3: Ejemplo lenguaje JDL en modelo de entidades para microservicio
Documentación con Swagger
Simplifica el desarrollo de API para usuarios, equipos y empresas con el conjunto de herra-
mientas de código abierto y profesional de Swagger. Descubre cómo te puede ayudar Swagger
[Web15].
Para el ejercicio la documuntación de cada microservicio es como se refleja en la figura
32 4 Construcción e Implementación
Figura 4-4: Contenedores docker
Figura 4-5: Documentación Swagger para microservicio
4.1 Microservicios 33
Figura 4-6: Documentación detallada Swagger para microservicio
34 4 Construccióne Implementación
4.2. Api Gateway Reactivo
4.2.1. Api Gateway NodeJS
NodeJS
Concebido como un entorno de ejecución de JavaScript orientado a eventos aśıncronos, Node
está diseñado para construir aplicaciones en red escalables. En dichas aplicaciones, se pueden
manejar muchas conexiones concurrentes. Por cada conexión el callback será ejecutado, sin
embargo si no hay trabajo que hacer Node estará durmiendo [Web7].
ExpressJS
Express es una infraestructura de aplicaciones web Node.js mı́nima y flexible que proporcio-
na un conjunto sólido de caracteŕısticas para las aplicaciones web y móviles [Web8].
Con miles de métodos de programa de utilidad HTTP y middleware a su disposición, la
creación de una API sólida es rápida y sencilla [Web8].
Aprovechando esta tecnoloǵıa se creó el Api Gateway nodeJS haciendo uso del siguiente
código, Figura 4-7 - Figura 4-10:
Figura 4-7: Archivo app.js, ejecución principal del Api Gateway
4.2 Api Gateway Reactivo 35
Figura 4-8: Archivo router.js, contenedor de los microservicios que se desean consumir
Figura 4-9: Gateway adapter, cada microservicio realiza su uso
4.2.2. Api Gateway Spring Cloud
Este proyecto proporciona una biblioteca para construir una API Gateway sobre Spring
MVC. Spring Cloud Gateway tiene como objetivo proporcionar una forma sencilla y eficaz
de enrutar a las API y brindarles preocupaciones transversales, como la seguridad, monitoreo
/ métrica y la resistencia [Web12].
Servidor Eureka
Eureka Server es una aplicación que contiene la información sobre todas las aplicaciones de
servicio al cliente. Cada Microservicio se registrará en el servidor Eureka y el servidor Eureka
conoce todas las aplicaciones cliente que se ejecutan en cada puerto y dirección IP. Eureka
36 4 Construcción e Implementación
Figura 4-10: Configuración de enrutamiento para cada microservicio, por servicio
Server también se conoce como Discovery Server [Web16].
El servidor eureka desarrollado para el funcinamiento del api gateway está bajo el siguiente
código (figura 4-11 - figura 4-13):
Por otro lado el Api Gateway con spring cloud, se desarrolló bajo la siguientes sentencias
(figura 4-14 - figura 4-16):
4.2 Api Gateway Reactivo 37
Figura 4-11: Configuración de archivo pom.xml del servidor eureka
Figura 4-12: Configuración general del servidor
38 4 Construcción e Implementación
Figura 4-13: Clase principal de Spring boot, servidor eureka
Figura 4-14: Dependencias pom.xml Api Gateway con spring cloud
4.2 Api Gateway Reactivo 39
Figura 4-15: Otras dependencias pom.xml Api Gateway con spring cloud
Figura 4-16: Gateway Routing con spring cloud
40 4 Construcción e Implementación
4.3. Api Gateway Orientado a Objetos
Spring boot
SpringBoot nace con la intención de simplificar los siguientes pasos: seleccionar los jar con
maven y despliegues en servidor; con la intención de que el programador se centre en el
desarrollo de la aplicación [Web4].
A continuación se incluye código en spring boot que hace referencia al Api Gateway orien-
tado a objetos:
Figura 4-17: Servicio web, punto de entrada Api Gateway
4.4 Despliegue final 41
Figura 4-18: Acción para la optención de url
Figura 4-19: Transformador de url a request
Figura 4-20: Consumo de servicio RestFul, microservicio
4.4. Despliegue final
42 4 Construcción e Implementación
Figura 4-21: Diagrama de despliegue de componentes del análisis
Caṕıtulo 5
ADM-Archimate
Archimate 2.1 facilita el modelado de la arquitectura empresarial, permitiendo bosquejar la
organización desde diversos puntos de vista donde se reflejan tanto los involucrados en el
negocio, la infraestructura y la misma solución como los diferentes componentes, dando una
visión general que describe a la perfección la organización y su solución informática.
El presente trabajo es del interés para la empresa Jirka IT Solutions, el cual sin nin-
guna duda le sacará provecho para sus desarrollos futuros. Por esta razón el ejercicio de
arquitectura empresarial se realizará sobre esta compañ́ıa
5.1. Organización
Jirka IT Solutions SAS
Jirka es una compañ́ıa especializada en servicios IT de desarrollo de software que ofrecemos
soluciones integrales con los más altos estándares tecnológicos del sector. Nos caracterizamos
por la investigación e innovación al fin de promover el desarrollo de soluciones que ayuden a
la transformación de la sociedad.
Figura 5-1: Logo Jirka It Solutions SAS
44 5 ADM-Archimate
Misión
Jirka es una compañ́ıa especializada en servicios IT de desarrollo de software y Software
Factory que ofrece soluciones integrales con los más altos estándares tecnológicos del sec-
tor. Nos caracterizamos por la investigación e innovación al fin de promover el desarrollo de
soluciones que ayuden a la transformación de la sociedad, por ello, estamos comprometidos
con la excelencia, la responsabilidad y la calidad, de la mano con nuestro Talento Humano,
quienes poseen una alta formación profesional enmarcada en las excelentes relaciones hu-
manas, con el objetivo de dar respuesta a las necesidades de nuestros clientes, proveedores
y colaboradores; conocemos la satisfacción que ofrece el éxito y estamos comprometidos en
lograrlo.
Visión
A 2020, ser la compañ́ıa ĺıder en servicios IT de desarrollo de software y Software Factory del
Mercado, con casos de éxitos que posicionan a nuestros clientes como referentes de la adop-
ción de nuestras soluciones tecnológicas, enmarcadas en los más altos estándares del sector;
demostrando siempre nuestro compromiso social soportado en la investigación e innovación,
de la mano con la formación de nuestro Talento Humano para afrontar los retos que diaria-
mente impone la excelencia, construyendo relaciones basadas en la ética, la responsabilidad
y la confianza.
5.2. Punto de vista del negocio
Los puntos de vista del negocio visualizan y definen los procesos de negocio, servicios y
funciones de la organización, los cuales se ofrecen a los clientes externos y son generados por
la organización por medio de procesos de negocios, a través de actores y sus diferentes roles
de participación.
Punto de vista organizacional
Este punto de vista se centra en la organización interna de la empresa, una red de empresas,
un departamento u otra entidad organizacional. Se pueden modelar diagramas de bloques
anidados o de una forma más tradicional como un organigrama. Estos diagramas ayudan en
la visualización e identificación de las responsabilidades, jerarqúıas y competencias de una
organización.
Punto de vista cooperación de actor
Este punto de vista se centra en las relaciones de cooperación entre los actores y su entorno,
para ello se puede utilizar el diagrama de contexto, el cual permite exponer la organización
5.2 Punto de vista del negocio 45
Figura 5-2: Metamodelo punto de vista de organización
Figura 5-3: Punto de vista de organización
en un ambiente de entidades externas tales como clientes, proveedores y demás colabora-
dores del negocio. Estos diagramas ayudan a determinar las dependencias externas y sus
colaboraciones, y a su vez visualizar la cadena de valor o la red de actores en la cual opera.
Figura 5-4: Metamodelo punto de vista cooperación de actor
46 5 ADM-Archimate
Figura 5-5: Punto de vista cooperación de actor
Punto de vista de función del negocio
Este punto de vista visualiza las principales funciones de negocio de la organización y las
relaciones de los flujos de información, el valor y los bienes entre ellos. Estas funciones per-
miten representar las caracteŕısticas de más estabilidad en una empresa en función de su
actividad principal, sin importar los cambios de la organización o desarrollos tecnológicos.
Figura 5-6: Metamodelo punto de vista de función de negocio
Punto de vista proceso del negocio
Este punto de vista visualiza una estructura de alto nivel y la composición de uno o más
procesos de negocio. Permite mostrarlos servicios a través de los procesos que contribuyen
5.2 Punto de vista del negocio 47
Figura 5-7: Punto de vista de función de negocio
al producto final de la organización, aśı como los roles en los procesos y las responsabilidades
de los actores implicados.
Figura 5-8: Metamodelo punto de vista de proceso de negocio
48 5 ADM-Archimate
Figura 5-9: Punto de vista de proceso de negocio
Punto de vista cooperación proceso del negocio
Este punto de vista visualiza la relación entre los procesos de negocio y su entorno, aśı como
las dependencias entre estos mismos. Sus caracteŕısticas son:
Figura 5-10: Metamodelo punto de vista de cooperación de proceso de negocio
5.2 Punto de vista del negocio 49
Figura 5-11: Punto de vista de cooperación de proceso de negocio
Punto de vista de producto
Este punto de vista visualiza el valor de los productos hacia el cliente o las partes externas
implicadas, muestra la composición de los productos en función de los servicios, contratos o
acuerdos. Visualiza las interfaces en las que el producto es presentado y los eventos asociados
con el producto.
50 5 ADM-Archimate
Figura 5-12: Metamodelo punto vista de producto
Figura 5-13: Punto vista de producto
5.3. Punto de vista de la aplicación
Los puntos de vista de la aplicación visualizan y definen las aplicaciones de software que
gestionan los componentes del negocio y los servicios, los componentes reusables, aśı como
las interfaces que relacionan y comunican los componentes del negocio.
5.3 Punto de vista de la aplicación 51
Punto de vista de comportamiento de aplicación
Este punto de vista visualiza y define el comportamiento a nivel interno de las aplicaciones,
se utiliza para modelar y diseñar el comportamiento de las aplicaciones o componentes y
lograr identificar el proceso funcional entre las aplicaciones.
Figura 5-14: Metamodelo punto de vista de comportamiento de aplicación
Figura 5-15: Punto de vista de comportamiento de aplicación
52 5 ADM-Archimate
Punto de vista de cooperación de aplicación
Este punto de vista visualiza y define las relaciones de los componentes a través del flujo
de información de los servicios ofrecidos o usados por la organización. Permite visualizar la
cooperación de los servicios que se unen para la ejecución de los procesos del negocio.
Figura 5-16: Metamodelo punto de vista de cooperación de aplicación
Figura 5-17: Punto de vista de cooperación de aplicación
Punto de vista de estructura de aplicación
Este punto de vista visualiza la estructura de las aplicaciones o de los componentes, permite
modelar y diseñar estas estructuras de las aplicaciones o componentes y su información
5.3 Punto de vista de la aplicación 53
asociada.
Figura 5-18: Metamodelo punto de vista de estructura de aplicación
Figura 5-19: Punto de vista de estructura de aplicación
Punto de vista de uso de aplicación
Este punto de vista visualiza y define el uso de las aplicaciones para soportar los procesos
del negocio, y como se deben utilizar por otras aplicaciones. Permite modelar y diseñar los
servicios de los procesos de negocio y demás aplicaciones de la organización.
54 5 ADM-Archimate
Figura 5-20: Metamodelo punto de vista de uso de aplicación
Figura 5-21: Punto de vista de uso de aplicación
5.4. Punto de vista tecnológico
Los puntos de vista tecnológicos visualizan y definen la infraestructura que soporta y permite
la comunicación de la capa de aplicación, dispone de servicios de infraestructura hardware
y software para el despliegue de las aplicaciones en la organización.
Punto de vista de infraestructura
Este punto de vista visualiza y define el software y hardware que soportan las aplicaciones,
a través de dispositivos f́ısicos, redes o sistemas de software.
5.4 Punto de vista tecnológico 55
Figura 5-22: Metamodelo punto de vista de infraestructura
Figura 5-23: Punto de vista de infraestructura
Punto de vista de uso de infraestructura
Este punto de vista visualiza y define como las aplicaciones son soportadas por la infraestruc-
tura de software y hardware, los cuales permiten el análisis de rendimiento y escalabilidad,
logrando obtener requerimientos de mejora y calidad en la infraestructura.
56 5 ADM-Archimate
Figura 5-24: Metamodelo punto de vista de uso de infraestructura
Figura 5-25: Punto de vista de uso de infraestructura
Punto de vista de organización e implementación
Este punto de vista visualiza y define como las aplicaciones son integradas en la infraestruc-
tura, a través del mapeo de aplicaciones (lógicas) y componentes (f́ısicos). Permite el análisis
de rendimiento y escalabilidad por medio de la relación que existe de las aplicaciones y la
infraestructura.
5.4 Punto de vista tecnológico 57
Figura 5-26: Metamodelo punto de vista de organización e implementación
Figura 5-27: Punto de vista de organización e implementación
Punto de vista de estructura de información
Este punto de vista visualiza y define la estructura de la información usada en la organización,
proceso o aplicación en función de los tipos de datos o las estructuras de clases (orientado a
objetos).
58 5 ADM-Archimate
Figura 5-28: Metamodelo punto de vista de Estructura de Información
Figura 5-29: Punto de vista de Estructura de Información
Punto de vista de realización del servicio
Este punto de vista visualiza y define como los servicios del negocio son ejecutados por
procesos subyacentes, a través de un puente de comunicación entre los puntos de vista de
negocio y los puntos de vista de procesos de negocio.
Punto de vista de capas
5.4 Punto de vista tecnológico 59
Figura 5-30: Metamodelo punto de vista de Realización del Servicio
Figura 5-31: Punto de vista de Realización del Servicio
60 5 ADM-Archimate
Figura 5-32: Punto de vista de Capas
5.5 Punto de vista motivacional 61
5.5. Punto de vista motivacional
Punto de vista de los skateholder
Este punto de vista visualiza y define los stakeholders, los manejadores internos y externos de
cambio, sus fortalezas, debilidades, oportunidades y amenazas (DOFA). Permite el proceso de
ingenieŕıa de requerimientos, el refinamiento de objetivos, contribución y análisis de conflictos
derivados de los objetivos.
Figura 5-33: Metamodelo punto de vista de stakeholder
Figura 5-34: Punto de vista de stakeholder
Punto de vista de realización de objetivos
Este punto de vista visualiza y define el proceso de mejorar los objetivos en objetivos más
concretos que permitan generar requerimientos o restricciones que ayuden en el cumplimiento
62 5 ADM-Archimate
de los objetivos planteados. Estas mejoras se modelan a través de la relación de realización.
Figura 5-35: Metamodelo punto de vista de realización de objetivos
Figura 5-36: Punto de vista de realización de objetivos
Punto de Vista de Contribución
El punto de vista de la contribución al objetivo permite a un diseñador o analista modelar las
relaciones de influencia entre los objetivos y los requisitos. Las vistas resultantes se pueden
utilizar para analizar el impacto que las metas tienen entre śı o para detectar conflictos entre
las metas de las partes interesadas.
5.5 Punto de vista motivacional 63
Figura 5-37: Metamodelo punto de vista de contribución
Figura 5-38: Metamodelo punto de vista de contribución
Punto de vista de principios
Este punto de vista visualiza y define los procesos más importantes para el diseño a mano y
los objetivos que conllevan a estos principios. Además permite modelar las relaciones de los
principios con sus obetivos.
64 5 ADM-Archimate
Figura 5-39: Metamodelo punto de vista de principios
Figura 5-40: Ejemplo punto de vista de principios
Punto de vista de realización de requerimientos
Este punto de vista visualiza y define la relación de requerimientos con los actores de negocio,
los servicios, procesos y aplicaciones de negocio.
Figura 5-41: Metamodelo punto de vista de realización de Requerimientos5.5 Punto de vista motivacional 65
Figura 5-42: Ejemplo punto de vista de realización de requerimientos
Punto de vista de motivación
Este punto de vista visualiza y define la revisión de los aspectos motivacionales relacionados
con los stakeholders, sus principios primarios, aplicados y los requerimientos más relevantes
de los servicios, procesos, aplicaciones y objetivos del negocio.
Figura 5-43: Metamodelo punto de vista de motivación
66 5 ADM-Archimate
Figura 5-44: Ejemplo punto de vista de realización de requerimientos
5.6. Punto de vista implementación y migración
Punto de vista de proyecto
Este punto de vista visualiza y define los cambios en la arquitectura del proceso de migración
desde un estado actual de la arquitectura empresarial a un estado objetivo de la arquitectura
empresarial, esta migración aporta de forma significativa en el proceso de crecimiento de la
estrategia y las decisiones de los procesos de realización.
Figura 5-45: Metamodelo punto de vista de proyecto
5.6 Punto de vista implementación y migración 67
Figura 5-46: Ejemplo punto de vista de proyecto
Punto de vista de migración
Este punto de vista visualiza y define las caracteŕısticas para la transición de una arquitec-
tura existente a una arquitectura deseada. La platea es el estado de la arquitectura que tiene
un un tiempo limitado.
Figura 5-47: Metamodelo punto de vista de migración
Punto de vista de migración e implementación
Este punto de vista visualiza y define las relaciones entre los programas y proyectos con la
arquitectura que ellas implementan. Permite modelar el alcance de los programas, proyec-
tos y actividades en función de la platea o los artefactos de arquitectura afectada. Además
68 5 ADM-Archimate
Figura 5-48: Ejemplo punto de vista de migración
relaciona objetivos de negocio a través de los programas y proyectos de la arquitectura.
Figura 5-49: Metamodelo punto de vista de migración e implementación
5.6 Punto de vista implementación y migración 69
Figura 5-50: Punto de Vista de Migración e Implementación
Parte III
Cierre de la investigación
Caṕıtulo 6
Resultados y discusión
Los resultados de este trabajo se hallaron con la ayuda de la aplicación Apache JMeter, en
donde se realizó cuatro (4) series de env́ıo de peticiones a cada Api Gateway. Las series se
estableció con las siguientes peticiones: 100, 500, 1.000 y 5.000 request.
Apache JMeter
La aplicación Apache JMeter es un software de cd́igo abierto, una aplicación Java 100 % pura
diseñada para cargar el comportamiento funcional de la prueba y medir el rendimiento. Ori-
ginalmente fue diseñado para probar aplicaciones web, pero desde entonces se ha expandido
a otras funciones de prueba.
Figura 6-1: Apache JMeter
Apache JMeter se puede usar para probar el rendimiento tanto en recursos estáticos como
dinámicos, aplicaciones dinámicas web. Se puede usar para simular una carga pesada en
un servidor, grupo de servidores, red u objeto para probar su resistencia o para analizar el
rendimiento general bajo diferentes tipos de carga.
72 6 Resultados y discusión
Resultados con 100 Peticiones http
En la figura 6-2 muestra el comportamiento de cada Api Gateway en relación al tiempo de
contestación de 100 peticiones.
Figura 6-2: Respuesta de cada Api Gateway
Promedio Mı́nimo Máximo
Gateway NodeJS 126 4 2161
Gateway Spring Cloud 10 5 110
Gateway Spring Boot 15 9 45
Cuadro 6-1: Resumen de transaccionalidad para 100 peticiones http
En la obtención de resultados, se evidencia que el Api con mayor transaccionalidad en prome-
dio para 100 peticiones realizadas es el Gateway desarrollado con Spring Cloud. (ver figura
6-3)
En adición, el Api que contestó con mayor velocidad frente a los demás fue el Api Ga-
teway con nodeJS. (ver figura 6-4)
73
Figura 6-3: Promedio tiempos de respuesta para 100 peticiones
Figura 6-4: Tiempos Mı́nimo de respuesta para 100 peticiones
También fue el mismo Api que presentó menor transaccionalidad para una petición. (ver
figura 6-5)
74 6 Resultados y discusión
Figura 6-5: Tiempos Máximo de respuesta para 100 peticiones
Resultados con 500 Peticiones http
La figura 6-6 detalla el comportamiento de 500 peticiones env́ıadas a cada uno de los Api
Gateway.
Promedio Mı́nimo Máximo
Gateway NodeJS 256 22 1042
Gateway Spring Cloud 213 9 778
Gateway Spring Boot 185 18 850
Cuadro 6-2: Resumen de transaccionalidad para 500 peticiones http
De la figura 6-7, se puede ver que la tendencia es que el API Gateway orientado a objetos
con Spring Boot, es el que tiene mayor transaccionalidad.
Por otro lado, el API Gateway que presentó la respuesta en el menor tiempo posible, fue el
desarrollado con tecnoloǵıa Spring Cloud Gateway. (Ver figura 6-8)
Finalmente para 500 peticiones, el API Gateway que que vuelve a presentar mayor tiempo
en una de las respuestas el desarrollado con NodeJS, ver figura (6-9)
75
Figura 6-6: Respuesta de cada Api Gateway
Figura 6-7: Promedio tiempos de respuesta para 500 peticiones
76 6 Resultados y discusión
Figura 6-8: Tiempos Mı́nimo de respuesta para 500 peticiones
Figura 6-9: Tiempos Máximo de respuesta para 500 peticiones
77
Resultados con 1.000 Peticiones http
La figura 6-10 muestra los tiempos de respuesta para 1000 peticiones env́ıadas a cada uno
de los Api Gateway.
Figura 6-10: Respuesta de cada Api Gateway
Promedio Mı́nimo Máximo
Gateway NodeJS 1641 8 3044
Gateway Spring Cloud 1510 9 3373
Gateway Spring Boot 2124 46 3691
Cuadro 6-3: Resumen de transaccionalidad para 1.000 peticiones http
De las métricas obtenidas están muy similares pero se puede determinar que el API Gateway
empezó a tener tendencia lineal.
Los API’s Gateways que representan al paradigma reactivo, son los que presentarón ma-
yor transaccionalidad. (ver figura 6-11 - 6-13)
78 6 Resultados y discusión
Figura 6-11: Promedio tiempos de respuesta para 1.000 peticiones
Figura 6-12: Tiempos Mı́nimo de respuesta para 1.000 peticiones
79
Figura 6-13: Tiempos Máximo de respuesta para 1.000 peticiones
80 6 Resultados y discusión
Resultados con 5.000 Peticiones http
Según los datos arrojados, se muestra en la figura 6-14 los tiempos de respuesta para 5.000
peticiones env́ıadas a cada uno de los Api Gateway.
Figura 6-14: Respuesta de cada Api Gateway
Promedio Mı́nimo Máximo
Gateway NodeJS 2972 35 6483
Gateway Spring Cloud 466 4 2401
Gateway Spring Boot 1474 5 6603
Cuadro 6-4: Resumen de transaccionalidad para 5.000 peticiones http
Aunque en las figuras 6-15, 6-16, 6-17 el API Gateway desarrollado con NodeJS, presen-
ta una baja transaccionalidad; en la figura 6-14 muestra la siguiente tendencia: a mayor
número de peticiones empieza a decrecer los tiempos de respuesta, caso contrario pasa con
el desarrollo de Spring Boot, el cual empieza a formar tendencia lineal a mayor número de
peticiones.
Finalmente el desarrollo con Spring Cloud Gateway, es el que tiene la mayor transaccio-
nalidad, es decir que los tiempos de respuesta son menores ante un número elevado de
peticiones. (ver figura 6-6)
81
Figura 6-15: Promedio tiempos de respuesta para 5.000 peticiones
Figura 6-16: Tiempos Mı́nimo de respuesta para 5.000 peticiones
82 6 Resultados y discusión
Figura 6-17: Tiempos Máximo de respuesta para 5.000 peticiones
Caṕıtulo 7
Conclusiones
7.1. Verificación, contraste y evaluación de los objeti-
vos
A continuación se presentan algunas reflexiones que a partir del desarrollo del presente
trabajo se generaron, se realiza un análisis de sus objetivos.
Analizando la transaccionalidad de un Api Gateway desarrollado con el paradigma
orientado a objetos frente al paradigma reactivo, se logra determinar que gracias a la
arquitectura aśıncrona del paradigma, el API Gateway que tiene mayor transacciona-
lidad concurrente es el desarrollado con programación reactiva.
El paradigma orientado a objetos con Spring Boot, es una buena alternativa para hacer
software en donde el dominio