- L'arquitectura de microserveis descompon una aplicació a serveis petits, autònoms i alineats amb dominis de negoci.
- Patrons com Database per Microservice, Saga, API Gateway, CQRS i Clean Architecture permeten gestionar dades, transaccions i comunicacions.
- Contenidors, Kubernetes, CI/CD, observabilitat avançada i seguretat Zero Trust són pilars tècnics imprescindibles per operar microserveis en producció.
- Aquest enfocament aporta agilitat i escalabilitat però introdueix complexitat i exigeix experiència en sistemes distribuïts i una forta cultura DevOps.
L' arquitectura de microserveis ha esdevingut l'estàndard de facto per construir aplicacions modernes al núvol: escalables, resilients i fàcils d'evolucionar. Lluny de ser només un “truc” per trossejar un monòlit, implica canvis profunds en com dissenyem, desenvolupem, despleguem i operem el programari.
En aquest article veurem de forma profunda i molt pràctica què és l'arquitectura de microserveis i l' arquitectura descentralitzada , quins són els seus avantatges i inconvenients reals, quins components la fan possible, com es relaciona amb patrons com MVC o Clean Architecture, quin paper juguen bases de dades i contenidors, i quins patrons de disseny i desplegament són de mantenir.
Què és realment l'arquitectura de microserveis
Quan parlem de microserveis ens referim a un enfocament de desenvolupament en què una aplicació es descompon en serveis petits, autònoms i especialitzats , cadascun amb una responsabilitat de negoci ben fitada. Aquests serveis es comuniquen normalment a través d'APIs lleugeres (REST, gRPC, missatgeria, esdeveniments), es despleguen de manera independent i, molt sovint, gestionen el seu propi emmagatzematge de dades.
Un microservei és, en essència, un component de programari desplegable per separat, controlat per un petit equip que es responsabilitza de tot el seu cicle de vida: disseny, desenvolupament, proves, desplegament, observabilitat i manteniment. Aquesta idea de “producte, no projecte” és al cor del model: el servei no es lliura i s'oblida, es cuida i evoluciona de manera contínua.
Davant d'una arquitectura monolítica clàssica, on totes les funcionalitats conviuen en un únic procés i una única base de dades , els microserveis aposten pel desacoblament: cada servei pot estar escrit en un llenguatge diferent, fer servir la seva pròpia tecnologia de base de dades i versionar-se al seu ritme, sense arrossegar tot el sistema amb cada canvi.
Aquest model encaixa com un guant amb les pràctiques de DevOps, integració contínua i entrega contínua , ja que permet cicles de desplegament ràpids, freqüents i de baix risc. A canvi, introdueix un nou nivell de complexitat en xarxa, dades, observabilitat i govern que cal saber gestionar.
Característiques clau dels microserveis
Un sistema basat en microserveis sol compartir una sèrie de característiques comunes, encara que cada organització les aterri a la seva manera :
En primer lloc, els components de l'aplicació s'implementen com a serveis independents que actuen com a unitats de desplegament i substitució aïllades . En lloc de biblioteques trucades en memòria, els serveis es comuniquen mitjançant trucades HTTP/REST, gRPC o missatgeria, cosa que introdueix latència però redueix l'acoblament.
La descomposició es fa al voltant de capacitats de negoci , no per capes tècniques. Cada servei s'alinea amb un subdomini o context delimitat (per exemple, usuaris, catàleg, comandes, pagaments) i concentra tota la lògica necessària: API, lògica de domini, accés a dades i integració amb tercers.
S'adopta una mentalitat de “productes, no projectes” : un mateix equip multidisciplinari (backend, frontend, QA, DevOps) és responsable del microservei durant tota la vida útil. Això fomenta la propietat end to end, accelera el lliurament i evita els trasllats eterns entre departaments.
Pel que fa a l'estil d'integració, se sol apostar pel principi d' “extrems intel·ligents i canonades simples” . La lògica de negoci viu als serveis, mentre que la infraestructura de comunicació (HTTP, cues, brokers d'esdeveniments) es manté el més lleugera possible, evitant orquestracions hipercomplexes acoblades a protocols pesants i afavorint la programació orientada a esdeveniments.
Un altre tret important és el govern descentralitzat de la tecnologia : cada equip pot triar el llenguatge, framework i tipus de base de dades que millor encaixi amb el seu problema, sempre que respecti uns mínims d'estàndards transversals (seguretat, logging, observabilitat, contractes API). Aquesta llibertat permet optimitzar el rendiment, el cost i la productivitat segons cada cas.
Gestió descentralitzada de dades i patró Database per Microservice
Una de les decisions més delicades en migrar a aquest enfocament és com tractar les dades. El patró més habitual és Database per Microservice : cada servei posseeix i administra la seva pròpia base de dades, que pot ser una instància de la mateixa tecnologia que altres o alguna cosa totalment diferent.
Aquest enfocament potencia l'autonomia perquè cada canvi d'esquema només afecta el servei propietari d'aquestes dades , redueix colls d'ampolla en un únic servidor de bases de dades i afavoreix la persistència políglota: un servei pot utilitzar PostgreSQL, un altre MongoDB, un altre una memòria cau a Redis i un altre un motor de cerca com Elasticsearch per a consultes complexes i anàlisi de text.
Per exemple, en un e-commerce podríem tenir un servei d'usuaris emmagatzemant les seves dades relacionals a PostgreSQL , un servei de catàleg usant una base NoSQL per modelar productes molt variables, un servei de comandes amb una altra base relacional optimitzada per a transaccions, un servei de carret recolzat a Redis per a dades efímeres, i un servei de cerca amb Elasticsearch per a consultas.
La contrapartida és que les transaccions distribuïdes ACID deixen de ser viables a la pràctica . En lloc d'una gran transacció que toca diverses taules, se sol treballar amb consistència eventual, esdeveniments de domini i patrons com Saga per coordinar canvis entre serveis, acceptant que durant un curt temps diferents serveis puguin veure estats diferents.
Per accedir a dades que pertanyen a un altre servei, en lloc d'anar “per darrere” a la base de dades es recomana utilitzar patrons com API Composition (un servei compon dades trucant a diversos serveis propietaris) o CQRS (separar lectures i escriptures i mantenir projeccions de només lectura actualitzades mitjançant esdeveniments).
Orquestració vs coreografia i patró Saga
Quan un procés de negoci travessa diversos serveis (per exemple, alta dun client, creació de compte de fidelitat, enviament de kit de benvinguda i correu electrònic ) hi ha dos grans estils de coordinació: orquestració i coreografia.
Amb un enfocament d' orquestració , hi ha un component central (un orquestrador o un servei “coordinador”) que coneix tot el flux: invoca el servei de punts, després el postal, després el correu electrònic, controla estats intermedis i maneja errors. És més senzill de seguir, però tendeix a concentrar massa lògica i esdevenir un “monstre centralitzador”.
En canvi, amb un enfocament de coreografia , el procés es basa en esdeveniments que els serveis publiquen i consumeixen . El servei de clients emet un esdeveniment “client_creat”; el servei de fidelitat ho escolta i assigna punts; el postal escolta i genera un enviament; el de correu electrònic envia el missatge de benvinguda. Cada servei sap què fer quan observa determinats esdeveniments, sense una peça central dictant el ball.
El patró Saga es recolza en aquestes idees per gestionar transaccions distribuïdes. Una Saga es compon d'una cadena d'operacions locals a diferents serveis i, en cas d'error, una sèrie d'accions de compensació que desfan (o mitiguen) els canvis previs. Les Sagas es poden implementar de forma orquestrada (un component dirigeix tot el flux) o coreografiada (cada servei reacciona a esdeveniments i publica nous).
Coreografia sol encaixar millor amb arquitectures de microserveis molt distribuïdes i orientades a esdeveniments, però requereix una molt bona observabilitat i monitorització del flux de negoci per saber què ha passat en cada pas i detectar inconsistències o errors parcials.
Tolerància a fallades i patrons de resiliència
En un sistema distribuït, cal partir de la base que qualsevol trucada de servei pot fallar, trigar massa o tornar errors intermitents . Ignorar això és la recepta perfecta per a fallades en cascada i caigudes globals.
Per minimitzar aquests riscos, s'apliquen diversos patrons de resiliència, començant per temps d'espera màxims (timeouts) a totes les trucades remotes. Ningú vol tenir fils bloquejats indefinidament esperant un servei caigut; en vèncer el timeout, el client pot decidir reintentar, encolar loperació per més tard o degradar la funcionalitat.
El patró circuit breaker afegeix una capa de protecció extra: si un client detecta que un percentatge significatiu de trucades a un servei està fallant, “obre el circuit” i deixa d'intentar invocar aquest servei durant un temps, retornant errors immediats o respostes degradades. Passat un interval, permet algunes trucades de prova (estat semiobert) i, si tornen a tenir èxit, tanca de nou el circuit.
També és habitual dissenyar compartiments estancs , tant lògics com físics, per contenir danys: diversos pods per servei, diverses màquines o fins i tot diverses regions, de manera que una fallada localitzada no tombi tot el sistema. L'ús de tècniques com el rate limiting o cues per anivellar càrrega ajuda a evitar que pics puntuals enfonsin serveis crítics.
Tot això es recolza en mòduls de resiliència reutilitzables (per exemple, biblioteques com Resilience4j integrades amb frameworks com Spring Cloud) que permeten configurar polítiques de reintents, límits de petició, circuits breakers i gestió d'errors de forma centralitzada i coherent en tots els serveis.
Components típics duna arquitectura de microserveis
A més dels propis serveis de negoci, una arquitectura de microserveis madura incorpora una sèrie de components de plataforma fonamentals perquè tot funcioni amb garanties :
D'una banda hi ha l' orquestrador o plataforma de contenidors (normalment Kubernetes), que s'encarrega de programar i executar contenidors, escalar rèpliques, reiniciar serveis caiguts i proporcionar mecanismes de descobriment de serveis i balanceig intern; sobre aquesta infraestructura convé aplicar mesures de seguretat en contenidors.
A la vora de l'arquitectura apareix la porta d'enllaç d'API (API Gateway) , que actua com a punt d'entrada únic per a clients externs: encamina peticions al microservei correcte, aplica autenticació i autorització, afegeix o valida capçaleres de seguretat, controla quotes, fa de servidor intermediari TLS i, en molts casos, afegeix respostes.
Per a la comunicació asíncrona s'utilitzen plataformes de missatgeria i streaming com Apache Kafka o Azure Service Bus, que suporten patrons de publicació-subscripció, cues de treball, esdeveniments de domini i arquitectures event-driven altament escalables.
L' observabilitat és una altra peça crítica: logs centralitzats, mètriques d'aplicació, traces distribuïdes i monitorització en temps real permeten entendre què passa en un sistema amb desenes o centenars de serveis. Frameworks com OpenTelemetry i pipelins de recol·lecció i anàlisi (amb col·lectors dedicats) són ja imprescindibles.
Finalment, la gestió de configuració centralitzada i el mòdul de seguretat (tokens d'accés, mTLS entre serveis, control d'accés basat en rols, gestió de secrets) completen el quadre. La configuració s'externalitza del codi perquè els mateixos artefactes es puguin desplegar en múltiples entorns canviant només paràmetres externs.
Patrons d'arquitectura i disseny en microserveis
Per no reinventar la roda (i evitar caure en antipatrons), és clau recolzar-se en patrons d'arquitectura i disseny que han demostrat funcionar bé en entorns distribuïts :
A la fase de modelatge destaca el patró Decompose by Subdomain , molt lligat al disseny dirigit pel domini (DDD). La idea és identificar subdominis i contextos delimitats clars (usuaris, comandes, facturació, logística, etc.) i assignar-los microserveis alineats amb aquests límits, evitant serveis ni massa grans ni absurdament petits.
Per a la comunicació síncrona, es recorre al patró Remote Procedure Invocation , implementat amb REST, gRPC, GraphQL o WebSockets. El que és recomanable és adoptar un enfocament API‑First, usant contractes formals (OpenAPI per a REST, IDL de gRPC o esquemes GraphQL) per dissenyar primer la interfície i després generar o adaptar el codi.
Quan es necessita comunicació asíncrona es fa servir el patró Messaging , basat en esdeveniments que un productor envia a un broker i que múltiples consumidors poden processar al seu ritme. Aquí encaixa molt bé definir contractes d'esdeveniments amb AsyncAPI, de manera similar a com es fa amb OpenAPI al món REST.
En l'àmbit de l'accés a dades, a més de Database per Microservice, cobra importància CQRS (Command Query Responsibility Segregation) : separar el model d'escriptura (ordres) del model de lectura (consultes), usant projeccions i esdeveniments per mantenir sincronitzades les vistes de només lectura optimitzades per a la cerca.
Per exposar microserveis a clients externs, el patró API Gateway centralitza l'accés, mentre que una variant com a Backend for Frontends (BFF) crea APIs específiques per a cada tipus de client (web, mòbil, apps internes) que afegeixen i adapten dades segons les necessitats de cada interfície.
Relació amb MVC, arquitectura neta i patrons clàssics
En molts projectes la història comença amb una aplicació monolítica basada en MVC (Model-Vista-Controlador): controladors web que atenen peticions, models de domini fortament acoblats a una única base de dades i vistes renderitzades al servidor.
El patró MVC continua sent útil dins de cada microservei que exposa una API o una interfície web (per exemple amb frameworks com Flask a Python ), però ja no és l'estructura global de tota l'aplicació . La tendència actual és desacoblar el frontend (SPA, apps mòbils) i utilitzar frameworks moderns que consumeixen APIs de microserveis, deixant el MVC clàssic com un detall intern en cas de continuar utilitzant-se.
La Clean Architecture (arquitectura neta) encaixa especialment bé amb els microserveis, perquè promou capes ben definides i dependències dirigides cap al domini: entitats i casos d'ús al nucli, adaptadors d'interfície (controladors, presenters, gateways de persistència) cap a fora i frameworks (bases de dades, HTTP, missatge)
Aplicant aquests principis dins d'un microservei aconseguim que la lògica de negoci quedi protegida dels detalls tècnics : podem canviar de base de dades, framework web o proveïdor de missatgeria sense reescriure el cor del servei. A més a més, facilita moltíssim les proves unitàries i d'integració.
Patrons de disseny com SOLID, separació de responsabilitats, injecció de dependències o principis de codi simple continuen sent igual de rellevants, únicament s'apliquen ara dins del context més reduït de cada microservei, cosa que fa més viable mantenir un codi net a llarg termini.
Automatització, CI/CD i desplegament en contenidors i serverless
L'arquitectura de microserveis té poc sentit sense automatització agressiva de tot el cicle de vida en entorns cloud-native . Amb desenes de serveis, fer desplegaments manuals és una recepta garantida per al desastre.
Els equips solen establir pipelins d' integració contínua i lliurament continu (CI/CD) , sovint recolzades per GitOps , que compilen el codi, executen proves, generen imatges de contenidor, apliquen migracions de base de dades (quan escaigui) i despleguen els serveis de forma repetible, controlada i traçable.
El patró de desplegament més estès és “deploy a service as container” , empaquetant cada microservei en una imatge (per exemple, Docker) i deixant que Kubernetes o un altre orquestrador gestioni rèpliques, escalat i actualitzacions. Això permet un ús eficient de recursos i desplegaments ràpids i homogenis.
A sobre d'això, es poden aplicar patrons de plataforma com a service mesh (Istio, Linkerd, etc.), que afegeixen capacitats d'encaminament avançat, polítiques de seguretat mTLS, observabilitat detallada i distribució de trànsit entre versions (canary releases, blue-green) sense tocar el codi dels serveis.
En determinats casos, especialment per a tasques molt acotades o event-driven, entra en joc el desplegament serverless : funcions que s'executen sota demanda (per exemple, AWS Lambda) orquestrades per serveis com API Gateway, cues, streams o programadors. Tot i que no tot ha de ser serverless, sol encaixar bé amb microserveis molt petits i altament elàstics.
Seguretat, observabilitat i testing en sistemes distribuïts
La seguretat en microserveis es recolza en el principi de Zero Trust: ningú no confia en ningú per defecte . Això implica autenticació robusta a través de l'API Gateway (OAuth2, OIDC), emissió de tokens (per exemple JWT) que viatgen amb cada petició i autorització local a cada servei, a més de xifrat de trànsit de servei a servei mitjançant mTLS.
El patró Access Token resumeix bé aquesta aproximació: el gateway valida les credencials del client, genera un token amb el context de seguretat (identitat, rols, scopes) i el reenvia als microserveis, que l'utilitzen per prendre decisions d'autorització sense emmagatzemar contrasenyes ni lògica d'autenticació interna.
Pel que fa a l'observabilitat, es combinen diversos patrons: Application Metrics (mètriques tècniques i de negoci per servei), Audit Logging (logs d'auditoria d'accions d'usuari), Distributed Tracing (seguir una petició a través de múltiples serveis), Exception Tracking (sistemes centralitzats de gestió d'errors ), Health Check API (endags d' Aggre d' API) comú).
Tot això permet detectar anomalies, retallar temps de diagnòstic i entendre com es comporta el sistema sota càrregues reals. Sense una bona observabilitat, un sistema de microserveis esdevé una caixa negra gairebé impossible d'operar.
En el terreny de les proves, a més de les unitàries clàssiques, prenen rellevància patrons com Service Integration Contract Test (verificar que proveïdor i consumidor respecten el mateix contracte d'API) i Service Component Test (executar el servei en aïllament usant stubs de dependències externes), reduint la dependència de proves end-to-end fràgils.
Finalment, una cultura DevOps madura i la pràctica d' enginyeria de caos (injectar errors controlats per validar la resiliència de l'arquitectura) ajuden a assegurar-se que el sistema es comporta bé quan les coses es torcen, que en producció sempre passa abans o després.
Avantatges, desavantatges i criteris d'adopció
Els principals avantatges dels microserveis giren al voltant de l'agilitat i l'escalabilitat: equips petits i autònoms, desplegaments freqüents sense parar tota l'aplicació, escalat independent de cada àrea funcional, llibertat tecnològica per servei i més resiliència gràcies a l'aïllament de fallades.
També afavoreixen la reutilització de funcionalitats ben encapsulades (un servei de pagament, autenticació o notificacions pot servir de bloc estàndard per a moltes solucions), redueixen el cost dels canvis locals i permeten alinear millor l'organització (equips) amb el model de negoci (dominis i productes).
A l'altra cara de la moneda, els microserveis introdueixen una complexitat gens trivial : més punts de fallada, més latència de xarxa, més dificultat per mantenir la coherència de dades, processos de desplegament i proves més sofisticades, i una necessitat molt més gran d'eines d'observabilitat, automatització i govern.
A més, exigeixen perfils tècnics amb experiència en sistemes distribuïts , contenidors, Kubernetes, seguretat, patrons d'integració, governança d'APIs i disseny de dominis, cosa que no sempre està disponible a tots els equips o empreses.
Per tot això, l'arquitectura de microserveis té sentit sobretot en organitzacions amb una base de codi gran, molts equips, alta taxa de canvi funcional i requisits forts d'escalabilitat , com ara grans plataformes digitals, SaaS complexos o sistemes amb audiències massives. Per a aplicacions petites o amb un equip reduït, un bon monòlit modular sol ser més simple, barat i suficient.
L'arquitectura de microserveis suposa un salt important respecte al desenvolupament monolític tradicional, però ben dissenyada i governada esdevé una palanca potentíssima per escalar organitzacions, equips i sistemes. Recolzant-se en patrons com Database per Microservice, Saga, API Gateway, CQRS, Clean Architecture, desplegaments en contenidors i plataformes d'observabilitat robustes, és possible construir solucions que combinin rapidesa de canvi, resiliència davant fallades, llibertat tecnològica i una alineació molt més fina amb el negoci , sempre que s'extreu en el negoci. automatització, cultura i bones pràctiques.
