Bygga robusta serverlösa system
Utforma mycket tillgängliga och feltåliga serverlösa arkitekturer genom att införa mönster som circuit breakers, återförsök och idempotens i era funktioner.
Bygga robusta serverlösa system är en gratis lektion i Serverlös utveckling med AWS Lambda på CoddyKit. Detta är lektion 2 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Serverlös utveckling med AWS Lambda, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Serverlös utveckling med AWS Lambda innehåller totalt 4 lektioner.
Bygga robusta serverlösa system
Välkommen! I den här lektionen går vi igenom hur man utformar mycket motståndskraftiga och feltoleranta serverlösa applikationer. Även om AWS hanterar en stor del av infrastrukturen måste dina funktioner fortfarande kunna hantera fel på ett kontrollerat sätt.
Vi utforskar viktiga arkitekturmönster som hjälper dig att säkerställa att applikationerna förblir stabila och har god prestanda även när något går fel.
Distribuerade systems verklighet
I en serverlös miljö samverkar dina funktioner ofta med många andra tjänster: databaser, API:er och meddelandeköer. Dessa interaktioner sker över ett nätverk, och nätverk kan vara opålitliga.
- Övergående fel: Korta nätverksstörningar eller tillfälliga tjänstefördröjningar.
- Problem i underliggande tjänster: En tjänst som din Lambda anropar kan vara tillfälligt otillgänglig.
- Oväntade data: Felaktigt formaterade indata kan få funktionen att krascha.
Att utforma systemet för sådana "fel" är avgörande för ett stabilt system.
Lambdas inbyggda logik för nya försök
För vissa typer av anrop försöker AWS Lambda automatiskt köra funktionen igen om den misslyckas. Detta är en kraftfull inbyggd motståndskraftsmekanism för asynkrona anrop.
Om till exempel en SQS-kö utlöser din Lambda och funktionen ger ett fel, försöker Lambda (eller SQS) göra om anropet några gånger. Det hjälper till att hantera övergående problem utan några kodändringar.
Nya försök är dock ingen universallösning. Om de inte hanteras korrekt kan de leda till att samma data behandlas flera gånger.
Göra operationer idempotenta
När nya försök görs kan din funktion köra samma operation flera gånger. Det är här idempotens kommer in i bilden.
En idempotent operation är en operation som kan utföras flera gånger utan att resultatet ändras utöver det som den första körningen åstadkom.
- Exempel: Att tilldela ett värde (
x = 5) är idempotent. - Motexempel: Att öka ett värde (
x++) är INTE idempotent, eftersom varje nytt försök skulle ändra värdet.
I motståndskraftiga system bör många operationer utformas så att de är idempotenta.
Nycklar till idempotenta funktioner
För att göra dina Lambda-funktioner idempotenta behöver du ofta hålla reda på tillståndet för en begäran. Detta innebär vanligtvis att:
- En unik idempotensnyckel genereras för varje begäran (till exempel från begärans-ID eller händelsekällans ID).
- Det kontrolleras om nyckeln redan har behandlats innan kärnlogiken körs.
- Resultatet eller statusen för operationen som hör till nyckeln lagras.
Detta säkerställer att den centrala sidoeffekten bara inträffar en gång, även om en funktion körs igen.
import hashlib
import json
# Imagine a database or cache for storing processed requests
# For simplicity, using a global dict here. A real app uses persistent storage.
processed_requests = {}
def is_idempotent(event_payload):
# Create a unique key from the event payload
# For a real app, use a proper hashing/unique ID strategy
event_hash = hashlib.md5(json.dumps(event_payload, sort_keys=True).encode('utf-8')).hexdigest()
if event_hash in processed_requests:
print(f"Request with hash {event_hash} already processed.")
return True
processed_requests[event_hash] = "processing" # Mark as processing
return False
def lambda_handler(event, context):
if is_idempotent(event):
return {
'statusCode': 200,
'body': json.dumps('Request already processed or is being processed.')
}
# Simulate actual work (e.g., writing to a database)
print(f"Processing new request: {event}")
# In a real scenario, update processed_requests[event_hash] = "completed"
# after successful processing and store the result in persistent storage.
return {
'statusCode': 200,
'body': json.dumps('Request processed successfully!')
}
Förhindra kaskaderande fel
Mönstret Circuit Breaker är ett kraftfullt sätt att förhindra att en tjänst med fel orsakar kaskaderande fel i hela applikationen.
Föreställ dig ett anrop till ett externt API som börjar misslyckas. Om du fortsätter att försöka anropa det slösar du bara med resurser och gör funktionen långsammare. En circuit breaker upptäcker detta och "öppnar" kretsen, vilket tillfälligt stoppar anropen till tjänsten med fel.
Det ger tjänsten med fel tid att återhämta sig och förhindrar att applikationen överbelastas.
Så fungerar en Circuit Breaker
En circuit breaker har vanligtvis tre tillstånd:
- Closed: Operationerna fortsätter som vanligt. Om antalet fel överskrider en tröskel övergår den till Open.
- Open: Alla anrop till den skyddade tjänsten misslyckas omedelbart (eller returnerar ett reservsvar). Efter en tidsgräns övergår den till Half-Open.
- Half-Open: Ett begränsat antal testanrop tillåts. Om de lyckas övergår den tillbaka till Closed. Om de misslyckas återgår den till Open.
Detta intelligenta beteende möjliggör självläkning.
Implementera en enkel Circuit Breaker
Att implementera en komplett circuit breaker innebär att tillstånd måste hanteras (antal fel, antal lyckade anrop och tidpunkt för det senaste felet). I serverlösa system kan detta tillstånd lagras i en delad cache (till exempel ElastiCache) eller i en databas.
Även om det är komplext att implementera detta från grunden i en enkel Lambda är det viktigt att förstå logiken. Det finns bibliotek för olika språk som kan hjälpa till, eller så kan du använda AWS-tjänster som Step Functions för att orkestrera logik för nya försök med fördröjningar.
import time
class CircuitBreaker:
def __init__(self, failure_threshold=3, reset_timeout=5):
self.state = "CLOSED"
self.failure_count = 0
self.last_failure_time = 0
self.failure_threshold = failure_threshold
self.reset_timeout = reset_timeout # seconds
def call(self, func, *args, **kwargs):
if self.state == "OPEN":
if time.time() - self.last_failure_time > self.reset_timeout:
self.state = "HALF-OPEN"
# In a real app, log this state change
else:
raise Exception("Circuit is open, service unavailable.")
try:
result = func(*args, **kwargs)
if self.state == "HALF-OPEN":
self.state = "CLOSED"
self.failure_count = 0
# In a real app, log this state change
return result
except Exception as e:
self.failure_count += 1
self.last_failure_time = time.time()
if self.failure_count >= self.failure_threshold:
self.state = "OPEN"
# In a real app, log this state change
raise e
Tidsgränser förhindrar att körningen hänger sig
Ett annat viktigt motståndskraftsmönster är att använda tidsgränser för externa anrop. Om din Lambda-funktion anropar en annan tjänst (till exempel en databas eller ett HTTP-API) kan anropet hänga sig för alltid om tjänsten inte svarar.
Genom att konfigurera en tidsgräns säkerställer du att funktionen inte väntar för evigt. Resurser frigörs och logiken för nya försök kan aktiveras snabbare. AWS Lambda har en konfigurerbar tidsgräns, men du bör också ange tidsgränser i koden för specifika externa begäranden.
Utmaning: Motståndskraftig design
Föreställ dig en Lambda-funktion som behandlar inkommande beställningar. Om funktionen misslyckas efter att betalningen har dragits men innan orderstatusen har uppdaterats i en databas, och sedan körs igen, vilket problem kan uppstå om betalningsdragningen INTE är idempotent?
Sammanfattning: Bygga för fel
Vi har gått igenom viktiga mönster för att bygga motståndskraftiga serverlösa applikationer:
- Nya försök: Lambdas inbyggda mekanism för övergående fel.
- Idempotens: Säkerställa att operationer kan göras om på ett säkert sätt utan oönskade sidoeffekter (till exempel dubbla debiteringar).
- Circuit Breakers: Förhindra kaskaderande fel genom att på ett intelligent sätt stoppa anrop till tjänster med fel.
- Tidsgränser: Skydda mot externa tjänster som inte svarar.
Genom att tillämpa dessa principer kan du skapa serverlösa system som hanterar oundvikliga fel på ett kontrollerat sätt.
Lär dig Serverlös utveckling med AWS Lambda med en AI-lärare – gratis
Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.
- Kurser
- 12
- Lektioner
- 48
Vanliga frågor
Är lektionen ”Bygga robusta serverlösa system” gratis?
Ja – hela texten till ”Bygga robusta serverlösa system” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Serverlös utveckling med AWS Lambda, kan Ni uppgradera till CoddyKit PRO. Kursen i Serverlös utveckling med AWS Lambda innehåller totalt 4 lektioner.
Vad lär jag mig i ”Bygga robusta serverlösa system”?
Utforma mycket tillgängliga och feltåliga serverlösa arkitekturer genom att införa mönster som circuit breakers, återförsök och idempotens i era funktioner. Ni övar på Serverlös utveckling med AWS Lambda med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.
Behöver jag någon erfarenhet för att börja lära mig Serverlös utveckling med AWS Lambda?
Du behöver inga förkunskaper. Utbildningen i Serverlös utveckling med AWS Lambda på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.
Hur lång tid tar lektionen ”Bygga robusta serverlösa system”?
De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.
Kan jag skriva och köra kod i den här Serverlös utveckling med AWS Lambda-lektionen?
Ja. Varje Serverlös utveckling med AWS Lambda-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.
Alla lektioner i den här kursen
- Canary- och Blue/Green-distributioner
- Bygga robusta serverlösa system
- Serverlösa arkitekturmönster
- Kostnadsoptimering i serverless-arkitekturer