Design af en serverless-mikrotjeneste

Velkommen til arbejdet med at designe en serverløs mikrotjeneste fra den virkelige verden! Lad os først forstå, hvad en mikrotjeneste er i denne sammenhæng.

• En mikrotjeneste er en lille, uafhængig tjeneste, der udfører én forretningsfunktion.
• Den udrulles og administreres uafhængigt og kommunikerer med andre mikrotjenester via API'er.
• Når vi siger serverløs mikrotjeneste, mener vi tjenester, der er bygget med serverløse teknologier som AWS Lambda og API Gateway.

Denne tilgang hjælper med at bygge skalerbare, vedligeholdelsesvenlige og robuste applikationer.

Serverløs arkitektur passer perfekt til mikrotjenester. Her er hvorfor:

• Automatisk skalering: Serverløse funktioner som Lambda skalerer automatisk op eller ned baseret på belastningen og håndterer trafikspidser uden problemer.
• Betaling efter forbrug: Du betaler kun for den beregningstid og de ressourcer, dine funktioner faktisk bruger, hvilket giver betydelige besparelser.
• Mindre driftsarbejde: AWS administrerer den underliggende infrastruktur, programrettelser og skalering, så du kan fokusere på applikationens logik.
• Hurtigere udvikling: Mindre, fokuserede tjenester er nemmere at udvikle, teste og udrulle uafhængigt.

Design af en serverløs mikrotjeneste involverer ofte nogle få centrale AWS-tjenester:

• AWS API Gateway: Den fungerer som 'hoveddøren' til din mikrotjeneste, håndterer alle indgående HTTP-anmodninger og dirigerer dem til den korrekte backend.
• AWS Lambda: Din beregningstjeneste. Lambda-funktionerne indeholder den faktiske forretningslogik for din mikrotjeneste.
• Amazon DynamoDB: En hurtig og fleksibel NoSQL-databasetjeneste, der er velegnet til serverløse applikationer på grund af dens skalerbarhed og betalingsmodel baseret på forbrug.
• Amazon SQS/SNS: Bruges til asynkron kommunikation mellem mikrotjenester og forbedrer afkobling og fejltolerance.

Det første trin i designet af din mikrotjeneste er at definere dens offentlige grænseflade: API-slutpunkterne.

• Identificer ressourcer: Hvilke "ting" administrerer din tjeneste? (f.eks. produkter, ordrer, brugere).
• Definer handlinger: Hvilke handlinger kan udføres på disse ressourcer? (f.eks. opret, hent, opdater, slet).
• Brug HTTP-metoder: Knyt handlinger til standardiserede HTTP-metoder (GET til hentning, POST til oprettelse, PUT/PATCH til opdatering, DELETE til sletning).
• Design tydelige stier: Brug beskrivende, hierarkiske URL'er til dine ressourcer (f.eks. /products/{id}).

Et veldesignet API er intuitivt og nemt at bruge.

Lad os designe API'et til en simpel mikrotjeneste for "Produkter":

• GET /products: Hent en liste over alle produkter.
• POST /products: Opret et nyt produkt.
• GET /products/{id}: Hent oplysninger om et bestemt produkt.
• PUT /products/{id}: Opdater et eksisterende produkt.
• DELETE /products/{id}: Fjern et produkt.

Hvert af disse slutpunkter vil typisk blive håndteret af en specifik Lambda-funktion, der udløses af API Gateway.

Efter at have defineret dit API skal du designe, hvordan mikrotjenestens data skal gemmes. I DynamoDB betyder det, at du skal overveje dine adgangsmønstre.

• Identificer entiteter: Hvad er de vigtigste dataobjekter? (f.eks. et produkt, en bruger).
• Fastlæg adgangsmønstre: Hvordan vil du forespørge på disse data? (f.eks. "hent produkt efter id", "vis produkter efter kategori").
• Vælg primærnøgler: Vælg en Partition Key og eventuelt en Sort Key, der understøtter dine hyppigste adgangsmønstre. Det er afgørende for ydeevnen i DynamoDB.
• Denormaliser efter behov: DynamoDB har ofte fordel af denormalisering, fordi det reducerer joins og forbedrer læseydeevnen.

For vores mikrotjeneste for "Produkter" kunne en simpel DynamoDB-datamodel se sådan ud:

Tabel: Products

• Partition Key: productId (f.eks. 'P123')
• Attributter:
• name (String)
• description (String)
• price (Number)
• category (String)
• stock (Number)
• createdAt (String/Timestamp)

Dette design gør det muligt at hente produkter effektivt efter deres entydige id.

Mikrotjenester eksisterer sjældent isoleret. De skal kommunikere med hinanden. Der findes to hovedmønstre:

• Synkron kommunikation: Én tjeneste kalder en anden direkte og venter på et svar.
• Eksempel: Tjeneste A kalder Tjeneste B's API Gateway-slutpunkt.
• Fordele: Øjeblikkelig feedback.
• Ulemper: Tæt kobling, Tjeneste A venter, og det kan føre til kaskaderende fejl.
• Asynkron kommunikation: Tjenester kommunikerer via meddelelser uden at vente på et øjeblikkeligt svar.
• Eksempel: Tjeneste A publicerer en meddelelse til SNS/SQS, og Tjeneste B behandler den senere.
• Fordele: Løst koblet, modstandsdygtigt over for fejl og bedre skalerbarhed.
• Ulemper: Sværere at spore, eventual consistency.

Asynkrone mønstre foretrækkes generelt til serverløse mikrotjenester.

Når du designer, skal du altid overveje, hvordan din mikrotjeneste håndterer forhold fra den virkelige verden:

• Fejltolerance: Design med henblik på fejl. Hvad sker der, hvis en downstream-tjeneste ikke er tilgængelig? Implementer gentagne forsøg med eksponentiel backoff.
• Idempotens: Sørg for, at det har samme effekt at gentage en forespørgsel flere gange som at sende den én gang. Det er afgørende i distribuerede systemer.
• Overvågning og logning: Planlæg, hvordan du vil overvåge tjenestens tilstand og ydeevne (f.eks. AWS CloudWatch).
• Sikkerhed: Definer IAM-roller efter princippet om mindst mulige privilegier. Overvej autorisatorer til API Gateway.

Disse overvejelser fører til mere modstandsdygtige og vedligeholdelsesvenlige systemer.

Tillykke! Du har gennemgået de vigtigste trin i designet af en serverløs mikrotjeneste.

• Vi definerede, hvad en serverløs mikrotjeneste er, og hvilke fordele den har.
• Vi udforskede de centrale AWS-tjenester, der indgår.
• Vi lærte at designe tydelige API-slutpunkter og effektive datamodeller.
• Vi forstod betydningen af asynkron kommunikation og robuste arkitekturprincipper.

Dette grundlæggende designarbejde er afgørende, før du skriver en eneste kodelinje. Nu skal du begynde at implementere disse designs!