Escuela Técnica Superior de Ingeniería de Sistemas...

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


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


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


AlbertoColsFermínyMarianaSalcedoReal Página9


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.


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.



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.


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]



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.


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]



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]


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]



• 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


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



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)


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:



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


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.



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


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



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]


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]



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]


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]



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.


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]



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]


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].



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


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



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.


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



• MicroserviciodeProfesores(ms-professor):

Figura13


• MicroserviciodeMaterias(ms-subject):

Figura14


EnlasFiguras12,13y14sepuedeobservarcómocadamicroserviciocontiene

laestructuradepaquetes correspondientealmóduloquevaa serutilizado comoel

dominiopertinente.


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



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.


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



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.


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


Unefectocolateraldeunirms-professoryms-paysheetesqueyanosetendráelproblema del acoplamiento innecesario que se tenía al tener el DTO de Professorreplicadoenms-paysheet.

Asímismo,eldiagramaERdelabasededatosresultantesepuedeobservaren

laFigura19.



Figura19ERDfinal


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:


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



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).


Página48

Figura25

Jsonconstruidoapartirdeljsonobtenidodelmicroservicioms-subjectydelosjsonsconlainformacióndelosprofesoresobtenidosdelmicroservicioms-employee


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



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.


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



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/


Página52



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.


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.

Escuela Técnica Superior de Ingeniería de Sistemas...

Documents

Transcript of Escuela Técnica Superior de Ingeniería de Sistemas...