Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios

Texto completo

(1)Graduado en Ingeniería Informática Universidad Politécnica de Madrid Escuela Técnica Superior de Ingenieros Informáticos. PROYECTO DE FIN DE GRADO Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Autor: Daniel Coto Martín Directores: Juan Antonio Fernández del Pozo Rubén Casado Tejedor. MADRID, JULIO 2017.

(2) Agradecimientos A mis tutores, Rubén y Juan Antonio, por proponer y aceptar este proyecto y por todo su interés mostrado. A mis padres y hermanos, por ayudarme a superar los momentos de frustración e impotencia durante la carrera. A mi novia Rocío, por su compañía, su aliento y todo su apoyo. A mis amigos de la facultad y a mis compañeros de prácticas, por hacer de cada momento un recuerdo inolvidable. A todos los profesores de la Facultad, por su incondicional dedicación y su inmensa labor.. i.

(3) Abstract Typically, web applications are compiled into a single file and deployed from it, which ends up causing an excessive expenditure of resources because of its huge volume. In order to minimize the problems of developing monolithic applications and inside the agile methodologies, the architecture based on microservices is emerged. On this approach, applications are built from a set of small independent services that communicate to one another through their own APIs. The purpose of this project is to implement the back-end of an e-commerce based on the microservices architectural philosophy, giving rise to a system composed by several independent services that are deployed according to demand needs. Due to this strategy, scalability and application performance are boosted. The development of microservices has been carried out by using Spring technologies such as Spring Boot or Spring JPA. It also handled Spring Consul to register the services and to enable communication between them. Finally, it has been possible to build the functional base of an e-commerce that can be used by any web page related to this area. Key words: web application, backend, microservices, monolithic, e-commerce, spring boot, framework, scalability, resources, API, deployment, communication.. Resumen Tradicionalmente, las aplicaciones web se compilan en un único fichero autocontenido desde el que posteriormente se despliegan, lo que termina suponiendo un elevado gasto de los recursos disponibles. Para minimizar los problemas derivados de este procedimiento y en el marco de las metodologías ágiles, surge la arquitectura basada en microservicios, dónde las aplicaciones pasan a estar formadas por un conjunto de pequeños servicios independientes que se comunican entre sí a través de sus API. El propósito de este proyecto consiste en implementar el back-end de un comercio electrónico basado en la filosofía arquitectónica de los microservicios y que dará lugar a un sistema compuesto por la conjunción de múltiples servicios independientes que se irán desplegando según las necesidades. Gracias a este enfoque se favorecerá la escalabilidad y el rendimiento de la aplicación final. El desarrollo de los microservicios se ha llevado a cabo haciendo uso de las tecnologías de Spring tales como Spring Boot o Spring JPA y la comunicación entre los mismos se ha realizado mediante Spring Consul. Finalmente se ha logrado construir la base funcional de un comercio electrónico que podrá ser usado por cualquier página web relativa a este campo. Palabras clave: aplicación web, backend, microservicios, monolítico, comercio electrónico, spring boot, plataforma, escalabilidad, recursos, API, despliegue, comunicación.. ii.

(4) Índice de contenido 1. 1.1. 1.1. 1.2. 1.3.. Introducción ..................................................................................................... 1 Fundamento del proyecto ............................................................................... 1 Objetivos y metas ........................................................................................... 1 Motivación ..................................................................................................... 2 Alcance ........................................................................................................... 2. 2.. Estado del arte .................................................................................................. 3 2.1. Introducción ................................................................................................... 3 2.2. Arquitecturas software ................................................................................... 3 2.2.1. Enfoque monolítico .................................................................................... 3 2.2.2. Enfoque basado en microservicios ............................................................. 4 2.2.3. Comparativa ............................................................................................... 6 2.3. Microservicios en el mercado actual .............................................................. 8 2.3.1. Microservicios en las grandes corporaciones ............................................. 8 2.3.2. Microservicios en las pequeñas empresas .................................................. 9 2.3.3. Microservicios en las administraciones públicas ....................................... 9 2.4. Spring Framework ........................................................................................ 10 2.4.1. Spring Boot ............................................................................................... 11 2.4.2. Spring Cloud (Consul) .............................................................................. 12 2.5. Otras tecnologías .......................................................................................... 13 2.5.1. JWT .......................................................................................................... 13 2.5.2. Maven ....................................................................................................... 15 2.5.3. Postman .................................................................................................... 16. 3.. Desarrollo ....................................................................................................... 17 3.1. Especificación de Requisitos Software ........................................................ 17 3.2. Descripción general ...................................................................................... 17 3.3. Funciones del sistema................................................................................... 17 3.4. Restricciones del sistema ............................................................................. 18 3.5. Particularidades y dependencias................................................................... 18 3.6. Requisitos ..................................................................................................... 18 3.7. Diseño........................................................................................................... 21 3.8. Implementación ............................................................................................ 23 3.8.1. Microservicio de bienvenida .................................................................... 23 3.8.2. Microservicio de catálogo ........................................................................ 25 3.8.3. Microservicio de cuentas .......................................................................... 27 3.8.4. Microservicio de carrito............................................................................ 32 3.8.5. Microservicio de pedidos.......................................................................... 34. iii.

(5) 3.8.6. Autenticación de tokens............................................................................ 36 3.8.7. Configuración de Spring Consul .............................................................. 38 3.9. Pruebas ......................................................................................................... 39 3.9.1. Prueba del microservicio de bienvenida ................................................... 41 3.9.2. Prueba del microservicio de catálogo ....................................................... 41 3.9.3. Prueba del microservicio de cuentas ........................................................ 44 3.9.4. Prueba del microservicio de carritos ........................................................ 45 3.9.5. Prueba del microservicio de pedidos ........................................................ 46 4. 4.1. 4.2. 4.3. 4.4.. Resultados y conclusiones ............................................................................. 48 Dificultades encontradas .............................................................................. 48 Logro de objetivos ........................................................................................ 49 Satisfacción de motivaciones ....................................................................... 50 Seguimiento de planificación ....................................................................... 50. 5.1. 5.2. 5.3. 5.4.. Desarrollo futuro............................................................................................ 52 Mejora .......................................................................................................... 52 Ampliación ................................................................................................... 52 Integración .................................................................................................... 53 Mantenimiento ............................................................................................. 53. 5.. 6.. Bibliografía ..................................................................................................... 54. 7.. Anexos ............................................................................................................. 56 7.1. Diagramas UML ........................................................................................... 56 7.1.1. Diagrama del microservicio de bienvenida .............................................. 56 7.1.2. Diagrama UML del microservicio de catálogo ........................................ 57 7.1.3. Diagrama UML del microservicio de cuentas .......................................... 59 7.1.4. Diagrama UML del microservicio de carrito ........................................... 61 7.1.1. Diagrama UML del microservicio de pedidos ......................................... 63. iv.

(6) Índice de tablas Tabla 1: comparativa entre arquitecturas de desarrollo software. .................................... 7 Tabla 2: principales funcionalidades del sistema. .......................................................... 18 Tabla 3: requisitos relacionados con el microservicio de bienvenida. ........................... 18 Tabla 4: requisitos relacionados con el microservicio de cuentas. ................................. 19 Tabla 5: requisitos relacionados con el microservicio de catálogo. ............................... 19 Tabla 6: requisitos relacionados con el microservicio de carrito. .................................. 20 Tabla 7: requisitos relacionados con el microservicio de pedidos. ................................ 20. v.

(7) Índice de Ilustraciones Ilustración 1: boceto del estilo arquitectónico monolítico o por capas. ........................... 3 Ilustración 2: esbozo del estilo arquitectónico basado en microservicios. ....................... 4 Ilustración 3: relación típica entre diversos frameworks. ............................................... 10 Ilustración 4: gestión de varios frameworks por parte Spring. ....................................... 10 Ilustración 5: diagrama de registro de servicios. ............................................................ 12 Ilustración 6: estructura de un JSON Web Token. ......................................................... 13 Ilustración 7 :aspecto de un JWT encriptado.................................................................. 14 Ilustración 8: dependencia de un programa en las librerías............................................ 15 Ilustración 9: estructura de un Artifact. .......................................................................... 15 Ilustración 10: captura del programa Postman. .............................................................. 16 Ilustración 11: visión general de la arquitectura del sistema. ......................................... 21 Ilustración 12: visión general de la arquitectura del sistema. ......................................... 22 Ilustración 13: implementación del microservicio de bienvenida. ................................. 24 Ilustración 14: implementación del microservicio de catálogo. ..................................... 26 Ilustración 15: implementación del registro en el microservicio de cuentas. ................. 28 Ilustración 16: implementación del login del microservicio de cuentas. ....................... 30 Ilustración 17: diagrama de secuencia del login y la autenticación de los tokens.......... 31 Ilustración 18: implementación del microservicio de carrito. ........................................ 33 Ilustración 19: implementación del microservicio de pedidos. ...................................... 35 Ilustración 20: autenticación de los tokens. .................................................................... 37 Ilustración 21: interfaz de Consul con los distintos microservicios registrados. ........... 39 Ilustración 22: colecciones creadas en Postman para probar los microservicios. .......... 40 Ilustración 23: captura de Postman de la prueba de bienvenida. .................................... 41 Ilustración 24: listado de todas las categorías del catálogo. ........................................... 42 Ilustración 25: solicitud de los productos de un mismo color. ....................................... 42 Ilustración 26: inserción de un nuevo producto en el catálogo. ..................................... 43 Ilustración 27: listado de todas las cuentas por parte del administrador. ....................... 44 Ilustración 28: contenido del carrito de un usuario. ....................................................... 45 Ilustración 29: confirmación del carrito de un usuario. .................................................. 46 Ilustración 30: historial de pedidos de un usuario. ......................................................... 46 Ilustración 31: contenido de un pedido concreto de un usuario. .................................... 47 Ilustración 32: diagrama UML del microservicio de bienvenida. .................................. 56 Ilustración 33: diagrama UML del microservicio de catálogo. ...................................... 58 Ilustración 34: diagrama UML del microservicio de cuentas......................................... 60 Ilustración 35: diagrama UML del microservicio de carritos......................................... 62 Ilustración 36: diagrama UML del microservicio de pedidos. ....................................... 64. vi.

(8) Índice de herramientas Spring Framework .......................................................................................................... 10 Spring Boot ..................................................................................................................... 11 Spring Consul ................................................................................................................. 12 JSON Web Token ........................................................................................................... 13 Maven ............................................................................................................................. 15 Postman .......................................................................................................................... 16. vii.

(9) Acrónimos y abreviaturas Acrónimo API BBDD CLIPS COC CSRF DB EAR HMAC HTML HTTP IEEE JAR JPA JSON JWT IDE MS NoSQL POM REST RSA SHA TTM UE UML URL WAR WIP XML XSS. Significado Application Programming Interface Base de Datos Cloud approach for Innovation in Public Services Convention Over Configuration Cross-Site Request Forgery DataBase Enterprise Application Archive Hash-based Message Authentication Code HyperText Markup Language HyperText Transfer Protocol Institute of Electrical and Electronics Engineers Java Application Archive Java Persistence API JavaScript Object Notation JSON Web Token Integrated Development Environment Micro Servicios Not Only Structured Query Language Proyect Object Model Representational State Transfer Rivest, Shamir, & Adleman (public key encryption technology) Secure Hash Algorithm Time To Market Unión Europea Unified Modeling Language Uniform Resource Locator Web Application Archive Work In Progress eXtensible Markup Language Cross-Site Scripting. viii.

(10) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 1. Introducción En este primer capítulo se indican las motivaciones del proyecto, sus principales objetivos y el alcance previsto.. 1.1. Fundamento del proyecto Generalmente, los proyectos software se despliegan a partir de un único fichero JAR, WAR o EAR [1] que contiene todos los componentes necesarios para correr el servicio de manera apropiada. Este tipo de aplicaciones se desarrollan siguiendo el denominado enfoque monolítico dónde la lógica del programa, a pesar de poder estar codificada en diferentes módulos, se empaqueta en un mismo lugar [2]. Este estilo arquitectónico, cómo se verá en profundidad más adelante, a pesar de contar con ciertas ventajas suele acarrear un gran esfuerzo, coste y tiempo. La razón se debe, fundamentalmente, al gran volumen que puede terminar adquiriendo la aplicación con el paso del tiempo. Como alternativa a este estilo y dentro del marco de las metodologías ágiles surge la arquitectura basada en microservicios, dónde las aplicaciones pasan a estar formadas por un conjunto de pequeños servicios independientemente desplegables que se ciñen a una única área de negocio y que se comunican entre sí a través de sus API.. 1.1.. Objetivos y metas. La finalidad principal del proyecto es la implementación de un sistema basado en la filosofía arquitectónica de los microservicios para obtener un sistema compuesto por la conjunción de múltiples servicios independientes que se irán desplegando según las necesidades. Este enfoque favorecerá la escalabilidad y la gestión de la propia aplicación. En un principio se desarrollará únicamente la parte de back-end, que será el conjunto de microservicios que, a posteriori, podrá usar una página web. Además, se usará virtualización para la gestión dinámica de recursos y herramientas como Github para el desarrollo ágil del software y para el seguimiento del propio proyecto. Los principales objetivos del proyecto son: x. Profundizar en los principios de diseño de los sistemas basados en microservicios.. x. Diseño e implementación de los servicios mediante el stack Spring.. x. Uso de tecnologías para el desarrollo ágil del software.. 1.

(11) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 1.2.. Motivación. Los estímulos para la realización del proyecto son diversos y responden a criterios personales, didácticos y profesionales: x. Motivación personal: mejorar e impulsar la dinámica de trabajo adquirida durante la carrera y las prácticas; potenciar la autogestión personal bajo el desafío que supone el propio proyecto.. x. Motivación didáctica: conocer los enfoques arquitectónicos más extendidos, comprendiendo las ventajas de cada uno y su posible aplicación según las necesidades particulares de cada proyecto; uso y familiarización de uno de los principales stack de desarrollo de aplicaciones como es el framework de Spring, centrándose en el manejo de Spring Boot para el desarrollo ágil de aplicaciones web.. x. Motivación profesional: familiarización con las herramientas, tecnologías y entornos de desarrollo aplicables en el entorno laboral actual.. 1.3.. Alcance. El alcance que se persigue con este proyecto es el aprendizaje y familiarización con el enfoque de desarrollo basado en microservicios, además del uso de las herramientas Spring Boot y el resto del framework de Spring para la creación y el despliegue de servicios y otras herramientas de desarrollo ágil como Git. Se pretende, además, aplicar todo el conocimiento adquirido al contexto laboral, por lo que se busca adquirir una base lo más sólida posible que permita afrontar y solucionar las tareas y proyectos futuros de una manera más eficaz y eficiente.. 2.

(12) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 2. Estado del arte 2.1.. Introducción. En esta sección se detallan las características principales de cada estilo arquitectónico, centrándose en las ventajas de la arquitectura basada en microservicios frente a la arquitectura monolítica. También se hace hincapié en los puntos clave del framework de Spring, especificando su papel en el devenir del trabajo. Por último, este apartado también define y aclara en profundidad el resto de tecnologías implicadas en el proyecto, como Maven o JWT.. 2.2. 2.2.1.. Arquitecturas software Enfoque monolítico. El enfoque monolítico hace referencia a una arquitectura en la que todas sus partes experimentan una gran dependencia y son implementadas mediante bajo el mismo componente de software (lenguaje, tecnología, etc.), dando lugar a sistemas fuertemente acoplados. Este tipo de aplicaciones, al tener todos sus elementos compilados y alojados en el mismo lugar, carecen de flexibilidad y su distribución, tanto lógica como física, resulta imposible. Esto supone que cualquier cambio o ampliación de funcionalidad puede afectar a un componente intesperado y causar resultados imprevistos dificiles de detectar y reparar.. Ilustración 1: boceto del estilo arquitectónico monolítico o por capas.. Este modelo cuenta, principalmente, con las siguientes ventajas: x. Predisposición de IDEs y resto de herramientas para el desarrollo de una aplicación autocontenida única.. x. El despliegue, consecuentemente, también se realiza desde un único fichero.. 3.

(13) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Sin embargo, las desventajas de los proyectos que adoptan este modelo suelen estar relacionadas con un mayor tiempo, esfuerzo y coste: x. Su mantenimiento es más costoso debido al gran volumen que puede alcanzar la aplicación.. x. Se actualizan más lentamente, ya que un cambio requiere en entendimiento del todo el código, así como la detección y el despliegue de toda la aplicación.. x. Resulta más difícil adoptar nuevos lenguajes o tecnologías que podrían ser beneficiosas debido al volumen de código.. x. Los componentes de la aplicación tienen una gran dependencia entre sí.. x. La integración continua y el escalado resultan imposibles a causa del volumen que adquieren las aplicaciones.. 2.2.2.. Enfoque basado en microservicios. La arquitectura basada en microservicios surge para hacer frente a las nuevas necesidades del software y como una alternativa a la perspectiva monolítica más tradicional. Su propósito es el desarrollo de las aplicaciones como conjuntos de pequeños servicios que se ejecutan independientemente y se comunican entre sí a través de mecanismos ligeros como HTTP o APIs REST. Con ello, se consigue aplicaciones mucho más tolerantes y dinámicas que pueden ejecutarse en diferentes lugares y adaptarse a las necesidades de cada momento.. Ilustración 2: esbozo del estilo arquitectónico basado en microservicios.. Este estilo arquitectónico está estrechamente ligado con las metodologías ágiles y otras disciplinas similares gracias al planteamiento de desarrollos más cortos y centrados en una única funcionalidad con valor propio dentro de la lógica de negocio. De esta forma, se facilita la entrega continua y se reduce el time to market, permitiendo cumplir con las líneas propuestas por las metodologías ágiles, el continuous integration, el continuous deployment o el DevOps.. 4.

(14) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Algunas de las principales metodologías y disciplinas que promueven el desarrollo ágil y el despliegue continuo del software son: •. •. Scrum: es un modelo de desarrollo ágil que tiene su origen en un estudio de 1986 sobre los procesos utilizados en los nuevos productos en Japón y los Estados Unidos, basados en requisitos novedosos y nuevas formas de trabajo para salir al mercado en el menor tiempo posible [3]. La palabra proviene de la equiparación con la colaboración que se muestran entre sí los jugadores de rugby durante la formación Scrum1. Está caracterizado por: o. La adopción de estrategias de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.. o. El fundamento de la calidad del resultado en función del conocimiento de las personas y no de la calidad de los procesos utilizados.. o. El uso de fases solapadas en lugar de secuenciales o en cascada.. Kanban: es otro de los principales estandartes de las metodologías ágiles. Tiene su origen en Toyota y su nombre es un término japonés que significa “tarjetas visuales” [4]. Sus principales características son: o El control y la regulación del WIP en la línea de producción. o La presentación de la información sobre producción de forma visual (identificación de componentes, estado del proceso, etc.). o La división del trabajo en “pendiente”, “en proceso” y “completado”.. •. DevOps: es una metodología de desarrollo software que permite a los desarrolladores centrarse en desarrollar y desplegar el código en solo unos instantes [5]. Su origen se remonta a una charla cancelada en la conferencia Agile’08 que derivó en una discusión sobre cómo llevar el agilismo al mundo de la infraestructura y la administración de sistemas. Esta disciplina hace posible: o La integración entre desarrolladores y administradores. o La creación rápida y flexible de software de mayor calidad, menor coste y con una alta tasa de lanzamientos para adaptarse a las demandas de TTM. Es importante subrayar que DevOps no es sinónimo de metodologías ágiles ni de arquitecturas basadas en microservicios. Sin embargo, es cierto que son herramientas que se complementan muy bien y que algunas organizaciones, como Amazon, Netflix o Paypal han adoptado en conjunto, obteniendo los beneficios que proporciona todo el paquete [6].. 1. Scrum: hace referencia a la formación de rugby conocida en castellano como melé.. 5.

(15) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Las ventajas más destacadas [7] de la arquitectura basada en los microservicios en comparación con la arquitectura monolítica son: •. Cada microservicio es una pequeña aplicación independiente que se ciñe a un área de negocio concreta, permitiendo así focalizar los esfuerzos en un único punto y obteniendo una productividad mayor.. •. El tamaño es sustancialmente menor gracias al reparto de las funcionalidades.. •. El acoplamiento entre servicios es mínimo o nulo.. •. El despliegue es más sencillo y continuo por lo que se agiliza el desarrollo.. •. Se consigue una mejora del rendimiento gracias a que cada microservicio puede escalar horizontalmente e individualmente.. A pesar de sus evidentes ventajas, los microservicios conllevan la complejidad propia de los sistemas distribuidos [2]: •. Se puede necesitar despliegue automático si el número de microservicios es muy elevado.. •. Requiere monitorización y gestión de fallos para conocer el estado de cada microservicio y actuar en caso necesario.. •. Se necesita hacer especial énfasis en los datos entre los diferentes microservicios para asegurar su consistencia.. En definitiva, los microservicios ofrecen un abanico de posibilidades inimaginable para la arquitectura monolítica, pudiendo elegir las tecnologías más adecuadas para cada servicio y agilizando el desarrollo gracias al reparto de los microservicios entre diferentes equipos de trabajo.. 2.2.3.. Comparativa. Una vez se tiene una imagen general de cada uno de los enfoques, cabe destacar que cualesquiera de los dos son perfectamente válidos y que la decisión de adoptar uno u otro dependerá de las necesidades puntuales de cada proyecto. Para entrar más en detalle y comprender cómo afecta una aplicación monolítica y una basada en microservicios a los distintos aspectos del desarrollo software (como la seguridad, la dependencia, el rendimiento, el lenguaje de programación o la propia implementación), se incluye a continuación una tabla comparativa en la que se pueden observar las diferencias más notorias, además de discernirse mejor las ventajas del modelo de microservicios sobre el modelo tradicional.. 6.

(16) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Característica Dependencia/ Acoplamiento Cohesión. Monolítica Mayor dependencia y acoplamiento entre clases. La interdependencia entre las clases implica poca cohesión Requiere recursos, más infraestructura y tiempo Despliegue único de la aplicación El desarrollo puede hacerse pesado y tedioso en el futuro La escalabilidad a nivel de aplicación reduce el rendimiento Una aplicación monolítica alcanza un enorme tamaño con el paso del tiempo Puede resultar más compleja Es lento y complejo porque se detiene toda la ejecución Resulta compleja debido al gran volumen que alcanza El volumen de información entorpece la documentación Suele ser más simple al tener un único despliegue. Microservicios Menor acoplamiento ya que cada microservicio es independiente. Gran cohesión al no depender de otros microservicios Coste Permite ahorrar en tiempo, costes y esfuerzo Despliegue Despliegue múltiple y progresivo de cada microservicio Desarrollo/ Es más ágil y simple porque se Implementación restringe a cada servicio Escalabilidad/ Al ser a nivel de microservicio Rendimiento permite adaptarse a la demanda y mejorar el rendimiento Tamaño Cada microservicio tiene un tamaño reducido al integrar una única necesidad de negocio Integración Integración sencilla y progresiva Mantenimiento/ Rápido ya que sólo se necesita Actualización parar el microservicio afectado Migración Es sencilla gracias al reducido tamaño de cada servicio Documentación La división en microservicios ayuda a la documentación Sincronización La distribución de los servicios suele dificultar la coordinación de los datos de cada uno Equipo de Requiere un mayor equipo de Mínimo y variable ya que el trabajo trabajo que debe ser fijo por reducido tamaño de los servicios el volumen de código los hace fácilmente comprensibles Riesgo El volumen de la aplicación Es mínimo gracias al aislamiento incrementa el riesgo de fallo de los servicios Pruebas Son sencillas ya que se El despliegue distribuido puede limitan al testeo de una única obstaculizar los test, pero el aplicación asilamiento facilita la resolución Lenguaje/ Se usa el mismo lenguaje de Cada microservicio puede usar Tecnología programación diferentes lenguajes, BBDDs, etc. Diseño Centralizado Descentralizado Seguridad Se ve reducida por la Aumenta al distribuir la dependencia interna responsabilidad en microservicios Comunicación Requiere complejos sistemas Resulta sencilla gracias a las APIs de tuberías entre los módulos REST o similares Transacciones Son más sencillas Son más complejas ya que suelen pasar por varios microservicios Tabla 1: comparativa entre arquitecturas de desarrollo software.. 7.

(17) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 2.3. 2.3.1.. Microservicios en el mercado actual Microservicios en las grandes corporaciones. La relevancia que han adquirido los microservicios en los últimos años se ve reflejada en el número de plataformas que han adoptado este estilo arquitectónico. La gran cantidad de servicios que ofrece una misma plataforma, unida a las crecientes necesidades de mantenimiento y escalabilidad de la actualidad, han supuesto que muchas de las principales compañías del mercado [8] adopten este enfoque. Algunas de estas empresas son: x. Amazon: fue una de las primeras compañías en migrar hacia los microservicios. Actualmente cuenta con cientos de microservicios que se coordinan entre sí para cumplir con toda la lógica de negocio. Gracias a la especialización que han adquirido desde que adoptaron esta arquitectura, Amazon es capaz de realizar más de 100.000 despliegues distintos en un mismo día con un ritmo de cerca de 2 despliegues por segundo [9].. x. Ebay: es conocida por ser una de las compañías con más visión de futuro. Fue pionera en la adopción de los microservicios y otras tecnologías de virtualización como Docker. Su aplicación está formada por distintos microservicios que se encargan de una parte concreta de la lógica de negocio y que en conjunto aportan todo el servicio a sus clientes.. x. Netflix: transformó su aplicación monolítica inicial en decenas de servicios que se han ido subdividiendo hasta llegar a las varias centenas de la actualidad. De no adoptar este estilo hubiera sido imposible alcanzar las cifras de suscriptores (más de 50 millones) o peticiones diarias (más de 2 mil millones) actuales [9].. x. Paypal: es una referente más en la adquisición de los microservicios, lo que hace posible recibir y dar respuesta a los miles de millones de transacciones que recibe diariamente. Actualmente, está adoptando nuevas técnicas de programación para desarrollar sus servicios de una manera más ágil (squbs).. x. Spotify: es otra de las principales compañías del panorama actual que han adquirido los microservicios y otros métodos de desarrollo ágil como la organización de sus equipos de desarrollo en tribus, escuadrones, capítulos y gremios (tribes, squads, chapters y guilds, respectivamente). Actualmente cuenta con más de 800 microservicios [9] que son invocados por un microservicio global desde la pantalla principal.. x. Twitter: cuenta con un enorme conglomerado de microservicios y es una de las primeras compañías en adoptar y promover activamente los microservicios a través de múltiples proyectos de código abierto.. 8.

(18) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 2.3.2.. Microservicios en las pequeñas empresas. Las exigencias en el mundo tecnológico actual cada vez son mayores, especialmente en el campo de las aplicaciones web. Constantemente se exige más rapidez, más funcionalidad y más disponibilidad, necesitando en consecuencia una mayor inversión. Las grandes corporaciones multinacionales pueden asumir estos grandes gastos que, sin embargo, resultan inalcanzables para las pequeñas o medianas empresas [10]. A pesar de ello, la continua evolución de las tecnologías y la explotación de los datos obliga a todo tipo de empresas a desarrollar sus soluciones lo más rápido posible. Esta situación les exige el uso de buenas prácticas y metodologías que agilicen los ciclos de vida, haciendo de los microservicios una opción realmente interesante y beneficiosa. Sin embargo, si los microservicios no se adoptan adecuadamente ni se alinean con las necesidades particulares de cada proyecto y organigrama, pueden contribuir a aumentar la brecha tecnológica entre las pequeñas empresas y las grandes organizaciones.. 2.3.3.. Microservicios en las administraciones públicas. Las administraciones públicas suelen caracterizarse por una inmovilidad organizativa y tecnológica que entorpece la creación de nuevas aplicaciones o la migración a nuevas tecnologías. Sin embargo, al igual que las empresas privadas, deben ser capaces de afrontar el desarrollo continuo de soluciones software para encargarse, en este caso, de servir y atender a la ciudadanía. Existen proyectos financiados por la UE como la plataforma CLIPS [11] para promover la implantación de servicios basados en la nube. El proyecto ofrece un mercado de servicios y microservicios en la nube en la que administraciones públicas, empresas o incluso ciudadanos pueden buscar aplicaciones, elegir las que mejor se ajustan a sus necesidades y crear sus propios sistemas. En paralelo, también se ofrece la posibilidad de anunciar y vender servicios y se fomenta la divulgación y reutilización de tecnologías ya desarrolladas por otras administraciones públicas. De este modo, las administraciones públicas y las empresas pueden dedicarse a la innovación en lugar de gastar sus recursos en infraestructura y tecnología. La creación de la plataforma se llevó a cabo mediante el traslado de los antiguos sistemas de información de las administraciones públicas y la reutilización de los recursos existentes siguiendo la arquitectura de los MS, lo que ha dado lugar a un sistema que no sólo ofrece microservicios, sino que también se basa en ellos, reforzando doblemente la apuesta por este paradigma.. 9.

(19) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 2.4.. Spring Framework. En términos informáticos, un framework o marco de trabajo, es un conjunto de código y herramientas reutilizables, configurables y relacionables que sirve de guía para la creación de soluciones software. Dentro de un framework se pueden encontrar librerías, plugins o módulos software que facilitan procesos como la autenticación o la presentación de la información. Sus objetivos principales son: agilizar el proceso de desarrollo, reutilizar código y promover el uso de buenas prácticas. El desarrollo de un sistema software suele acarrear el uso de más de un framework, ya que el desarrollador muchas veces acostumbra o necesita hacer uso de componentes que proceden de diferentes marcos para dar con la solución adecuada [12]. Esto conlleva una tarea extra al tener que gestionar e integrar componentes de diferentes orígenes, lo que puede ocasionar problemas de compatibilidad y versionado.. Ilustración 3: relación típica entre diversos frameworks.. Bajo la premisa de eliminar la carga de trabajo que supone la gestión particular de cada framework surge Spring, una plataforma de código abierto desarrollada por Pivotal para el desarrollo de aplicaciones Java y que da soporte a la generación, gestión e integración de los objetos a través del uso de anotaciones o ficheros XML.. Ilustración 4: gestión de varios frameworks por parte Spring.. 10.

(20) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 2.4.1.. Spring Boot. Spring Boot es una parte del framework de Spring destinada especialmente al desarrollo ágil de aplicaciones y que se fundamenta en el paradigma de desarrollo Convention over Configuration. El paradigma CoC tiene como objetivo reducir el número de decisiones que tiene que tomar el programador sobre las áreas de desarrollo de una aplicación. Para ello, el entorno de trabajo (sistemas, librerías, lenguaje, etc.) asume por defecto una gran cantidad de situaciones lógicas (nombrado, configuración, etc.) haciendo el desarrollo más sencillo, rápido y productivo a costa de una curva de aprendizaje mayor [13]. Cuando la convención es suficiente para lograr el comportamiento deseado, se hace innecesario cambiar el comportamiento por defecto, pero en caso contrario, el desarrollador puede alterar el patrón preestablecido y adaptarlo a sus necesidades2. Para el caso de uso que concierne al proyecto, conviene destacar que Spring Boot permite crear aplicaciones web sin necesidad de ejecutar un contenedor de servlets como Tomcat o un servidor de aplicaciones, ya que el propio Spring Boot incluye un Tomcat embebido que se despliega automáticamente durante la ejecución. Como se ha mencionado anteriormente, la principal cualidad de Spring Boot es la facilidad que presenta a la hora de configurar los proyectos, especialmente en la etapa inicial. A continuación, se indican otras de sus características más relevantes [14]: x. Permite la creación de aplicaciones de Spring independientes.. x. Integración directa de Tomcat o Jetty que elimina la necesidad de desplegar ficheros WAR.. x. Creación sencilla de POMs a través de Spring Starter para simplificar aún más la configuración de los proyectos: al indicar el tipo de aplicación la herramienta genera un proyecto Maven (o Gradle) con las dependencias necesarias.. x. Configuración automática en la mayoría de los casos: no requiere configuración mediante ficheros XML.. x. Otras herramientas de producción inmediata para métricas, comprobación de estado o configuración externa.. x. Elimina posibles conflictos relacionados con el versionado de las dependencias gracias a la autoconfiguración.. 2. Por ejemplo, si se tiene una clase «producto» en el modelo, por convención la tabla correspondiente en la base de datos se denominará «productos». Sólo si el desarrollador se aparta de esta convención y opta por llamar a la tabla «artículos», deberá escribir código para referenciar ese nombre.. 11.

(21) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 2.4.2.. Spring Cloud (Consul). La conexión entre los distintos servicios de una aplicación monolítica suele realizarse mediante ficheros de configuración estáticos dónde se indica el dominio y el puerto de cada uno. Esta forma de configuración es suficiente si se tiene un número reducido de servicios que no suelen sufrir grandes variaciones tras su despliegue. Sin embargo, con la llegada de los microservicios, esta forma de configuración resulta insuficiente por su distribución y dinamismo, ya que estos pueden replicarse o cambiar de ubicación según las necesidades de cada momento y, a pesar de ello, la aplicación debe seguir siendo operativa. Para dar solución a estas necesidades y otras muchas referentes a los sistemas distribuidos, Spring Framework cuenta con un módulo llamado Spring Cloud que permite construir rápidamente algunos de los patrones más comunes como la gestión de configuración, el descubrimiento de servicios, el enrutamiento inteligente, la elección de liderazgo o la monitorización de los servicios. La coordinación de sistemas distribuidos suele dar lugar al uso de patrones repetitivos, pero gracias a Spring Cloud se puede levantan rápidamente los servicios y las aplicaciones que implementan tales patrones. Así, los servicios pueden funcionar adecuadamente en cualquier entorno distribuido, desde el propio equipo de desarrollo hasta centros de datos o plataformas gestionadas como Cloud Foundry [15]. Para hacer posible la coordinación y comunicación de los diferentes servicios, Spring Cloud cuenta con herramientas como Consul o Netflix, que gracias a la funcionalidad del Service Discovery permiten a los microservicios conocer la ubicación del resto de procesos [16]. Para el caso particular de Spring Cloud Consul (que es la opción adoptada en el proyecto), las diferentes aplicaciones deben contactar con el agente de Consul para que este puede gestionar toda comunicación con el resto de instancias.. Ilustración 5: diagrama de registro de servicios.. 12.

(22) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 2.5. 2.5.1.. Otras tecnologías JWT. El concepto JSON Web Token, más conocido por sus siglas en inglés JWT, es un estándar abierto para la transmisión de información en un objeto JSON [17] de manera: •. Segura: ya que la información está firmada digitalmente y puede ser verificada. La firma se puede realizar mediante una contraseña secreta usando el algoritmo HMAC o bien mediante RSA a través de una clave pública y otra privada.. •. Compacta: debido a su pequeño tamaño, los tokens JWT se pueden enviar a través de una URL, un a petición POST o dentro de una cabecera HTTP. Además, su reducido tamaño también ayuda a que la transmisión sea más rápida.. •. Autónoma: el token contiene toda la información necesaria sobre el usuario, eliminando la necesidad de consultar la base de datos más de una vez.. Estos tokens se estructuran como un contenedor formado por tres partes: -. Cabecera: la cabecera o encabezado consta generalmente de dos partes: el tipo de token, que es JWT, y el algoritmo de hashing utilizado, como por ejemplo HMAC SHA256 o RSA.. -. Cuerpo: conocido también como payload o claims, es la parte que contiene la información propiamente útil del token. Esta pieza aloja las declaraciones acerca de la entidad (normalmente el usuario) y otros metadatos necesarios para la interacción con el sistema. Los claims o demandas pueden ser públicas, reservadas o privadas. Estas últimas son las que se usarán en el proyecto para almacenar ciertos datos sobre el usuario.. -. Firma: este componente se crea a partir del encabezado y el cuerpo codificados, una clave secreta y el algoritmo especificado en la cabecera. Esta firma se utiliza para verificar que el remitente del JWT es legítimo y para asegurarse de que el mensaje no ha sido modificado durante el trayecto. JSON Web Token. Sistema de encriptación. Cabecera Cuerpo. Lógica de negocio. Firma. Firma de seguridad. Ilustración 6: estructura de un JSON Web Token.. 13.

(23) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. El resultado final son tres cadenas de caracteres en Base64 separadas por puntos que se pueden transmitir fácilmente en entornos HTML y HTTP.. Ilustración 7 :aspecto de un JWT encriptado.. Los JSON Web Token pueden emplearse en cualquier intercambio de información que requiera cierto grado de seguridad, ya que la firma y el encriptado permiten confirmar la procedencia y el contenido de los tokens. Sin embargo, se ha vuelto muy popular en los últimos años como método de autenticación gracias a que cuenta con múltiples beneficios en comparación con el resto de mecanismos existentes (cookies, sesiones, etc.). Para autenticarse, el usuario simplemente proporciona sus credenciales durante el logueo y el servidor devuelve un JWT que se almacena localmente, sin necesidad de crear ninguna sesión. Cuando el usuario quiera acceder a una ruta o recurso protegido, se debe enviar el token en la cabecera Authorization de la petición (normalmente siguiendo el patrón Bearer3). Las principales ventajas de este sistema que han sido claves para su elección en el proyecto son: •. Permite la autenticación sin tener que hacer uso de sesiones, por lo que en ningún momento se almacena información del usuario.. •. No necesita protección frente a CSRF.. •. Conlleva una menor carga en el servidor de autorización y no se necesita almacenar las sesiones.. A pesar de las ventajas mencionadas, existe una serie de desventajas que se deben tener en cuenta durante la implementación: •. Es más vulnerable a ataques XSS.. •. El token de acceso puede contener claims obsoletas.. •. El token puede llegar a adquirir un gran tamaño dependiendo del número de claims almacenados.. 3. Bearer: este patrón sigue el estándar de autorización <tipo><credenciales> introducido por el W3C en la primera versión de HTTP, con la particularidad de que el token va precedido por el término Bearer.. 14.

(24) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 2.5.2.. Maven. Las librerías son ficheros que proporcionan una serie de funciones que simplifican el trabajo del programador y que suelen ser un elemento fundamental de cualquier desarrollo software [18]. Normalmente, el desarrollador necesita saber qué librería usar y qué versión en particular. Además, una librería puede depender de otras para operar adecuadamente, lo que obliga a tener que gestionarlas para que no entren en conflicto entre sí. Programa. Librería A. Librería B. Ilustración 8: dependencia de un programa en las librerías.. Para lidiar con este problema, existe una herramienta llamada Maven que se ocupa de la gestión de las distintas librerías mediante el uso de los llamados Artefactos o Artifacts, que son elementos que engloban las clases de una librería y la información necesaria para su óptima gestión (grupo, nombre, versión, otras dependencias…). Los Artifact se definen en el archivo POM.xml, que es el fichero que almacena toda la información del proyecto. Artifact Grupo Nombre Versión. Otras dependencias Ilustración 9: estructura de un Artifact.. Maven, por tanto, se encarga de descargar mediante un sencillo artefacto todas las librerías declaradas en el fichero POM.xml. Además, también hace posible la descarga de documentación relativa a estas librerías u otras dependencias subyacentes que no hayan sido definidas intencionadamente por el desarrollador. En última instancia, Maven usa las librerías descargadas para la compilación del proyecto.. 15.

(25) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 2.5.3.. Postman. Los servicios se probarán y depurarán con el programa Postman, que es un cliente HTTP para probar servicios web. Su sencillez es tal, que solo se necesita indicar la URL del recurso, el método HTTP deseado y las cabeceras en caso de que sean necesarias. También permite establecer el tipo de autenticación en caso de que sea solicitada por el servicio, pudiendo elegir entre múltiples opciones como identificación básica, OAuth y otras. Esta herramienta registra y guarda automáticamente las peticiones lanzadas para reusarlas sin necesidad de construirlas de nuevo. Asimismo, también permite la creación de colecciones personalizables dónde guardar las distintas peticiones, lo que se traduce en un incremento inmediato de la productividad. Para el caso concreto del proyecto, se ha creado una colección por cada microservicio en las que se almacenan las distintas llamadas a los recursos expuestos.. Ilustración 10: captura del programa Postman.. 16.

(26) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 3. Desarrollo 3.1.. Especificación de Requisitos Software. Seguidamente, se incluye la Especificación de los Requisitos basándose en las pautas marcadas por los estándares IEEE 830 e IEEE 29148. En ella se concretan las principales funcionalidades, se definen los requisitos y se tienen en cuenta las posibles restricciones y particularidades del proyecto.. 3.2.. Descripción general. El propósito de la aplicación, como ya se ha mencionado en el apartado introductorio del proyecto, es componer la plataforma de un e-commerce a través de diversos microservicios que hagan posible parte de la funcionalidad que se espera con este tipo de sistemas. Por lo tanto, la aplicación ha de ser capaz de gestionar los datos relativos a los usuarios/clientes, productos, compras, pedidos, así como el registro y login de las cuentas.. 3.3.. Funciones del sistema. La aplicación deberá cumplir una serie de funcionalidades que podrán verse ampliadas tras la finalización del proyecto (ver apartado de Desarrollo Futuro). Cada funcionalidad está asociada a una necesidad de negocio, por lo que se desarrollará un microservicio para cada una. De esta manera, la aplicación en su conjunto deberá: Microservicio Gestionar la página de bienvenida Gestionar las cuentas de usuario. Capacidades Mensaje de bienvenida Alta a un usuario/cliente Login/acceso al usuario/cliente Cambio de los datos de una cuenta Listado de una cuenta Borrado de una cuenta Listado de todas las cuentas (admin) Borrado de todas las cuentas (admin) Gestionar el catálogo de productos Listado de los productos disponibles Listado de las categorías disponibles Listado de un producto en particular Listado de los productos por color Listado de todos los productos de una categoría Inclusión de un producto en el catálogo (admin) Cambio de un producto del catálogo (admin) Borrado de un producto en concreto (admin) Borrado de todos los productos (admin). 17.

(27) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Gestionar el carrito de la compra. Gestión de pedidos. Inclusión de productos al carrito Listado del contenido del carrito Borrado el contenido del carrito Confirmación del carrito Creación de un pedido Listado de pedidos Borrado del historial de pedidos. Tabla 2: principales funcionalidades del sistema.. 3.4.. Restricciones del sistema. Las condiciones que se deben tener en cuenta durante la implementación del sistema son: •. Un nombre de usuario o username solo puede estar asociado a un usuario/cliente, por lo que el identificador único de cada cuenta es el username.. •. Se tienen dos tipos de cuentas: una de administrador que puede realizar todas las operaciones y otra de usuario con el acceso limitado a los recursos propiamente accesibles por un cliente.. 3.5.. Particularidades y dependencias. Los microservicios que implementen la lógica planteada podrán estar desplegados en distintas máquinas (ver apartado de Desarrollo futuro) una vez concluido el proyecto, por lo que el funcionamiento íntegro del sistema dependerá en última instancia del estado de las mismas. Asimismo, estas máquinas deberán contar con Spring Boot y Spring Consul para la ejecución y comunicación de los microservicios.. 3.6.. Requisitos. ID Función R_01 Bienvenida. Descripción La aplicación contará con un microservicio de bienvenida que proporcionará un mensaje personalizado según el e-commerce. Tabla 3: requisitos relacionados con el microservicio de bienvenida.. ID Función R_02 Alta cuenta. Descripción Se tendrá un microservicio de cuentas para dar de alta a un usuario mediante sus datos personales (nombre, apellido, username, dirección) y una contraseña. 18.

(28) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. R_03 Acceso cuenta R_04 Listado de cuenta R_05 Modificación de cuenta R_06 Eliminación de cuenta R_07 Listado de todas las cuentas R_08 Borrado de todas las cuentas. Se dará acceso a los clientes mediante el username y la contraseña Cada usuario podrá ver la información personal asociada a su cuenta. Cada usuario podrá modificar o actualizar los datos relativos a la cuenta personal Un usuario podrá dar de baja su cuenta solicitando que se elimine del sistema El administrador del sistema podrá listar todas las cuentas almacenadas El administrador del sistema podrá borrar todas las cuentas. Tabla 4: requisitos relacionados con el microservicio de cuentas.. ID Función R_09 Consultar categorías R_10 Consultar productos R_11 Consultar productos de una categoría R_12 Consultar un producto R_13 Consultar productos por color R_14 Añadir producto. R_15 Modificación de producto R_16 Borrado de producto R_17 Borrado de todos los productos. Descripción El microservicio de catálogo debe ser capaz de mostrar las categorías disponibles El sistema podrá proporcionar una lista con todos los productos disponibles El correspondiente microservicio debe ser capaz de devolver los productos de una categoría en particular El sistema será capaz de mostrar un producto en concreto a través de su nombre o id El sistema permitirá listar todos los productos de un mismo color. El administrador podrá incluir un nuevo producto en el sistema incluyendo nombre, categoría, precio y color. El administrador podrá cambiar los datos de cualquier producto. El administrador será capaz de borrar cualquier producto a partir de su id. El administrador podrá vaciar el catálogo.. Tabla 5: requisitos relacionados con el microservicio de catálogo.. ID Función R_18 Añadir producto al carrito. R_19 Eliminar contenido del carrito. Descripción La aplicación cuenta con un microservicio de carrito que añade el producto al carrito del usuario solicitante. Cada usuario podrá vaciar el contenido de su carrito.. 19.

(29) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. R_20 Listar carrito R_21 Confirmar carrito. Cada cliente podrá observar el contenido de su carrito. La confirmación del carrito supondrá la generación automática de un pedido. Tabla 6: requisitos relacionados con el microservicio de carrito.. ID Función R_22 Creación de un pedido. R_23 Listado de un pedido R_24 Listado de pedidos R_25 Eliminación del historial de pedidos. Descripción El sistema contará con un microservicio de pedidos que hará posible la creación de un pedido a partir de los datos del carrito El usuario podrá solicitar al sistema información referente a un pedido a través del id del pedido El sistema devolverá todos los pedidos realizados por un cliente específico El microservicio podrá limpiar el registro de pedidos de un cliente particular.. Tabla 7: requisitos relacionados con el microservicio de pedidos.. 20.

(30) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 3.7.. Diseño. El diseño de la arquitectura debe fundamentarse en los microservicios y, siguiendo la línea pautada en la especificación de requistos software, deberá abarcar un total de cinco microservicios encargados de las cinco áreas de negocio básicas de un comercio electrónico, es decir, gestión de bienvenida, gestión de cuentas de usuario, gestión del catálogo de productos, gestión del carrito de los usuarios y gestión de los pedidos. Cada uno de los cinco microservicios, al ser una arquitectura basada en los microservicios, tendrá asociada una base de datos independiente para gestionar sus diferentes datos. El diseño también debe reflejar el componente de unión entre los microservicios, que hará posible la comunicación entre ellos en caso necesario, como por ejemplo la confirmación del carrito que requerirá realizar una llamada al microservicio de pedidos para crear un nuevo pedido a partir de la información recogida en el carro. Recapitulando, sería necesario: -. Cinco microservicios, uno por cada una de las áreas de negocio identificadas.. -. Cada microservicio tiene su base de datos para gestionar los datos que maneja.. -. La pieza que permita la comunicación entre los microservicios (Spring Consul).. Así, una primera visión de la arquitectura quedaría como se representa a continuación:. Servidor de registros (Spring Consul). Microservicio de bienvenida. Microservicio de cuentas. Microservicio de catálogo. Microservicio de carrito. Microservicio de pedidos. BD de cuentas. BD de productos. BD de carritos. BD de pedidos. Ilustración 11: visión general de la arquitectura del sistema.. 21.

(31) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Entrando más en detalle, el diseño de los distintos microservicios planteados queda: Microservicio de bienvenida. Controlador REST. Servicio. Spring Consul (registro de servicios y balanceo de carga). Cliente. Objeto/ Entidad Microservicio de cuentas. Controlador REST. Servicio. DB. Objeto/ Entidad Controlador REST. Microservicio de catálogo. Servicio. DB. Objeto/ Entidad Controlador REST. Microservicio de carritos. Servicio. DB. Objeto/ Entidad Microservicio de pedidos. Controlador REST. Servicio. DB. Imagen 3: visión general de de la la arquitectura delsistema. sistema. Ilustración 12: visión general arquitectura del Como se puede ver en la figura superior, cada microservicio (salvo el de bienvenida) consta de un controlador que se encarga de recibir las peticiones sobre cada uno de los recursos llamando al servicio encargado según la acción solicitada. El servicio hace uso de una base de datos propia del microservicio para obtener o aplicar los datos de la solicitud. Todo ello está supervisado por Spring Consul, que es el encargado de gestionar los microservicios y coordinar la comunicación entre ellos. Así, cada servicio define su ubicación registrándose en esta herramienta, que se encarga además de recibir las peticiones del cliente y redirigirlas a cada uno de los microservicios.. 22.

(32) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 3.8.. Implementación. La implementación de los servicios se ha llevado a cabo mediante el lenguaje de programación Java. Además, para facilitar la comprensión del código, se ha optado por comentarlo siguiendo Javadoc.. 3.8.1.. Microservicio de bienvenida. Este servicio es el más sencillo de todos los abarcados en el proyecto. Su función es la de lanzar un mensaje de bienvenida a los visitantes y usuarios del e-commerce. Consta de:. - La aplicación de Spring Boot correspondiente encargada de desplegar el servicio. - Una sencilla API gestionada por un controlador REST y encargada de recibir las peticiones http sobre el recurso (welcome-microservice/welcome o welcomemicroservice/).. - Una vez el controlador ha recibido la petición de acceso al recurso, un servicio se encarga de lanzar el mensaje. Este servicio accede al fichero de propiedades y toma la variable indicada que contiene el mensaje.. - El mensaje, como se ha mencionado, se encuentra en el archivo application.properties ya que así se facilita un posible cambio del mensaje sin tener que acceder a ninguna base de datos. El acceso al recurso de bienvenida es público y no tiene ninguna restricción, por lo que es accesible a cualquiera sin necesidad de autenticación previa.. 23.

(33) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Ilustración 13: implementación del microservicio de bienvenida.. 24.

(34) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 3.8.2.. Microservicio de catálogo. El servicio de catálogos se encarga de mostrar los productos disponibles y listarlos de diferentes maneras, según la petición recibida. Asimismo, también permite gestionar los distintos productos y categorías, pudiendo añadirlos o eliminarlos si se cuenta con una determinada autorización (es decir, si se es administrador). De esta manera, este servicio cuenta con los siguientes componentes:. - La aplicación de Spring Boot correspondiente encargada de desplegar el servicio. - Una API gestionada por un controlador REST que se encarga de recibir las distintas peticiones http sobre los recursos:. o catalogue-microservice/catalogue/products o catalogue-microservice/catalogue/categories o catalogue-microservice/catalogue/products/id=x o catalogue-microservice/catalogue/products/name=x - Una vez el controlador ha recibido la petición de acceso al recurso, un servicio se encarga de devolver los datos o realizar la acción solicitada.. - Un repositorio que extiende de JpaRepository que facilita las operaciones sobre la base de datos al contar con funciones como guardado (save) o búsqueda (find).. - Un filtro encargado de autenticar los tokens y determinar su nivel de acceso al sistema para bloquear o permitir el acceso a los recursos protegidos.. 25.

(35) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Ilustración 14: implementación del microservicio de catálogo.. 26.

(36) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 3.8.3.. Microservicio de cuentas. Este microservicio es el encargado de proporcionar dos de las funcionalidades con mayor relevancia dentro del sistema: el registro de usuarios y el login. Estas dos funciones comparten la misma aplicación de Spring Boot ya que se encuentran alojadas dentro del mismo microservicio. Una misma aplicación de Spring Boot lo engloba entero. En cuanto al registro de nuevas cuentas, el usuario necesita proporcionar un nombre de usuario, una contraseña y otros datos personales. El nombre de usuario es único dentro del sistema y ninguna otra cuenta puede estar asociado a uno ya existente. Consta de los siguientes elementos propios:. - Una API REST gestionada por un controlador que recibe las peticiones http sobre cada uno de los distintos recursos:. o account-microservice/accounts. o account-microservice/accounts/id=x. - Una vez el controlador ha recibido la petición de acceso al recurso, un servicio se encarga de lanzar el mensaje.. - Un repositorio que extiende de JpaRepository que facilita las operaciones sobre la base de datos al contar con funciones como guardado (save) o búsqueda (find). Además, cuenta con un método adicional para buscar una cuenta a partir del nombre de usuario haciendo uso de la anotación @Param.. 27.

(37) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Ilustración 15: implementación del registro en el microservicio de cuentas.. 28.

(38) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Por otro lado, el proceso de login es necesario para poder acceder a algunos de los recursos que exponen los microservicios, tales como el carrito de la compra o el acceso a los pedidos. Está compuesto por los siguientes elementos:. - Una API REST gestionada por un controlador que recibe las credenciales del usuario (username y contraseña) sobre la dirección del recurso (accountmicroservice/accounts/login).. - Una vez el controlador ha recibido las credenciales de la cuenta, un filtro se encarga de comprobar si los datos recibidos existen en la base de datos de las cuentas y si coinciden con los datos de alguna de las cuentas.. - En caso afirmativo, un autentificador genera un token JWT con información que ayudará a identificar la cuenta y su nivel de acceso durante el resto de peticiones. Este token es enviado al cliente en la cabecera Authorization de la respuesta. Posteriormente, el resto de peticiones deben llevar en la correspondiente cabecera el token devuelto tras el logueo.. 29.

(39) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Ilustración 16: implementación del login del microservicio de cuentas.. 30.

(40) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. El proceso de login y autenticación de los tokens se puede comprender mejor con el siguiente diagrama de secuencia: Microservicio de cuentas. Cliente El cliente se loguea con su correo y contraseña. El filtro de login captura la petición El servicio de cuentas comprueba si existe la cuenta El gestor de tokens crea un nuevo token JWT Se envía el token en la cabecera Authorization de la respuesta El token se envía en la cabecera Authorization El autenticador de tokens descifra el token y obtiene la información necesaria Se envía la respuesta al cliente. Ilustración 17: diagrama de secuencia del login y la autenticación de los tokens.. 31.

(41) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 3.8.4.. Microservicio de carrito. Se tiene también un microservicio dedicado a gestionar exclusivamente los carritos de cada uno de los usuarios. Los usuarios pueden añadir los productos que deseen comprar a su carrito, ver el contenido de su carrito, eliminar su contenido o validarlo para proceder a crear un pedido. Para ello, cuenta de las siguientes partes:. - La aplicación de Spring Boot, que como en el resto de microservicios, tiene como principal la creación del contexto de la aplicación, la búsqueda de los componentes y configuraciones y la agregación de los distintos elementos del path.. - Un controlador REST que recibe las peticiones sobre el recurso: o cart-microservice/cart. o cart-microservice/cart/confirm - Un servicio que contiene las funciones necesarias para devolver la información o acometer la acción requerida sobre el carrito.. - Un repositorio que almacena los elementos que hay en el carrito de cada usuario y sobre los cuales se realizan las operaciones.. 32.

(42) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Ilustración 18: implementación del microservicio de carrito.. 33.

(43) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 3.8.5.. Microservicio de pedidos. Este microservicio tiene la particularidad de que consume datos del microservicio de carrito, ya que cuando un usuario confirma el contenido de un carrito, internamente se genera un pedido para dicho cliente, requiriendo por tanto una llamada a este microservicio. Está constituido por las clases:. - La aplicación de Spring Boot correspondiente encargada de la creación del contexto y la configuración de la aplicación.. - Un controlador REST con una API encargada de recibir las peticiones sobre los siguientes recursos:. o order-microservice/orders o order-microservice/orders/id=x -. Un servicio que con las funciones que realizan la orden recibida por el controlador.. -. Un repositorio, basado en JpaRepository como en el resto de servicios y que se emplea para almacenar toda la información relativa a los pedidos de los usuarios del sistema.. 34.

(44) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Ilustración 19: implementación del microservicio de pedidos.. 35.

(45) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 3.8.6.. Autenticación de tokens. Los microservicios de catálogo, cuentas, carrito y pedidos cuentan con una serie de clases encargadas de autenticar los tokens recibidos:. - Una clase de configuración de seguridad en el que se establecen los recursos tanto públicos como restringidos. Si se recibe una petición sobre una ruta protegida, esta clase la redirige a un filtro.. - Un filtro que recibe las llamadas http sobre los recursos que requieren autenticación. Este filtro es el responsable de descifrar el token para averiguar si dichas credenciales tienen permiso (autorización) para acceder a las rutas, servicios o recursos solicitados.. - Si el token resulta válido se crea un perfil autenticado y se almacena en el contexto de la aplicación para operar posteriormente sobre él.. 36.

(46) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. Ilustración 20: autenticación de los tokens.. 37.

(47) Implementación de un e-commerce 24x7 con ajuste dinámico mediante microservicios. 3.8.7.. Configuración de Spring Consul. Cada microservicio cuenta con un fichero llamado aplication.properties donde se detalla el nombre del servicio y su ubicación. De esta manera, Spring Consul es capaz de comunicar los servicios entre sí a través de un balanceador de carga (Load Balancer) y una plantilla rest (Rest Template), sobre la que se opera cuando un microservicio depende de otro.. Ilustración 21: inserción del Rest Template en el microservicio de carrito.. 38.