El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

L'arquitectura de microserveis consisteix a construir una aplicació com un conjunt de serveis petits, autònoms i desplegables de manera independent, cadascun responsable d'una capacitat de negoci concreta i comunicant-se mitjançant mecanismes lleugers com ara APIs HTTP o missatgeria. És un dels estils arquitectònics més populars de l'última dècada, però també un dels més malinterpretats: aporta enormes beneficis quan s'aplica amb criteri i un cost de complexitat considerable quan s'adopta per moda.

En aquesta lliçó en definirem les característiques, el compararem amb el monòlit, analitzarem quan convé (i quan no) i veurem un exemple concret de descomposició d'una aplicació d'assegurances.

Contingut

Definició i característiques
Microserveis enfront del monòlit
El monòlit modular com a alternativa
Quan SÍ que cal usar microserveis
Quan NO cal usar microserveis
Exemple de descomposició
Errors comuns i consells
Exercicis
Conclusió

Definició i característiques

Un microservei és un servei que compleix, idealment, aquestes característiques:

Responsabilitat única de negoci: gestiona una capacitat concreta (pòlisses, sinistres, facturació).
Desplegament independent: es pot desplegar sense coordinar-se amb la resta.
Base de dades pròpia: cada servei és propietari de les seves dades; ningú no accedeix a la seva base de dades directament.
Autonomia d'equip: un equip el desenvolupa, prova i opera de principi a fi.
Comunicació per xarxa: via API o missatges, mai compartint memòria.
Tolerància a errors: dissenyat per suportar que les seves dependències fallin.

graph TB
    subgraph "Aplicació d'Assegurances"
        P[Servei Pòlisses]
        S[Servei Sinistres]
        C[Servei Clients]
        F[Servei Facturació]
    end
    P --> DBP[(BD Pòlisses)]
    S --> DBS[(BD Sinistres)]
    C --> DBC[(BD Clients)]
    F --> DBF[(BD Facturació)]

Fixa't que cada servei té la seva pròpia base de dades. Aquest és un dels principis més importants: un servei mai no llegeix ni escriu a la base de dades d'un altre. Si necessita dades alienes, les demana per API o reacciona a esdeveniments.

Microserveis enfront del monòlit

Un monòlit és una aplicació desplegada com una única unitat. No és intrínsecament dolent; de fet, sol ser el punt de partida correcte. La comparació honesta és:

Aspecte	Monòlit	Microserveis
Desplegament	Una unitat	Moltes unitats independents
Escalat	Tot o res	Per servei, segons necessitat
Complexitat operativa	Baixa	Alta (xarxa, observabilitat, orquestració)
Velocitat inicial	Alta	Baixa (molta infraestructura prèvia)
Aïllament d'errors	Pobre (un error pot tombar-ho tot)	Bo (errors continguts)
Transaccions	ACID locals senzilles	Distribuïdes i complexes (sagues)
Tecnologia	Una pila comuna	Heterogènia per servei
Autonomia d'equips	Baixa (tots toquen el mateix)	Alta
Depuració	Senzilla (un procés, una traça)	Complexa (traces distribuïdes)

La conclusió clau: els microserveis canvien complexitat de desenvolupament per complexitat operativa. No l'eliminen.

El monòlit modular com a alternativa

Abans de saltar a microserveis, existeix una opció intermèdia molt infravalorada: el monòlit modular. Es tracta d'un únic desplegable, però internament organitzat en mòduls amb fronteres clares i comunicació explícita entre ells.

// Mòduls ben separats dins d'un únic desplegable.
// El mòdul de sinistres NO accedeix a les classes internes de pòlisses;
// només usa la seva API pública (una interfície).
package com.fiatc.siniestros;

public class ServicioSiniestros {

    private final PolizaApi polizaApi; // interfície pública del mòdul Pòlisses

    public ServicioSiniestros(PolizaApi polizaApi) {
        this.polizaApi = polizaApi;
    }

    public void registrarSiniestro(String polizaId) {
        // Consultem a través de l'API pública, no de taules internes
        if (!polizaApi.estaVigente(polizaId)) {
            throw new IllegalStateException("La póliza no está vigente");
        }
        // ... lògica de registre
    }
}

Aquest enfocament et dóna fronteres netes sense el cost de la xarxa. Si més endavant un mòdul necessita escalar o desplegar-se per separat, ja està aïllat i extreure'l a un microservei és molt més fàcil. És l'estratègia recomanada per començar.

Quan SÍ que cal usar microserveis

Els microserveis tenen sentit quan es compleixen diverses d'aquestes condicions:

L'organització és gran: molts equips que es trepitgen en treballar sobre el mateix codi.
Necessitats d'escalat dispars: el servei de facturació necessita 20 instàncies i el de configuració només 1.
Ritmes de canvi diferents: unes parts canvien a diari i altres gairebé mai.
Requisits de disponibilitat per domini: aïllar un error en sinistres perquè no tombi la contractació.
Maduresa en DevOps: existeix automatització de CI/CD, contenidors, observabilitat i orquestració.

La famosa "llei de Conway" ho resumeix: l'arquitectura del sistema tendeix a reflectir l'estructura de comunicació de l'organització. Si tens equips autònoms, els microserveis encaixen.

Quan NO cal usar microserveis

Evita els microserveis si:

L'equip és petit: la sobrecàrrega operativa no compensa.
El domini no està clar: si encara no entens bé les fronteres, les dibuixaràs malament i pagaràs un cost altíssim per corregir-les.
No hi ha maduresa operativa: sense observabilitat ni automatització, depurar és un infern.
Busques rendiment extrem en transaccions: les transaccions distribuïdes són lentes i complexes.

Un antipatró habitual és el monòlit distribuït: microserveis tan acoblats entre si que cal desplegar-los junts. Reuneix el pitjor de tots dos mons: la complexitat de la xarxa i la rigidesa del monòlit.

Símptoma	Diagnòstic
Per desplegar un servei cal desplegar-ne d'altres	Monòlit distribuït
Un canvi d'esquema afecta diversos serveis	Fronteres mal definides
Serveis que comparteixen base de dades	Acoblament de dades
Cadenes llargues de crides síncrones	Acoblament temporal

Exemple de descomposició

Partim d'un monòlit d'assegurances amb tot en un sol procés: clients, pòlisses, sinistres i facturació. Una descomposició raonable, per capacitats de negoci, seria:

# Mapa de serveis resultant
servicios:
  - nombre: clientes
    responsabilidad: "Datos de contacto y perfil del asegurado"
    datos_propios: [cliente, direccion]
  - nombre: polizas
    responsabilidad: "Contratación y ciclo de vida de pólizas"
    datos_propios: [poliza, cobertura]
  - nombre: siniestros
    responsabilidad: "Apertura y tramitación de siniestros"
    datos_propios: [siniestro, peritaje]
  - nombre: facturacion
    responsabilidad: "Recibos, cobros y devoluciones"
    datos_propios: [recibo, cobro]

Cada servei és propietari de les seves taules. Com obté el servei de sinistres el nom del client? No accedeix a la base de dades de clients; el demana per API o manté una còpia local de les poques dades que necessita, actualitzada mitjançant esdeveniments:

sequenceDiagram
    participant CL as Servei Clients
    participant BUS as Bus d'esdeveniments
    participant SI as Servei Sinistres
    CL->>BUS: Esdeveniment ClienteActualizado
    BUS->>SI: ClienteActualizado
    Note over SI: Actualitza la seva còpia local<br/>(nom, NIF anonimitzat)

Quan un client canvia les seves dades, el servei de clients publica un esdeveniment. El de sinistres manté una còpia mínima del que necessita i l'actualitza en rebre'l. Així s'evita l'acoblament directe a la base de dades aliena.

Errors Comuns i Consells

Començar directament amb microserveis: prefereix un monòlit modular fins a entendre bé el domini.
Compartir base de dades entre serveis: trenca l'autonomia i crea acoblament ocult. Cada servei, la seva base de dades.
Fer microserveis massa petits (nanoserveis): generen una explosió de crides de xarxa i dificulten raonar sobre el sistema.
Oblidar l'observabilitat: inverteix des del primer dia en traces distribuïdes, mètriques i logs correlacionats.
Sincronitzar-ho tot: les cadenes llargues de crides síncrones acoblen disponibilitat. Considera esdeveniments asíncrons.

Exercicis

Construeix una taula amb tres avantatges i tres inconvenients dels microserveis enfront del monòlit, justificant cada punt.
Una startup de 4 desenvolupadors vol llançar un MVP en 3 mesos. Recomanaries microserveis? Raona la teva resposta i proposa una alternativa.
Donat un monòlit d'e-commerce amb mòduls de catàleg, cistella, comandes i pagaments, proposa una descomposició en serveis indicant quines dades té cadascun i com obté el servei de comandes el preu actual d'un producte.

Solucions

Avantatges: desplegament independent (menys coordinació), escalat selectiu (estalvi de recursos), aïllament d'errors (major disponibilitat). Inconvenients: complexitat operativa (xarxa, orquestració), transaccions distribuïdes (sagues), depuració més difícil (traces distribuïdes).
No. Amb 4 persones i pressa per validar el producte, la sobrecàrrega operativa dels microserveis retardaria l'MVP. Recomanació: un monòlit modular amb fronteres netes, que permeti extreure serveis més endavant si el producte creix.
El catàleg té producto i precio; la cistella té linea_carrito; les comandes tenen pedido i linea_pedido; els pagaments tenen transaccion. El servei de comandes obté el preu cridant l'API del catàleg en el moment de confirmar la comanda i, molt important, desa el preu aplicat a la seva pròpia taula linea_pedido, perquè el preu del catàleg pot canviar després.

Conclusió

Els microserveis són serveis petits, autònoms i desplegables de manera independent, cadascun propietari de les seves dades. Canvien complexitat de desenvolupament per complexitat operativa, així que només valen la pena quan l'organització, l'escalat i la maduresa tècnica ho justifiquen. En cas de dubte, el monòlit modular és un excel·lent punt de partida.

La pregunta més difícil que queda pendent és on traçar les fronteres entre serveis. A això dedicarem la lliçó següent, Descomposició de Serveis i Bounded Contexts, on aplicarem les idees del Disseny Guiat pel Domini per encertar amb la mida i els límits de cada servei.

Arquitectura de Microserveis

Contingut

Definició i característiques

Microserveis enfront del monòlit

El monòlit modular com a alternativa

Quan SÍ que cal usar microserveis

Quan NO cal usar microserveis

Exemple de descomposició

Errors Comuns i Consells

Exercicis

Solucions

Conclusió

Curs d'Arquitectura d'Aplicacions

Mòdul 1: Fonaments de l'Arquitectura d'Aplicacions

Mòdul 2: Principis i Tàctiques de Disseny

Mòdul 3: Estils i Patrons Arquitectònics

Mòdul 4: Arquitectures Distribuïdes i Microserveis

Mòdul 5: Arquitectures Dirigides per Esdeveniments i Missatgeria

Mòdul 6: Disseny Dirigit pel Domini (DDD)

Mòdul 7: Dades i Persistència

Mòdul 8: Arquitectura al Núvol i Desplegament

Mòdul 9: Qualitat, Seguretat i Observabilitat

Mòdul 10: Evolució, Governança i Casos Pràctics