Robustes HTTP-Client-Design in Go

Einleitung

In modernen verteilten Systemen interagieren Dienste häufig über HTTP miteinander. Während Go's net/http-Paket einen robusten und effizienten http.Client für diese Anfragen bietet, reicht die reine Nutzung oft nicht aus, um die Anforderungen der Produktion zu erfüllen. Netzwerkaufrufe sind von Natur aus unzuverlässig; sie können aufgrund transienter Netzwerkprobleme, Serverüberlastung oder unerwarteter Latenzen fehlschlagen. Ohne angemessene Schutzmaßnahmen können sich diese Ausfälle in einem System fortpflanzen, was zu kaskadierenden Ausfällen und einer schlechten Benutzererfahrung führt. Dieser Artikel befasst sich damit, wie wir Go's Standard-http.Client wrappen können, um wesentliche fehlertolerante Muster zu integrieren: Wiederholungsversuche, Timeouts und Circuit Breaker. Durch die Übernahme dieser Strategien können wir die Ausfallsicherheit und Stabilität unserer Anwendungen erheblich verbessern und eine zuverlässige Kommunikation auch angesichts von Widrigkeiten gewährleisten.

Kernkonzepte erklärt

Bevor wir uns mit den Implementierungsdetails befassen, wollen wir die Kernkonzepte verteilter Systeme klären, die wir besprechen werden:

Timeout: Ein Timeout definiert die maximale Dauer, die eine Operation dauern darf, bevor sie abgebrochen wird. Sein Hauptzweck ist es, zu verhindern, dass ein Client unendlich lange auf eine Antwort wartet, wodurch Ressourcen freigegeben und ein Rückstau von blockierten Anfragen vermieden wird. Es gibt im Allgemeinen zwei Arten: Verbindungs-Timeouts (zum Herstellen einer Verbindung) und Anforderungs-Timeouts (für den gesamten Anfrage-Antwort-Zyklus).

Retry (Wiederholungsversuch): Ein Wiederholungsmechanismus versucht eine fehlgeschlagene Operation automatisch erneut und geht davon aus, dass der Fehler vorübergehend sein könnte. Es ist wichtig, Wiederholungsversuche mit einer exponentiellen Backoff-Strategie und einer maximalen Anzahl von Versuchen zu implementieren, um den Zielservice nicht zu überlasten und ihm Zeit zur Erholung zu geben. Nicht alle Fehler sind wiederholbar; zum Beispiel wird eine Anfrage mit Fehlercode 400 Bad Request bei einem erneuten Versuch nicht magisch zu einer 200.

Circuit Breaker (Leistungsschalter): Inspiriert von elektrischen Leistungsschaltern verhindert dieses Muster, dass eine Anwendung wiederholt versucht, eine Operation auszuführen, die fehlschlagen wird. Wenn ein Circuit Breaker eine hohe Fehlerrate erkennt, löst er aus (öffnet) und schlägt nachfolgende Aufrufe sofort fehl, ohne die Operation zu versuchen. Nach einem vordefinierten Intervall wechselt er in einen „halb offenen“ Zustand, der einer begrenzten Anzahl von Testanfragen erlaubt, durchzukommen. Wenn diese erfolgreich sind, schließt sich der Stromkreis wieder; andernfalls kehrt er in den offenen Zustand zurück. Dieses Muster verhindert kaskadierende Fehler und gibt dem fehlerhaften Dienst Zeit zur Erholung.

Aufbau eines ausfallsicheren HTTP-Clients

Unser Ziel ist es, einen Dekorierer für http.Client zu erstellen, der diese Fehlertoleranzfunktionen nahtlos integriert. Lassen Sie uns eine benutzerdefinierte HTTPClient-Schnittstelle und deren Implementierung entwerfen.

Einrichtung und Basiskomponente

Zuerst definieren wir eine einfache Schnittstelle für unseren HTTP-Client, um einfaches Mocking und Testen zu ermöglichen.

package resilientclient

import (
	"net/http"
	"time"
)

// HTTPClient interface definiert den Vertrag für unseren Client
type HTTPClient interface {
	Do(req *http.Request) (*http.Response, error)
}

// defaultClient wrappt den Standard http.Client
type defaultClient struct {
	client *http.Client
}

// NewDefaultClient erstellt einen neuen Standardclient
func NewDefaultClient(timeout time.Duration) HTTPClient {
	return &defaultClient{
		client: &http.Client{
			Timeout: timeout, // Basis-Anforderungs-Timeout
			Transport: &http.Transport{
				MaxIdleConns:        100,
				IdleConnTimeout:     90 * time.Second,
				TLSHandshakeTimeout: 10 * time.Second,
				// Weitere Transportoptionen können hier hinzugefügt werden
			},
		},
	}
}

// Do implementiert das HTTPClient-Interface für defaultClient
func (c *defaultClient) Do(req *http.Request) (*http.Response, error) {
	return c.client.Do(req)
}

Hier haben wir bereits einen grundlegenden Anforderungs-Timeout über http.Client.Timeout eingeführt. Dies ist ein guter Ausgangspunkt, um unendliche Wartezeiten zu verhindern.

Implementierung von Wiederholungsversuchen

Wiederholungsversuche wrappen die Do-Methode. Wir führen einen RetryClient ein, der einen anderen HTTPClient als Argument nimmt.

package resilientclient

import (
	"bytes"
	"fmt"
	"io"
	"io/ioutil"
	"log"
	"net/http"
	"time"
)

// RetryConfig speichert Parameter für die Wiederholungslogik
type RetryConfig struct {
	MaxRetries    int
	InitialDelay  time.Duration
	MaxDelay      time.Duration
	// Fügen Sie eine Prädikatsfunktion hinzu, wenn bestimmte Fehler nicht wiederholt werden sollen
	ShouldRetry func(*http.Response, error) bool
}

// RetryClient bietet Wiederholungslogik für HTTP-Anfragen
type RetryClient struct {
	delegate HTTPClient
	config   RetryConfig
}

// NewRetryClient erstellt einen neuen Client mit Wiederholungsfunktionen
func NewRetryClient(delegate HTTPClient, config RetryConfig) *RetryClient {
	if config.MaxRetries == 0 {
		config.MaxRetries = 3 // Standard-Wiederholungsversuche
	}
	if config.InitialDelay == 0 {
		config.InitialDelay = 100 * time.Millisecond // Standard-Startverzögerung
	}
	if config.MaxDelay == 0 {
		config.MaxDelay = 5 * time.Second // Standard-Maximalverzögerung
	}
	if config.ShouldRetry == nil {
		config.ShouldRetry = func(resp *http.Response, err error) bool {
			if err != nil {
				return true // Netzwerkfehler sind normalerweise wiederholbar
			}
			// Statuscodes, die serverseitige Probleme anzeigen (z. B. 5xx)
			return resp.StatusCode >= 500
		}
	}
	return &RetryClient{
		delegate: delegate,
		config:   config,
	}
}

func (c *RetryClient) Do(req *http.Request) (*http.Response, error) {
	var (
		resp  *http.Response
		err   error
		delay = c.config.InitialDelay
	)

	for i := 0; i < c.config.MaxRetries; i++ {
		// Wichtig: Bei Anfragen mit Body müssen wir den Body-Reader
		// für jeden Wiederholungsversuch zurücksetzen, da der ursprüngliche Reader nach dem ersten Versuch verbraucht wird.
		if req.Body != nil {
			// Prüfen, ob der Body zurückgesetzt werden kann (z. B. *http.NoBody, bytes.Buffer oder ein benutzerdefiniertes io.Seeker)
			if seeker, ok := req.Body.(io.Seeker); ok {
				_, seekErr := seeker.Seek(0, io.SeekStart)
				if seekErr != nil {
					return nil, fmt.Errorf("failed to seek request body: %w", seekErr)
				}
			} else {
				// Wenn nicht seekbar, lesen Sie den Body in den Speicher und erstellen Sie einen neuen NopCloser.
				// Dies ist im Allgemeinen für große Payloads nicht ideal. Erwägen Sie die Verwendung von `bytes.Buffer`
				// oder `io.ReaderAt` für den ursprünglichen Body, wenn Wiederholungsversuche erwartet werden.
				bodyBytes, readErr := ioutil.ReadAll(req.Body)
				if readErr != nil {
					return nil, fmt.Errorf("failed to read request body for retry: %w", readErr)
				}
				req.Body = ioutil.NopCloser(bytes.NewReader(bodyBytes))
			}
		}

		resp, err = c.delegate.Do(req)

		if c.config.ShouldRetry(resp, err) {
			log.Printf("Request failed (attempt %d/%d), retrying in %v. Error: %v", i+1, c.config.MaxRetries, delay, err)
			time.Sleep(delay)
			delay = time.Duration(float64(delay) * 2) // Exponentielle Backoff
			if delay > c.config.MaxDelay {
				delay = c.config.MaxDelay
			}
			continue
		}
		return resp, err // Erfolg oder nicht wiederholbarer Fehler
	}

	return resp, err // Geben Sie die letzte Antwort/Fehler zurück, wenn alle Wiederholungsversuche fehlschlagen
}

Wichtige Überlegung für Anfragetextkörper: Bei der Wiederholung von Anfragen, die einen Body senden (z. B. POST, PUT), wird der req.Body (ein io.ReadCloser) nach dem ersten Do-Aufruf verbraucht. Bei nachfolgenden Wiederholungen wäre der Body leer, was zu falschen Anfragen führt. Der bereitgestellte Code versucht, dies zu handhaben, indem er den Body entweder zurücksucht, wenn er ein io.Seeker ist, oder indem er den gesamten Body in den Speicher liest, um einen neuen NopCloser zu erstellen. Für große Bodies kann das Lesen in den Speicher ineffizient sein. Daher ist es vorzuziehen, den ursprünglichen http.Request-Body so zu gestalten, dass er seekbar ist (z. B. mithilfe von bytes.Buffer).

Implementierung von Circuit Breaker

Für Circuit Breaker können wir auf eine ausgereifte Bibliothek wie sony/gobreaker zurückgreifen. Diese Bibliothek bietet eine robuste Implementierung des Circuit Breaker-Musters.

package resilientclient

import (
	"fmt"
	"net/http"
	"time"

	"github.com/sony/gobreaker"
)

// CircuitBreakerClient wrappt einen HTTPClient mit Circuit-Breaking-Logik
type CircuitBreakerClient struct {
	delegate HTTPClient
	breaker  *gobreaker.CircuitBreaker
}

// NewCircuitBreakerClient erstellt einen neuen Client mit Circuit-Breaker-Funktionen
func NewCircuitBreakerClient(delegate HTTPClient, settings gobreaker.Settings) *CircuitBreakerClient {
	if settings.Name == "" {
		settings.Name = "default-circuit-breaker"
	}
	if settings.Timeout == 0 {
		settings.Timeout = 60 * time.Second // Wie lange im 'offenen' Zustand warten, bevor 'halb offen' versucht wird
	}
	if settings.MaxRequests == 0 {
		settings.MaxRequests = 1 // Erlaubt 1 Anfrage im 'halb offenen' Zustand
	}
	if settings.Interval == 0 {
		settings.Interval = 5 * time.Second // Zeit bis zum Zurücksetzen der Zähler
	}
	if settings.ReadyToTrip == nil {
		settings.ReadyToTrip = func(counts gobreaker.Counts) bool {
			failureRatio := float64(counts.TotalFailures) / float64(counts.Requests)
			// Auslösen, wenn mindestens 3 Anfragen gestellt wurden und 60 % davon fehlgeschlagen sind
			return counts.Requests >= 3 && failureRatio >= 0.6
		}
	}

	return &CircuitBreakerClient{
		delegate: delegate,
		breaker:  gobreaker.NewCircuitBreaker(settings),
	}
}

func (c *CircuitBreakerClient) Do(req *http.Request) (*http.Response, error) {
	// Die Execute-Methode ruft die bereitgestellte Funktion auf, wenn der Breaker geschlossen oder halb offen ist.
	// Wenn der Breaker offen ist, gibt er sofort gobreaker.ErrOpenState zurück.
	result, err := c.breaker.Execute(func() (interface{}, error) {
		resp, err := c.delegate.Do(req)
		if err != nil {
			// Fehler vom Delegierten (wie Netzwerkfehler, Timeouts) sollten als Fehler gezählt werden
			return nil, err
		}
		// Für Circuit Breaker werden auch serverseitige Fehler (5xx) als Fehler betrachtet
		if resp.StatusCode >= 500 {
			// Wichtig: Um Ressourcenlecks zu vermeiden, lesen und schließen Sie den Body auch bei Fehlern
			// wenn Sie nur nil für die Schnittstelle zurückgeben.
			// Oder idealerweise geben Sie den *http.Response als interface{} zurück und lassen den Aufrufer
			// den Body behandeln, wenn er fehlschlägt, was sauberer ist.
			// Hier der Einfachheit halber kennzeichnen wir dies als Fehler.
			return resp, fmt.Errorf("server error: %d", resp.StatusCode)
		}
		return resp, nil
	})

	if err != nil {
		if err == gobreaker.ErrOpenState {
			return nil, fmt.Errorf("%w", err)
		}
		// Wenn es sich um einen Serverfehler oder einen Netzwerkfehler handelt, geben wir den ursprünglichen Fehler zurück.
		// Wenn der Fehler ein formatierter Serverfehler war, können wir die Antwort extrahieren,
		// wenn wir sie als Schnittstelle zurückgegeben haben.
		if resp, ok := result.(*http.Response); ok && resp != nil {
			return resp, err // Geben Sie die Antwort zurück, die vor der Circuit-Breaker-Betrachtung empfangen wurde
		}
		return nil, err
	}

	return result.(*http.Response), nil
}

Die gobreaker-Bibliothek kümmert sich automatisch um die Zustandsübergänge (geschlossen, offen, halb offen) und die Fehlerzählung. Wir konfigurieren sie mit gobreaker.Settings, um Schwellenwerte für das Auslösen und die Wiederherstellung zu definieren. Die Execute-Methode nimmt eine Funktion entgegen, die die eigentliche Operation ausführt und interface{}, error zurückgibt. Die gobreaker-Bibliothek verwendet den zurückgegebenen Fehler, um zu bestimmen, ob die Operation fehlgeschlagen ist.

Verkettung

Die Schönheit dieses Dekorator-Musters liegt darin, dass wir diese Clients verkettet können. Ein typisches Setup wäre: CircuitBreakerClient, der RetryClient wrappt, der DefaultClient wrappt. Dies stellt sicher, dass:

1. Noch bevor ein Versuch unternommen wird, prüft der Circuit Breaker, ob der entfernte Dienst wahrscheinlich ausgefallen ist.
2. Wenn der Stromkreis geschlossen (oder halb offen) ist, wird die Anfrage an die Wiederholungslogik weitergeleitet.
3. Die Wiederholungslogik kümmert sich mit Backoff um vorübergehende Fehler.
4. Der zugrunde liegende defaultClient führt die eigentliche HTTP-Anfrage mit seinem Basissignal aus.

package main

import (
	"fmt"
	"io"
	"log"
	"net/http"
	"time"

	"github.com/sony/gobreaker"
	"your_module_path/resilientclient" // Angenommen, resilientclient ist in einem Unterpaket enthalten
)

func main() {
	// 1. Erstellen Sie den Basiskunden mit einem Standard-Timeout
	baseClient := resilientclient.NewDefaultClient(5 * time.Second)

	// 2. MitRetry-Logik wrappen
	retryConfig := resilientclient.RetryConfig{
		MaxRetries:   5,
		InitialDelay: 200 * time.Millisecond,
		MaxDelay:     10 * time.Second,
		ShouldRetry: func(resp *http.Response, err error) bool {
			if err != nil {
				return true // Bei Netzwerkfehlern wiederholen
			}
			// Nur bei bestimmten Serverfehlern oder zu vielen Anfragen wiederholen
			return resp.StatusCode == http.StatusTooManyRequests || resp.StatusCode >= http.StatusInternalServerError
		}}
	retryClient := resilientclient.NewRetryClient(baseClient, retryConfig)

	// 3. Mit Circuit Breaker wrappen
	cbSettings := gobreaker.Settings{
		Name:        "ExternalService",
		MaxRequests: 3,                 // Erlaubt 3 Anfragen im Halb-offenen Zustand
		Interval:    5 * time.Second,   // Zähler alle 5 Sekunden zurücksetzen
		Timeout:     30 * time.Second,  // 30 Sekunden offen, bevor ein Halb-offener Versuch unternommen wird
		ReadyToTrip: func(counts gobreaker.Counts) bool {
			failureRatio := float64(counts.TotalFailures) / float64(counts.Requests)
			return counts.Requests >= 10 && failureRatio >= 0.3 // Auslösen, wenn 30 % von 10 Anfragen fehlschlagen
		},
	}
	resilientHttClient := resilientclient.NewCircuitBreakerClient(retryClient, cbSettings)

	// Beispielnutzung
	for i := 0; i < 20; i++ {
		req, err := http.NewRequest("GET", "http://localhost:8080/api/data", nil)
		if err != nil {
			log.Fatalf("Error creating request: %v", err)
		}

		log.Printf("Making request %d...", i+1)
		resp, err := resilientHttClient.Do(req)
		if err != nil {
			log.Printf("Request %d ERROR: %v", i+1, err)
			time.Sleep(500 * time.Millisecond) // Simulation von Verzögerungen zwischen Anrufen
			continue
		}

		defer resp.Body.Close()
		body, _ := io.ReadAll(resp.Body)
		log.Printf("Request %d SUCCESS: Status %d, Body: %s", i+1, resp.StatusCode, string(body))
		time.Sleep(500 * time.Millisecond)
	}
}

Diese main-Funktion demonstriert, wie unser resilientHttClient erstellt und verwendet wird. Sie würden http://localhost:8080/api/data normalerweise durch Ihre tatsächliche Service-Endpunktadresse ersetzen.

Anwendungsfälle

Dieses Muster ist unschätzbar wertvoll für:

• Microservices-Kommunikation: Sicherstellen, dass Service-zu-Service-Aufrufe trotz Netzwerkproblemen oder vorübergehender Überlastung von Abhängigkeiten stabil bleiben.
• Integrationen mit externen APIs: Zuverlässiger Konsum von APIs von Drittanbietern, die möglicherweise Ratenlimits unterliegen oder gelegentlich instabil sind.
• Datenbankinteraktionen (indirekt): Obwohl http.Client nicht für direkte Datenbankinteraktionen gedacht ist, schützten diese Muster bei Diensten, die eine HTTP-API bereitstellen, die eine Datenbank kapselt, vor datenbankbezogenen Dienstfehlern.

Fazit

Indem wir Go's http.Client programmgesteuert mit Retry-, Timeout- und Circuit Breaker-Logik wrappen, haben wir einen grundlegenden HTTP-Client in eine produktionsreife, fehlertolerante Komponente verwandelt. Dieser geschichtete Ansatz, der das Dekorator-Muster verwendet, trennt die Belange und macht unseren Code wartbarer und robuster. Die Implementierung dieser Muster dient nicht nur der Fehlerbehandlung; es geht darum, ausfallsichere Systeme zu erstellen, die sich anmutig verschlechtern und erholen, um einen kontinuierlichen Betrieb auch in herausfordernden verteilten Umgebungen zu gewährleisten. Robustheit ist nicht optional; sie ist grundlegend für zuverlässige verteilte Systeme.