Utforma en serverless-mikrotjänst

Välkommen till utformningen av en verklig serverlös mikrotjänst! Låt oss först förstå vad en mikrotjänst innebär i det här sammanhanget.

• En mikrotjänst är en liten, oberoende tjänst som tillhandahåller en enda affärsfunktion.
• Den distribueras och hanteras oberoende av andra tjänster och kommunicerar med andra mikrotjänster via API:er.
• När vi säger serverlös mikrotjänst menar vi tjänster som byggs med serverlösa tekniker som AWS Lambda och API Gateway.

Detta tillvägagångssätt bidrar till skalbara, lättunderhållna och motståndskraftiga applikationer.

Serverlös arkitektur passar perfekt för mikrotjänster. Här är varför:

• Automatisk skalning: Serverlösa funktioner, som Lambda, skalas automatiskt upp eller ned utifrån efterfrågan och hanterar trafiktoppar utan problem.
• Betala per användning: Ni betalar endast för den beräkningstid och de resurser som Era funktioner faktiskt använder, vilket ger betydande kostnadsbesparingar.
• Mindre driftarbete: AWS hanterar den underliggande infrastrukturen, korrigeringar och skalning, så att Ni kan fokusera på applikationens logik.
• Snabbare utveckling: Mindre, fokuserade tjänster är enklare att utveckla, testa och distribuera oberoende av varandra.

Utformningen av en serverlös mikrotjänst omfattar ofta några centrala AWS-tjänster:

• AWS API Gateway: Fungerar som mikrotjänstens ”ytterdörr”, hanterar alla inkommande HTTP-förfrågningar och dirigerar dem till rätt backend.
• AWS Lambda: Er beräkningstjänst. Lambda-funktionerna innehåller mikrotjänstens faktiska affärslogik.
• Amazon DynamoDB: En snabb och flexibel NoSQL-databastjänst som passar bra för serverlösa applikationer tack vare skalbarheten och modellen med betalning per användning.
• Amazon SQS/SNS: För asynkron kommunikation mellan mikrotjänster, vilket förbättrar frikoppling och feltålighet.

Det första steget när Ni utformar Er mikrotjänst är att definiera dess offentliga gränssnitt: API-slutpunkterna.

• Identifiera resurser: Vilka ”saker” hanterar Er tjänst? (t.ex. Products, Orders, Users).
• Definiera åtgärder: Vilka åtgärder kan utföras på dessa resurser? (t.ex. Create, Read, Update, Delete).
• Använd HTTP-metoder: Koppla åtgärder till standardiserade HTTP-metoder (GET för Read, POST för Create, PUT/PATCH för Update, DELETE för Delete).
• Utforma tydliga sökvägar: Använd beskrivande, hierarkiska URL:er för Era resurser (t.ex. /products/{id}).

Ett välutformat API är intuitivt och enkelt att använda.

Låt oss utforma API:et för en enkel mikrotjänst för ”Products”:

• GET /products: Hämtar en lista över alla produkter.
• POST /products: Skapar en ny produkt.
• GET /products/{id}: Hämtar information om en specifik produkt.
• PUT /products/{id}: Uppdaterar en befintlig produkt.
• DELETE /products/{id}: Tar bort en produkt.

Var och en av dessa slutpunkter hanteras vanligtvis av en specifik Lambda-funktion som utlöses av API Gateway.

När Ni har definierat Ert API behöver Ni utforma hur mikrotjänstens data ska lagras. För DynamoDB innebär det att tänka igenom Era åtkomstmönster.

• Identifiera entiteter: Vilka är de viktigaste dataobjekten? (t.ex. en Product eller en User).
• Fastställ åtkomstmönster: Hur kommer Ni att fråga efter dessa data? (t.ex. ”hämta produkt efter ID” eller ”visa produkter efter kategori”).
• Välj primärnycklar: Välj en Partition Key och vid behov en Sort Key som stöder Era vanligaste åtkomstmönster. Detta är avgörande för prestandan i DynamoDB.
• Denormalisera vid behov: DynamoDB drar ofta nytta av denormalisering för att minska antalet joins och förbättra läsprestandan.

För vår mikrotjänst för ”Products” kan en enkel datamodell i DynamoDB se ut så här:

Tabell: Products

• Partition Key: productId (t.ex. 'P123')
• Attribut:
• name (String)
• description (String)
• price (Number)
• category (String)
• stock (Number)
• createdAt (String/Timestamp)

Den här utformningen gör det möjligt att effektivt hämta produkter med deras unika ID.

Mikrotjänster existerar sällan isolerat. De behöver kommunicera. Det finns två huvudsakliga mönster:

• Synkron kommunikation: En tjänst anropar en annan direkt och väntar på ett svar.
• Exempel: Service A anropar API Gateway-slutpunkten för Service B.
• Fördelar: Omedelbar återkoppling.
• Nackdelar: Hårt kopplade tjänster, Service A måste vänta och det kan leda till kedjereaktioner av fel.
• Asynkron kommunikation: Tjänster kommunicerar via meddelanden utan att vänta på ett omedelbart svar.
• Exempel: Service A publicerar ett meddelande till SNS/SQS och Service B konsumerar det senare.
• Fördelar: Löskopplade tjänster, motståndskraft mot fel och förbättrad skalbarhet.
• Nackdelar: Svårare att spåra och eventual consistency.

Asynkrona mönster föredras i allmänhet för serverlösa mikrotjänster.

När Ni utformar Er mikrotjänst bör Ni alltid överväga hur den ska hantera verkliga förhållanden:

• Feltålighet: Utforma lösningen för att hantera fel. Vad händer om en nedströms tjänst inte är tillgänglig? Implementera nya försök med exponentiell backoff.
• Idempotens: Säkerställ att flera upprepningar av samma begäran ger samma resultat som ett enda anrop. Detta är avgörande i distribuerade system.
• Övervakning och loggning: Planera hur Ni ska observera tjänstens hälsa och prestanda (t.ex. AWS CloudWatch).
• Säkerhet: Definiera IAM-roller enligt principen om minsta privilegium. Överväg authorizers i API Gateway.

Dessa överväganden leder till mer motståndskraftiga och lättare underhållna system.

Grattis! Ni har gått igenom de viktigaste stegen för att utforma en serverlös mikrotjänst.

• Vi definierade vad en serverlös mikrotjänst är och vilka fördelar den har.
• Vi utforskade de centrala AWS-tjänsterna som ingår.
• Vi lärde oss att utforma tydliga API-slutpunkter och effektiva datamodeller.
• Vi förstod vikten av asynkron kommunikation och robusta arkitekturprinciper.

Detta grundläggande designarbete är avgörande innan Ni skriver en enda rad kod. Nästa steg är att börja implementera dessa designer!