Microserveis

En enginyeria de programari, una arquitectura de microserveis és un patró arquitectònic que organitza una aplicació en una col·lecció de serveis poc acoblats i de granularitat fina que es comuniquen a través de protocols lleugers. Aquest patró es caracteritza per la capacitat de desenvolupar i implementar serveis de manera independent, millorant la modularitat, l'escalabilitat i l'adaptabilitat. Tanmateix, introdueix una complexitat addicional, especialment en la gestió de sistemes distribuïts i la comunicació entre serveis, cosa que fa que la implementació inicial sigui més difícil en comparació amb una arquitectura monolítica.^[1]

Definició

No hi ha una definició única i universalment acordada dels microserveis. Tanmateix, generalment es caracteritzen per un enfocament en la modularitat, amb cada servei dissenyat al voltant d'una capacitat empresarial específica. Aquests serveis estan dèbilment acoblats, es poden desplegar independentment i sovint es desenvolupen i escalen per separat, cosa que permet una major flexibilitat i agilitat en la gestió de sistemes complexos. L'arquitectura de microserveis està estretament associada amb principis com el disseny basat en dominis, la descentralització de dades i governança, i la flexibilitat d'utilitzar diferents tecnologies per a serveis individuals per satisfer millor els seus requisits.^[2][3]

Ús

És habitual que s'adoptin arquitectures de microserveis per a aplicacions natives del núvol, computació sense servidor i aplicacions que utilitzen la implementació de contenidors lleugers. Segons Fowler, a causa del gran nombre de serveis (en comparació amb les implementacions d'aplicacions monolítiques), el lliurament continu descentralitzat i DevOps amb monitorització holística de serveis són necessaris per desenvolupar, mantenir i operar aquestes aplicacions de manera eficaç.^[4] Una conseqüència (i una justificació) de seguir aquest enfocament és que els microserveis individuals es poden escalar individualment. En l'enfocament monolític, una aplicació que admet tres funcions s'hauria d'escalar en la seva totalitat, fins i tot si només una d'aquestes funcions tingués una restricció de recursos.^[5] Amb els microserveis, només cal escalar el microservei que admet la funció amb restriccions de recursos, cosa que proporciona beneficis d'optimització de recursos i costos.^[6]

El febrer de 2020, l'informe d'investigació de mercat de microserveis al núvol va predir que la mida del mercat global d'arquitectura de microserveis augmentaria a una taxa de creixement anual composta (CAGR) del 21,37% del 2019 al 2026 i arribaria als 3.100 milions de dòlars el 2026.^[7]

Arquitectura basada en cel·les en microserveis

L'arquitectura basada en cel·les és un disseny de computació distribuïda en què els recursos computacionals s'organitzen en unitats autònomes anomenades cel·les. Cada cel·la funciona de manera independent, gestionant un subconjunt de sol·licituds alhora que manté l'escalabilitat, l'aïllament de fallades i la disponibilitat.^[8][9][10]

Una cel·la normalment consta de múltiples microserveis i funciona com una unitat autònoma. En algunes implementacions, es repliquen conjunts sencers de microserveis a través de múltiples cel·les, cosa que permet que les sol·licituds es redirigin a una altra cel·la operativa si una experimenta un error. Aquest enfocament pretén millorar la resiliència de tot el sistema limitant l'impacte dels errors localitzats.^[11][12][13]

Algunes implementacions incorporen interruptors dins i entre cel·les. Dins d'una cel·la, els interruptors es poden utilitzar per mitigar les fallades en cascada entre microserveis, mentre que els interruptors entre cel·les poden aïllar les cel·les que fallen i redirigir el trànsit a les que romanen operatives.^[14][15][16]

L'arquitectura basada en cel·les s'ha adoptat en certs sistemes distribuïts a gran escala on l'aïllament de fallades i la redundància són prioritats de disseny. La seva implementació varia en funció dels requisits del sistema, les restriccions d'infraestructura i els objectius operatius específics.^[17][18][19]

Història

El 1999, el desenvolupador de programari Peter Rodgers havia estat treballant en el projecte de recerca Dexter als laboratoris Hewlett Packard, l'objectiu del qual era fer que el codi fos menys fràgil i que els sistemes de programari complexos i a gran escala fossin robustos al canvi.^[20] Finalment, aquest camí de recerca va conduir al desenvolupament de la computació orientada a recursos (ROC), una abstracció de computació generalitzada en què REST és un subconjunt especial. El 2005, durant una presentació a la conferència Web Services Edge, Rodgers va defensar els "serveis REST " i va afirmar que " els components de programari són microserveis web... Els microserveis es componen mitjançant canonades tipus Unix (el Web es troba amb Unix = veritable acoblament fluix). Els serveis poden cridar serveis (+ múltiples temps d'execució d'idiomes). Els conjunts de serveis complexos s'abstreuen darrere d'interfícies URI simples. Qualsevol servei, amb qualsevol granularitat, es pot exposar". Va descriure com una plataforma de microserveis ben dissenyada "aplica els principis arquitectònics subjacents dels serveis web i REST juntament amb la planificació i les canalitzacions tipus Unix per proporcionar una flexibilitat radical i una simplicitat millorada en les arquitectures orientades a serveis.^[21]

També el 2005, Alistair Cockburn va escriure sobre l'arquitectura hexagonal, que és un patró de disseny de programari que s'utilitza juntament amb els microserveis. Aquest patró fa possible el disseny del microservei, ja que aïlla en capes la lògica de negoci dels serveis auxiliars necessaris per desplegar i executar el microservei completament independentment dels altres.

Granularitat de microserveis

Determinar el nivell adequat de granularitat de (micro)serveis en una arquitectura de microserveis sovint requereix una col·laboració iterativa entre arquitectes i desenvolupadors. Aquest procés implica avaluar els requisits dels usuaris, les responsabilitats del servei i les característiques arquitectòniques, com ara els requisits no funcionals. Neal Ford destaca el paper dels factors integradors i desintegradors en aquest context. Els factors integradors, com ara les transaccions compartides o els processos estretament acoblats, afavoreixen la combinació de serveis, mentre que els factors desintegradors, com ara la tolerància a fallades o l'escalabilitat independent, fomenten la divisió de serveis per assolir els objectius operatius i arquitectònics. A més, les funcions d'aptitud, tal com proposa Neal Ford, es poden utilitzar per validar les decisions arquitectòniques i la granularitat del servei mesurant contínuament les qualitats o els comportaments del sistema que són crítics per a les parts interessades, garantint l'alineació amb els objectius arquitectònics generals.^[22][23]

Mapeig de microserveis a contextos delimitats

Un context limitat, un concepte fonamental en el disseny basat en dominis (DDD), defineix una àrea específica dins de la qual un model de domini és coherent i vàlid, garantint la claredat i la separació de les preocupacions.^[24] En l'arquitectura de microserveis, un context limitat sovint es correspon amb un microservei, però aquesta relació pot variar segons l'enfocament de disseny. Una relació d'un a un, on cada context limitat s'implementa com un únic microservei, sol ser ideal, ja que manté límits clars, redueix l'acoblament i permet el desplegament i l'escalat independents. Tanmateix, altres assignacions també poden ser apropiades: una relació d'un a molts pot sorgir quan un context limitat es divideix en múltiples microserveis per abordar una escalabilitat variable o altres necessitats operatives, mentre que una relació de molts a un pot consolidar múltiples contextos limitats en un únic microservei per simplicitat o per minimitzar la sobrecàrrega operativa. L'elecció de la relació ha d'equilibrar els principis del DDD amb els objectius comercials, les restriccions tècniques i els requisits operatius del sistema.^[25]

Beneficis

Els beneficis de descompondre una aplicació en diferents serveis més petits són nombrosos:

• Modularitat: Això fa que l'aplicació sigui més fàcil d'entendre, desenvolupar, provar i esdevenir més resistent a l'erosió de l'arquitectura. Sovint es compara aquest avantatge amb la complexitat de les arquitectures monolítiques.^[26]

• Escalabilitat: Com que els microserveis s'implementen i es despleguen independentment els uns dels altres, és a dir, s'executen dins de processos independents, es poden monitorar i escalar de manera independent.^[27]

• Integració de sistemes heterogenis i antics: els microserveis es consideren un mitjà viable per modernitzar les aplicacions de programari monolítices existents.^[28][29] Hi ha informes d'experiència de diverses empreses que han substituït amb èxit parts del seu programari existent per microserveis o que estan en procés de fer-ho.^[30] El procés de modernització del programari d'aplicacions antics es duu a terme mitjançant un enfocament incremental.^[31]

• Desenvolupament distribuït: paral·lelitza el desenvolupament permetent que petits equips autònoms desenvolupin, implementin i escalin els seus respectius serveis de manera independent.^[32] També permet que l'arquitectura d'un servei individual emergeixi mitjançant una refactorització contínua. Les arquitectures basades en microserveis faciliten la integració contínua, el lliurament i el desplegament continus.^[33]

Crítiques i preocupacions

L'enfocament de microservices és objecte de crítiques per diversos problemes:

• Els serveis formen barreres d'informació.^[34]
• Les trucades entre serveis a través d'una xarxa tenen un cost més elevat pel que fa a la latència de la xarxa i al temps de processament de missatges que les crides en procés dins d'un procés de servei monolític.^[35]
• Les proves i el desplegament poden ser complicats.^[36]
• Transferir responsabilitats entre serveis és més difícil. Pot implicar la comunicació entre diferents equips, reescriure la funcionalitat en un altre llenguatge o adaptar-la a una infraestructura diferent.^[35] Tanmateix, els microserveis es poden implementar independentment de la resta de l'aplicació, mentre que els equips que treballen en monòlits han de sincronitzar-se per implementar-se junts.^[37]
• Considerar la mida dels serveis com el principal mecanisme d'estructuració pot conduir a massa serveis quan l'alternativa de la modularització interna pot conduir a un disseny més senzill. Això requereix comprendre l'arquitectura general de les aplicacions i les interdependències entre components.^[38]
• Els commits en dues fases es consideren un antipatró en les arquitectures basades en microserveis, cosa que resulta en un acoblament més estret de tots els participants de la transacció. Tanmateix, la manca d'aquesta tecnologia provoca danses incòmodes que han de ser implementades per tots els participants de la transacció per tal de mantenir la coherència de les dades.^[39]
• El desenvolupament i el suport de molts serveis són més difícils si es construeixen amb diferents eines i tecnologies; això és especialment problemàtic si els enginyers es mouen entre projectes amb freqüència.^[40]
• El protocol que s'utilitza normalment amb els microserveis (HTTP) va ser dissenyat per a serveis de cara al públic i, per tant, no és adequat per al funcionament de microserveis interns que sovint han de ser impecablement fiables.^[41]
• Tot i que no és específica dels microserveis, la metodologia de descomposició sovint utilitza la descomposició funcional, que no gestiona els canvis en els requisits i alhora afegeix complexitat als serveis.^[41]
• El concepte mateix de microservei és enganyós, ja que només hi ha serveis. No hi ha cap definició sòlida de quan un servei comença o deixa de ser un microservei.^[41]
• Agregació de dades. Per tenir una vista completa d'un sistema en funcionament, cal extreure conjunts de dades dels repositoris de microserveis i agregar-los en un únic esquema. Per exemple, per poder crear informes operatius que no són possibles amb un únic repositori de microserveis.