Hoppa till innehållet

ett distribuerat affärssystem · 2022 · universitetsprojekt

Distribuerat affärssystem

Ett universitetsprojekt där jag byggde ett system så som stora organisationer gör: flera tjänster som var och en äger sin egen data och pratar över REST. Det mesta jag vet om gränserna mellan tjänster lärde jag mig genom att få dem fel här först.

Lager
applikation, tjänster, data
Byggt med
SOA · Microservices · Service Architecture · Enterprise Patterns
Länkar
källkod på GitHub
TJÄNSTEZON · PRIVAT NÄT PUBLIK KANT client browser · JSON gateway auth · JWT rate limit route · retry REST · HTTP/1.1 account :8081 ctrl svc repo accounts person :8082 ctrl svc repo persons bank :8083 ctrl svc repo banks ETT LAGER PER TJÄNST GET /persons/{id} EN BEGÄRAN, TIDSLINJE · req 7f3a client gateway account person t=0 · POST /transfer +4 ms · auth ok +11 ms · owner? +23 ms · 200 +31 ms · 201 created +33 ms timeout 800 ms · 2 försök 1 2 3 4 5 6
Fig. 01 — Tjänster bakom en gateway, var och en med sitt eget lager, som pratar över REST. Nedanför, en begäran som korsar dem.
  1. 1API-gateway · auth, hastighetsbegränsning, routing med omförsök
  2. 2Tjänst · controller-, service- och repository-lager
  3. 3Lager · en databas per tjänst, inget delat
  4. 4REST · JSON över HTTP, versionerade sökvägar
  5. 5Anrop mellan tjänster · account frågar person vem som äger vad
  6. 6Timeout och omförsök · misslyckas snabbt, logga med begärans id

Problemet

En universitetskurs i enterprise-system med en avsiktligt obekväm uppgift: bygg ett system så som stora organisationer gör, som flera oberoende tjänster som måste samarbeta utan att dela databas.

Vad jag byggde

En uppsättning mikrotjänster, var och en med ansvar för en affärsdomän och sitt eget datalager, som pratar med varandra över RESTful API:er bakom en gateway. Jag tillämpade mönstren kursen handlade om, Repository, Service Layer och DTO:er, och lade den mesta kraften på gränserna: hur en tjänst ber en annan om något den inte äger, vad som händer när anropet misslyckas, och hur man loggar tvärs över tjänster så att ett problem går att spåra från början till slut.

Vad jag lärde mig

Det mesta jag vet om gränser mellan tjänster lärde jag mig genom att få dem fel här först. Att dela upp ett system är lätt; att bestämma vad varje del äger är det verkliga designarbetet. De lärdomarna gick rakt över till molnsidan av IoT-arbetet senare, där maskiner och tjänster pratar över opålitliga nätverk.