Disseny d'una arquitectura de microserveis

14 preguntas de exámenes anteriores · 18 min · 1 hermanas, de otra categoría

Elaboración propia: la fuente es de pago y no se reproduce

Enunciat oficial. Disseny d'una Arquitectura de Microserveis.

1. La idea central

Microserveis: estil arquitectònic que estructura una aplicació com un conjunt de serveis petits, autònoms i desplegables de manera independent, cadascun organitzat al voltant d'una capacitat de negoci, amb la seva pròpia base de dades i comunicats mitjançant API (Application Programming Interface, interfície de programació d'aplicacions) lleugeres.

La idea central que impulsa l'arquitectura de microserveis és descompondre l'aplicació en serveis autònoms i desplegables de manera independent, alineats amb capacitats de negoci, per poder desenvolupar-los, escalar-los, desplegar-los i evolucionar-los per separat. La independència de desplegament és el que ho justifica tot: si per posar en producció un canvi d'un servei cal desplegar-ne uns altres, no són microserveis.

Característiques essencials:

1. Independència de desplegament: cada servei es desplega sense coordinació amb els altres.
2. Alineació amb capacitats de negoci (context delimitat del Domain-Driven Design).
3. Descentralització de les dades: cada servei posseeix la seva base de dades; cap altre servei no hi accedeix directament.
4. Comunicació per API ben definides, mai per base de dades compartida.
5. Autonomia dels equips: un equip petit posseeix el servei extrem a extrem.
6. Heterogeneïtat tecnològica possible (persistència poliglota, llenguatges diferents).
7. Disseny per a la fallida: assumeix que la xarxa i els altres serveis fallaran.
8. Automatització de la construcció, prova i desplegament.

Aquestes vuit són les respostes correctes quan es pregunta «quina característica és essencial en una arquitectura de microserveis». La base de dades compartida és exactament el contrari: és l'error més comú i converteix el conjunt en un monòlit distribuït, que combina els inconvenients de tots dos móns.

Microservei ≠ funció sense servidor. Un microservei és un procés de llarga durada que l'equip propietari desplega, escala i opera, amb el seu estat persistent i el seu cicle de vida; una funció (FaaS) és codi efímer i sense estat que el proveïdor arrenca en resposta a un esdeveniment, escala fins a zero i factura per execució. Una funció pot implementar un microservei, però ni la granularitat ni qui n'opera el temps d'execució són les mateixes → tema 47.

2. Monòlit, SOA i microserveis

Monòlit vol dir una sola unitat de desplegament: tot el codi es construeix, es prova i es posa en producció alhora, sobre una base de dades única. No vol dir codi desordenat. El monòlit modular conserva aquesta unitat de desplegament però hi imposa mòduls amb frontera explícita que només es parlen per interfícies internes: el domini queda partit sense pagar la xarxa. Per tant la diferència entre monòlit i monòlit modular és la qualitat de les fronteres internes, i la que separa el monòlit modular dels microserveis és si les peces es poden desplegar per separat — no la qualitat del codi.

Quan un monòlit és millor: aplicacions petites, equips reduïts, domini poc conegut i requisits estables. El patró recomanat és començar amb un monòlit ben modularitzat (monolith first) i extreure serveis quan els límits del domini siguin clars i el dolor justifiqui el cost.

SOA — arquitectura orientada a serveis:

Avantatge principal: la reutilització de serveis i la interoperabilitat entre sistemes heterogenis: exposar funcionalitat com a serveis estàndard, independents de la plataforma, que diverses aplicacions poden consumir sense duplicar la lògica. En derivar-ne una conseqüència: com totes les aplicacions accedeixen a la mateixa dada a través del mateix servei, en lloc que cadascuna en mantingui una còpia pròpia, SOA facilita la integració entre aplicacions diferents i en millora la coherència de les dades entre múltiples aplicacions.

La interfície d'un servei: el contracte entre el proveïdor i el consumidor del servei — què ofereix (operacions, dades d'entrada i de sortida) sense exposar-ne la implementació interna. En SOA aquest contracte és el WSDL (Web Services Description Language, llenguatge de descripció de serveis web); en REST, l'OpenAPI.

Protocol habitual per a la comunicació entre serveis en SOA: SOAP (Simple Object Access Protocol), sobre XML (eXtensible Markup Language, llenguatge de marcatge extensible) i normalment HTTP (HyperText Transfer Protocol, protocol de transferència d'hipertext), amb els seus contractes WSDL i l'ecosistema WS-* (WS-Security, WS-ReliableMessaging, WS-AtomicTransaction) i UDDI (Universal Description, Discovery and Integration) com a registre. És la resposta a la pregunta d'examen. Als microserveis, en canvi, el protocol dominant és REST sobre HTTP amb JSON (JavaScript Object Notation).

REST (Representational State Transfer, transferència d'estat representacional) vs SOAP — la característica que els distingeix:

Mètodes HTTP estàndard: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE, CONNECT. UPDATE no és un mètode HTTP —l'actualització es fa amb PUT (substitució completa) o PATCH (parcial)—. Al tribunal li agrada aquest tipus de pregunta —quin verb NO és un mètode estàndard de HTTP, amb un verb plausible que no ho és (DOWNLOAD, TS-TIC 2025)— però aquesta és del tema d'Internet, arquitectura i protocols, no d'aquest.

Nivells de maduresa REST (model de Richardson): 0 un únic URI i POST · 1 recursos · 2 verbs HTTP i codis d'estat · 3 HATEOAS (Hypermedia As The Engine Of Application State, hipermèdia).

3. Components d'una arquitectura de microserveis

3.1 API Gateway

Funció principal: actuar com a punt d'entrada únic per als clients, encaminant les peticions als microserveis corresponents i concentrant les funcions transversals —autenticació i autorització, limitació de ritme, terminació TLS (Transport Layer Security, seguretat de la capa de transport), transformació de protocol i de format, agregació de respostes, cau, versionat i telemetria—, de manera que els clients no hagin de conèixer la topologia interna ni cada servei hagi d'implementar aquestes funcions.

API Manager: va més enllà de la passarel·la. És la plataforma de gestió del cicle de vida complet de les API: disseny i publicació, catàleg i portal per als desenvolupadors, registre i alta de consumidors amb les seves claus, polítiques de seguretat i de quota, versionat i desactivació, analítica d'ús i, si escau, monetització. La passarel·la n'és el component d'execució en temps real; l'API Manager és el govern. Per als consumidors, això es tradueix en el que permet als usuaris i a les aplicacions consumir serveis, interconnectar mòduls i aplicacions, i facilitar l'accés al backend, afavorint-ne la reutilització; per a qui l'opera, és el que controla l'accés a les API i n'aplica les polítiques de seguretat. Productes: Kong, Apigee, WSO2 API Manager, Azure API Management, AWS (Amazon Web Services) API Gateway, Gravitee, 3scale.

Seguretat de les API REST — les opcions correctes: OAuth 2.0 amb OpenID Connect i tokens JWT (JSON Web Token) signats, amb àmbits (scopes) i temps de vida curt; mTLS entre serveis; claus d'API només per a identificació d'aplicacions, mai com a única autenticació; limitació de ritme i quotes; validació estricta d'entrada; HTTPS (HyperText Transfer Protocol Secure, protocol de transferència d'hipertext segur) obligatori; i seguir l'OWASP (Open Web Application Security Project) API Security Top 10, encapçalat per l'autorització a nivell d'objecte trencada i l'autenticació trencada —els dos primers riscos de la llista, i els que expliquen per què l'autorització s'ha de comprovar a cada servei i no només a la passarel·la—.

3.2 Descobriment de serveis i configuració

Les instàncies neixen, moren i canvien d'adreça contínuament, així que les adreces no es poden escriure ni al codi ni a un fitxer. El descobriment de serveis ho resol amb un registre de serveis: la base de dades de quines instàncies de cada servei hi ha vives i on són (Consul, etcd, Eureka, el DNS (Domain Name System, sistema de noms de domini) intern de Kubernetes).

• Com s'hi donen d'alta: per autoregistre —la instància s'inscriu en arrencar i es dona de baixa en parar— o per registre de tercers, quan ho fa per ella un component extern, típicament l'orquestrador. En tots dos casos és la prova de salut periòdica la que retira la instància que ha deixat de respondre.
• Com el consulta qui truca: en el descobriment del costat client el consumidor demana la llista al registre i tria ell mateix la instància; en el descobriment del costat servidor truca sempre una adreça estable i és un intermediari —passarel·la, balancejador o el Service de Kubernetes— qui resol i encamina.

Balanceig de càrrega: repartir les peticions entre les instàncies vives, amb la llista que surt del registre. El que canvia és on es decideix — al client (la biblioteca del consumidor), a la infraestructura (un balancejador de capa 4, per adreça i port, o de capa 7, per URI, capçalera o versió de l'API) o al costat, en un sidecar adjunt a cada instància. Criteris de repartiment: cíclic (round robin), menys connexions actives, per pes i per resum de la clau (hashing) quan cal enganxar un client a una instància.

Configuració centralitzada i externalitzada (ConfigMaps, Consul KV (Key-Value, clau-valor), Spring Cloud Config): viu a l'entorn i no a la imatge, de manera que la mateixa imatge es promociona entre entorns sense reconstruir-la.

3.3 Comunicació

• Síncrona: REST i gRPC (HTTP/2 + Protocol Buffers, alt rendiment, contracte fort). Simple, però acobla temporalment els serveis.
• Asíncrona: missatgeria (RabbitMQ) i flux d'esdeveniments (Kafka). Desacobla en el temps, absorbeix pics i millora la resiliència; a canvi, complica el raonament i la traçabilitat.
• EDA (Event-Driven Architecture, arquitectura orientada a esdeveniments): els serveis publiquen fets i altres hi reaccionen.

Patró de conversa: petició-resposta —un consumidor n'espera la resposta— davant publicació-subscripció —el productor emet un fet i no sap qui l'escolta—. El primer acobla; el segon no.

Passarel·la ≠ malla de serveis. L'API Gateway governa el trànsit nord-sud, el que entra de fora cap als serveis; la malla de serveis governa l'est-oest, el que els serveis es fan entre ells, amb un sidecar per instància i sense tocar el codi → tema 47.

3.4 Dades

Base de dades per servei: cada servei posseeix el seu esquema i és l'únic que hi escriu i el llegeix; els altres hi arriben només per la seva API. És el que permet desplegar i escalar un servei sense tocar-ne cap altre, i el preu és que una operació que travessa diversos serveis ja no és una transacció. La persistència poliglota —que cada servei triï el tipus de magatzem que s'ajusta a les seves dades— n'és la conseqüència directa, i es desplega al tema 32.

Consistència eventual, no ACID. Una transacció ACID dona atomicitat i aïllament dins d'una base de dades; entre serveis caldria un commit en dues fases (2PC), que no s'usa als microserveis perquè bloqueja recursos i fa que la disponibilitat del conjunt sigui la del participant més lent. El que se n'obté a canvi és consistència eventual: durant una finestra de temps cada servei pot veure una dada diferent, i acaben convergint. Dissenyar per a microserveis és acceptar aquesta finestra i fer-la explícita al negoci, no dissimular-la.

• Patró Saga: transacció distribuïda com a seqüència de transaccions locals amb compensacions. Les compensacions desfan l'efecte de les anteriors amb una operació de negoci —abonar el càrrec—, no amb un rollback, perquè cada transacció local ja s'ha confirmat.
• Transactional outbox per publicar esdeveniments de manera fiable: l'esdeveniment s'escriu a la mateixa transacció local que la dada, i un procés a part el publica després.
• CQRS (Command Query Responsibility Segregation, segregació de responsabilitat entre comandes i consultes): separar el model d'escriptura del de lectura. Event sourcing és un patró diferent i independent: emmagatzemar la seqüència d'esdeveniments com a font de veritat en lloc de l'estat final.
• API composition i CQRS per a consultes que travessen serveis: la primera pregunta a cada servei i ajunta les respostes; la segona manté una vista de lectura ja ajuntada.

Coreografia ≠ orquestració, i val tant per a la saga com per a qualsevol composició de serveis:

3.5 Resiliència i observabilitat

Als microserveis la xarxa forma part del disseny: una crida remota pot arribar tard, no arribar o arribar duplicada, i la fallada d'un servei no pot arrossegar la dels altres. Els patrons de resiliència són la resposta, i com que el tribunal els contraposa, el que cal saber de cadascun és quin problema resol ell i no els altres:

Qui els implementa: o bé el codi de l'aplicació amb una biblioteca (Resilience4j, Polly), o bé la infraestructura amb un sidecar, que aplica les mateixes polítiques sense tocar el servei → tema 47.

Observabilitat: sense traçat distribuït amb propagació de context —un identificador de correlació que viatja amb la petició per tots els serveis que travessa— un error no es pot seguir fins a l'origen. Què és una traça i quina plataforma ho recull, al tema 23.

4. Disseny: com trobar els límits

• Domain-Driven Design: contextos delimitats (bounded contexts), llenguatge ubic i mapes de context. Un microservei sol correspondre a un context delimitat.
• Descomposició per capacitat de negoci, no per capa tècnica. Un servei «de base de dades» o «de lògica» és un antipatró.
• Acoblament feble i cohesió alta: dins d'un servei, tot allò que canvia junt; entre serveis, com menys se sàpiguen l'un de l'altre, millor. Es trenca de tres maneres i totes tenen nom — acoblament de dades (dos serveis comparteixen taula), acoblament temporal (el consumidor no pot avançar si el proveïdor no respon ara mateix) i acoblament de desplegament (s'han de publicar alhora)—. La prova és senzilla: si un canvi obliga a tocar i desplegar més d'un servei, la frontera està mal posada.
• Llei de Conway: l'arquitectura del sistema reprodueix l'estructura de comunicació de l'organització. La maniobra Conway inversa consisteix a organitzar els equips segons l'arquitectura desitjada.
• Mida: no hi ha una regla; el criteri és que un equip petit el pugui posseir i entendre, i que es pugui reescriure en poques setmanes.
• Estrangulador (strangler fig): patró per migrar un monòlit gradualment, interceptant funcionalitat i redirigint-la als serveis nous fins que el monòlit desapareix.

5. Costos

Els microserveis no són gratuïts. El que es guanya en independència es paga en:

• Complexitat distribuïda: xarxa poc fiable, latència, consistència eventual.
• Operació: cal orquestració, observabilitat, CI/CD, gestió de secrets i de configuració madurs.
• Proves: les proves d'integració extremes són difícils; calen contractes de consumidor (consumer-driven contracts, Pact).
• Depuració: sense traçat distribuït, un error és impossible de seguir.
• Governança: versionat i compatibilitat de les API, evitar canvis trencadors.
• Cost d'infraestructura superior.

Antipatrons: monòlit distribuït (serveis que s'han de desplegar junts), base de dades compartida, microserveis anèmics que només fan CRUD (Create, Read, Update, Delete), ESB (Enterprise Service Bus, bus de serveis empresarial) als microserveis (bus intel·ligent), nanoserveis (granularitat excessiva) i comunicació síncrona en cadena (un error a la punta cau tota la cadena).

6. Al sector públic

• L'arquitectura de microserveis encaixa amb la reutilització (Llei 40/2015, art. 158) i amb l'exposició de serveis a altres administracions.
• Interoperabilitat (ENI): les API han de complir els estàndards del catàleg i, quan afecten l'intercanvi entre administracions, els models de dades de les NTI (Normes Tècniques d'Interoperabilitat).
• Contractació: cal definir la propietat de les API i del codi, i la reversibilitat (LCSP, Mesura de digitalització oberta).
• Seguretat: l'ENS exigeix control d'accés, traçabilitat i protecció de les comunicacions; mTLS i OAuth 2.0 en són la implementació habitual.
• Realisme: la major part de la tramitació administrativa viu en plataformes corporatives (a Barcelona, el GPA, Gestor de Procediments Administratius); els microserveis són adequats per als serveis digitals nous i d'alt trànsit, no per reescriure-ho tot.

Claus d'examen

• API Gateway ≠ API Manager: la passarel·la és el component d'execució que encamina peticions en temps real; l'API Manager és la plataforma que en governa el cicle de vida complet —catàleg, claus, quotes, analítica—. El tribunal ha preguntat pels dos per separat (TS-TIC 2018, p. 19; TS-TIC 2023 específic, p. 20; TS-TIC 2023 pràctica, s4-p5; TS-TIC 2025 pràctica, s3-p16).
• UPDATE no és un mètode HTTP. El truc del tribunal és preguntar quin verb NO ho és i colar-hi un de plausible que tampoc ho és; ha caigut amb DOWNLOAD (TS-TIC 2025 específic, p. 70), però aquesta pregunta és del tema d'Internet, arquitectura i protocols.
• SOA no és microserveis: SOA sol anar amb SOAP/WSDL; microserveis, amb REST/JSON. Confondre'ls fa fallar la pregunta del protocol habitual (TS-TIC 2018, p. 1; TS-TIC 2025 pràctica, s3-p18).
• Base de dades compartida = monòlit distribuït. És el parany més repetit: sembla arquitectura de microserveis però trenca l'autonomia de dades per servei.
• El 2PC no s'usa als microserveis; la consistència entre serveis es resol amb el patró Saga (transaccions locals amb compensacions), no amb transaccions distribuïdes clàssiques.

Per recordar

• La idea central és la independència de desplegament de serveis alineats amb capacitats de negoci.
• Cada servei té la seva base de dades; la base de dades compartida genera un monòlit distribuït.
• SOA: avantatge = reutilització i interoperabilitat; protocol habitual = SOAP (amb WSDL). Microserveis: REST/JSON i gRPC.
• REST és un estil arquitectònic orientat a recursos i sense estat; SOAP és un protocol XML amb contracte WSDL.
• UPDATE no és un mètode HTTP: s'usa PUT o PATCH.
• API Gateway = punt d'entrada únic i funcions transversals en temps d'execució; API Manager = govern del cicle de vida complet de les API.
• Saga substitueix les transaccions distribuïdes amb transaccions locals i compensacions; el 2PC no s'usa. Entre serveis hi ha consistència eventual, no ACID.
• Coreografia = cada servei reacciona a esdeveniments; orquestració = un coordinador dona ordres.
• Descobriment: del costat client tria el consumidor amb la llista del registre; del costat servidor tria un intermediari darrere d'una adreça estable.
• Reintent insisteix, tallacircuits desisteix, mampara aïlla recursos i temps d'espera és el que fa possibles els altres tres.
• Comença amb un monòlit modular i extreu serveis quan els límits siguin clars.
• Antipatrons: monòlit distribuït, base de dades compartida, nanoserveis, cadenes síncrones.

Practicar este tema