ANALISIS DEL RENDIMIENTO DE LA TRANSACCIONALIDAD EN …

1

ANALISIS DEL RENDIMIENTO DE LA TRANSACCIONALIDAD EN UNAPI GATEWAY DESARROLLADO CON EL PARADIGMA ORIENTADO A

OBJETOS FRENTE AL PARADIGMA REACTIVO

AutorJairo Edinson Viuche Madronero

Universidad Distrital Francisco Jose de CaldasFacultad de Ingenierıa

Especializacion en Ingenierıa de SoftwareBogota, Colombia

Ano 2019

2

ANALISIS DEL RENDIMIENTO DE LA TRANSACCIONALIDAD EN UNAPI GATEWAY DESARROLLADO CON EL PARADIGMA ORIENTADO A

OBJETOS FRENTE AL PARADIGMA REACTIVO

AutorJairo Edinson Viuche Madronero

Monografıa de gradoPresentada como requisito para optar al tıtulo de

Especialista en Ingenierıa de Software

DirectorDr. Roberto Ferro Escobar

RevisorMsc. John Freddy Parra

Universidad Distrital Francisco Jose de CaldasFacultad de Ingenierıa

Especializacion en Ingenierıa de SoftwareBogota, Colombia

Ano 2019

Indice de figuras

1-1. Arquitectura microservicios con Api Gateway . . . . . . . . . . . . . . . . . 71-2. Ejemplo de composicion de Api para un Api Gateway . . . . . . . . . . . . . 91-3. Arquitectura Api Gateway con multiples clientes . . . . . . . . . . . . . . . . 101-4. Clasificacion taxonomica de los vertebrados . . . . . . . . . . . . . . . . . . . 121-5. Caracterısticas de un sistema reactivo, y como se relacionan entre sı . . . . . 141-6. Relacion en una implementacion del flujo reactivo . . . . . . . . . . . . . . . 151-7. El zoo de los paradigmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161-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 . . . . . 253-2. Diagrama de secuencia Api Gateway con paradigma orientado a objetos . . . 263-3. Diagrama de componentes Api Gateway con paradigma orientado a objetos . 263-4. Diagrama de flujo de datos fısico . . . . . . . . . . . . . . . . . . . . . . . . 273-5. Diagrama de secuencia Api Gateway con paradigma reactivo . . . . . . . . . 273-6. Concurrencia api reactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4-1. Plataforma Jhipster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294-2. Ejemplo modelo de entidades microservicio en JDL Studio . . . . . . . . . . 304-3. Ejemplo lenguaje JDL en modelo de entidades para microservicio . . . . . . 314-4. Contenedores docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324-5. Documentacion Swagger para microservicio . . . . . . . . . . . . . . . . . . . 324-6. Documentacion detallada Swagger para microservicio . . . . . . . . . . . . . 334-7. Archivo app.js, ejecucion principal del Api Gateway . . . . . . . . . . . . . . 344-8. Archivo router.js, contenedor de los microservicios que se desean consumir . 354-9. Gateway adapter, cada microservicio realiza su uso . . . . . . . . . . . . . . 354-10.Configuracion de enrutamiento para cada microservicio, por servicio . . . . . 364-11.Configuracion de archivo pom.xml del servidor eureka . . . . . . . . . . . . . 374-12.Configuracion general del servidor . . . . . . . . . . . . . . . . . . . . . . . . 374-13.Clase principal de Spring boot, servidor eureka . . . . . . . . . . . . . . . . . 384-14.Dependencias pom.xml Api Gateway con spring cloud . . . . . . . . . . . . 384-15.Otras dependencias pom.xml Api Gateway con spring cloud . . . . . . . . . 394-16.Gateway Routing con spring cloud . . . . . . . . . . . . . . . . . . . . . . . 394-17.Servicio web, punto de entrada Api Gateway . . . . . . . . . . . . . . . . . . 40

4 INDICE DE FIGURAS

4-18.Accion para la optencion de url . . . . . . . . . . . . . . . . . . . . . . . . . 414-19.Transformador de url a request . . . . . . . . . . . . . . . . . . . . . . . . . 414-20.Consumo de servicio RestFul, microservicio . . . . . . . . . . . . . . . . . . . 414-21.Diagrama de despliegue de componentes del analisis . . . . . . . . . . . . . . 42

5-1. Logo Jirka It Solutions SAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 435-2. Metamodelo punto de vista de organizacion . . . . . . . . . . . . . . . . . . 455-3. Punto de vista de organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . 455-4. Metamodelo punto de vista cooperacion de actor . . . . . . . . . . . . . . . . 455-5. Punto de vista cooperacion de actor . . . . . . . . . . . . . . . . . . . . . . . 465-6. Metamodelo punto de vista de funcion de negocio . . . . . . . . . . . . . . . 465-7. Punto de vista de funcion de negocio . . . . . . . . . . . . . . . . . . . . . . 475-8. Metamodelo punto de vista de proceso de negocio . . . . . . . . . . . . . . . 475-9. Punto de vista de proceso de negocio . . . . . . . . . . . . . . . . . . . . . . 485-10.Metamodelo punto de vista de cooperacion de proceso de negocio . . . . . . 485-11.Punto de vista de cooperacion de proceso de negocio . . . . . . . . . . . . . 495-12.Metamodelo punto vista de producto . . . . . . . . . . . . . . . . . . . . . . 505-13.Punto vista de producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505-14.Metamodelo punto de vista de comportamiento de aplicacion . . . . . . . . . 515-15.Punto de vista de comportamiento de aplicacion . . . . . . . . . . . . . . . . 515-16.Metamodelo punto de vista de cooperacion de aplicacion . . . . . . . . . . . 525-17.Punto de vista de cooperacion de aplicacion . . . . . . . . . . . . . . . . . . 525-18.Metamodelo punto de vista de estructura de aplicacion . . . . . . . . . . . . 535-19.Punto de vista de estructura de aplicacion . . . . . . . . . . . . . . . . . . . 535-20.Metamodelo punto de vista de uso de aplicacion . . . . . . . . . . . . . . . . 545-21.Punto de vista de uso de aplicacion . . . . . . . . . . . . . . . . . . . . . . . 545-22.Metamodelo punto de vista de infraestructura . . . . . . . . . . . . . . . . . 555-23.Punto de vista de infraestructura . . . . . . . . . . . . . . . . . . . . . . . . 555-24.Metamodelo punto de vista de uso de infraestructura . . . . . . . . . . . . . 565-25.Punto de vista de uso de infraestructura . . . . . . . . . . . . . . . . . . . . 565-26.Metamodelo punto de vista de organizacion e implementacion . . . . . . . . 575-27.Punto de vista de organizacion e implementacion . . . . . . . . . . . . . . . 575-28.Metamodelo punto de vista de Estructura de Informacion . . . . . . . . . . . 585-29.Punto de vista de Estructura de Informacion . . . . . . . . . . . . . . . . . . 585-30.Metamodelo punto de vista de Realizacion del Servicio . . . . . . . . . . . . 595-31.Punto de vista de Realizacion del Servicio . . . . . . . . . . . . . . . . . . . 595-32.Punto de vista de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605-33.Metamodelo punto de vista de stakeholder . . . . . . . . . . . . . . . . . . . 615-34.Punto de vista de stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . 615-35.Metamodelo punto de vista de realizacion de objetivos . . . . . . . . . . . . 625-36.Punto de vista de realizacion de objetivos . . . . . . . . . . . . . . . . . . . . 625-37.Metamodelo punto de vista de contribucion . . . . . . . . . . . . . . . . . . 635-38.Metamodelo punto de vista de contribucion . . . . . . . . . . . . . . . . . . 635-39.Metamodelo punto de vista de principios . . . . . . . . . . . . . . . . . . . . 64

INDICE DE FIGURAS 5

5-40.Ejemplo punto de vista de principios . . . . . . . . . . . . . . . . . . . . . . 645-41.Metamodelo punto de vista de realizacion de Requerimientos . . . . . . . . . 645-42.Ejemplo punto de vista de realizacion de requerimientos . . . . . . . . . . . . 655-43.Metamodelo punto de vista de motivacion . . . . . . . . . . . . . . . . . . . 655-44.Ejemplo punto de vista de realizacion de requerimientos . . . . . . . . . . . . 665-45.Metamodelo punto de vista de proyecto . . . . . . . . . . . . . . . . . . . . . 665-46.Ejemplo punto de vista de proyecto . . . . . . . . . . . . . . . . . . . . . . . 675-47.Metamodelo punto de vista de migracion . . . . . . . . . . . . . . . . . . . . 675-48.Ejemplo punto de vista de migracion . . . . . . . . . . . . . . . . . . . . . . 685-49.Metamodelo punto de vista de migracion e implementacion . . . . . . . . . . 685-50.Punto de Vista de Migracion e Implementacion . . . . . . . . . . . . . . . . 69

6-1. Apache JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716-2. Respuesta de cada Api Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 726-3. Promedio tiempos de respuesta para 100 peticiones . . . . . . . . . . . . . . 736-4. Tiempos Mınimo de respuesta para 100 peticiones . . . . . . . . . . . . . . . 736-5. Tiempos Maximo de respuesta para 100 peticiones . . . . . . . . . . . . . . . 746-6. Respuesta de cada Api Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 756-7. Promedio tiempos de respuesta para 500 peticiones . . . . . . . . . . . . . . 756-8. Tiempos Mınimo de respuesta para 500 peticiones . . . . . . . . . . . . . . . 766-9. Tiempos Maximo de respuesta para 500 peticiones . . . . . . . . . . . . . . . 766-10.Respuesta de cada Api Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 776-11.Promedio tiempos de respuesta para 1.000 peticiones . . . . . . . . . . . . . 786-12.Tiempos Mınimo de respuesta para 1.000 peticiones . . . . . . . . . . . . . . 786-13.Tiempos Maximo de respuesta para 1.000 peticiones . . . . . . . . . . . . . . 796-14.Respuesta de cada Api Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 806-15.Promedio tiempos de respuesta para 5.000 peticiones . . . . . . . . . . . . . 816-16.Tiempos Mınimo de respuesta para 5.000 peticiones . . . . . . . . . . . . . . 816-17.Tiempos Maximo de respuesta para 5.000 peticiones . . . . . . . . . . . . . . 82

Indice de cuadros

6-1. Resumen de transaccionalidad para 100 peticiones http . . . . . . . . . . . . 726-2. Resumen de transaccionalidad para 500 peticiones http . . . . . . . . . . . . 746-3. Resumen de transaccionalidad para 1.000 peticiones http . . . . . . . . . . . 776-4. Resumen de transaccionalidad para 5.000 peticiones http . . . . . . . . . . . 80

Contenido

Introduccion 2

I Contextualizacion de la investigacion 3

1. Descripcion de la investigacion 41.1. Planteamiento/Identificacion del problema . . . . . . . . . . . . . . . . . . . 41.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3. Justificacion del trabajo/investigacion . . . . . . . . . . . . . . . . . . . . . . 61.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5. Marco referencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5.1. Marco teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5.2. Marco conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.6. Metodologıa de la investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 171.7. Organizacion del trabajo de grado . . . . . . . . . . . . . . . . . . . . . . . . 181.8. Estudio de sistemas previos . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

II Desarrollo de la investigacion 22

2. Analisis del sistema 232.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3. Diseno de Api Gateway 253.1. Paradigma orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2. Paradigma reactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4. Construccion e Implementacion 294.1. Microservicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2. Api Gateway Reactivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1. Api Gateway NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.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 435.1. Organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2. Punto de vista del negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3. Punto de vista de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 505.4. Punto de vista tecnologico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5. Punto de vista motivacional . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.6. Punto de vista implementacion y migracion . . . . . . . . . . . . . . . . . . 66

III Cierre de la investigacion 70

6. Resultados y discusion 71

7. Conclusiones 837.1. Verificacion, contraste y evaluacion de los objetivos . . . . . . . . . . . . . . 837.2. Sıntesis del modelo propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 837.3. Aportes originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8. Prospectiva del trabajo de grado 858.1. Lıneas de investigacion futuras . . . . . . . . . . . . . . . . . . . . . . . . . . 858.2. Trabajos de Investigacion futuros . . . . . . . . . . . . . . . . . . . . . . . . 85

Bibliografıa 87

Referencias web 89

2 CONTENIDO

Introduccion

Este proyecto tiene como objetivo recabar informacion y formular una hipotesis acerca de latransaccionalidad en el componente API Gateway desarrollado con el paradigma orientadoa objetos frente al paradigma reactivo. El componente Api Gateway es un patron que bus-ca solucionar la forma que los diferentes clientes tratan de acceder a los microservicios delBanckend.

Las aplicaciones con arquitectura a microservicios, han optado por incluir este patron ensu arquitectura y como es el caso de Netflix ha sido conveniente, puesto que ofrecen un APIde 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 excepcion, las aplicaciones en su mayorıa usan la pro-gramacion orientada a objetos, brindando buenas soluciones para lo que fueron construidas.Sin embargo, en los ultimos anos viene emergiendo el paradigma reactivo, el cual es unabuena alternativa por su manejo de recursos fısicos.

Segun la literatura sobre arquitectura de software actual, es conveniente que para el desa-rrollo de aplicacion con una alta concurrencia, el paradigma elegido sea el reactivo, porqueque ası cada flujo tiene un manejo independiente, lo que puede llevar a que haya un serviciode atencion mucho mas rapido.

Con el presente analisis lo que se busca es encontrar diferencias entre uno de los para-digma mas usados, puede ser el mas usado, y el paradigma que esta emergente y que en laliteratura recomienda, adicional a esto se realizara con diversas librerıas de programacionreactiva para dar peso a la conclusion.

Parte I

Contextualizacion de la investigacion

Capıtulo 1

Descripcion de la investigacion

1.1. Planteamiento/Identificacion del problema

El patron Api Gateway ha demostrado ser conveniente para aplicaciones basadas en micro-servicios. Si no se tiene un Api Gateway, las aplicaciones clientes deben enviar solicitudesdirectamente 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. Actua como un proxy inverso, enrutando las solicitudes de los clientes a los servicios.Tambien puede proporcionar caracterısticas transversales adicionales como autenticacion,terminacion SSL y cache.

Por otro lado en los ultimos anos; el paradigma de la programacion reactiva ha recibidouna mayor atencion, ya que cada vez mas aplicaciones se han vuelto impulsadas por eventos[4, 1]. El paradigma gira en torno a la propagacion del cambio para variables que varıancontinuamente en el tiempo. En otras palabras, el paradigma gira en torno al procesamientoasıncrono de flujo de datos sin bloqueo. Este paradigma adopta un enfoque declarativo quepermite a los desarrolladores especificar que hacer, pero esta dejando el tiempo de ejecucional lenguaje [4].

Al mismo tiempo, la programacion orientada a objetos es un paradigma que posiblemen-te sea el mas ampliamente utilizados hoy en dıa, trata los datos como objetos con atributosy metodos que pueden aplicarse a estos objetos y tambien ser heredados por otros objetos.

En la actualidad, hay afirmaciones que a las aplicaciones con paradigma orientado a objetoscuando se les han realizado pruebas tanto de concepto como de carga, han evidenciado que apesar de tener una respuesta aceptable en una cantidad mediana de usuarios y operacionesmedianamente complejas, la capacidad del sistema se degrada de manera rapida al empezara tener mas usuarios concurrentes (alrededor de 1000 usuarios al mismo tiempo) [Web17].Es difıcil encontrar documentacion a cerca de un API Gateway haya sido desarrollado conprogramacion orientada a objetos, ¿a que se debe este fenomeno?, las limitaciones que semencionaron anteriormente ¿impactan la atencion de solicitudes en este componente?, ¿Que

1.2 Objetivos 5

diferencias tiene la programacion reactiva frente a la programacion orientada a objetos?

Formulacion del problema

Para un componente API Gateway de la arquitectura de microservicios desarrollado bajoel paradigma orientado a objetos y el mismo componente desarrollado bajo el paradigmareactivo, ¿Que API tiene mayor ındice de atencion a las peticiones enviadas en un lapso detiempo dado?

Sistematizacion del problema

¿Como proveer los API Gateways que seran objetos de estudio, en donde se determinaracual tiene mayor rendimiento en su transaccionalidad?

¿Como se obtendran los datos de la transaccionalidad de cada API Gateway para npeticiones en un lapso de tiempo dado?

¿Como demostrar que API Gateway tiene mayor ındice de atencion a sus peticionesenviadas?

1.2. Objetivos

1.2.1. Objetivo General

Analizar el rendimiento de la transaccionalidad en un API Gateway desarrollado con elparadigma orientado a objetos frente al paradigma reactivo, determinando que paradigmatiene mayor ındice de atencion.

1.2.2. Objetivos especıficos

Desarrollar el API Gateway mediante las tecnologıas Spring Cloud y NodeJS para elparadigma Reactivo y por parte del paradigma orientado a objetos con Java; los cualesseran objetos de estudio.

Obtener los datos de la transaccionalidad de cada API Gateway con la ayuda de laherramienta: Apache JMeter; para n peticiones en un lapso de tiempo determinado,en donde n esta en unidades de mil; estos datos representan a cada paradigma usadoen el desarrollo del API.

Clasificar los paradigmas de acuerdo al nivel de transaccionalidad del API, determi-nados por la comparacion de resultados; el orden de la clasificacion es el numero depeticiones atendidas en un tiempo dado, de mayor a menor.

6 1 Descripcion de la investigacion

1.3. Justificacion del trabajo/investigacion

En la actualidad las aplicaciones con arquitectura a microservicios estan en su pleno auge,esto se debe a que han solventado varios inconvenientes comunes que presentan las aplica-ciones monolıticas. Entre algunas ventajas se tienen: Servicios pequenos e independientes(principio de responsabilidad unica), unidades de despliegue pequenas, reduccion en tiemposde desarrollo, agilidad en hot fixes, multitecnologıa, facil escalado horizontal.

El patron Api Gateway nace en respuesta a como deberıan los clientes de una aplicacionbasada a microservicios acceder a los servicios individuales, porque estos sistemas necesi-tan mucha informacion que se distribuye en varios servicios dentro del catalogo de servicios[Web14]. Ademas, muchos tipos de clientes consumen los servicios del sistema, agregandomas complejidad a las soluciones finales; cuando comenzamos a pensar en la evolucion deesos servicios, respetando las comunicaciones y el intercambio de tamano/formato de datospara cada uno de esos clientes; de esta manera, los servicios deben poder ”hablarcon cadauno de estos clientes (y ser facilmente detectables) sin perder los requisitos no funcionalesde rendimiento, mantenimiento, escalabilidad, seguridad y disponibilidad necesarios para so-portar estas soluciones distribuidas [Web14].

Las aplicaciones microservicios con el patron API Gateway estan orientadas para tener unaalta concurrencia, como es el caso de Netflix, por tal motivo la literatura se centra en unenfoque 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 opcion.

Con la realizacion del analisis de la transaccionalidad en el Api Gateway bajo el para-digma orientado a objetos frente al paradigma reactivo, lo que se pretende es determinarque paradigma tiene mejor atencion de solicitudes. Este analisis es una contribucion para lasaplicaciones basadas en arquitectura microservicios y por ende al desarrollo de software.

1.4 Hipotesis 7

1.4. Hipotesis

Con el analisis de la transaccionalidad en el API Gateway desarrollado bajo el paradigmareactivo frente al paradigma orientado a objetos, para la funcionalidad de “mostrar regalo”de la aplicacion microservicios seloreglo.com; se determinara que para el alto numero desolicitudes concurrentes, el API Gateway desarrollado con programacion reactiva responderamayor numero de peticiones en un tiempo dado.

1.5. Marco referencial

1.5.1. Marco teorico

El patron Api Gateway

Un API Gateway es un servicio que es el unico punto de entrada para las solicitudes deAPI en una aplicacion desde fuera del firewall. Es similar al patron de fachada del disenoorientado a objetos. Como una fachada, un Api Gateway encapsula la arquitectura interna dela aplicacion y la proporciona a sus clientes. Tambien podrıa tener otras responsabilidades,tales como autenticacion, monitoreo y limitacion de velocidad. La figura 1-1 muestra larelacion 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 composicion de API yla traduccion de protocolos. Todas las solicitudes de clientes externos primero van al API


Gateway. Este encamina algunas solicitudes al servicio apropiado y da manejo a otras solici-tudes usando el patron de composicion de API e invocando multiples servicios y agregandolos resultados. Tambien actua como traductor entre protocolos amigables para el cliente,como HTTP y WebSockets, y los protocolos hostiles para el cliente que son utilizados porlos 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 lassolicitudes al servicio correspondiente. Cuando recibe una solicitud, el API Gateway consul-ta un mapa de enrutamiento que especifica a que servicio enrutar la solicitud. Un mapa deenrutamiento podrıa, por ejemplo, asignar un metodo HTTP y una ruta a la URL HTTPde un servicio. Esta funcion es identica a las funciones de proxy inverso proporcionadas porservidores web como NGINX [7] .

Composicion Api Un API Gateway normalmente hace mas que un proxy inverso. Tam-bien podrıa implementar algunas operaciones de API utilizando la composicion. Como semuestra en la Figura 1-2, la aplicacion movil realiza una solicitud al API Gateway, queobtiene los detalles del pedido de multiples servicios.

Traduccion del Protocolo Un API Gateway tambien puede realizar la traduccion delprotocolo. Puede proporcionar una API RESTful a clientes externos, aunque los serviciosde la aplicacion utilizan una combinacion de protocolos que incluyen internamente REST ygRPC. Cuando sea necesario, la implementacion de algunas operaciones de API se traduceentre la API externa RESTful y las API internas basadas en gRPC [7].

El API Gateway proporciona para cada cliente un API especıfico Un API Ga-teway podrıa proporcionar una unica API de talla unica para todos (OSFA). El problemacon una unica API es que los diferentes clientes a menudo tienen diferentes requisitos. Porejemplo, una aplicacion de terceros puede requerire que la operacion de obtencion de detallesde pedidos de la API devuelva los detalles completos de los pedidos, mientras que un clientemovil solo necesita un subconjunto de los datos. Una forma de resolver este problema es dara los clientes la opcion de especificar en una solicitud que campos y objetos relacionadosdebe devolver el servidor. Este enfoque es adecuado para una API publica que debe servira una amplia gama de aplicaciones de terceros, pero a menudo no proporciona a los clientesel control que necesitan [7].Un mejor enfoque es que el API Gateway proporcione a cada cliente su propia API. Porejemplo, se podrıa tener diferentes API para las aplicaciones moviles de Android e iPhone.

Arquitectura Api Gateway

Un API Gateway tiene una arquitectura modular en capas. Su arquitectura, que se muestraen la Figura 1-3. Arquitectura API Gateway con multiples clientes, consta de dos capas, lacapa API y una capa comun.

1.5 Marco referencial 9

Figura 1-2: Ejemplo de composicion de Api para un Api Gateway

La capa API consta de uno o mas modulos independientes. Cada modulo implementauna API para un cliente en particular. La capa comun implementa una funcionalidadcompartida que incluye funciones de borde como la autenticacion.En este ejemplo, el API Gateway tiene tres modulos:

Mobile API: Implementa el Api de servicios para clientes Moviles.

Browser API: El cual implementa el API para aplicaciones Javascript ejecutadas porun 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 APIGateway es que encapsula la estructura interna de la aplicacion. En lugar de tener queinvocar servicios especıficos, los clientes hablan con el API. Este proporciona a cada cliente


Figura 1-3: Arquitectura Api Gateway con multiples clientes

una API especıfica para cliente. Esto reduce el numero de viajes de ida y vuelta entre elcliente y la aplicacion. Tambien simplifica el codigo del cliente [7].

Inconvenientes de un Api Gateway El patron API Gateway tambien tiene algunosinconvenientes. 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 cuellode botella de desarrollo. Los desarrolladores deben actualizar el API Gateway para exponerla API de sus servicios. Es importante que el proceso para actualizarlo sea lo mas liviano po-sible. De lo contrario, los desarrolladores se ven obligados a esperar en lınea para actualizarel 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 transmision deNetflix esta disponible en cientos de diferentes tipos de dispositivos, incluidos televisores, re-productores de Blu-ray, telefonos inteligentes, etc. Inicialmente, Netflix intento tener un APIde estilo unico para su servicio de transmision. Desafortunadamente, pronto descubrieronque 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 paracada dispositivo.

En la primera version del API Gateway de Netflix, cada equipo de clientes implementosu API utilizando scripts Groovy que realizan enrutamiento y composicion de API. Cadasecuencia de comandos invoco una o mas API de servicio utilizando las bibliotecas de clien-


te Java proporcionadas por los equipos de servicio. Por un lado, esto funciona bien y losdesarrolladores de clientes han escrito mas de miles de scripts. El API Gateway de Netflixmaneja miles de millones de solicitudes por dıa; en promedio, cada API llama a los fanaticosa seis o siete servicios de back-end. Netflix ha encontrado que esta arquitectura monolıticaes algo incomoda.

Como resultado, Netflix ahora se esta moviendo a una arquitectura de API Gateway que essimilar a los Backends para los patrones front-end. En esta nueva arquitectura, los equiposde clientes escriben modulos API utilizando NodeJS. Cada modulo API ejecuta su propiocontenedor Docker. Los scripts no invocan los servicios directamente. En su lugar, invocanun segundo “API Gateway”, que expone las API de servicio utilizando Netflix Falcor. NetflixFalcor es una tecnologıa de API que realiza una composicion de API dinamica y declarativa,y permite a un cliente invocar multiples servicios utilizando una sola solicitud. Esta nuevaarquitectura tiene una serie de beneficios. Los modulos API estan aislados entre sı, lo quemejora la confiabilidad y la capacidad de observacion. Ademas, el modulo API del cliente esescalable de forma independiente.

Programacion Orientada a Objetos

Un programa orientado a objetos (OOP) se ve como una coleccion 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, procesardatos y enviar mensajes a otros objetos. Cada objeto puede verse como una “maquina”independiente con una funcion o responsabilidad distinta. Las acciones o metodos en estosobjetos estan estrechamente asociados con el objeto [6].

Clase Una clase, es simplemente una abstraccion que hacemos de nuestra experiencia sen-sible. El ser humano tiende a agrupar seres o cosas -objetoscon caracterısticas similares engrupos -clases-. Ası, aun cuando existen por ejemplo multitud de vasos diferentes, podemosreconocer un vaso en cuanto lo vemos, incluso aun cuando ese modelo concreto de vaso no lohayamos visto nunca. El concepto de vaso es una abstraccion de nuestra experiencia sensible.Quizas el ejemplo mas claro para exponer esto lo tengamos en las taxonomıas; los biologoshan dividido a todo ser (vivo o inerte) sobre la tierra en distintas clases [5] . Tomemos comoejemplo una pequena porcion del inmenso arbol taxonomico: Ellos, llaman a cada una deestas parcelas reino, tipo, clase, especie, orden, familia, genero, etc.; sin embargo, nosotrosa todas las llamaremos del mismo modo: clase. Ası, hablaremos de la clase animal, clasevegetal y clase mineral, o de la clase felidos y de las clases leo (leon) y tigris (tigre). Cadaclase posee unas cualidades que la diferencian de las otras. Ası, por ejemplo, los vegetales sediferencian de los minerales -entre otras muchas cosas- en que los primeros son seres vivos ylos minerales no. De los animales se diferencian en que las plantas son capaces de sintetizarclorofila a partir de la luz solar y los animales no [5].

Objeto En OOP, un objeto es un conjunto de datos y metodos como imaginamos quese habra quedado igual, le vamos a dar mas pistas [5].


Figura 1-4: Clasificacion taxonomica de los vertebrados

Los datos son lo que antes hemos llamado caracterısticas o atributos, los metodos son loscomportamientos que pueden realizar [5].

Lo importante de un sistema OOP es que ambos, datos y metodos estan tan intrınseca-mente ligados, que forman una misma unidad conceptual y operacional. En OOP, no sepueden desligar los datos de los metodos de un objeto. Ası es como ocurre en el mundo real[5].

Herencia Esta es la cualidad mas importante de un sistema OOP, la que nos dara mayorpotencia y productividad, permitiendonos ahorrar horas y horas de codificacion y de depu-racion de errores.

Las cualidades comunes que comparten distintas clases, pueden y deben agruparse paraformar una clase padre -tambien llamada superclase-. Por ejemplo, usted podrıa derivar lasclases presupuesto, albaran y factura de la superclase pedidos, ya que estas clases compartencaracterısticas comunes. De este modo, la clase padre poseerıa los metodos comunes a todasellas y solo tendrıamos que anadir aquellos metodos propios de cada una de las subclases,pudiendo reutilizar el codigo escrito en la superclase desde cada una de las clases deriva-das. Ası, si ensenamos a la clase padre a imprimirse, cada uno de los objetos de las clasesinferiores sabra automaticamente y sin escribir ni una solo lınea mas de codigo imprimirse[5].


Encapsulamiento Hay muchos datos que no tiene por que conocerlo aquel que este usan-do la clase X; ya que son inherentes al objeto y solo controlan su funcionamiento interno.

Esto es la encapsulacion u ocultacion; hacer las variables que son innecesarias para el trata-miento del objeto pero necesarias para su funcionamiento privadas, ası como las funcionesque no necesitan interaccion del usuario o que solo pueden ser llamadas por otras funcionesdentro del objeto (como por ejemplo, palpitar) [5].

La encapsulacion 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 reglasde la ingenieria del software) [5].

Formas de encapsular:

Abierto: hace que el miembro de la clase pueda ser accedido desde el exterior de laClase 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 pararesponder 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 como hacerlo y realizara este comporta-miento a su modo.

Veamos otro ejemplo algo mas ilustrativo. Tomemos las clases barco, avion y coche, to-das ellas derivadas de la clase padre vehıculo; si les enviamos el mensaje Desplazate, cadauna de ellas sabe como hacerlo.

Realmente, y para ser exactos, los mensaje no se envıan a las clases, sino a todos o algunosde los objetos instanciados de las clases. Ası, por ejemplo, podemos decirle a los objetosJuan Sebastian el Cano y Kontiqui, de la clase barco que se desplacen, con los que el restode los objetos de esa clase permaneceran inmoviles.

Paradigma reactivo

Sistemas Reactivos

En 1985, Harel y Puneli propusieron dos categorıas de sistemas [3, 4]. Hicieron una distin-cion entre sistemas transformacionales y reactivos. Un sistema de transformacion se definecomo un sistema que responde a la entrada transformandolo y luego produciendo salidas. Lanaturaleza es que estos sistemas procesan la entrada y producen la salida de vez en cuando.


Sin embargo, los sistemas reactivos se definen como sistemas que responden continuamentea las entradas. Harel y Puneli tambien senalan que los sistemas reactivos estan presentes entodas partes, desde automoviles hasta telefonos. La reactividad puede ser incluida por soft-ware o chips, por ejemplo. Tanto los sistemas transformacionales como los reactivos puedenser sıncronos o asıncronos.

El centro de mayor atencion para la programacion reactiva esta especialmente en combinar laprogramacion reactiva y la distribucion. Buenos ejemplos para la combinacion de programa-cion reactiva y distribucion son las aplicaciones web y las aplicaciones moviles distribuidas.Un inconveniente conocido de la combinacion de programacion reactiva y distribucion esque puede provocar fallas [1, 4]. Evitar fallos es un factor a considerar cuando se utiliza laprogramacion reactiva. Es mas difıcil evitarlos en los sistemas distribuidos debido a los pro-blemas de la red, como la latencia. La combinacion de programacion reactiva y distribuciona menudo se denomina programacion reactiva distribuida o microservicios reactivos.

Figura 1-5: Caracterısticas de un sistema reactivo, y como se relacionan entre sı

Programacion reactiva

En la comunidad Java, el paradigma de la programacion reactiva ha logrado cada vez masatencion en los ultimos anos. Las bibliotecas reactivas como Project Reactor y RxJava y laintroduccion de un estandar reactivo en la API de Java 9 han contribuido al mayor interesen la programacion reactiva en Java.Esta programacion se trata de flujos de datos y propagacion de cambios. Para aplicacionesdirigidas por eventos, este paradigma es adecuado. Sin embargo, centrandose principalmenteen el paradigma de la programacion reactiva funcional [1, 4].

La programacion reactiva reside dentro del paradigma de la programacion declarativa. En


contraste con la programacion imperativa, donde el desarrollador usa declaraciones paracambiar el estado de un programa, en la programacion declarativa el desarrollador defineque hacer, pero el tiempo de ejecucion lo maneja el propio programa [1, 4].

Programacion Reactiva vs Sistemas Reactivos

La diferencia entre la programacion reactiva y los sistemas reactivos estan en sus aplicaciones.La programacion reactiva se aplica a la logica interna de los componentes, mientras que lossistemas se aplican a nivel arquitectonico para los sistemas. Las aplicaciones que implementanla programacion reactiva son altamente controladas por eventos, lo que significa que son estoslos que impulsan la ejecucion en lugar de un hilo de ejecucion. La programacion reactivafacilita el desacoplamiento en el tiempo y, por lo tanto, la concurrencia. Los sistemas reactivosson altamente impulsados por mensajes. Los sistemas facilitaron el acoplamiento en el espacioy por lo tanto la distribucion.

Figura 1-6: Relacion en una implementacion 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 orıgenes de eventosdireccionables y el mensaje se define como destinatarios direccionables. Esto significa que lossuscriptores en un sistema controlado por eventos se adjuntan a los editores, mientras queen un sistema dirigido por mensajes, los suscriptores esperan que los mensajes lleguen sin lanecesidad de adjuntarlos al editor.

1.5.2. Marco conceptual

Paradigma

Un paradigma de programacion indica un metodo de realizar computos y la manera en quese deben estructurar y organizar las tareas que debe llevar a cabo un programa [8].

Los paradigmas fundamentales estan asociados a determinados modelos de computo.


Tambien se asocian a un determinado estilo de programacion.

Los lenguajes de programacion suelen implementar, a menudo de forma parcial, varios pa-radigmas [8].

Figura 1-7: El zoo de los paradigmas

Patron

Los patrones son disciplinas de la Ingenierıa de Software que facilitan la reutilizacion deldiseno y de la arquitectura. Son soluciones de problemas conocidos en la programacion.No es obligatorio usar patrones pero reinventar la rueda en situaciones similares facilitancatalogos de elementos reusables, evitar reiteraciones, formular un vocabulario comun entreprogramadores, estandarizar el diseno y facilitar el aprendizaje de los nuevos programadores[Web2].

Arquitectura software

La arquitectura de software es un tema creciente de la ingenierıa de software para ayudar alas personas a resolver problemas. Con el, los disenadores o gerentes de proyectos tienen laoportunidad de supervisar el estado del software en un alto nivel. Ademas, la arquitecturadel software puede reutilizarse, lo que permite ahorrar enormes costos y reducir los riesgosdentro de los procesos de desarrollo y las actividades posteriores, incluido el diseno de mo-delos, la implementacion, las pruebas, la evaluacion, el mantenimiento y la evolucion [Web1].

1.6 Metodologıa de la investigacion 17

Sin embargo, el seguimiento de la arquitectura del software es difıcil, porque siempre seesconde detras de lo que se puede tocar. Visualizarlo requiere un profundo conocimiento dela informacion global de los sistemas, ası como excelentes habilidades y metodos. Las per-sonas de diferentes organizaciones o empresas utilizan diferentes estrategias para manejarlo,pero la mayorıa de ellas tiene algo en comun. El resumen y el sol de estas experiencias se hanconvertido en la base de la ciencia de la arquitectura de software en la actualidad [Web1].

Servicio web

Un servicio web realiza una tarea especıfica o un conjunto de tareas. La descripcion deservicio proporciona todos los detalles necesarios para interactuar con el servicio, incluidoslos formatos de mensaje (que detallan las operaciones), los protocolos de transporte y laubicacion [Web6].

1.6. Metodologıa de la investigacion

Tipo de estudio

El nivel de profundidad que aborda este proyecto, es el tipo de confirmatorio. Ya quela intencion de este analisis es determinar que paradigma tiene un mayor rendimiento en laatencion de solicitudes en un API Gateway para un tiempo determinado.

El nivel en la investigacion holıstica es la Integrativa y el holotipo de investigacion esconfirmatoria . Porque se verificara y demostrara con datos la conclusion final del presentetrabajo.

Metodo de investigacion

En aras de obtencion de la respuesta planteada en la formulacion del problema, es necesarioestablecer un procedimiento riguroso de manera organizada. Por lo anterior, se define comometodo de investigacion el Metodo Cuantitativo, en donde a partir de diversas medicionesen la transaccionalidad del API Gateway, se encontraran diferencias entre paradigmas deprogramacion.

Fuentes y tecnicas para recoleccion de la informacion

Las fuentes a los que se acudio para el marco referencial son:

Documentacion: Se reviso literatura tanto internet, tesis online, sistema BDigital (Bi-blioteca Digital) de la universidad Distrital Francisco Jose de Caldas, Trabajos de gradoexpuestos en RIUD (Repositorio Institucional) de la universidad Distrital Francisco Jose deCaldas.


1.7. Organizacion del trabajo de grado

El trabajo realizado para el presente proyecto inicia con la Contextualizacion de la in-vestigacion, en donde se puede identificar el planteamiento del problema, definicion de lajustificacion, los objetivos para la investigacion, hipotesis, marco referencial, metodologıa yestudio de sistemas previos.

En una segunda parte, se puede econtrar el Desarrollo de la investigacion, la cual lacompone los siguientes capıtulos:

Fase de Analisis: Se realizo identificacion de tecnologıas y requerimientos de un ApiGateway.

Fase de diseno: Modelamiento de cada Api Gateway mediante UML, y se acompanael uso del componente en aplicaciones con microservicios mediante el uso de ADM-Archimate.

Fase de construccion: Se muestra la implementacion de cada uno de los Api Gatewayhaciendo uso de los microservicios.

Fase de pruebas: Se realizan consumos de los servicios expuestos por cada Api Gatewaymediante herramientas de analisis de peticiones RestFul.

Para el cierre de la investigacion, se presenta una muestreo de la recoleccion de datos paracada Api Gateway, orientado a objetos y reactivo; se presenta el comportamiento de cadaApi Gateway mediante graficas estadısticas y se realiza comparacion 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 hipotesis planteada.

1.8. Estudio de sistemas previos

Hace aproximadamente un ano, el equipo de API de Netflix comenzo a redisenar la API paramejorar el rendimiento y permitir que los equipos de ingenierıa de UI en Netflix optimicen lasaplicaciones de cliente para dispositivos especıficos. Las filosofıas del rediseno se introdujeronen una publicacion anterior acerca de abarcar las diferencias entre los diferentes clientes ydispositivos [Web5].

Netfilx ademas de: Disminuir el numero de llamados, distribuir el desarrollo de la API,mitigar los riesgos de implementacion, Soporta multiples idiomas, distribuir operaciones,tambien presento su arquitectura [Web5].

1.8 Estudio de sistemas previos 19

Arquitectura

Para lograr los objetivos por encima de nuestra arquitectura destilada en algunos puntosclave:

Tiempo de ejecucion polıglota dinamico.

capa de servicio totalmente asıncrono.

Modelo de programacion reactiva.

El siguiente diagrama, Figura 1-8 y las siguientes anotaciones explican la arquitectura:

Figura 1-8: Arquitectura en Api de Netflix

1. Endpoints dinamicos Todos los nuevos puntos finales de servicios web ahora se defi-nen dinamicamente en tiempo de ejecucion. Cada equipo cliente puede desarrollar, probar,canarear e implementar nuevos puntos finales sin coordinacion (a menos que dependan de lanueva funcionalidad de la capa de servicio API subyacente que se muestra en el elemento 5,en cuyo caso tendrıan que esperar hasta que se implementen los cambios antes de presionarsu punto final) [Web5].


2. Administracion y gestion de codigos Endpoint El codigo de punto final se publicaen un cluster multirregional de Cassandra (replicado globalmente) a traves de una APIRESTful Endpoint Management utilizada por los equipos de clientes para administrar suspuntos finales [Web5].

3. Lenguaje Runtime JVM polıglota dinamico Se puede admitir cualquier lenguajeJVM 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 defunciones de primera clase (cierres), sintaxis de lista / diccionario, rendimiento y capacidadde depuracion fueron todos aspectos de nuestra decision. Ademas, Groovy proporciona unasintaxis comoda para una amplia gama de desarrolladores, lo que ayuda a reducir la curvade aprendizaje del primer idioma en la plataforma [Web5].

4 y 5 API Java Asıncrona + modelo de programacion reactiva Adoptar la concu-rrencia fue un requisito clave para lograr mejoras de rendimiento, pero abstraer los detallesde implementacion de ejecucion paralela y seguridad de subprocesos de los desarrolladoresclientes fue igualmente importante para reducir la complejidad y acelerar su tasa de inno-vacion. El primer paso fue hacer que la API de Java fuera totalmente asıncrona, ya quepermite que las implementaciones de los metodos subyacentes controlen si algo se ejecutasimultaneamente o no, sin que cambie el codigo del cliente. Elegimos un modelo de pro-gramacion reactivo con un estilo de programacion funcional para manejar la composicion ylos flujos condicionales de devoluciones de llamada asıncronas. Nuestra implementacion estamodelada a partir de Rx Observables [Web5].

6. Tolerancia a fallos de Hystrix Como hemos descrito en una publicacion anterior,todas las llamadas de servicio a los sistemas de back-end se realizan a traves de la capade tolerancia a fallos Hystrix (que se abrio recientemente, junto con su panel de control)que aısla los puntos finales dinamicos y la capa de servicio API de los inevitables fallos queOcurre mientras se ejecutan miles de millones de llamadas de red cada dıa desde la API alos sistemas backend [Web5].

La capa Hystrix es intrınsecamente multihilo debido a su uso de subprocesos para aislardependencias y, por lo tanto, se aprovecha para la ejecucion simultanea de llamadas de blo-queo a sistemas backend. Estas solicitudes asıncronas se componen juntas a traves del marcoreactivo [Web5].

7. Backend Services y Dependencias La Capa de servicios API abstrae todos losservicios de fondo y dependencias detras de las fachadas. Como resultado, el codigo de puntofinal accede a la “funcionalidad” en lugar de a un “sistema”. Esto nos permite cambiar lasimplementaciones y la arquitectura subyacentes sin impacto o con un impacto limitado enel codigo que depende de la API. Por ejemplo, si un sistema backend se divide en 2 serviciosdiferentes, o 3 se combinan en uno solo, o una llamada de red remota se optimiza en uncache en memoria, ninguno de estos cambios deberıa afectar el codigo 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 acoplamientoscerrados similares se abstraen y no se les permite “filtrarse” en el codigo del punto final[Web5].

Parte II

Desarrollo de la investigacion

Capıtulo 2

Analisis del sistema

En una arquitectura de microservicios, un cliente puede interactuar con mas de un servicio defrontEnd. Dado este hecho, ¿como sabe un cliente a que puntos finales llamar? ¿Que sucedecuando se introducen nuevos servicios o se refactorizan los servicios existentes? ¿Como ma-nejan los servicios la terminacion SSL, la autenticacion y otras inquietudes? El Api Gatewayque se propone a continuacion 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. Actua como un proxy inverso,enrutando las solicitudes de los clientes a los servicios. Tambien puede realizar varias tareastransversales, como la autenticacion, la terminacion SSL y la limitacion de velocidad. Si nose despliega un API Gateway, los clientes deben enviar las solicitudes directamente a losservicios.

24 2 Analisis 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 queno las necesite todas. Las funciones que cumpliran cada Api desarrollado cumplen con lossiguientes patrones de diseno que seran los requerimientos:

2.1. Requerimientos

Gateway Routing Uso del Gateway como un proxy inverso para enrutar las solicitudes auno o mas servicios de backEnd. La puerta de enlace proporciona un unico punto final paralos clientes y ayuda a desvincular a los clientes de los servicios.

Gateway Aggregation Utiliza el Gateway para agregar varias solicitudes individualesen una sola solicitud. Este patron se aplica cuando una sola operacion requiere llamadasa multiples servicios backend. El cliente envıa una solicitud al Gateway. El Gateway envıasolicitudes a los diversos servicios de backEnd, y luego agrega los resultados y los envıa devuelta 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 utilconsolidar estas funciones en un solo lugar, en lugar de hacer que cada servicio sea responsa-ble de implementarlas. Esto es particularmente cierto para las caracterısticas que requierenhabilidades especializadas para implementarse correctamente, como la autenticacion y la au-torizacion.

Estos son algunos ejemplos de la funcionalidad que se podrıa descargar en un Gateway:

Terminacion SSL.

Autenticacion.

Cache de respuestas.

Capıtulo 3

Diseno de Api Gateway

En el presente capıtulo se presentan los disenos del API Gateway desarrollados bajo elparadigma orientado a objetos y el reactivo respectivamente. Se hace uso de diagramas queel autor considera representativos para la monografıa.

3.1. Paradigma orientado a objetos

En funcion del desarrollo del Api Gateway usando el paradigma orientado a objetos se usanlos diagramas de clases, secuencia y componentes para resaltar su diseno.

Figura 3-1: Diagrama de clases Api Gateway con paradigma orientado a objetos

26 3 Diseno 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 funcion del desarrollo del Api Gateway usando el paradigma reactivo se usan los diagra-mas flujos de datos, secuencia. En adicion, la figura 3-6 muestra la concurrencia en el ApiGateway 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 Diseno de Api Gateway

Figura 3-6: Concurrencia api reactivo

Capıtulo 4

Construccion e Implementacion

4.1. Microservicios

Aunque los microservicios no hacen parte del analisis de transaccionalidad del presente tra-bajo, son la fuente de datos para cada API Gateway desarrollados. Con el animo de conservarla misma fuente de datos y la razon del patron API Gateway se comenta a continuacion sudesarrollo:

Construccion 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 aplicacion web completa y moderna o una arquitecturade microservicio, unificando:

Figura 4-1: Plataforma Jhipster

Un Stack de Java robusto y de alto rendimiento en el lado del servidor con SpringBoot.

Un frontal moderno, elegante y moderno, con Angular, React y Bootstrap.

Una robusta arquitectura de microservicio con JHipster Registry, Netflix OSS, ElasticStack y Docker.

30 4 Construccion e Implementacion

Una vez instalado, ver guıa de instalacion en [Web10]; se realizo modelo de entidades delnegocio del microservicio; Una caracterıtica de Jhipster es generar codigo a partir de estemodelo.

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 esde gran ayuda para la exposicion de un Api RestFul.

Implementacion con Docker

Un contenedor es una unidad estandar de software que empaqueta el codigo y todas susdependencias para que la aplicacion se ejecute de forma rapida y confiable de un entornoinformatico a otro. Una imagen de contenedor Docker es un paquete de software liviano,independiente y ejecutable que incluye todo lo necesario para ejecutar una aplicacion: codi-go, tiempo de ejecucion, herramientas del sistema, bibliotecas del sistema y configuraciones[Web9].

Una vez construido el microservicio, se despliega en una instancia de Jhipster aparte con laintencion 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

Documentacion con Swagger

Simplifica el desarrollo de API para usuarios, equipos y empresas con el conjunto de herra-mientas de codigo abierto y profesional de Swagger. Descubre como te puede ayudar Swagger[Web15].

Para el ejercicio la documuntacion de cada microservicio es como se refleja en la figura


Figura 4-4: Contenedores docker

Figura 4-5: Documentacion Swagger para microservicio

4.1 Microservicios 33

Figura 4-6: Documentacion detallada Swagger para microservicio


4.2. Api Gateway Reactivo

4.2.1. Api Gateway NodeJS

NodeJS

Concebido como un entorno de ejecucion de JavaScript orientado a eventos asıncronos, Nodeesta disenado para construir aplicaciones en red escalables. En dichas aplicaciones, se puedenmanejar muchas conexiones concurrentes. Por cada conexion el callback sera ejecutado, sinembargo si no hay trabajo que hacer Node estara durmiendo [Web7].

ExpressJS

Express es una infraestructura de aplicaciones web Node.js mınima y flexible que proporcio-na un conjunto solido de caracterısticas para las aplicaciones web y moviles [Web8].

Con miles de metodos de programa de utilidad HTTP y middleware a su disposicion, lacreacion de una API solida es rapida y sencilla [Web8].

Aprovechando esta tecnologıa se creo el Api Gateway nodeJS haciendo uso del siguientecodigo, Figura 4-7 - Figura 4-10:

Figura 4-7: Archivo app.js, ejecucion 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 SpringMVC. Spring Cloud Gateway tiene como objetivo proporcionar una forma sencilla y eficazde enrutar a las API y brindarles preocupaciones transversales, como la seguridad, monitoreo/ metrica y la resistencia [Web12].

Servidor Eureka

Eureka Server es una aplicacion que contiene la informacion sobre todas las aplicaciones deservicio al cliente. Cada Microservicio se registrara en el servidor Eureka y el servidor Eurekaconoce todas las aplicaciones cliente que se ejecutan en cada puerto y direccion IP. Eureka


Figura 4-10: Configuracion de enrutamiento para cada microservicio, por servicio

Server tambien se conoce como Discovery Server [Web16].

El servidor eureka desarrollado para el funcinamiento del api gateway esta bajo el siguientecodigo (figura 4-11 - figura 4-13):

Por otro lado el Api Gateway con spring cloud, se desarrollo bajo la siguientes sentencias(figura 4-14 - figura 4-16):


Figura 4-11: Configuracion de archivo pom.xml del servidor eureka

Figura 4-12: Configuracion general del servidor


Figura 4-13: Clase principal de Spring boot, servidor eureka

Figura 4-14: Dependencias pom.xml Api Gateway con spring cloud


Figura 4-15: Otras dependencias pom.xml Api Gateway con spring cloud

Figura 4-16: Gateway Routing con spring cloud


4.3. Api Gateway Orientado a Objetos

Spring boot

SpringBoot nace con la intencion de simplificar los siguientes pasos: seleccionar los jar conmaven y despliegues en servidor; con la intencion de que el programador se centre en eldesarrollo de la aplicacion [Web4].

A continuacion se incluye codigo 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: Accion para la optencion de url

Figura 4-19: Transformador de url a request

Figura 4-20: Consumo de servicio RestFul, microservicio

4.4. Despliegue final


Figura 4-21: Diagrama de despliegue de componentes del analisis

Capıtulo 5

ADM-Archimate

Archimate 2.1 facilita el modelado de la arquitectura empresarial, permitiendo bosquejar laorganizacion desde diversos puntos de vista donde se reflejan tanto los involucrados en elnegocio, la infraestructura y la misma solucion como los diferentes componentes, dando unavision general que describe a la perfeccion la organizacion y su solucion informatica.

El presente trabajo es del interes para la empresa Jirka IT Solutions, el cual sin nin-guna duda le sacara provecho para sus desarrollos futuros. Por esta razon el ejercicio dearquitectura empresarial se realizara sobre esta companıa

5.1. Organizacion

Jirka IT Solutions SAS

Jirka es una companıa especializada en servicios IT de desarrollo de software que ofrecemossoluciones integrales con los mas altos estandares tecnologicos del sector. Nos caracterizamospor la investigacion e innovacion al fin de promover el desarrollo de soluciones que ayuden ala transformacion de la sociedad.

Figura 5-1: Logo Jirka It Solutions SAS

44 5 ADM-Archimate

Mision

Jirka es una companıa especializada en servicios IT de desarrollo de software y SoftwareFactory que ofrece soluciones integrales con los mas altos estandares tecnologicos del sec-tor. Nos caracterizamos por la investigacion e innovacion al fin de promover el desarrollo desoluciones que ayuden a la transformacion de la sociedad, por ello, estamos comprometidoscon la excelencia, la responsabilidad y la calidad, de la mano con nuestro Talento Humano,quienes poseen una alta formacion profesional enmarcada en las excelentes relaciones hu-manas, con el objetivo de dar respuesta a las necesidades de nuestros clientes, proveedoresy colaboradores; conocemos la satisfaccion que ofrece el exito y estamos comprometidos enlograrlo.

Vision

A 2020, ser la companıa lıder en servicios IT de desarrollo de software y Software Factory delMercado, con casos de exitos que posicionan a nuestros clientes como referentes de la adop-cion de nuestras soluciones tecnologicas, enmarcadas en los mas altos estandares del sector;demostrando siempre nuestro compromiso social soportado en la investigacion e innovacion,de la mano con la formacion de nuestro Talento Humano para afrontar los retos que diaria-mente impone la excelencia, construyendo relaciones basadas en la etica, la responsabilidady la confianza.

5.2. Punto de vista del negocio

Los puntos de vista del negocio visualizan y definen los procesos de negocio, servicios yfunciones de la organizacion, los cuales se ofrecen a los clientes externos y son generados porla organizacion por medio de procesos de negocios, a traves de actores y sus diferentes rolesde participacion.

Punto de vista organizacional

Este punto de vista se centra en la organizacion interna de la empresa, una red de empresas,un departamento u otra entidad organizacional. Se pueden modelar diagramas de bloquesanidados o de una forma mas tradicional como un organigrama. Estos diagramas ayudan enla visualizacion e identificacion de las responsabilidades, jerarquıas y competencias de unaorganizacion.

Punto de vista cooperacion de actor

Este punto de vista se centra en las relaciones de cooperacion entre los actores y su entorno,para ello se puede utilizar el diagrama de contexto, el cual permite exponer la organizacion

5.2 Punto de vista del negocio 45

Figura 5-2: Metamodelo punto de vista de organizacion

Figura 5-3: Punto de vista de organizacion

en un ambiente de entidades externas tales como clientes, proveedores y demas colabora-dores del negocio. Estos diagramas ayudan a determinar las dependencias externas y suscolaboraciones, 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 cooperacion de actor

46 5 ADM-Archimate

Figura 5-5: Punto de vista cooperacion de actor

Punto de vista de funcion del negocio

Este punto de vista visualiza las principales funciones de negocio de la organizacion y lasrelaciones de los flujos de informacion, el valor y los bienes entre ellos. Estas funciones per-miten representar las caracterısticas de mas estabilidad en una empresa en funcion de suactividad principal, sin importar los cambios de la organizacion o desarrollos tecnologicos.

Figura 5-6: Metamodelo punto de vista de funcion de negocio

Punto de vista proceso del negocio

Este punto de vista visualiza una estructura de alto nivel y la composicion de uno o masprocesos de negocio. Permite mostrar los servicios a traves de los procesos que contribuyen


Figura 5-7: Punto de vista de funcion de negocio

al producto final de la organizacion, ası como los roles en los procesos y las responsabilidadesde 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 cooperacion proceso del negocio

Este punto de vista visualiza la relacion entre los procesos de negocio y su entorno, ası comolas dependencias entre estos mismos. Sus caracterısticas son:

Figura 5-10: Metamodelo punto de vista de cooperacion de proceso de negocio


Figura 5-11: Punto de vista de cooperacion 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 externasimplicadas, muestra la composicion de los productos en funcion de los servicios, contratos oacuerdos. Visualiza las interfaces en las que el producto es presentado y los eventos asociadoscon 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 aplicacion

Los puntos de vista de la aplicacion visualizan y definen las aplicaciones de software quegestionan los componentes del negocio y los servicios, los componentes reusables, ası comolas interfaces que relacionan y comunican los componentes del negocio.

5.3 Punto de vista de la aplicacion 51

Punto de vista de comportamiento de aplicacion

Este punto de vista visualiza y define el comportamiento a nivel interno de las aplicaciones,se utiliza para modelar y disenar el comportamiento de las aplicaciones o componentes ylograr identificar el proceso funcional entre las aplicaciones.

Figura 5-14: Metamodelo punto de vista de comportamiento de aplicacion

Figura 5-15: Punto de vista de comportamiento de aplicacion

52 5 ADM-Archimate

Punto de vista de cooperacion de aplicacion

Este punto de vista visualiza y define las relaciones de los componentes a traves del flujode informacion de los servicios ofrecidos o usados por la organizacion. Permite visualizar lacooperacion de los servicios que se unen para la ejecucion de los procesos del negocio.

Figura 5-16: Metamodelo punto de vista de cooperacion de aplicacion

Figura 5-17: Punto de vista de cooperacion de aplicacion

Punto de vista de estructura de aplicacion

Este punto de vista visualiza la estructura de las aplicaciones o de los componentes, permitemodelar y disenar estas estructuras de las aplicaciones o componentes y su informacion

5.3 Punto de vista de la aplicacion 53

asociada.

Figura 5-18: Metamodelo punto de vista de estructura de aplicacion

Figura 5-19: Punto de vista de estructura de aplicacion

Punto de vista de uso de aplicacion

Este punto de vista visualiza y define el uso de las aplicaciones para soportar los procesosdel negocio, y como se deben utilizar por otras aplicaciones. Permite modelar y disenar losservicios de los procesos de negocio y demas aplicaciones de la organizacion.

54 5 ADM-Archimate

Figura 5-20: Metamodelo punto de vista de uso de aplicacion

Figura 5-21: Punto de vista de uso de aplicacion

5.4. Punto de vista tecnologico

Los puntos de vista tecnologicos visualizan y definen la infraestructura que soporta y permitela comunicacion de la capa de aplicacion, dispone de servicios de infraestructura hardwarey software para el despliegue de las aplicaciones en la organizacion.

Punto de vista de infraestructura

Este punto de vista visualiza y define el software y hardware que soportan las aplicaciones,a traves de dispositivos fısicos, redes o sistemas de software.

5.4 Punto de vista tecnologico 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 analisis 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 organizacion e implementacion

Este punto de vista visualiza y define como las aplicaciones son integradas en la infraestruc-tura, a traves del mapeo de aplicaciones (logicas) y componentes (fısicos). Permite el analisisde rendimiento y escalabilidad por medio de la relacion que existe de las aplicaciones y lainfraestructura.


Figura 5-26: Metamodelo punto de vista de organizacion e implementacion

Figura 5-27: Punto de vista de organizacion e implementacion

Punto de vista de estructura de informacion

Este punto de vista visualiza y define la estructura de la informacion usada en la organizacion,proceso o aplicacion en funcion de los tipos de datos o las estructuras de clases (orientado aobjetos).

58 5 ADM-Archimate

Figura 5-28: Metamodelo punto de vista de Estructura de Informacion

Figura 5-29: Punto de vista de Estructura de Informacion

Punto de vista de realizacion del servicio

Este punto de vista visualiza y define como los servicios del negocio son ejecutados porprocesos subyacentes, a traves de un puente de comunicacion entre los puntos de vista denegocio y los puntos de vista de procesos de negocio.

Punto de vista de capas


Figura 5-30: Metamodelo punto de vista de Realizacion del Servicio

Figura 5-31: Punto de vista de Realizacion 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 decambio, sus fortalezas, debilidades, oportunidades y amenazas (DOFA). Permite el proceso deingenierıa de requerimientos, el refinamiento de objetivos, contribucion y analisis de conflictosderivados de los objetivos.

Figura 5-33: Metamodelo punto de vista de stakeholder

Figura 5-34: Punto de vista de stakeholder

Punto de vista de realizacion de objetivos

Este punto de vista visualiza y define el proceso de mejorar los objetivos en objetivos masconcretos que permitan generar requerimientos o restricciones que ayuden en el cumplimiento

62 5 ADM-Archimate

de los objetivos planteados. Estas mejoras se modelan a traves de la relacion de realizacion.

Figura 5-35: Metamodelo punto de vista de realizacion de objetivos

Figura 5-36: Punto de vista de realizacion de objetivos

Punto de Vista de Contribucion

El punto de vista de la contribucion al objetivo permite a un disenador o analista modelar lasrelaciones de influencia entre los objetivos y los requisitos. Las vistas resultantes se puedenutilizar para analizar el impacto que las metas tienen entre sı o para detectar conflictos entrelas metas de las partes interesadas.


Figura 5-37: Metamodelo punto de vista de contribucion

Figura 5-38: Metamodelo punto de vista de contribucion

Punto de vista de principios

Este punto de vista visualiza y define los procesos mas importantes para el diseno a mano ylos objetivos que conllevan a estos principios. Ademas permite modelar las relaciones de losprincipios 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 realizacion de requerimientos

Este punto de vista visualiza y define la relacion de requerimientos con los actores de negocio,los servicios, procesos y aplicaciones de negocio.

Figura 5-41: Metamodelo punto de vista de realizacion de Requerimientos


Figura 5-42: Ejemplo punto de vista de realizacion de requerimientos

Punto de vista de motivacion

Este punto de vista visualiza y define la revision de los aspectos motivacionales relacionadoscon los stakeholders, sus principios primarios, aplicados y los requerimientos mas relevantesde los servicios, procesos, aplicaciones y objetivos del negocio.

Figura 5-43: Metamodelo punto de vista de motivacion

66 5 ADM-Archimate

Figura 5-44: Ejemplo punto de vista de realizacion de requerimientos

5.6. Punto de vista implementacion y migracion

Punto de vista de proyecto

Este punto de vista visualiza y define los cambios en la arquitectura del proceso de migraciondesde un estado actual de la arquitectura empresarial a un estado objetivo de la arquitecturaempresarial, esta migracion aporta de forma significativa en el proceso de crecimiento de laestrategia y las decisiones de los procesos de realizacion.

Figura 5-45: Metamodelo punto de vista de proyecto

5.6 Punto de vista implementacion y migracion 67

Figura 5-46: Ejemplo punto de vista de proyecto

Punto de vista de migracion

Este punto de vista visualiza y define las caracterısticas para la transicion de una arquitec-tura existente a una arquitectura deseada. La platea es el estado de la arquitectura que tieneun un tiempo limitado.

Figura 5-47: Metamodelo punto de vista de migracion

Punto de vista de migracion e implementacion

Este punto de vista visualiza y define las relaciones entre los programas y proyectos con laarquitectura que ellas implementan. Permite modelar el alcance de los programas, proyec-tos y actividades en funcion de la platea o los artefactos de arquitectura afectada. Ademas

68 5 ADM-Archimate

Figura 5-48: Ejemplo punto de vista de migracion

relaciona objetivos de negocio a traves de los programas y proyectos de la arquitectura.

Figura 5-49: Metamodelo punto de vista de migracion e implementacion

5.6 Punto de vista implementacion y migracion 69

Figura 5-50: Punto de Vista de Migracion e Implementacion

Parte III

Cierre de la investigacion

Capıtulo 6

Resultados y discusion

Los resultados de este trabajo se hallaron con la ayuda de la aplicacion Apache JMeter, endonde se realizo cuatro (4) series de envıo de peticiones a cada Api Gateway. Las series seestablecio con las siguientes peticiones: 100, 500, 1.000 y 5.000 request.

Apache JMeter

La aplicacion Apache JMeter es un software de cdigo abierto, una aplicacion Java 100 % puradisenada para cargar el comportamiento funcional de la prueba y medir el rendimiento. Ori-ginalmente fue disenado para probar aplicaciones web, pero desde entonces se ha expandidoa otras funciones de prueba.

Figura 6-1: Apache JMeter

Apache JMeter se puede usar para probar el rendimiento tanto en recursos estaticos comodinamicos, aplicaciones dinamicas web. Se puede usar para simular una carga pesada enun servidor, grupo de servidores, red u objeto para probar su resistencia o para analizar elrendimiento general bajo diferentes tipos de carga.

72 6 Resultados y discusion

Resultados con 100 Peticiones http

En la figura 6-2 muestra el comportamiento de cada Api Gateway en relacion al tiempo decontestacion de 100 peticiones.

Figura 6-2: Respuesta de cada Api Gateway

Promedio Mınimo MaximoGateway NodeJS 126 4 2161Gateway Spring Cloud 10 5 110Gateway Spring Boot 15 9 45

Cuadro 6-1: Resumen de transaccionalidad para 100 peticiones http

En la obtencion 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 figura6-3)

En adicion, el Api que contesto con mayor velocidad frente a los demas 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

Tambien fue el mismo Api que presento menor transaccionalidad para una peticion. (verfigura 6-5)


Figura 6-5: Tiempos Maximo 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 ApiGateway.


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 objetoscon Spring Boot, es el que tiene mayor transaccionalidad.

Por otro lado, el API Gateway que presento la respuesta en el menor tiempo posible, fue eldesarrollado con tecnologıa Spring Cloud Gateway. (Ver figura 6-8)

Finalmente para 500 peticiones, el API Gateway que que vuelve a presentar mayor tiempoen una de las respuestas el desarrollado con NodeJS, ver figura (6-9)

75


Figura 6-7: Promedio tiempos de respuesta para 500 peticiones


Figura 6-8: Tiempos Mınimo de respuesta para 500 peticiones

Figura 6-9: Tiempos Maximo 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 unode los Api Gateway.



Cuadro 6-3: Resumen de transaccionalidad para 1.000 peticiones http

De las metricas obtenidas estan muy similares pero se puede determinar que el API Gatewayempezo a tener tendencia lineal.

Los API’s Gateways que representan al paradigma reactivo, son los que presentaron ma-yor transaccionalidad. (ver figura 6-11 - 6-13)


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 Maximo de respuesta para 1.000 peticiones


Resultados con 5.000 Peticiones http

Segun los datos arrojados, se muestra en la figura 6-14 los tiempos de respuesta para 5.000peticiones envıadas a cada uno de los Api Gateway.



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 mayornumero de peticiones empieza a decrecer los tiempos de respuesta, caso contrario pasa conel desarrollo de Spring Boot, el cual empieza a formar tendencia lineal a mayor numero depeticiones.

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 numero elevado depeticiones. (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


Figura 6-17: Tiempos Maximo de respuesta para 5.000 peticiones

Capıtulo 7

Conclusiones

7.1. Verificacion, contraste y evaluacion de los objeti-

vos

A continuacion se presentan algunas reflexiones que a partir del desarrollo del presentetrabajo se generaron, se realiza un analisis de sus objetivos.

Analizando la transaccionalidad de un Api Gateway desarrollado con el paradigmaorientado a objetos frente al paradigma reactivo, se logra determinar que gracias a laarquitectura asıncrona del paradigma, el API Gateway que tiene mayor transacciona-lidad concurrente es el desarrollado con programacion reactiva.

El paradigma orientado a objetos con Spring Boot, es una buena alternativa para hacersoftware en donde el dominio de usuario no supere los 5.000 usuarios, pero cuando setrata de manejar una alta concurrencia de usuarios, como por ejemplo aplicaciones detalla mundial (Netflix, Uber, etc). No es un paradigma recomendado.

Spring Cloud Gateway es una tecnologıa bastante eficiente comparada con las demastecnologıas evaluadas, en verdad es una alternativa a servicios ofrecidos por grandescompanıas como por ejemplo Amazon con su AWS. Sin embargo se recomienda realizarpruebas con tecnologıas tales como: ReactiveX y Akka.

El analisis no solo sirvio para identificar que paradigma tiene un mejor rendimientofrente al otro, sino que tambien se destaca el diseno, funcionamiento y comportamientodel componente software.

7.2. Sıntesis del modelo propuesto

Esta monografıa es un analisis al rendimiento de la transaccionalidad en un Api Gatewayque se desarrollo bajo el paradigma orientado a objetos frente al paradigma reactivo. Siendoeste componente un patron para la arquitectura microservicios, es de interes que paradigmaofrece un alto rendimiento.

84 7 Conclusiones

7.3. Aportes originales

El analisis llevado a cabo en este trabajo contempla el desarrollo de tres Api Gateway, unobajo el paradigma orientado a objetos y dos (2) con el paradigma reactivo. Cada uno deestos desarrollos fue sometido a diferentes pruebas de carga con 100, 500, 1.000 y 5.000peticiones http. El analisis no solo proporciona graficos que describen el comportamiento dela transaccionalidad de cada API Gateway si no que muestra su diseno estructural. Caberesaltar que el diseno se realizo para el entendimiento funcional de este componente ya quecompanıas como Amazon, ofrecen Gateway como servicio siendo este una caja negra paralos desarrolladores.

Capıtulo 8

Prospectiva del trabajo de grado

8.1. Lıneas de investigacion futuras

El API Gateway con programacion reactiva fue el reto para este analisis, por lo tanto haytecnologıas que ameritan explorarse, con estas tecnologıas quizas se pueda crear componentescon mayor rendimiento software.

Reactive X

ReactiveX es una biblioteca para componer programas asıncronos y basados en eventos me-diante el uso de secuencias observables.

Extiende el patron de observador para admitir secuencias de datos y/o eventos y agregaoperadores que le permiten componer secuencias de manera declarativa al tiempo que abs-trae las preocupaciones sobre cosas como subprocesos de bajo nivel, sincronizacion, seguridadde subprocesos, estructuras de datos concurrentes. Bloqueo de Entrada/Salida. [Web13]

Akka

Akka proporciona API para Java y Scala. Ambas son compatibles con la gama completa decaracterısticas de Akka para brindar una excelente experiencia de desarrollo al crear sistemasconcurrentes y distribuidos. [Web11]

Akka es un conjunto de herramientas para crear aplicaciones basadas en mensajes altamenteconcurrentes, distribuidas y resistentes para Java y Scala.

8.2. Trabajos de Investigacion futuros

Acorde a este trabajo, en donde se analiza la transaccionalidad del componente API Gate-way que se desarrollo bajo el paradigma orientado a objetos frente al paradigma reactivo,

86 8 Prospectiva del trabajo de grado

unicamente se considero el rendimiento a la hora de contestar peticiones. Por eso se proponelos siguientes trabajos futuros:

Analizar la mantenibilidad de un componente API Gateway desarrollado bajo elparadigma orientado a objetos frente al paradigma reactivo. Si bien es cierto, la pro-gramacion reactiva es asıncrona lo cual permite una mayor transaccionalidad, no tienemucha documentacion; por lo tanto realizar un cambio, una mejora, puede ser mascostoso si se compara a otra programacion.

Realizar el analisis de transaccionalidad comparando el paradigma reactivo frente aun API Gateway ofertado por la companıa Amazon, como por ejemplo AWS. Laintencion es encontrar alternativas dependiendo de las necesidades del cliente..

Bibliografıa

[1] E. Bainomugisha, A. L. Carreton, T. van Cutsem, S. Mostinckx, and W. de Meuter, “Asurvey on reactive programming,” ACM Computing Surveys (CSUR), vol. 45, no. 52,2013.

[2] C. de la Torre, B. Wagner, and M. Rousos, .NET Microservices: Architecture for Con-tainerized .NET Applications. Microsoft Corporation, 2018.

[3] D. Harel and A. Pnueli, “On the development of reactive systems,” in Logics and Modelsof Concurrent Systems, K. R. Apt, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg,1985, pp. 477–498.

[4] G. Hochbergs, “Reactive programming and its effect on performance and the developmentprocess,” 2017, student Paper.

[5] F. Morero, Introduccion a la OOP. Grupo EIDOS, 2000.

[6] W. Pree and H. Sikora, “Design patterns for object-oriented software development,”ACM, 1997.

[7] C. Richardson, Microservices Patterns: With examples in Java. Manning Publications,2018.

[8] C. V. Rodrıguez, Paradigmas de Programacion, Departamento de Informatica Universi-dad de Valladolid, feb 2011.

Referencias web

[Web1] Introduction to Software Architecture. Berlin, Heidelberg: Springer Ber-lin Heidelberg, 2008, pp. 1–33. [Online]. Available: https://doi.org/10.1007/978-3-540-74343-9 1

[Web2] (2014) Topicos generales de ingenierıa de software. [Online]. Available: https://ingsoftwarei2014.wordpress.com/category/patrones-en-la-ingenieria-de-software/

[Web3] J. Boner, D. Farley, R. Kuhn, and M. Thompson. (2014, sep) El manifiesto desistemas reactivos. [Online]. Available: https://www.reactivemanifesto.org/es

[Web4] C. A. Caules. (2016, mar) ¿que es spring boot? [Online]. Available: https://www.arquitecturajava.com/que-es-spring-boot/

[Web5] B. Christensen. (2013, jan) Optimizing the netflix api. [Online]. Available:https://medium.com/netflix-techblog/optimizing-the-netflix-api-5c9ac715cf19

[Web6] I. Corporation. (2014, apr) ¿que es un servicio web? [Online]. Availa-ble: https://www.ibm.com/support/knowledgecenter/es/SSMKHH 9.0.0/com.ibm.etools.mft.doc/ac55710 .htm

[Web7] N. Foundation. Acerca de node.js. [Online]. Available: https://nodejs.org/es/about/

[Web8] ——. Express. fast, unopinionated, minimalist web framework for node.js. [Online].Available: https://expressjs.com/es/

[Web9] D. Inc. (2019) Enterprise container platform for high-velocity innovation. [Online].Available: https://www.docker.com/

[Web10] JHipster. (2013-2019) Greetings, java hipster! [Online]. Available: https://www.jhipster.tech/

[Web11] I. Lightbend. (2011-2019) akka. [Online]. Available: https://akka.io/

[Web12] I. Pivotal Software. (2019) Spring cloud gateway. [Online]. Available: https://spring.io/projects/spring-cloud-gateway

[Web13] ReactiveX. Reactivex. [Online]. Available: http://reactivex.io/

https://doi.org/10.1007/978-3-540-74343-9_1

https://doi.org/10.1007/978-3-540-74343-9_1

https://ingsoftwarei2014.wordpress.com/category/patrones-en-la-ingenieria-de-software/

https://ingsoftwarei2014.wordpress.com/category/patrones-en-la-ingenieria-de-software/

https://www.reactivemanifesto.org/es

https://www.arquitecturajava.com/que-es-spring-boot/

https://www.arquitecturajava.com/que-es-spring-boot/

https://medium.com/netflix-techblog/optimizing-the-netflix-api-5c9ac715cf19

https://www.ibm.com/support/knowledgecenter/es/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac55710_.htm

https://www.ibm.com/support/knowledgecenter/es/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac55710_.htm

https://nodejs.org/es/about/

https://expressjs.com/es/

https://www.docker.com/

https://www.jhipster.tech/

https://www.jhipster.tech/

https://akka.io/

https://spring.io/projects/spring-cloud-gateway

https://spring.io/projects/spring-cloud-gateway

http://reactivex.io/

REFERENCIAS WEB 89

[Web14] C. Richardson. (2018) Pattern: Api gateway / backend for front-end. [Online].Available: https://microservices.io/patterns/apigateway.html

[Web15] S. Software. (2019) Api development for everyone. [Online]. Available:https://swagger.io/

[Web16] tutorialspoint simply easy learning. (2019) Spring boot - eureka server. [Online].Available: https://www.tutorialspoint.com/spring boot/spring boot eureka server.htm

[Web17] E. Uscanga. (2016, aug) [opinion] programacion reactiva:un paradigma necesario para los tiempos actuales. [Online].Available: https://medium.com/@erik uscanga/opini%C3%B3n-programaci%C3%B3n-reactiva-un-paradigma-necesario-para-los-tiempos-actuales-8c8da0384083

https://microservices.io/patterns/apigateway.html

https://swagger.io/

https://www.tutorialspoint.com/spring_boot/spring_boot_eureka_server.htm

https://www.tutorialspoint.com/spring_boot/spring_boot_eureka_server.htm

https://medium.com/@erik_uscanga/opini%C3%B3n-programaci%C3%B3n-reactiva-un-paradigma-necesario-para-los-tiempos-actuales-8c8da0384083

https://medium.com/@erik_uscanga/opini%C3%B3n-programaci%C3%B3n-reactiva-un-paradigma-necesario-para-los-tiempos-actuales-8c8da0384083

ANALISIS DEL RENDIMIENTO DE LA TRANSACCIONALIDAD EN …

Documents

Transcript of ANALISIS DEL RENDIMIENTO DE LA TRANSACCIONALIDAD EN …