UNIVERSIDADPOLITÉCNICADEMADRIDEscuelaTécnicaSuperiordeIngenieríadeSistemasInformáticos
MÁSTERENINGENIERÍAWEBProyectoFindeMáster
Arquitectura de Microservicios con RESTful
AutoresAlbertoColsFermínMarianaSalcedoReal
TutorLuisFernándezMuñoz
Juliode2017
ArquitecturadeMicroserviciosconRESTful
[UPM]MásterenIngenieríaWeb
RESUMEN Desarrollar un sistemade software es un trabajo arduodesde su concepción
hasta su despliegue.Durante todo este proceso se tomanen consideración factorescomolosrequerimientosdelnegocio,laafluenciadeusuariosesperada,laescalabilidaddelsistema,laformaenquesedesplegaráelsistema,entreotrostantosfactores.Sinembargo,apesardequealolargodelprocesodedesarrollodelsistemasetomanencuentacontinuamenteestosfactores,existeunapartedelprocesoqueresultavitalparaelbuendevenirdelsistema:eldiseñodelaarquitectura. Ahora bien, dentro de esta delicada tarea existen dos principales vertientes:optarporunaarquitecturamonolíticamástradicional,uoptarporundiseñoorientadoamicroservicios.EstetrabajobuscaexplicarsobrequétratalaArquitecturabasadaenMicroservicios,lasventajasydesventajasquetieneestetipodediseño,comollevaracaboladivisióndeunsistemaenmicroservicios,yfinalmentecuandodeberíaonoserutilizadaestaarquitectura.
Paraapoyaresta investigaciónydar sustentoa las conclusionesobtenidas setomócomodominiounsistemadeGestiónUniversitaria,pero,al ser tanextensoseescogieron a su vez tres(03) subdominios: gestión de profesores, de materias y denómina. Teniendo en cuenta este dominio, se realizaron tres(03) implementaciones,estascubrenundiseñomonolíticoydosposiblessolucionesbasadasenmicroservicios.Concluidas dichas implementaciones se pasa a resumir qué ventajas poseen y queproblemasfueronencontradosencadauna.
Por último se concluye en que circunstancias es recomendable aplicarmicroserviciostomandocomobaselosresultadosobtenidosanteriormente.
Palabras clave Arquitectura,Microservicio,Spring,RESTful
ArquitecturadeMicroserviciosconRESTful
[UPM]MásterenIngenieríaWeb
ABSTRACT Developing a software system is hardwork from conception to deployment.
Throughoutthisprocess,manyfactorshavetobetakenintoaccount,suchas:business
requirements, expected user inflows, system scalability, how the system will be
deployed,andmanyothers.However,althoughthesefactorsarecontinuallytakeninto
account throughout the development process of the system, there is a part of the
processthatisvitaltothegooddevelopmentofthesystem:architecturedesign.
Withinthisdelicatetasktherearetwomainapproaches:optingforatraditional
monolithicarchitecture,oroptforamicroservice-orienteddesign.Thisworkseeksto
explainwhatisaMicroservicesbasedarchitecture,theadvantagesanddisadvantages
of this type of design, how to carry out the division of a monolithic system into
microservicesone,and,finally,whenthisarchitectureshouldbeused.
In order to support this research and support the conclusions obtained, a
UniversityManagementsystemwastakenasadomain,but,sincethis isareallyvast
domain, three (03)subdomainswerechosen:managementof teachers, subjectsand
paysheet. Taking into account this domain, three (03) implementations were done:
these cover amonolithic design and two possible solutions based onmicroservices.
Once these implementationshavebeencompleted, it ispossible tosummarizewhat
advantagestheyhaveandwhatproblemswerefoundineachone.
Finally, it is concluded in what circumstances it is advisable to apply
microservicesbasedontheresultsobtainedpreviously.
Keywords Architecture,Microservice,Spring,RESTful
ArquitecturadeMicroserviciosconRESTful
[UPM]MásterenIngenieríaWeb
TABLA DE CONTENIDOS Resumen...............................................................................................................4
Palabrasclave....................................................................................................4
Abstract.................................................................................................................6
Keywords...........................................................................................................6
TabladeContenidos.............................................................................................8
Objetivos.............................................................................................................10
Capítulo1:DefinicióndeArquitecturas..............................................................12
ArquitecturaMonolítica..................................................................................12
DiseñoOrientadoaDominio...........................................................................16
ArquitecturabasadaenMicroservicios...........................................................17
BackendForFrontend.....................................................................................28
Capítulo2:HerramientasUtilizadas...................................................................29
Eureka.............................................................................................................29
Zuul..................................................................................................................31
ProtocoloREST................................................................................................32
MySQL.............................................................................................................32
Spring..............................................................................................................32
Node.Js............................................................................................................33
Capítulo3:Implementación...............................................................................34
CasoBase:ArquitecturaMonolítica................................................................35
Iteración1:PrimeraseparaciónenMicroservicios.........................................38
Iteración2:RefactorizacióndelosMicroservicios..........................................44
Bibliografía..........................................................................................................50
ConclusionesyPosiblesAmpliaciones................................................................53
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página9
[UPM]MásterenIngenieríaWeb
Página10
OBJETIVOS LosobjetivosprincipalesdeesteTrabajoFinaldeMásterson:
• Entender en qué consiste un Microservicio y conocer sus características
principales.
• ComprenderenquésituacionesesrecomendableaplicarunaArquitectura
basadaenMicroservicios.
• Comprender lasdistintasmanerasqueexistendedividirunaaplicaciónen
Microservicios.
• CompararunaArquitecturaMonolíticaversusunabasadaenMicroservicios.
• Proponerlabasedeunsistemadegestiónparaprofesoresymateriasbasado
enunaarquitecturademicroservicios.
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página11
[UPM]MásterenIngenieríaWeb
Página12
CAPÍTULO 1: DEFINICIÓN DE ARQUITECTURAS
Arquitectura Monolítica
La arquitectura monolítica es aquella en la que todos los componentes o
módulos de un software se encuentran desarrollados y desplegados en una únicaaplicación. Sin embargo, esto no la limita a no tener dependencias de terceros
desplegadosenservidoresindependientesparapodersatisfacerciertasfuncionalidades
(Ej.manejadoresdecola,manejadoresdebasesdedatos,etc.).[1]
Todalalógicadenegocioestáauto-contenidaensimisma,cuyoscomponentes
estáninterconectadosysoninterdependientes,adiferenciadearquitecturasmodulares
cuyoscomponentesestánpocoacoplados.[2]
VentajasinicialesdelasArquitecturasMonolíticas[3]
• Rápidodesarrolloinicial
Los desarrolladores pueden enfocarse en implementar todas las
funcionalidadessinpreocuparseporlaintegraciónentredistintoscomponentes
endistintosservidores.
• Ubicacióndelcódigofuente
Elcódigofuentedetodalaaplicaciónseencuentraenunúnicopaquete
porloquenavegaratravésdelmismoessencilloutilizandoalgúnIDE(IntegratedDevelopmentEnvironment).
• Fácildespliegue
Sóloesnecesariodesplegarelpaquetedelaaplicaciónenunservidor.
Además,todos los IDEsactualesestánenfocadosaldesarrollodeaplicacionesmonolíticasporlocualesrelativamentesencillogenerarelpaquetelaaplicación
(archivos.WAR,.JAR,.EAR)desdeelmismoIDE.
• Fácildeescalarhorizontalmente
Basta con correr varias copias de la misma en varios servidores
manejadosconunmanejadordecargas.
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página13
DesventajasdelasArquitecturasMonolíticas
Sinembargo,amedidaquelaaplicaciónvacreciendoyelequipodedesarrollo
sevahaciendomásgrande,aparecendiversosproblemasquesevuelvencadavezmás
significativos:
• Dificultaddeadaptación
Laadaptacióndenuevosdesarrolladoresalequipodetrabajotiendea
serlentasielmonolitotienegrantamaño,estoconllevaaquelavelocidadde
desarrollo del equipo se vea afectada. Más aún, si no existe una buena
metodologíadetrabajo,laaplicacióncadavezserámásdifícildeentenderyde
modificar,locualconllevaquecualquiernuevocambioporpartedelosnuevos
desarrolladorespuedaninfluirnegativamenteenlacalidaddelcódigo.[4]
• Incrementoeneltiempodedespliegue
Mientrasmásgrandeseaelmonolito,mástiempotomarálainicialización
del mismo lo cual influye negativamente en la productividad de los
desarrolladores puesto que tendrán que esperar períodos de tiempo más
prolongados para iniciar la aplicación. Esto también influye en el tiempo de
despliegueaproduccióndelaaplicación.
Aunado a esto se tiene el problema de que cualquier cambio que se
realiceenuncomponente(asíestenoafectealosdemáscomponentes)implica
re-empaquetar, re-ensamblar y re-desplegar la aplicación completa,
aumentandolostiemposdeesperadetodoslosmiembrosdelequipo.[4]
• Problemasparaescalareficientementelaaplicación
A pesar de que la aplicación puede escalar horizontalmente
desplegándolaenvariosservidores,existenvariosproblemasconesteenfoque:
o Todaslasinstanciasdelamismatienenaccesoatodaladatalocual
dificultaelcacheodelamismaeincrementalosaccesosamemoria,
ralentizandolaaplicación.
o Siexistealgúnbugenuncomponenteenespecífico(porejemplo,un
memoryleak)estopodríaafectaratodalaaplicación.Además,como
todaslas instanciasdelaaplicaciónsoniguales,elerrorafectarála
disponibilidad global de lamisma sin importar en qué servidor se
encuentredesplegada.
[UPM]MásterenIngenieríaWeb
Página14
o Siunserviciodelaaplicacióneselqueposeemáscargadetrabajoy
sedeseatenervariasinstanciasdeesteúnicamente,estonopodría
serposibleenestetipodearquitectura.
Tomandoporejemplounaaplicacióndeventadeproductos
que tenga tres servicios:ServiciodeClientes,ServiciodeCarritodeVentayServiciodeProductos.EnelcasoqueelServiciodeCarritodeVentarequieramásrecursosparapodermanejarlaspeticionesdelos
clientestendríamosquecrearinstanciascompletasdelaaplicación.[4]
Figura1
Problemaenlaescalabilidadhorizontalcuandosenecesitaescalarunúnicocomponente
Fuente:ElaboraciónPropia
Como puede observarse en la Figura 1, para tener varias
instancias del Servicio de Carrito de Compra se debe instanciar elmonolito en su totalidad, lo cual implica un gasto innecesario de
recursospuestoquelosdemásserviciosnonecesitanserescalados.
• Componentescondistintosrequerimientos
Cada componente del software puede necesitar distintos tipos
derecursos(unopuederequerirmáscapacidaddeprocesamientomientrasotro
más capacidad dememoria), al tener un solomonolito no se podría escalar
verticalmentecadacomponenteindependientementesegúnsusnecesidades.[4]
• Difícildeadaptaranuevastecnologías
Unaarquitecturamonolíticafuerzaalaaplicaciónaestaratadaalmismo
stack tecnológicodesdeel iniciode lamisma.Si sedeseautilizarun lenguaje
distintoparaalgúncomponente,estonopodríaserimplementadopuestoque
laaplicaciónestáatadaaladecisióninicial.[4]
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página15
Además, en caso de tener que cambiar de lenguaje o de frameworkporque el actual se vuelva obsoleto o cambien a grandes rasgos los
requerimientos del sistema, se vuelve más complicado el proceso demigrar
gradualmente la aplicación para adaptarse a las nuevas tecnologías, quizás
teniendoquellegaralpuntodereescribirlaaplicaciónensutotalidadlocuales
unprocesobastanteriesgosoycostoso.
[UPM]MásterenIngenieríaWeb
Página16
Diseño Orientado a Dominio
ElDiseñoOrientado aDominio es un enfoquepara desarrollar softwarepara
necesidadescomplejasconectandoprofundamentelaimplementaciónaunmodeloen
evolucióndelosconceptosbásicosdenegocio.
Tienelassiguientespremisas:
• Elfocoprincipaldelproyectoeseldominioysulalógica.
• Basareldiseñocomplejoenunmodelo.
• Sedeberealizarunacolaboraciónentreelequipotécnicoylosexpertosdel
dominioparairencontrandodemaneraevolutivaelcentrodelproblema
Laspremisasessimple,perohacerusodeellascomodebeser,eneldíaadíaes
complicado. Requiere nuevas habilidades y disciplina, y un enfoque sistemático al
momentodedesarrollarsoftware.
ElDiseñoOrientadoaDominionoesunatecnologíaounametodología.DDD
proporcionaunaestructuradeprácticasyterminologíaparatomardecisionesdediseño
que enfocan y aceleran proyectos de software que se ocupan de dominios
complicados.[5]
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página17
Arquitectura basada en Microservicios
La arquitectura basada en Microservicios es una variante de la arquitectura
orientada a servicios (SOA), cada servicio debe estar finamente separados y se
comunicanentreellosutilizandométodosdecomunicaciónligeroscomopuedeserun
recursoHTTPatravésdeunAPI.[6]
Es una forma particular de diseñar aplicaciones de software como suites deserviciossiendoejecutadocadaunoenunprocesopropioyqueasuvezpuedenser
desplegados de forma independiente, para esto se utiliza toda una maquinaria de
despliegues continuos. Cada Microservicio puede estar implementado utilizando
distintos frameworks, lenguajesdeprogramacióne inclusodiferentes tecnologíasde
almacenamientodedatos.
Aúnnoexisteunadefiniciónexactadeestetipodearquitectura,perosíexisten
unaseriedecaracterísticasquesedebencumplir.
CaracterísticasdeunaArquitecturabasadaenMicroservicios
• Componentizaciónvíaservicios
Un componente se define como una unidad de software que es
independientementereemplazableyactualizable,unejemplosonlaslibrerías.
Los microservicios harán uso de librerías que formarán parte de sus
dependencias,pero,lamaneraenquesellevanacaboloscomponenteseneste
tipo de arquitecturas es separando el software en distintos servicios, que se
comunicarán entre ellos mediante un servicio web o una llamada a un
procedimientoremoto(RPC).
Larazónprincipalparautilizarservicioscomocomponentes,envezde
utilizarloscomolibrerías,esqueestossondesplegablesindividualmente.Siuna
aplicación está compuesta pormúltiples librerías un cambio en una de estas
requeriría que la aplicación completa fuese re-desplegada, en cambio si la
aplicaciónestáseparadaenmicroserviciossiesnecesariomodificaruno, sólo
habríaquedesplegar lanuevaversióndelmicroservicio,porsupuestohabrán
cambiosquenecesitencambiosenmásdeunmicroservicio,pero,estosepuede
minimizaratravésdelímitesdeservicioscohesivosymecanismosdeevolución
enloscontratosdeestos.[6]
[UPM]MásterenIngenieríaWeb
Página18
• Organizaciónentornoalascapacidadesdelnegocio
CadaMicroservicio implementaráunáreadelnegociocontodo loque
estoconlleva:interfazdeusuario,lógicadenegocio,almacenamientodedatosy
cualquier colaboración con algún servicio externo que sea necesaria, como
consecuenciadeestoel equipoencargadodel desarrollodebe serunequipo
multidisciplinario,queseacapazderealizareldesarrollodelasfuncionalidades
requeridas.[6]
• Productosnoproyectos
Elenfoquetradicionalalmomentodellevaracaboeldesarrollodeuna
aplicación es de un proyecto, esto quiere decir que al culminar la
implementacióndelamismaelmantenimientoesrealizadoporotraspersonas
oinclusootraempresayelequipoesdisuelto.
En cambio la visión que se propone con este tipo de arquitecturas es
orientada a producto, dígase, que almomento de comenzar un desarrollo el
equipoesresponsabledeél,desdesuconcepciónhastasumantenimiento.Esto
tambiénvieneligadoconlascapacidadesdenegocio,porqueenvezdeveruna
aplicacióncomoconjuntodefuncionalidadesquesedeberealizar,sevecomo
unarelaciónenlaquesebuscamejorarcontinuamentelacapacidadempresarial
medianteelsoftware.
Este enfoque puede ser utilizado también en una arquitectura
Monolítica,peroporlagranularidaddelosequiposesmássencilloaplicarloen
unaarquitecturadeMicroservicios.[6]
• SmartEndpointsDumbsPipes
Unaaplicaciónbasadaenmicroserviciosdeberserlomásdesacopladay
cohesivaposible,cadaunodebeserdueñodesudominioycomportarsecomo
unfiltroalestilodeUnix(serecibeunasolicitud,seaplicalalógicanecesariay
seproduceunarespuesta).
Estos se pueden comunicar usando un protocolo estilo REST y/o
mensajería ligera, para este último se suele utilizar estructuras sencillas, que
sirvancomounenrutadordemensajescomoporejemplo:RabbitMqoZeroMq,estosfuncionancomounintermediosinlógicayaquelosextremossonlosque
laposeen,queenestecasoseríanlosMicroservicios.[6]
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página19
• AdministraciónDescentralizada
Unadelasconsecuenciasdelaadministracióncentralizadaesquetiende
autilizarunasolatecnología,sehademostradoqueesteenfoquepuedenoser
elmás apropiado, ya queno todos los problemas se solucionande lamisma
manera,porloquetienesentidoqueunasoluciónposeamúltiplestecnologías.
CuandoseseparaunaaplicaciónMonolíticaenmicroserviciossedejala
posibilidaddeseleccionarlamejoropciónparacadaunoaniveldelenguajede
programación,frameworks,librerías,sistemasdealmacenado,etc.
Ademásdeseleccionarconlastecnologíasqueseránutilizadaselequipo
puede definir los estándares que seguirán, se pueden crear librerías o
herramientasqueseanútilesentreequiposquepresentenalgúnproblemaen
común.[6]
• ManejodeDatosDescentralizado
Lamaneramásabstractadeverladescentralizacióndelosdatossignifica
queelmodelo conceptual del “todo” va a cambiar entremicroservicios. Esto
sueleseruninconvenientealintegrarunsistemamuyextenso.
Puedeverseelcasoenquelavisióndeclienteseadistintaenelmódulo
deventasyelmódulodesoporte,por loquepuedeserqueexistanatributos
comunesoaúnpeoratributoscomunesperoconsemánticasdistintas.
Estosuelesucederentreaplicacionesperotambiénsepuedeverdentro
de las aplicaciones, sobre todo cuando las aplicaciones están divididas en
componentes separados. Una manera de verlo es siguiendo la noción de
Bounded Context del Diseño Orientado a Dominio, este divide un dominio
complejoenvariosboundedcontextymapealasrelacionesentreellos.
Asícomosedescentralizanlasdecisionessobreelmodeloconceptual,los
Microservicios descentralizan las decisiones sobre el almacenaje de datos.
Mientrasqueunsistemamonolíticosueletenerunasolabasededatoslógica
para persistir la data, losMicroservicios prefieren que cada uno controle su
propiabasededatos,asíseacondiferentesinstanciasdelmismomanejadorde
basededatos,oinclusoconunsistemadebasededatostotalmentediferente.[6]
• AutomatizacióndeInfraestructura
Las técnicas de automatización de infraestructura han evolucionado
muchísimoatravésdelosúltimosaños,dadaalaevolucióndelanubeyAWSen
[UPM]MásterenIngenieríaWeb
Página20
particularhanreducidolacomplejidaddeconstruir,desplegarylaoperatividad
engeneraldelosMicroservicios.
Muchos de los productos o sistemas que se construyen con
Microservicios son hechos por equipos que tienen bastante experiencia en
ContinuosDelivery,estossuelenutilizarestetipodetécnicasdeformaextensiva.
Cuando se ha utilizado esta técnica de despliegue en aplicaciones
Monolíticas demanera continua hasta hacerlo parte del día a día realizar el
despliegue de más aplicaciones(en este caso Microservicios) debería ser
natural.[6]
• Diseñoparafallos
UnadelasconsecuenciasdeldesarrolloorientadoaMicroserviciosesel
hechoqueestosdebenserprogramadosparasoportarqueotrosfallenyaque
estopuedesucederyelMicroserviciodebesercapazderesponderdelamanera
máseleganteposible.
Yaqueestospueden fallar en cualquiermomento, es importanteque
estosfallossedetectenrápidamenteydeserposiblequeelMicroserviciosea
restauradodemaneraautomática.
Monitorear el comportamiento de los microservicios es sumamente
importanteyaqueayudaaprevenircomportamientosnodeseadosycorregirlos
rápidamente.
Losequiposprocuranrealizarunbuenplanyherramientaspararealizar
el monitoreo y logging para cada Microservicios, tales como tableros que
muestrenelestadodecadaunoyalgunasmétricasqueseanrelevantespara
poderdetectarfallos.[6]
• DiseñoEvolutivo
Las personas que siguen este tipo de arquitecturas, suelen utilizar el
diseñoevolutivoyladescomposiciónenMicroservicioscomounaherramienta
paralosdesarrolladoresquepermitecontrolarloscambiosenlasaplicaciones
sinnecesidaddehacerlosmáslentos.
Un sistema que haya sido creado inicialmente como una aplicación
monolíticapuedeirevolucionandoaMicroservicios,puedehacerlodemanera
progresiva,esdecir,irseparandopocoapocosusmódulosencomponentesy
estos irlos llevando a Microservicios, teniendo aún como su centro una
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página21
aplicación monolítica; o ir agregando funcionalidades en forma de
Microservicios.
Colocarloscomponentescomoserviciosapartepermitenrealizarsalidas
aproduccióndeunamaneramásgranularycontrolada,porejemplo,siserealizó
un cambio solo en un Microservicio no es necesario desplegar la aplicación
completa,convolverdesplegareseMicroservicioessuficiente.[6]
ManerasdedividirunaaplicaciónenMicroservicios
Idealmente un Microservicio debe hacerse cargo de un conjunto de
responsabilidadesreducido.Laresponsabilidaddeunaclasepuedeserdefinidacomola
razóndecambio,yestasolodebetenerunarazóndecambio,estosiguiendoelPrincipio
de Única Responsabilidad[7], por lo que tiene sentido aplicar lo mismo a los
Microservicios.
Sepuedetomarcomoejemplo losserviciosenLinux,porejemplogrep,catofind;cadaunodeestosseencargadeunasolaresponsabilidadynormalmentelohacen
excepcionalmentebien,ademásestossepuedencombinarentresípararealizartareas
complejas, lo que encaja perfectamente con la forma en que se desea que los
Microserviciossecomporten.
No existe una única forma en la que se puede dividir una aplicación en
microservicios,ysepuededecirqueesunprocesoqueseconsideraunarte,peroexisten
estrategiasquesepuedenseguirparallevaracaboestaseparación.Acontinuaciónson
descritas:
• PorCapacidadesdeNegocio
SeconocealasCapacidadesdeNegociocomolaspartesquepermiten
generar valor al negocio, por ejemplo: la gestión de órdenes o la gestión de
cliente; por lo que una de las formas naturales de dividir un sistema sería
justamentesiguiendoesadivisiónqueyaexisteenelnegociocomotal.
Se puede tomar como ejemplo un negocio que tenga las siguientes
CapacidadesdeNegocio:
o Productcatalogmanagement(gestióndecatálogodeproductos)o Inventorymanagement(gestióndeinventario)o Ordermanagement(gestióndeordenes)o Deliverymanagement(gestióndeenvíos)
[UPM]MásterenIngenieríaWeb
Página22
NuestrossistemaestaríacompuestoporunmicroservicioporCapacidad
deNegocio
Figura2
Fuente:Pattern:Decomposebysubdomain
http://microservices.io/patterns/decomposition/decompose-by-subdomain.html
De estamanera podemos obtener una arquitectura estable ya que la
capacidades de negocios cambian muy poco, se puede tener un sistema
cohesivo, poco acoplado con equipos multifuncionales y organizados para
generarvaloralnegocio.[8]
• PorDominio
AldividirpordominiounsistemasedebeseguirelDiseñoOrientadoa
Dominio(DDD[5]ensussiglaseninglés),esteseencuentrabasadoenlosmodelos
deldominio.UnmodelofuncionacomounLenguajeUbicuo[9]queayudaalos
desarrolladoresdelsoftwareacomunicarseconlosexpertosdeldominio.Actúa
tambiéncomolabaseconceptualparaeldiseñodelsoftwareensí,porejemplo
cómo descomponer en objetos o funciones; para ser eficiente un modelo
necesita estar unificado, es decir que sea consistente y que no haya
contradiccionesenel.
ElDiseñoOrientadoaDominioseenfocaenresolverelproblemadeuna
aplicación como su dominio, y este se encuentra conformado por múltiples
subdominios,cadaunodeestoscorrespondenaunapartedistintadelnegocioy
puedenestarclasificadosdelasiguienteforma:
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página23
o Central:esloquediferenciaalnegocio,porlotantoeslapartemás
importantedelaaplicación.
o Soporte: son laspartesque componenelnegocioperono lasmás
resaltantes.
o Genérico:nosonespecíficosdelnegocio.
Podemos tomar un sitio de ventas como ejemplo y obtener dos
subdominiosdeél,comopodríanser:
o Ventas
o Soporte
Por lo que nuestro sistema tendría un microservicio para el área de
VentasyotroparaeláreadeSoportecomolopodemosobservarenlasiguiente
imagen.[9]
Figura3.
Fuente:BoundedContext,
https://martinfowler.com/bliki/BoundedContext.html
VentajasdeunaArquitecturabasadaenMicroservicios
• FronterasdelimitadasentreMódulos
Esteesunbeneficioimportanteperoextraño,porquenohayrazón,en
teoría,porquélosmicroserviciosdebentenerlímitesdemódulomásfuertesque
unmonolito.
Eldesacoplamientoconmódulosfuncionaporqueloslímitesdelmódulo
sonunabarreraparalasreferenciasentremódulos.Elproblemaesque,conun
[UPM]MásterenIngenieríaWeb
Página24
sistemamonolítico, por lo general es bastante fácil de saltarse esta barrera.
Distribuir los módulos en servicios separados hace que los límites sean más
firmes,loquehacemuchomásdifícilencontrarlaformadeevitarlasdivisiones
entremódulos.[11]
• DespliegueIndependiente
Varios desarrollos de microservicio fueron desencadenados por la
dificultad de desplegar monolitos grandes, donde un pequeño cambio en
cualquierpartedelmonolitopodríacausareldespliegueenterofallara.
Un principio clave de microservicios es que los servicios son
componentesy,porlotanto,sondesplegablesdeformaindependiente.Asíque
ahoracuandoserealizauncambio,sólotienequeserprobadoydesplegadoun
sóloservicio.Sifalla,nosehabrácaídotodoelsistema,solamenteelservicioque
hanecesitadouncambio.Despuésdetodo,debidoalanecesidadqueexisteen
este tipo de diseños de diseñar para el fallo, incluso un completo fallo del
componentenodebeimpedirqueotraspartesdelsistemasiganfuncionando.
Elgranbeneficiodelaentregacontinuaeslareduccióndeltiempoen
elcicloentreunaideayelsoftwareenejecución.Lasorganizacionesquehacen
esto pueden responder rápidamente a los cambios del mercado, e incluso
introducirnuevascaracterísticasmásrápidoquesucompetencia.[12]
• DiversidadTecnológica
Puesto que cadamicroservicio es una unidad que se puede desplegar
independientemente,cadaunotieneunalibertadconsiderableensusopciones
de tecnología. Los microservicios se pueden escribir en diferentes lenguajes,
utilizardiferenteslibreríasyutilizardiferentesbasededatos.Estopermitealos
equiposelegirunaherramientaadecuadadependiendodelsistemaadesarrollar,
algunoslenguajesylibreríassonmásadecuadosparaciertostiposdeproblemas.
La discusión de la diversidad técnica amenudo se centra en lamejor
herramienta para el trabajo, pero a menudo el mayor beneficio de los
microservicioseslacuestiónmásbásicadelcontroldeversiones.Enunmonolito
sólosepuedeusarunaversiónúnicadeunalibrería,unasituaciónqueamenudo
conduceaactualizacionesproblemáticas.Unapartedelsistemapuederequerir
unaactualizaciónparausarsusnuevasfuncionalidades,peronopuedeporque
esta actualización rompe otra parte del sistema. Tratar los problemas de
versionado de las librerías es uno de esos problemas que se vuelven
exponencialmentemás difíciles amedida que la base de código se hacemás
grande.
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página25
Conunsistemamonolítico, lasdecisionestempranassobre lenguajesy
marcossondifícilesderevertir.Despuésdemuchotiempodedesarrollo,tales
decisiones pueden bloquear a los equipos en tecnologías incómodas. Los
microserviciospermitenalosequiposexperimentarconnuevasherramientas,y
tambiénmigrargradualmentelossistemasdeunservicioalavezencasodeque
unatecnologíasuperiorsearelevante.[11]
• FacilidadparaEscalar
Dadoqueunaaplicaciónestácompuestademúltiplesmicroserviciosqueno
compartendependenciasexternas,elescaladodeunainstanciademicroservicioen
elflujosesimplificamucho:siunmicroservicioenunflujoseconvierteenuncuello
debotelladebidoalaejecuciónlenta,estemicroserviciosepuedeejecutarenun
servidorpotenteparaunmayorrendimientosiesnecesario,osepuedenejecutar
variasinstanciasdelMicroservicioendiferentesmáquinasparaprocesarelementos
dedatosenparalelo.
Contraste laescalabilidadfácildemicroserviciosconsistemasmonolíticos,
dondeelescalamientonoestrivial;siunmódulotieneunpedazointernolentodel
código, no haymanera de hacer ese pedazo individual de código funcionarmás
rápidamente.Paraescalarunsistemamonolítico,unotienequeejecutarunacopia
delsistemacompletoenunamáquinadiferenteeinclusohaceresonoresuelveel
cuello debotella deunpaso interno lentodentrodelmonolito o incrementar la
capacidaddelservidordondeestásiendoejecutadoelsistema.[11]
DesventajasdeunaArquitecturabasadaenMicroservicios
• Latenciaagregadaporlacomunicaciónentremicroservicios
RendimientogolpeadodebidoaHTTP, serializaciónydeserialización,ysobrecargaenlared.EnlugardelasllamadasAPIprogramáticas,esdecir,realizarunallamadaaunmétododentrodelamismaaplicación,setienequerealizarllamadas HTTP. Esto puede ser incluso más problemático si sus solicitudesresultan en múltiples solicitudes posteriores a otros servicios. Sin embargo,existen enfoques que pueden aplicarse para reducir peticiones en cascada ymejorarlostiemposderespuesta(redundanciadedatosenunabasededatosde servicios y sincronización de datos mediante mensajería o sondeo dealimentación).
• ConsistenciaEventual
Esteesunproblemadeusabilidad, yes casi seguroque sedebea los
peligros de la consistencia final, es decir, que si se realizó una solicitud de
actualización y esta fue recibida por el nodo rosado, pero su solicitud fue
[UPM]MásterenIngenieríaWeb
Página26
manejadaporelnodoverde,hastaqueelnodoverderecibalaactualizaciónde
color rosa, este quedará atrapado en una ventana de inconsistencia.
Eventualmente será consistente, pero hasta entonces el usuario se está
preguntandosialgohaidomal.
AcontinuaciónotroejemplodelproblemadeConsistenciaEventual: • Se hace una petición para eliminar un profesor en un microservicio
Profesor.• SeeliminaelprofesorenProfesoryseenvíaunmensajeparaeliminarlas
instanciasdeliddelprofesorenunmicroservicioMateria. • Al no tener certeza de cuándo se eliminará dicho id podría llevar a
problemas como que se haga una solicitud de los profesores de una
materiaantesdeserborradoelid,yalintentarbuscardichoprofesoren
Profesornosepuedaencontrar.
Inconsistencias como esta son bastante irritantes, pero pueden ser
muchomásgraves.La lógicadenegociospuedeterminartomandodecisiones
sobre información inconsistente, en caso que esto suceda, puede ser
extremadamente difícil diagnosticar lo que salió mal porque cualquier
investigaciónocurrirámuchodespués de que la ventanade inconsistencia se
hayacerrado.
Los microservicios introducen problemas de consistencia eventuales
debidoasuinsistenciaelogiableenlagestióndescentralizadadedatos.Conun
monolito, puede actualizar muchos registros en una sola transacción.
Microserviciosrequierenmúltiplesrecursosparaactualizar,ylastransacciones
distribuidas son mal vistas (por una buena razón). Así que ahora, los
desarrolladores deben ser conscientes de los problemas de consistencia, y
averiguarcómodetectarcuandolascosasestánfueradesincronización.[11]
• Complejidadoperacional
Sercapazdedesplegarrápidamentepequeñasunidadesindependientesesunagranbendiciónparaeldesarrollo,peroponeunapresiónadicionalsobrelasoperaciones yaquemediadocenadeaplicacionesahora se conviertenencientosdepequeñosmicroservicios.Muchasorganizacionesencontraránqueladificultaddemanejartalenjambredeherramientasquecambianrápidamenteessumamentecomplicado.
Estorefuerzaelimportantepapeldelaentregacontinua.Mientrasquelaentregacontinuaesunahabilidadvaliosapara losmonolitos,unoqueescasisiemprevale lapenaelesfuerzoparaconseguir,seconvierteenesencialparaunaconfiguracióndemicroservicios.Simplementenohaymanerademanejardocenas de servicios sin la automatización y la colaboración que fomenta laentregacontinua.Lacomplejidadoperacionaltambiénseincrementadebidoa
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página27
lasmayoresdemandasenlagestióndeestosserviciosyelmonitoreo.Denuevo,unniveldemadurezqueesútilparaaplicacionesmonolíticassehacenecesariosilosexistenmicroserviciosenelsistema.[11]
• Incrementoenelusoderecursos
Laarquitecturademicroservicios reemplaza instanciasdeaplicaciónNmonolíticas con instanciasde serviciosNxM.Si cada servicio seejecutaen supropia JVM (o equivalente), que suele ser necesario aislar las instancias,entonceshaylasobrecargadeMvecescomomuchostiemposdeejecuciónJVM.Además,sicadaservicioseejecutaensupropiaVM(porejemplo,instanciadeEC2),comoeselcasoenNetflix,lasobrecargaesinclusomásalta.[12]
[UPM]MásterenIngenieríaWeb
Página28
Backend For Frontend
Esteconceptoesmásunasoluciónaunproblemaenespecíficoqueunconcepto
ensí,altrabajarconmicroserviciosexistencasosenlosquellamaraunsoloservicio
webnoessuficienteparaobtenertodalainformaciónnecesaria,porejemplosiexiste
unservicioparaelmanejodeInventarioyotroparaelmanejodeProductos,perose
quieredesplegarenlainterfazgráficalainformacióndelosProductosconsuInventario.
Paraestetipodesituacionesenlasquelainterfazgráficadebehacerpeticiones
amásdeunservicioydependiendodeloqueesteretornesolicitarciertofragmentode
información, se puede realizar un Backend for Frontend, este backend recibirá laspeticionesquerequierandeinformacióncompuestaeiráacadaMicroservicioquesea
necesariopararetornarlainformacióncompleta.
OtrousoparalosBackendForFrontendescuandoseposeendistintostiposdeclientes(móviles,web..)enestoscasoslainformaciónqueseesperarecibirencadauno
de estos no suele ser la misma, por lo que una solución es crear un backendespecializadoparacadatipodeclientequesedeseesoportaryesteseráelencargado
desolicitarymanipularlainformaciónquesearequerida.
Alagregarunacapaextraalsistemasecorreelriesgoqueéstacomienceatener
lógicaquenolecorresponda,porloquesedebetenermuchocuidadoennoagregar
lógicadenegocioenlosBackendForFrontend,estossolodebenencargarsedeentregarla información de cierta manera para una experiencia de usuario particular, no de
realizarlógicadenegocioquedeberíaencontrarseenlosMicroservicios.[13]
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página29
CAPÍTULO 2: HERRAMIENTAS UTILIZADAS
Eureka
Eureka es un servidor basado en el protocolo REST desarrollado por Netflix,
utilizadoparaelregistroylocalizacióndemicroservicios,balanceodecargaytolerancia
afallos.LafuncióndeEurekaesregistrarlainformacióndelasdiferentesinstanciasde
microserviciosexistentesdelecosistema.[14]
Parapoderregistrardichainformación,cadamicroserviciodurantesuarranque
se comunicará conel servidor Eurekaparanotificar queestádisponible, dóndeestá
situado y susmetadatos. Luego de registrarse, continuarán notificando a Eureka su
estadocada30segundos(estanotificaciónsedenominaheartbeats).SidespuésdetresperiodosEurekanorecibenotificacióndedichomicroservicioloeliminarádelregistro.
Delamismaformaunavezvueltosarecibirtresnotificacionesconsideraráelservicio
disponibledenuevo.[15]
Los clientes (microservicios registrados) de Eureka podrán recuperar la
informacióndeotrosmicroserviciosregistradosparaasíconocersulocalizaciónypoder
comunicarseconellos.Dichainformaciónderegistrosecacheaenelcliente.Además
Eurekasepuedeconfigurarparafuncionarenmodoclústerdondevariasinstanciaspeerintercambiaránsuinformación.Esto,juntoalcacheodelainformaciónderegistroen
losclientesdaaEurekaunaaltatoleranciaafallos.
VentajasdeutilizarEureka
• Abstraccióndelalocalizaciónfísicadelosmicroservicios:cualquiermicroservicio
queseaunclienteEurekasólonecesitaconocerelidentificadordelmicroservicio
alquedeseainvocaryEurekaresolverásulocalización.
Estosignificaquenoimportaenquéambienteestédesplegadoelservicio
(desarrollo,producción,prueba,etc.),Eurekadevolveráalclientelalocalización
delosmicroserviciosdelambienteespecificadoporesteenlaconfiguracióndel
mismo.Esdecir,siundesarrolladorestáprobandolocalmenteunafuncionalidad
y necesita conectarse con unmicroservicio desplegado en el ambiente local,
Eureka resolverá dicho requisito; así mismo, si el desarrollador (desde un
ambiente local)deseaconectarsealmismomicroservicioperodesplegadoen
ambientedeproducción,bastaconindicarleaEurekadequéambientesedesea
obtener la información del microservicio y se encargará de devolver la
localizaciónypuertosdeeste.[15]
[UPM]MásterenIngenieríaWeb
Página30
• Conocerelestadodenuestroecosistemademicroservicios:Eurekaproporciona
unpaneldecontrolquepermiteverlosmicroserviciosexistentesactualmente
enelregistro.[15]
Figura4
PaneldecontroldeEureka
Fuente:http://meuslivros.github.io/microservices-flexible-software-architectures/text/part0019.html
• Sepuedeconfigurarcomoclústerincrementandonotablementesutoleranciaa
fallos. Esto quiere decir que en caso de que un servidor de Eureka no esté
disponible, los clientes podrán comunicarse con otro de los servidores para
obtenerlainformacióndeseada.
• Eureka proporciona soporte a multiregión, pudiendo definir diferentes
agrupaciones de microservicios. En la figura 4 se explica cómo puede ser
desplegadounclústerdeEurekaenunaregión.Existeunclústerporregióny
estesólosabelainformacióndelosregistrosqueseencuentrenenlasinstancias
desplegadasenestaregión.
Los servicios se registran en una de las instancias del clúster y dicha
informaciónesreplicadaatodoslosnodosdelmismo.Deestaformasemejora
la tolerancia a fallos puesto que, en caso de que uno de los nodos no esté
disponible,unclientepuedecomunicarseconcualquieradelosnodosyaquela
información de registro de todos los clientes está replicada en todos los
nodos.[15]
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página31
En la Figura 5 se puede observar la arquitectura de multiregión
desplegadaporNetflix.
Figura5
ArquitecturamultiregióndesplegadaporNetflixFuente:DocumentaciónEureka
https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance
Zuul
Zuuleslapuertaprincipalparatodaslassolicitudesdedispositivosysitiosweb
albackenddelaaplicacióndestreaming.Siendouncomponenteexpuestoalpúblico,Zuul está construido para permitir enrutamiento dinámico, monitoreo, resiliencia yseguridad.
Elenrutamientoesunaparteintegraldeunaarquitecturademicroservicio.Porejemplo,/api/usersseasignaalserviciodeusuarioy/api/shopseasignaalserviciodetienda.ZuulesunenrutadorbasadoenJVMyequilibradordecargadelladodelservidordeNetflix.
Elvolumeny ladiversidaddel tráficode laAPIdeNetflixavecesdan lugaraproblemasenelambientedeproducciónquesurgenrápidamenteysinprevioaviso.Necesitamosunsistemaquenospermitacambiarrápidamenteelcomportamientoparareaccionaranteestassituaciones.
Zuulutilizaunagamadediferentestiposdefiltrosquenospermiteaplicarrápidayágilmentefuncionalidadanuestroserviciodeborde.Estosfiltrosnosayudanarealizarlassiguientesfunciones:[16]
• Autenticación y seguridad: identificación de requisitos de autenticación paracadarecurso.
• Insightsymonitoreo:seguimientodedatosyestadísticassignificativos.
[UPM]MásterenIngenieríaWeb
Página32
• Enrutamiento dinámico: enrutamiento dinámico de las peticiones a losdiferentesbackend.
• Pruebasdeestrés:aumentargradualmenteeltráfico.• Desconexiónde carga: asignación de capacidad para cada tipo de solicitud y
solicituddedescarte.• Manejo de respuestas estáticas: construyendo algunas respuestas
directamente.• Resilienciamultiregión:solicitudesdeenrutamientoenlasregionesAWS.
Zuulcontienemúltiplescomponentes:
• Zuul-core:libreríaquecontienelafuncionalidadprincipaldecompilaryejecutarfiltros.
• Zuul-simple-webapp:aplicaciónwebquemuestraunejemplosimpledecómoconstruirunaaplicaciónconzuul-core.
• Zuul-netflix: libreríaqueañadeotroscomponentesdeNetflixOSSaZuul -porejemplo,utilizandoRibbon[17]paralassolicitudesdeenrutamiento.
• Zuul-netflix-webapp:aplicaciónwebqueagrupazuul-coreyzuul-netflixenunpaquetefácildeusar.
Protocolo REST
LaTransferenciadeEstadoRepresentacional(eninglésRepresentationalStateTransfer) o REST es un estilo de arquitectura software para sistemas hipermedia
distribuidoscomolaWorldWideWeb,tambiénconocidocomoservicioswebRESTful,estospermitenrealizarsolicitudesasistemasexponenestosservicios,paraaccedery
manipular un recurso web usando un conjunto de acciones predefinidas y que no
poseenestado.[18]
MySQL
MySQLesunsistemadegestióndebasededatosrelacionaldesarrolladoporOracle
Corporationyestáconsideradacomolabasededatosdecódigoabiertomáspopular
delmundo[19],yesunadelasmáspopularesengeneraljuntoaOracleyMicrosoftSQL
Server,sobretodoparadesarrollosweb.
Spring
Creado por Rod Jhonson en 2003 bajo la licencia Apache 2.0, Spring es el
frameworkmáspopularparaeldesarrollodeaplicacionesbasadoenJavapuestoque
permite crear aplicaciones de alto rendimiento, fáciles de probar y con código
reutilizable.SibienlascaracterísticasfundamentalesdeSpringFrameworkpuedenserusadasencualquieraplicacióndesarrolladaenJava,existenvariadasextensionespara
laconstruccióndeaplicacioneswebsobrelaplataformaJavaEE.[20]
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página33
Está organizado por módulos independientes y puede integrarse con otros
frameworks.
• SpringFramework:Apoyobásicoparalainyeccióndedependencias,gestióndetransacciones,aplicacionesweb,deaccesoadatos,mensajería,pruebas.
• SpringData:Proporcionaunmodelodeprogramaciónamigableparaelacceso
dedatos.Esteesunproyectoparaguasquecontienemuchossub-proyectosque
sonespecíficosdeunabasededatosdada(relacional,norelacional,enlanube).
• Spring Boot: Simplifica la creación de aplicaciones de Spring embebiendo los
serviciossubyacentesenlaaplicación(servidorweb,motorBD...).
Node.Js
Node.Jsesunaplataformadedesarrolloconstruidasobrelamáquinavirtualde
Javascript V8 desarrollada por Google. Mientras que los motores de Javascript
tradicionalmentesonejecutadosenelnavegadordel ladodelcliente, las libreríasde
Node.JsestánenfocadasaconstruiraplicacionesdelladodelservidorenJavascript.
Node.Js es un entorno en tiempo de ejecución multiplataforma asíncrono
orientadoaeventos.Permitemanejarmúltiplesconexionessimultáneamente,yluego
que cada petición concluye, Node entra enmodo descanso hasta recibir la próxima
petición.
ElhechoqueNode.Jsestádiseñadosinelmanejodehilosnoimplicaquenose
puedanaprovecharlosmúltiplesnúcleosdesuentorno.Losprocesoshijossepueden
generarmediante el uso delmétodo child_process.fork() y están diseñados para serfácilesdecomunicarseconestosmétodos.Construidosobreesamismainterfazestáel
módulo de clúster, que le permite compartir sockets entre procesos para permitir
balanceodecargasobresusnúcleos.[21]
[UPM]MásterenIngenieríaWeb
Página34
CAPÍTULO 3: IMPLEMENTACIÓN
EnprimerainstanciaseseleccionóundominiopararealizaresteTrabajodefin
deMáster, siendoeldeGestiónUniversitariaelelegido,pero,siendotanextensose
limitóatressubdominios:
• GestióndeProfesores.
• GestióndeMaterias.
• GestióndeNómina.
Figura7
DiagramadeClasesdeldominioFuente:Elaboraciónpropia
Teniendo en cuenta este dominio, se comenzó el desarrollo de este trabajo
basándoseenunArquitecturaMonolítica,luegosefueiterandosobreestasoluciónyse
llegóaunaArquitecturafinalbasadaenMicroservicios.
Laarquitecturaqueseproponeessólodelladodelservidor.Aunqueestapuede
serutilizadaparaeldesarrollodelainterfazgráfica,paraefectosdeestetrabajosólose
realizaráeldesarrollodelservidor.ComosemencionóanteriormenteseutilizaráSpring
Frameworkparaeldesarrollodelaaplicación,MySQLcomomanejadordebasededatos
yEureka[14].
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página35
Caso Base: Arquitectura Monolítica
Como se dijo anteriormente el desarrollo de esta solución se inició con una
ArquitecturaMonolítica,esdecir,lostres(03)subdominiosseleccionadosseencuentran
dentrodeunamismaaplicación.
Laaplicaciónfueestructuradadelasiguientemanera:existeunmóduloporcada
subdominioydentrodecadamóduloseencuentranloscomponentesnecesariospara
implementarlasfuncionalidadesrequeridas.
Cadamódulosedivideen:
• Service
• Entity
• REST
• Repository
• Exception
• Converter
Acontinuaciónsepuedeverlaestructuraquesesiguióparacrearestecasobase.
Figura8
DiagramadepaquetesdelaaplicaciónMonolíticaFuente:Elaboraciónpropia
[UPM]MásterenIngenieríaWeb
Página36
Enlafigura8sepuedeobservarcómocadamóduloposeeunpaqueteRESTque
asuvezcontieneunpaqueteDTO,enestepaqueteseagrupan lasclasesquesirven
comolarepresentacióndeladataqueseesperarecibirenunasolicitudvíaunservicio
webolarespuestaqueestedebeproveer.Cadaunadeestasclasesrecibenelnombre
deDTO.
Labasededatosqueseplanteaparaestaprimerafase,poseelassiguientes
tablas:
Figura9
DiagramaERDdelaaplicaciónMonolíticaFuente:Elaboraciónpropia
Para este caso base se plantea una arquitectura de despliegue que estáconformadapor:unservidorwebquealbergarálaaplicación,unservidordebasededatosyelclientequesedeseecomunicarconlaaplicación,enlaFigura10sepuedeapreciardichadistribución.
Figura10
DiagramadedesplieguedelaaplicaciónMonolíticaFuente:Elaboraciónpropia
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página37
DesventajasdeestaArquitectura
• Mantenibilidad
Unsistemadegranescalacomoes lagestiónUniversitariasueletener
unabasedecódigodegrantamaño,estoafectadirectamentealadificultadde
entenderelproyecto,derealizarnuevasmodificacionesodecorregirerrores.
Además,sedeberesaltarquealnohaberunaseparacióndeserviciosestricta,la
modularidad suele perderse con el tiempo y esto también incrementa la
dificultad de entender cómo se debería implementar correctamente una
funcionalidadnueva.
• DespliegueContinuo
Yaqueunaaplicaciónmonolíticanecesitaserdesplegadaensutotalidad
cadavezquesequierapublicarunanuevafuncionalidad,oalgúncambiodelas
actuales, sin importar el (o los) componente que se haya visto afectado, los
riesgosquesecorrenal realizarundesplieguesonmuchomásaltosporesta
misma razón. Esto suele ser un problema por ejemplo para el desarrollo de
interfazdeusuario,quesuelennecesitarcambiosfrecuentes.
• Escalabilidad
Tomandoencuentaeldominioutilizadosepuedepresentarelcasoen
queunmóduloesmásdemandadoqueotro,porejemploelmódulodenómina,
porloquelomásconvenienteseríaaumentarlacapacidaddelservidorparaese
móduloenparticular,peroaltenertodoelsistemaenunasolaaplicaciónesto
noesposible(comosepuedeapreciarenlaFigura10),porloquesetendríaque
aumentar la capacidadde servidor para toda la aplicacióno crear unanueva
instanciadeesta,enamboscasosexisteundesperdicioderecursos.
[UPM]MásterenIngenieríaWeb
Página38
Iteración 1: Primera separación en Microservicios
Luego de desarrollar una aplicación utilizando una arquitectura
monolítica,ahorapasamosarealizarunadivisiónenmicroservicios.
La primera división que se realizó fue separar los tres subdominios en un
microserviciocadauno,quedandoasíeldiagramaER:
Figura11
DiagramadeBasedeDatosparaestaprimeradivisiónenMicroserviciosFuente:Elaboraciónpropia
La primera división que se realizó fue separar los tres subdominios en un
Microservicio cada uno, es decir, que cada uno de los microservicios tendrá una
estructuradepaquetessimilaralaquevimosenelpuntoanterior,acontinuaciónse
muestracadaestructura:
• MicroserviciodeNóminas(ms-paysheet):
Figura12
Fuente:Elaboraciónpropia
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página39
• MicroserviciodeProfesores(ms-professor):
Figura13
Fuente:Elaboraciónpropia
• MicroserviciodeMaterias(ms-subject):
Figura14
Fuente:Elaboraciónpropia
EnlasFiguras12,13y14sepuedeobservarcómocadamicroserviciocontiene
laestructuradepaquetes correspondientealmóduloquevaa serutilizado comoel
dominiopertinente.
[UPM]MásterenIngenieríaWeb
Página40
Figura15
EspecificacióndeclasespertenecientesacadapaqueteDTOdecadamicroservicioFuente:Elaboraciónpropia
EnlaFigura15seencuentraeldetalledelasclasesqueposeeelpaqueteDTOde
cada Microservicio, estos contienen los DTOs correspondientes a su dominio. Sin
embargo, como puede observarse en la imagen, en esta solución se tuvieron que
agregar las distintas clases ajenas a su dominio necesarias para poder devolver las
respuestasquecontenganinformaciónanidada.Estoocurreen:
• ms-subject: cuando se solicita la lista de profesores para unamateria, se
necesita el DTO deProfessorpara poder agregar dicha información en la
respuesta.
• ms-professor: cuando se solicita la lista dematerias para un profesor, se
necesita el DTO de Subject para poder agregar dicha información en la
respuesta.
• ms-paysheet:cuandosesolicitalanóminadeunprofesor,serequiereelDTO
deProfessor.
Cadamicroserviciosedesplegarádemanera individual.Estosepuedellevara
cabodedistintasmaneras:desplegandocadaunoenunservidordistinto;ejecutarlos
todosovariosenunmismoservidor(alseraplicacionesdistintascadaunaestaríasiendo
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página41
ejecutada en un proceso distinto); o podrían ser ejecutados como contenedores de
Dockerenunmismoservidoroenmúltiplesservidores.
Figura16
DiagramadedespliegueparaestadivisiónenMicroserviciosFuente:Elaboraciónpropia
Comosepuedeobservaren laFigura16cadamicroservicioesunaaplicación
independientedondecadaunoposeesupropiabasededatos,asísegarantizaquecada
unoseadueñodesuinformaciónylapuedatratardelamaneraenqueseanecesaria.
AdemássedesplegóunservidordeZuulqueseencargarádelredireccionamientodelas
peticiones de parte del cliente y, un servidor de Eureka que se encargará de la
localización de los servicios para realizar un balanceo de carga e intercomunicar las
diferentesinstanciasdemicroservicios.
Ventajasdeesteenfoquerespectoalmonolítico
Estasoluciónsolventalosproblemasquefueronencontradosenlapropuesta
anterior:
• La escalabilidad vertical ya no es un inconveniente puesto que se puede
asignar recursos según convenga al microservicio que posea una mayor
demandaporpartede losusuarios.Porotro lado, también se solventael
problemadelaescalabilidadhorizontalyaquesiesnecesariocrearnuevas
instancias,en lugarde incrementar lascapacidadesdelservidor,sepuede
hacersinproblema,comosepuedeobservarenlaFigura17.
[UPM]MásterenIngenieríaWeb
Página42
Figura17
ComparacióndeescalabilidadhorizontalFuente:https://martinfowler.com/articles/microservices.html
• Los riesgos que se corrían al momento de realizar Despliegue Continuo se
reducenengranmedida,yaquenoesnecesariohacerunredesplieguecompleto
delaaplicaciónporcualquiercambio.Enestecasodeestudio,sims-professorfuemodificado,solamenteesnecesarioconstruirydesplegarestemicroservicio
mientrasquelosdemásnotendríanquepasarporestosprocesos.
• Lamantenibilidadpormicroserviciosevemejorada,yaqueunequiposólose
debepreocuparpormantenerymejorarunmicroservicio,envezdetenerque
conocerymanipularunaaplicaciónentera.
• Ademássedebeagregarqueunadelasventajasdetenerunaarquitecturade
esteestiloesquesepuedeseleccionarlatecnologíaquemejorseadaptealas
necesidades de cada microservicio. Por ejemplo, si params-paysheet fuesenecesario generar reportes sumamente pesados de procesar, se puede
investigarcuáltecnologíaseadaptamejoraesterequerimientoeimplementar
este servicio de esta manera. Mientras que para ms-subject capaz no esnecesarioalgotanelaboradoysepuedeutilizarunframeworkmássencillo,ésta
esunagranventajaquenosproveeutilizarMicroservicios.
Problemasencontradosaresolver
• División de los microservicios: Uno de los mayores problemas al dividir un
monolitoocomenzarunsistemautilizandoMicroservicios,esidentificarquetan
granular debe ser cada servicio, es decir, que tan pequeño debe ser un
Microservicio. Cada uno debe encargarse de un conjunto nomuy grande de
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página43
responsabilidades,losuficientementegrandeparanoserunsimpleserviciode
CRUD,perosinperderlaaltacohesiónentresusresponsabilidades.
En este caso se ha hecho una división excesiva, ya que es totalmente
innecesariocrearunmicroservicioporentidadenelsistema,siseplanteaestoa
un sistema que pueda tener 40 entidades, se estaría hablando de una
arquitecturade40microserviciossinmuchalógicadenegocioencadauno.
• ComunicaciónentreMicroservicios:esrealizadaatravésdellamadasHTTP,esto
trae2consecuenciasprincipales:
o Siseestárealizandounapeticiónquerequiereinformacióndemásdeun
Microserviciobienseaalmomentoderealizarlasolicitudoalmomento
de obtener la respuesta, se agrega una pequeña latencia que en la
solución anterior no existía ya que toda la información necesaria se
encontrabaenlamismaaplicación,peroahoraesnecesariosolicitarla
datafaltantealmicroservicioresponsable.Paraestetipodeproblemas
sepuedeimplementarlacomunicaciónentreserviciosvíaunenrutador
demensajescomosemencionóanteriormente.
o Como tanto ms-subject como el de ms-paysheet tienen el DTO deProfessor,cualquiercambioeneste“contrato”enelms-professortendríatendría que ser replicado en los antes mencionados, ya que cada
microserviciotendríaqueactualizarestaclaseparamantenerelcontrato,
locualtambiénimplicaríarealizarunnuevodespliegue.Estorompecon
elconceptodebajoacoplamiento,altacohesión.
Aunado a esto, esta actualización, además de no debería ser
responsabilidaddeestosmicroserviciosporestarfueradesudominio,en
caso de que no haya una comunicación efectiva entre los equipos de
desarrolloynosellevenacaboloscambiospertinentes,ocurriránfallos
innecesarios.
EsteproblematambiénloencontramosconelDTOdeSubjectqueseencuentraenms-professor.
• Porúltimo,sindudaalgunahayunincrementoenelusoderecursos,aunque
mejoraprovechadosestonoquitaelhechoqueenvezdecorrerporejemplo
unamáquinavirtualdeJava (JVM)seesténutilizandoNsegún lacantidadde
microserviciosqueesténimplementadosenJava.
[UPM]MásterenIngenieríaWeb
Página44
Iteración 2: Refactorización de los Microservicios
Enestaiteraciónsebuscósolventarlosproblemasqueseconsiguieronluegode
hacerelprimerintentodeseparacióndelaaplicaciónenMicroservicios.
El primer problema atacado fue el de la extrema granularidad de cada
microservicio. La idea al separar por Dominio es agrupar los conceptos similares o
relacionadosparaquecadamicroserviciotengaunaaltacohesión,sinembargoestono
implicasepararcadatabladelabasededatosenunmicroservicioespecíficocomose
hizo en la primera iteración. Por esto se procedió a unir las funcionalidades de los
microserviciosms-professoryms-paysheet,puesto que ambos conceptos estánmuy
relacionadosentresi(unanóminanopuedeexistirsinunprofesoralqueestéasignada),enunnuevomicroserviciodenominadoms-employee.
En la Figura 18 se puede observar la estructura resultante al unir los
funcionalidadesdelosms-professoryms-paysheetenelmicroservicioms-employee.
Figura18Diagramadepaquetesdelmicroservicioms-employee
Fuente:Elaboraciónpropia
Unefectocolateraldeunirms-professoryms-paysheetesqueyanosetendráelproblema del acoplamiento innecesario que se tenía al tener el DTO de Professorreplicadoenms-paysheet.
Asímismo,eldiagramaERdelabasededatosresultantesepuedeobservaren
laFigura19.
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página45
Figura19ERDfinal
Fuente:Elaboraciónpropia
Eldiagramadedespliegue(afaltadelaúltimamodificaciónqueseexponemásadelante)quedaríacomoestáexpuestoenlaFigura20.
Figura20
DiagramadedesplieguedelosmicroserviciosFuente:Elaboraciónpropia
El siguiente problema resuelto fue el del alto acoplamiento entre los
microserviciosms-subjectyms-employeederivadode ladecisiónde tenerelDTOdeProfessorenms-subjectparapoderdevolverlalistademateriasconsusprofesores,así
comoladecisióndequems-employee(ms-professor,enlaiteraciónanterior)tuvieraelDTOdelaclaseSubjectparadevolverlistademateriasparaunprofesor.
EnprimerlugarseprocedióaremoverelDTOdeProfessordems-subjectyelDTOdeSubjectdelmicroservicioms-employee,quedandoladistribucióndelosDTOsdelasiguienteforma:
[UPM]MásterenIngenieríaWeb
Página46
Figura21
EspecificacióndeclasespertenecientesacadapaqueteDTOdecadamicroservicioFuente:Elaboraciónpropia
Luego, se siguió el patrón de Backends For Frontends y se creó un tercermicroserviciodenominadoms-composite,quetendráunaresponsabilidad:
• ComponerlosjsonsolicitadosenlasllamadasGETquerequierenobtenerobjetosdedistintosmicroserviciosytransformarlosparadevolverlarespuestaesperada
porelcliente.
EldiagramadedespliegueresultanteeselexpuestoenlaFigura22.
Figura22
DiagramadedesplieguefinaldelaarquitecturaFuente:Elaboraciónpropia
Sinembargo,estenuevomicroservicionofueimplementadoutilizandoelmismo
frameworkqueenlosanteriorespuestoque,apesardequeSpringpermiteelmanejo
de objetos del tipo JsonNode con lo cual se podrían manipular las respuestas o
solicitudessinnecesidaddetenerunDTOdefinido,existenherramientasconlasquese
puedehacerestacomposicióndemaneramássencilla.
Por esto se decidió implementar estemicroservicio enNode.Js ya que no esnecesarioconocerdetalladamentelaestructurainternadelosjsondevueltosporcadamicroservicio,elms-compositesólodebeobtenerlosyarmarunnuevo jsonqueseráretornado al cliente. Elms-composite es capaz de recibir un objeto de clase A del
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página47
microservicio X y unobjetode claseBdelmicroservicio Y sin importar la estructura
internadecadaobjeto,paraluegocomponerunnuevojsonconlainformacióndeseada
de cada uno, ya sea transformando parte de la información, obteniendo atributos
específicosocombinandolosdosobjetosdirectamente.
Para mostrar más claramente el punto anterior se puede observar el
procedimientoquerealizaelms-compositeparaobtenerunamateriaconlosprofesores
quelaimparten:
1. El cliente solicita la materia con sus respectivos profesores al ms-composite.
2. ms-compositerealizaunallamadaalmicroservicioSubjectparaobtenerlainformacióndeleinformacióncompletadalamateriamáslalistade
idsdelosprofesoresasociadosaella(Figura23).
Figura23
JsonobtenidodelmicroservicioSubjectconinformacióndelamateriaylistadeprofesoresFuente:Elaboraciónpropia
3. El ms-composite solicita al microservicio ms-employee la lista deprofesorescorrespondientesalos idsobtenidosenlallamadaanterior
(Figura24).
Figura24
JsonconlalistaconlainformacióndelosprofesoressolicitadosFuente:Elaboraciónpropia
4. Porúltimo,ms-compositecreaunnuevoobjetoconlainformacióndela
materiaylainformacióncompletadetodoslosprofesoreselcualserá
devueltoalcliente(Figura25).
[UPM]MásterenIngenieríaWeb
Página48
Figura25
Jsonconstruidoapartirdeljsonobtenidodelmicroservicioms-subjectydelosjsonsconlainformacióndelosprofesoresobtenidosdelmicroservicioms-employee
Fuente:Elaboraciónpropia
Comosepuedeobservar,deestamanera se rompeconelacoplamientoque
existíaentrelosdosmicroservicioslocualnospermiteevitarhacerunbuildnuevodelms-subjectencasodequesemodifiqueelDTOdeProfessorenelms-employee,delamismaformaquetambiénseevitahacerunbuildnuevodems-employeecuandocambie
elDTOdeSubject.
Problemasencontrados
Apesardequeenestaiteraciónselograronsolventarvariosdelosproblemas
identificadosen la iteraciónpasada,aúnsepresentan inconvenientes inherentesa la
arquitecturabasadaenmicroservicios.Paraempezar,losproblemasdelalatenciaentre
la comunicación de microservicios y del uso de recursos (ambos explicados en la
iteración anterior). Sumado a esto se presentan se evidenciaron los siguientes
problemas:
• ComunicaciónentrelosMicroserviciosAdiferenciadeunaaplicaciónhechaenunaArquitecturaMonolíticaen la
quetodoelsistemaesa interconectado, losdistintosmicroserviciosnotienen
unaconexióndirectaentresi,porloquelosdesarrolladorestienenqueinvertir
tiempoextradedesarrollodiseñandoeimplementandolavíadecomunicación
entre estos. Estas vías de comunicación pueden ser realizada a través de
llamadasRESTfulodecolasdemensaje.
• ComunicaciónentrelosequiposdedesarrolloLosdesarrolladoresdebeninvertirunacantidaddetiempoconsiderable
en establecer los contratos de comunicación entre los microservicios.
Además, a pesar de que en el presente proyecto no se presentó dicho
problema por ser de un alcance tan corto, si el proyecto crece y existen
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página49
numerosos microservicios desarrollados por varios equipos de
desarrolladores, se deben crear mecanismos de comunicación lo
suficientemente efectivos y eficientes para transmitir todos los cambios
realizadosalosdiversosgrupos.
[UPM]MásterenIngenieríaWeb
Página50
BIBLIOGRAFÍA 1. MonolithicApplication.RecursoWeb.Disponibleen:
https://www.wikiwand.com/en/Monolithic_application
2. MonolithicArchitecture.RecursoWeb.Disponibleen:http://whatis.techtarget.com/definition/monolithic-architecture
3. Monolithicvs.MicroservicesArchitecture.RecursoWeb.Disponibleen:https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59
4. Pattern:MonolithicArchitecture.RecursoWeb.Disponibleen:
http://microservices.io/patterns/monolithic.html
5. WhatisDomainDrivenDesign?.RecursoWeb.Disponibleen:http://dddcommunity.org/learning-ddd/what_is_ddd/
6. Microservices.RecursoWeb.Disponibleen:
https://martinfowler.com/articles/microservices.html
7. Martin,RobertC.(2003).AgileSoftwareDevelopment,Principles,Patterns,andPractices.PrenticeHall.p.95
8. Pattern:Decomposebybusinesscapability.RecursoWeb.Disponibleen:http://microservices.io/patterns/decomposition/decompose-by-business-capability.html
9. Pattern:Decomposebysubdomain.RecursoWeb.Disponibleen:http://microservices.io/patterns/decomposition/decompose-by-subdomain.html
10. UbiquitousLanguage.RecursoWeb.Disponibleen:
https://martinfowler.com/bliki/UbiquitousLanguage.html
11. MicroserviceTrade-Offs.RecursoWeb.Disponibleen:https://martinfowler.com/articles/microservice-trade-offs.html
12. Pattern:MicroserviceArchitecture.RecursoWeb.Disponibleen:http://microservices.io/patterns/microservices.html
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página51
13. Newman,Sam(2015).BuildingMicroservices.O’Reilly.p.71-72
14. EurekaataGlance.RecursoWeb.Disponibleen:https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance
15. MicroserviciosSpringCloud:Arquitectura.RecursoWeb.Disponibleen:
https://www.paradigmadigital.com/dev/quien-es-quien-en-la-arquitectura-de-microservicios-spring-cloud-12/
16. Zuul.RecursoWeb.Disponibleen:
https://github.com/Netflix/zuul/wiki
17. Ribbon.RecursoWeb.Disponibleen:https://github.com/Netflix/ribbon/wiki
18. WebServicesArchitecture.RecursoWeb.Disponibleen:
https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest
19. OracleMySQL.RecursoWeb.Disponibleen:https://www.oracle.com/mysql/index.html
20. JesúsBernal.TransparenciasutilizadasenelcursoBack-endconTecnologíasdeCódigoAbiertodelMásterdeIngenieríaWeb.UniversidadPolitécnicadeMadrid,Madrid,España(2017).
21. AboutNode.Js.RecursoWeb.Disponibleen:https://nodejs.org/en/about/
[UPM]MásterenIngenieríaWeb
Página52
ArquitecturadeMicroserviciosconRESTful
AlbertoColsFermínyMarianaSalcedoReal Página53
CONCLUSIONES Y POSIBLES AMPLIACIONES En el presente informe se realizó un trabajo de investigación sobre la
Arquitectura Monolítica y la Arquitectura Basada enMicroservicios. Inicialmente se
presentaron las características de cada una, sus ventajas y desventajas teóricas, y
estudiaronlasdistintasformasdedividirunmonolitoenmicroservicios.Posteriormente
seprocedióponerenprácticadicha teoría implementandoenprimera instanciauna
aplicación para la gestión de materias, profesores, y nóminas de la universidad
basándoseenlaArquitecturaMonolítica,paraluegopasararealizarladivisióndeesta
entresmicroservicios(ms-subject,ms-paysheet,yms-professor).Porúltimo,luegode
analizarlosproblemasqueseencontraronalrealizarladivisiónanterior,seprocedióa
refinarla,dandocomoresultadodosmicroservicios(ms-subjectyms-employee).
Alfinalizarlaimplementaciónsepudieronobservarmásclaramentelasventajas
ydesventajasdelaArquitecturaBasadaenMicroservicios.Entrelasventajasobservadas
podemosmencionarqueexistenfronterasmásfirmesentrecadamóduloporelhecho
deestarenaplicacionesseparadas;sepuedenrealizardesplieguesindependientespor
cadamicroservicio;cadamicroservicio,alserdueñodesupropiodominio,puedeser
implementarsedelamaneramásconvenienteparasatisfacersusnecesidades,cadauno
tiene total control sobre las decisiones de implementación propias (como en qué
lenguajeoframeworkseráimplementadooquemanejadordebasededatosseadapta
mejorasusnecesidades);asícomoexistemayorfacilidadparaescalartantohorizontal
comoverticalmentecadamicroservicio.Porotrolado,entrelasdesventajasseevidenció
que hay una mayor latencia por la comunicación entre los microservicios, existe el
problemadelaconsistenciaeventual,hayunincrementoenlacomplejidadoperacional
causadoporelincrementodeaplicacionesquesetienenquedesplegarymonitoreara
diferenciade laarquitecturamonolíticaen laqueúnicamentesedebe manejaruna
aplicación,locualtambiénconllevaaunincrementoenelusoderecursos.
Enbaseatodoestosepuededecirquenoexisteunaregladeoroalmomento
detomarladecisióndequétipodearquitecturaimplementar(monolíticaobasadaen
microservicios),sinoquesedebentomarciertasconsideracionesrespectoalosproylos
contradedichaarquitectura.Tomandoestoenconsideración,sepuederecomendarel
usodemicroserviciosenlossiguientescasos:
• Cuandohaypartesdelaaplicaciónqueseanmáspropensasatenerunalto
consumoderecursosporloqueseríanecesarioescalarlasindividualmente,
yaseahorizontaloverticalmente.
• Cuandoeldominioesmuyextensooesunaaplicaciónmuygrandeporloque
setendránmuchosequiposdetrabajoenfocadosendesarrollarlosmódulos.
[UPM]MásterenIngenieríaWeb
Página54
• Cuando el proyecto es de largo recorrido ya que se asegura que la
productividad perdida al inicio del desarrollo, se verá compensada por el
aumentodeproductividadalteneracadaequipodedesarrollotrabajando
enunaaplicaciónindependiente.
Posibles Ampliaciones
Respectoalateoríaexpuestaenelpresenteinformesepodríaahondarencómo
realizar las pruebas de las funcionalidades que impliquen comunicación entre
microservicios,asícomocómopuedeserelmanejodetemasdeseguridad.
Respectoalaaplicaciónfinalserecomiendanlassiguienteampliaciones:
• Ampliareldominiodelsistema.
• Incluirpruebas.
• Incluirseguridadcomoelmanejodesesionesypermisos.
• Mejorarelmanejodeexcepciones.