2024 hjälpte vi ett lokalt fintechföretag att konvertera en 6-årig monolit (80 000+ rader kod, 12 utvecklare, 45 installationer dagligen) för mikrotjänster. Resan ägde rum14 månaderDet är mycket arbete, fler lektioner och siffror som talar.

När funderar du på att byta?

Inte varje monolit behöver transformation. Varningsskyltar som säger att det är dags:

  • Distribuera en paus i 3 separata delar
  • Ett team som kräver timmar av koordination för att publicera en funktion
  • Du kan inte stänga av en del av systemet utan att stänga av hela systemet
  • CI-pipelinetiden översteg 30 minuter
  • Kodbasen förblir ”ingen vet allt”

När?vadFunderar du på att byta?

  • Ditt team är mindre än 10 utvecklare
  • Monolith fungerar bra och det finns inga prestandaklagomål
  • Du har inget specialiserat infrastrukturteam
  • Att anta MVP – mikrotjänster i början är självmord

”Mikrotjänster har en hög driftskostnad. Företag som byter på grund av trenden förlorar – de löser problem som inte fanns och importerar nya.”

Stadier av transformation – metoden vi följde

Steg 1: Strangler Fig Pattern (3 månader)

Vi började med att placera API-gatewayen framför monoliten och byggde sedan den första nya mikrotjänsten (Notifications) utan att röra monoliten. Varje ny begäran går till den nya tjänsten, den gamla fortsätter att köras.

Fas 2: Extrahera begränsade sammanhang (5 månader)

Vi definierade de avgränsade sammanhangen (användare, beställningar, betalningar, rapporter) och började extrahera dem en efter en. Varje extraktion tog 4-6 veckor. Databasen var den största utmaningen – inte koden.

Fas 3: Datanedbrytning (4 månader)

Partitionering av databasen var det svåraste steget. Vi använde dendual-write patternFörst – vi skriver i två delar – sedan en gradvis övergång. Vi arbetade med avstämningsskript varje dag för att säkerställa konsekvens.

Steg 4: Rengöring (2 månader)

Efter att alla tjänster körts återvände vi till monoliten och tog bort den överförda koden. Monoliten förvandlas till en ”legacy tjänst” men med 20 % av sin ursprungliga storlek.

Verkliga siffror

  • Distributionsfrekvens: från 45/dag till200+/dag
  • Medeltid till återhämtning: från 45 minuter till8 minuter
  • Infrastructure cost: ökade 40%(verklig byteskostnad)
  • Utvecklarens produktivitet (funktioner/sprint): Ökad2,3x
  • Incidenter: minskat60 %6 månader efter färdigställandet

5 lektioner vi lärde oss

1. Börja med distributionspipeline, inte med koden

Om du inte har mogen CI/CD, behållare, övervakning och servicenät — kommer transformationen att misslyckas. Förbered den första infrastrukturen.

2. Databasen är den verkliga fienden

Det är enkelt att dela upp koden. Dela upp data samtidigt som konsistensen bibehålls – det här är det verkliga projektet.

3. Den återstående distribuerade spårningen är valfri

Utan Jaeger eller Tempo är det omöjligt att felsöka ett problem med 5 tjänster. Installera det innan den första servicen.

4. Laget behöver träning

Mönstren är helt olika. Saga, event sourcing, CQRS — inte alla lag är redo för det. Investera i förkodsutbildning.

5. Ändra inte allt på en gång

Big bang-migreringar misslyckas alltid. Strypmönstret ger möjligheten att dra sig tillbaka i vilket skede som helst.

Slutsats

Mikrotjänster är ingen magisk lösning – de är ett verktyg som löser specifika problem och introducerar nya. Om du bestämmer dig för att börja, planera 18 månader, tilldela en tillräcklig budget och förbered dig för en svår men givande resa. Om du behöver bevis från någon som har gått vägen så finns vi här.