Direkte Kompatibilität

Was ist direkte Kompatibilität

Direkte Kompatibilität (forward compatibility) ist die Fähigkeit eines Systems, mit neueren Clients oder Daten korrekt zu arbeiten als die, für die es ursprünglich konzipiert wurde. Einfacher: Der alte Server bricht nicht zusammen, wenn ein neuer Client zu ihm kommt; Der alte Verbraucher fällt nicht, wenn er auf eine neue Nachricht trifft.

Von der Abwärtskompatibilität (wenn das neue System alte Kunden unterstützt) unterscheidet sich forward in der Richtung der Verantwortung: Wir entwerfen Protokolle und Clients, um zukünftige Erweiterungen zu „überleben“, ohne das gesamte Ökosystem vollständig zu aktualisieren.

Grundlagen

1. Tolerant reader & tolerant writer

Der Reader ignoriert unbekannte Felder/Header und erlaubt neue Enum-Werte mit korrektem Fallback.
Der Writer sendet nichts, was der Server nicht explizit als unterstützt deklariert hat (capabilities).

2. Capability negotiation

Expliziter Austausch von Möglichkeiten (Fiches/Versionen/Medientypen) in der Handshake-Phase. Der Client passt sein Verhalten an die Antwort des Servers an.

3. Default Degradation

Neue Funktionen gelten als optional: Wenn der Server/Consumer sie nicht unterstützt, wird das Skript immer noch mit einem nützlichen Minimum (MGC) abgeschlossen.

4. Stabiler Kern (MGC)

Der Mindestgarantievertrag bleibt unverändert; Innovationen leben als Erweiterungen.

5. Fehlerverträge als Teil des Protokolls

Vorhersehbare Codes/Ursachen („ficha nicht unterstützt“, „Medientyp unbekannt“) ermöglichen dem Client ein automatisches Zurücksetzen auf den unterstützten Modus.

6. Versionen ohne Überraschungen

Die Hauptlinien sind getrennt; Kleinere Erweiterungen erfordern kein Server/Consumer-Upgrade.

Wo es besonders wichtig ist

Öffentliche APIs mit langlebigen Integrationen (Partner, SDKs in mobilen Anwendungen).
Event-Plattformen mit vielen unabhängigen Konsumenten.
Mobile Clients, die langsamer aktualisiert werden als das Backend.
Edge/IoT, wo ein Teil der Geräteflotte selten geflasht wird.

Implementierungsmuster nach Stil

REST/HTTP

• 'Accept '/Mediatypen mit Parametern (' application/vnd. example. order+json; v=1; profile=risk`).
• 'Prefer: include =...' für optionale Blöcke.
• Titel 'X-Capabilities: risk_score,item_details_v2'.

• Sendet eine Anfrage im Basisformat, Erweiterungen nur, wenn der Server die Kapazität bestätigt hat (über OPTIONS/desc/lead endpoint).
• Bei '415/406/501' wird automatisch auf das unterstützte Format/Methode zurückgesetzt.
• Antwort des Servers: unbekannte Parameter - ignorieren; zusätzliche Felder - erlaubt; Fehlerformat stabil ('type/code/detail/trace _ id').

gRPC / Protobuf

Stabile Dienste: neue Methoden/Felder - additiv; der alte Server ignoriert leise unbekannte Abfragefelder.
Feature discovery: Die Methode' GetCapabilities () 'gibt eine Liste von Daten/Limits zurück. Der Client ruft die „v2-Methode“ nicht auf, wenn der Server sie nicht deklariert hat.
Streaming: Legen Sie die Reihenfolge der Mindestanzahl von Nachrichten fest; neue „Frames“ mit Erweiterungen/Typen markieren, die der alte Client ignoriert.

GraphQL

Forward-friendly: Neue Felder/Typen erscheinen auf dem Server - alte Clients fragen sie einfach nicht ab.
Vermutungen sind verboten: Der Kunde muss das Schema (Introspektion/Kodogen) beibehalten und darf keine unbekannten Direktiven/Variablen senden.
Degradierung: Wenn der Server die benutzerdefinierte Direktive/Funktion nicht kennt - der Client erstellt die Abfrage ohne sie.

Event-driven (Kafka/NATS/Pulsar, Avro/JSON/Proto)

FORWARD-Kompatibilität des Schemas in der Registrierung: Alte Consumer können Nachrichten lesen, die vom neuen Schema geschrieben wurden.
Additive Felder mit Defaults: Neue Produzenten brechen alte Konsumenten nicht.
Core vs Enriched: Der Kernel bleibt gleich, neue Informationen werden in '.enriched' oder als optionale Felder veröffentlicht.

Entwurfspraktiken

1. Mindestanforderungsvertrag (MGC)

Der Betrieb sollte einen „schmalen Hals“ haben, der von allen Servern für viele Jahre unterstützt wird.

2. Ficha-Flaggen auf Vertragsebene

Beschreiben Sie die Fiches als benannte Fähigkeiten: 'risk _ score', 'pricing _ v2', 'strong _ idempotency'. Der Kunde schließt sie explizit ein.

3. Explizite Fehlercodes für „nicht unterstützt“

HTTP: `501 Not Implemented`, `415 Unsupported Media Type`, детальные `problem+json`.
gRPC: `UNIMPLEMENTED`/`FAILED_PRECONDITION`.
Events: Route im DLQ mit 'reason = unsupported _ feature'.

4. Verlassen Sie sich nicht auf die Reihenfolge/vollständige Listen

Der Kunde muss auf neue enum-Werte, keine neuen Felder und auf „zusätzliche“ Eigenschaften vorbereitet sein.

5. Stabile IDs und Formate

Ändern Sie nicht das Format der ID/Schlüssel Partitionierung innerhalb der Linie - es bricht vorwärts auf der Seite der Leser.

6. Dokumentation „maschinenlesbar“

Hosting-Deskriptoren: OpenAPI/AsyncAPI/Proto descriptors/GraphQL SDL. Kunden können die Unterstützung von fitch überprüfen.

Testen der Forward-Kompatibilität

Schema-diff im FORWARD/FULL-Modus: Das neue Schema validiert den alten Verbraucher/Server.
Client Contract Tests: Der neue Client wird gegen den alten Server mit On/Off-Fichs ausgeführt.
Golden requests: Eine Reihe von „neuen“ Anfragen wird über den „alten“ Server geleitet; Degradation ohne kritische Fehler erwartet.
Chaos/Latenz: Überprüfung von Timeouts/Retrays - der neue Client muss die schlimmsten SLAs des alten Servers korrekt überstehen.
Canary: Einige der neuen Clients arbeiten mit der vorherigen Serverversion - wir sammeln Telemetrie von Fehlern/Degradationen.

Beobachtbarkeit und Betriebskennzahlen

Anteil der Anfragen/Nachrichten mit nicht unterstützten Fics und deren automatischen Rollbacks.
Verteilung nach Client-Versionen (User-Agent/Metadaten/Claims).
Fehler 'UNIMPLEMENTED/501/415' und Routen im DLQ mit 'unsupported _ feature'.
Degradationszeit: p95/p99 für MGC vs. „erweiterte“ Antwort.

Kompatibilitätsmodi in der Schemaregistrierung

VORWÄRTS: Der neue Eintrag ist mit dem alten Leser kompatibel (Standardwerte erforderlich, optional).
FULL: и FORWARD, и BACKWARD; Bequem für öffentliche Aufträge.
Empfehlung: für Events - BACKWARD beim Produzenten und FORWARD beim Consumer (über toleranten Reader), für externe APIs - FULL.

Beispiele

REST (Kapazitäten + Degradation)

1. Der Client macht „GET/meta/capabilities“ → „{“ risk_score": false, „price_v2": true}“.
2. Auf 'POST/orders' sendet die Basisfelder; 'risk _ score' fragt nicht ab, weil der Server es nicht kann.
3. Wenn Sie versehentlich 'Prefer: include = risk _ score' gesendet haben, antwortet der Server 200 ohne das Feld 'risk _ score' (oder 'Preference-Applied: none') - der Client stürzt nicht ab.

gRPC (discovery)

'GetCapabilities ()' gab eine Liste von Methoden/Daten zurück. Der Client ruft 'CaptureV2' nicht auf, wenn er nicht vorhanden ist - stattdessen verwendet er 'Capture' und konvertiert die Eingabe lokal in eine unterstützte Ansicht.

Ereignisse (VORWÄRTS im Register)

Der Produzent hat das Feld 'risk _ score' (nullbar mit default) hinzugefügt. Der alte Consumer ignoriert es; seine Logik verwendet nur stabile Kernelfelder.

Anti-Pattern

Harter Client: Filtert die Antwort nach Whitelist-Feldern und fällt auf eine unbekannte Eigenschaft.
Implizite Zeichen: Der Client beginnt, einen neuen Parameter zu senden, ohne die Fähigkeiten zu überprüfen.
Änderung der ID/Schlüsselformate innerhalb der Leitung → Alte Server/Consumer verstehen neue Anfragen/Nachrichten nicht mehr.
Genähte Annahmen über die vollständige enum-Liste (Schalter ohne default).
Logging als Flow Control: Parsen von Fehlerzeilen statt Vertragscodes.

Checkliste für die Implementierung

• MGC definiert; Neue Funktionen sind als optional gekennzeichnet.
• Capability Negotiation (Endpoint/Metadaten/Handshake) beschrieben und implementiert.
• Kunden ignorieren ungewohnte Felder und verarbeiten neue enum (Fallback) korrekt.
• Fehlerverträge fixieren „nicht unterstützt“ vorhersehbar (HTTP/gRPC/Event).
• Die Scheme Registry ist für die entsprechenden Artefakte auf FORWARD/FULL eingestellt.
• Autotests: schema-diff (FORWARD), Vertragstests des Clients gegen den alten Server, canary.
• Metriken: Client-Version, Fich-Fehler, Anteil der Degradationen, p95 MGC.
• Dokumentation/SDKs veröffentlichen eine Liste von Themen und Beispielen für Degradation.

FAQ

Wie unterscheidet sich forward in der Praxis von backward?
Backward: Der neue Server bricht die alten Clients nicht. Vorwärts: Der alte Server bricht nicht mit neuen Clients (oder der alte Consumer mit neuen Nachrichten). Im Idealfall erreichen Sie voll.

Muss ich immer capabilities eingeben?
Wenn Sie eine aktive Evolution ohne synchrone Releases erwarten, ja. Es ist billiger als Dutzende von großen Linien zu halten.

Was ist mit der Sicherheit?
Neue Fiches sollten separate Scopes/Claims erfordern. Wenn der Server sie nicht unterstützt, sollte der Client die Sicherheit nicht reduzieren, sondern auf das Feature verzichten.

Kann ich die Unterstützung durch die Serverversion „erraten“?
Unerwünscht. Es ist besser, explizit zu fragen (Kapazitäten) oder einen Mediatyp/Schema zu betrachten.

Summe

Direkte Kompatibilität ist die Disziplin, Möglichkeiten auszuhandeln und sicher zu degradieren. Stabiler Kern, Capability Negotiation, additive Erweiterungen und vorhersehbare Fehler ermöglichen es neuen Clients und Daten, mit alten Servern und Verbrauchern auszukommen - ohne Massenveröffentlichungen und nächtliche Migrationen.