Οπίσθια συμβατότητα

Τι είναι συμβατότητα προς τα πίσω

Οπισθοδρομική συμβατότητα - ιδιοκτησία του συστήματος για την αποδοχή και ορθή επεξεργασία παλαιών πελατών/καταναλωτών κατά την επικαιροποίηση του συστήματος. Απλούστερη: κυκλοφορείτε μια νέα έκδοση της υπηρεσίας/των γεγονότων, και οι υφιστάμενες ενοποιήσεις συνεχίζουν να λειτουργούν αμετάβλητα.

Το κλειδί: μην παραβαίνετε τις συμφωνίες. Οποιαδήποτε εξέλιξη γίνεται με την προσθήκη, όχι με την ανακατασκευή, ενός ήδη κυκλοφορούντος.

Βασικές αρχές

1. Πρώτη πρόσθετη ύλη

Προστίθενται προαιρετικά νέα πεδία/μέθοδοι/εκδηλώσεις. Τίποτα δεν έχει αφαιρεθεί και δεν αλλάζει το νόημα.

2. Σύμβαση ελάχιστης εγγύησης (MGC)

Ορισμός ενός πυρήνα - ένα σύνολο πεδίων/λειτουργιών χωρίς τα οποία το σενάριο χάνει τη σημασία του. Ο πυρήνας είναι σταθερός. Όλα τα άλλα είναι επεκτάσεις.

3. Ανεκτικός αναγνώστης

Οι πελάτες αγνοούν άγνωστα πεδία και χειρίζονται σωστά νέες τιμές enum (εφεδρικό).

4. Πολιτική εκδόσεων

Αλλαγές ρήξης - μόνο μέσω της κύριας γραμμής ('/v2 ',' πληρωμές. v2 ',' event. v2 '). Ελάσσονος σημασίας - πρόσθετη ύλη.

5. Παρατηρησιμότητα - μέρος της σύμβασης

Η έκδοση πελάτη, η μορφή, οι σημαίες ικανοτήτων είναι ορατές σε αρχεία καταγραφής/κομμάτια και μετρήσεις. Αυτό σας επιτρέπει να διαχειριστείτε τη μετανάστευσή σας.

Ασφαλείς έναντι επικίνδυνων αλλαγών

Γενικά ασφαλής (BC-OK)

Προσθήκη προαιρετικών πεδίων (JSON/Avro/Protobuf 'προαιρετικά '/' ακυρώσιμα').
Προσθήκη νέων τελικών σημείων/μεθόδων/συμβάντων.
Επέκταση Enum με πρόσθετες τιμές (με ανεκτικό αναγνώστη).
Αποδυνάμωση της επικύρωσης (μεγιστοποίηση, προσθήκη εναλλακτικών μορφών).
Προσθήκη μη σημαντικών κεφαλίδων/μεταδεδομένων.

Επικίνδυνο (Σπάσιμο)

Διαγραφή/μετονομασία πεδίων, αλλαγή του τύπου ή υποχρεωτικό των υφιστάμενων πεδίων.
Αλλαγή σημασιολογίας κώδικα κατάστασης/σφάλματος.
Επαναχρησιμοποίηση ετικετών protobuf για άλλα πεδία.
Αλλαγή κλειδιού κατάτμησης γεγονότων (διακόπτει τη σειρά για το σύνολο).
Ενίσχυση των SLA/timeouts, προκαλώντας την έναρξη πτώσης των παλαιών πελατών.

Κατά στυλ αλληλεπίδρασης

REST/HTTP + JSON

Προσθετικότητα: νέα πεδία - «προαιρετικά», ο εξυπηρετητής δεν τα απαιτεί από παλαιούς πελάτες.
Εκδόσεις: μείζονος σημασίας - υπό διαμετακόμιση ('/v2 ') ή τύπου πολυμέσων. ελάσσονος σημασίας - μέσω επεκτάσεων και '? συμπεριλαμβάνονται = '/' πεδία = '.
Σφάλματα: ομοιόμορφος μορφότυπος. δεν αλλάζουν κωδικούς/σημασιολογία χωρίς μείζονα σημασία.
ETag/If-Match: για ασφαλείς επικαιροποιήσεις χωρίς αγώνες.
Idempotency: 'Idempotency-Key' για την POST - οι παλιοί πελάτες δεν «διπλασιάζουν» την επίδραση στις υποχωρήσεις.

gRPC/Protobuf

Οι ετικέτες είναι αμετάβλητες. Οι διαγραμμένες ετικέτες δεν μπορούν να επαναχρησιμοποιηθούν.
Νέα πεδία - «προαιρετικά »/« επαναλαμβανόμενα». οι προκαθορισμένες τιμές αντιμετωπίζονται σωστά με παλαιό κώδικα.
Ροή: Μη αλλάξετε την εντολή/υποχρέωση των μηνυμάτων εντός ελάσσονος σημασίας.
Σφάλματα - ένα σταθερό σύνολο καταστάσεων. νέα σημασιολογία → νέα μέθοδος/υπηρεσία ('.v2').

Kafka/NATS/Pulsar) + Avro/JSON/Proto

Ονομασία: 'domain. δράση. v {major} '.
Core vs Εμπλουτισμένος: βασικός σταθερός· εμπλουτισμός - μεμονωμένοι τύποι/θέματα («.εμπλουτισμένος»).
Λειτουργία συμβατότητας σχήματος: πιο συχνά BACKWARD. Ο ΚΚΠ εμποδίζει ασύμβατες αλλαγές.
Κατάτμηση: κλειδί (για παράδειγμα, «πληρωμή _ id») - μέρος της σύμβασης· αλλάξτε το - σπάσιμο.

GraphQL

Προσθήκη πεδίων/τύπων - OK; διαγραφή/μετονομασία - μέσω του '@ detrected' και του παραθύρου μετάβασης.
Μην εγείρετε «εκμηδενίσιμα → μη εκμηδενιζόμενα» χωρίς μείζονα ανάγκη.
Παρακολούθηση της πολυπλοκότητας/βάθους - οριακή αλλαγή = αλλαγή σύμβασης.

Πρότυπα που βοηθούν στη διατήρηση του BC

Αντίστροφο μοντέλο πυραμίδας: σταθεροποίηση του πυρήνα, επέκταση προαιρετικά.
Διαπραγμάτευση δυνατοτήτων: ο πελάτης αναφέρει υποστηριζόμενες δυνατότητες ('X-Capabilities '/χειραψία), ο εξυπηρετητής προσαρμόζεται.
Διπλή/διπλή εκπομπή: Διατήρηση του 'v1' και του 'v2' ταυτόχρονα κατά τη διάρκεια της μετάβασης.
Προσαρμογείς: πληρεξούσιοι/πύλες μεταφράζουν «v1↔v2» αιτήματα για «βαρείς» πελάτες.
Επέκταση και σύμβαση (για DB): πρώτα προσθέστε ένα νέο, αρχίστε να γράφετε/διαβάζετε, μόνο μετά διαγράψτε το παλιό.

Διακυβέρνηση και διαδικασία

1. Κατάλογος συμβάσεων (Schema Registry): Μια ενιαία πηγή αλήθειας με πολιτικές συμβατότητας.
2. Έλεγχοι linters και diff σε CI/CD: OpenAPI-diff, Buf-breaking, Avro/JSON Schema έλεγχος συμβατότητας.
3. Συμβάσεις CDC/Συμβάσεις με γνώμονα τον καταναλωτή: Ο πάροχος ελέγχεται για πραγματικές καταναλωτικές συμβάσεις.
4. Χρυσά δείγματα: ερωτήματα αναφοράς/απαντήσεις/γεγονότα για παλινδρόμηση.
5. Διαχείριση αλλαγών: RFC/ADR για τη διακοπή λειτουργίας, σχέδια λήξης ισχύος, επικοινωνία.

Αποεπεξεργασία και αφαίρεση παλαιών εκδόσεων

Μαρκ παρωχημένο ('@ deprected', περιγραφές, κεφαλίδες 'Deprecation', 'Sunset').
Παράθυρο μετάβασης: προαναγγελθείσα ημερομηνία, πάγκος δοκιμών, παραδείγματα κωδικών.
Τηλεμετρία χρήσης: Ποιος άλλος είναι στο 'v1' μετρήσεις τμήματος/καταγραφές ανά έκδοση.
Διπλή κίνηση στο μηδέν και μετά διαγραφή.

Παρατηρησιμότητα και λειτουργικές μετρήσεις

Ποσοστό αιτήσεων/μηνυμάτων ανά έκδοση.
Μερίδιο σφαλμάτων/χρονοδιαγραμμάτων για ηλικιωμένους πελάτες μετά την έκδοση.
Το ποσοστό του ασύμβατου ωφέλιμου φορτίου (επικύρωση από το σύστημα στα φίλτρα πύλης/ροής).
Υστέρηση στη μετανάστευση των καταναλωτών (πόσοι ακόμα ακούνε το «v1»).

Δοκιμή συμβατότητας προς τα πίσω

Σχήμα-diff: αποτυχία αφαίρεσης/μετονομασίας/αλλαγής τύπου.
Δοκιμές συμβάσεων: Παλαιά SDK/πελάτες αγωνίζονται ενάντια σε νέα εφαρμογή.
καναρίνι: μέρος της παλιάς κυκλοφορίας με τη νέα έκδοση, σύγκριση p95/p99, κωδικοί, retrays.
Επανάληψη γεγονότων: Οι προβολές συλλέγονται με νέα λογική από το παλιό ημερολόγιο χωρίς ασυμφωνίες.
Σφάλμα: καθυστερήσεις/μερικές απαντήσεις - οι παλαιοί πελάτες δεν πέφτουν.

Παραδείγματα

REST (πρόσθετο)

Ήταν:

json
{ "id": "p1", "status": "authorized" }

Έγινε:

json
{ "id": "p1", "status": "authorized", "risk_score": 0. 12 }

Οι παλιοί πελάτες, αγνοώντας το 'risk _ score', συνεχίζουν να δουλεύουν.

Protobuf (ετικέτες)

proto message Payment {
string id = 1;
string status = 2;
optional double risk_score = 3 ;//new field, safe
}
//Tags 1 and 2 cannot be changed/deleted without v2

Συμβάντα (πυρήνας + εμπλουτισμός)

"πληρωμή. έχει εγκριθεί. v1 '- πυρήνας (ελάχιστα γεγονότα).
"πληρωμή. εμπλουτισμένος. v1 '- μέρη, Οι βασικοί καταναλωτές δεν εξαρτώνται από τον εμπλουτισμό.

Αντιπατερίδια

Swagger-wash: το σύστημα έχει ενημερωθεί, αλλά η υπηρεσία συμπεριφέρεται με τον παλιό τρόπο (ή αντιστρόφως).
Κρυμμένα διαλείμματα: αλλαγή της έννοιας του πεδίου/κατάστασης χωρίς έκδοση.
Επαναχρησιμοποίηση ετικετών protobuf: «αθόρυβη» διαφθορά δεδομένων.
Οι σκληροί πελάτες: πέφτουν σε άγνωστα πεδία/enum. δεν υπάρχει ανεκτικός αναγνώστης.
Mega-endpoint: Ένα all-in-one - οποιαδήποτε αλλαγή γίνεται ένα πιθανό παλιοσίδερο.

Κατάλογος ελέγχου πριν από την απελευθέρωση

Οι αλλαγές είναι πρόσθετες ύλες. ο πυρήνας (MGC) είναι ανέγγιχτος.
Έλεγχοι γραμμών/diff. δεν υπάρχουν σημαίες που να σπάνε.
Τα SDK πελατών έχουν επικαιροποιηθεί (ή δεν απαιτούνται για την επέκταση της πρόσθετης ύλης).
Ενεργοποιημένος ανεκτικός αναγνώστης για τους πελάτες. έλεγχος της εφεδρικής εφεδρείας.
Οι μετρήσεις/καταγραφές περιέχουν σημαίες έκδοσης και ικανοτήτων.
Για πιθανή διακοπή υπάρχει '/v2 ', σχέδιο διπλής λειτουργίας και ηλιοβασίλεμα.
Η τεκμηρίωση/τα παραδείγματα έχουν επικαιροποιηθεί, υπάρχουν χρυσά σύνολα.

ΣΥΧΝΈΣ ΕΡΩΤΉΣΕΙΣ

Προς τα εμπρός - ποια είναι η διαφορά

Οπισθοδρόμηση - νέοι διακομιστές εργάζονται με παλιούς πελάτες. Προς τα εμπρός - οι νέοι πελάτες εργάζονται σωστά με παλαιούς διακομιστές (λόγω ανεκτικών αναγνωστών και τακτοποιημένων προεπιλογών). Πλήρης κύκλος - πλήρης συμβατότητα.

Χρειάζεται πάντα να κάνω το '/v2 'για μεγάλες αλλαγές

Ναι, αν οι αναλλοίωτοι/τύποι/κλειδιά/σημασιολογία σπάσουν. Διαφορετικά, κρατήστε τη γραμμή και εξελιχθείτε προσθετικά.

Τι γίνεται με το enum

Προσθήκη νέων τιμών χωρίς αλλαγή της έννοιας των παλαιών. Οι πελάτες πρέπει να έχουν οπισθοδρόμηση σε άγνωστη αξία.

Τι γίνεται αν έχετε ήδη «σπάσει»

Rollback, hot-fix προσαρμογέας, 'v2' απελευθέρωση με οδηγό διπλής λειτουργίας, επικοινωνίας και μετανάστευσης.

Σύνολο

Οπισθοδρομική συμβατότητα είναι η πειθαρχία της εξέλιξης: σταθεροποίηση του πυρήνα, επέκταση προσθετικά, εφαρμογή ενός ανεκτικού αναγνώστη, αυτόματους ελέγχους και διατήρηση μιας συνειδητής υποτίμησης. Με αυτόν τον τρόπο μπορείτε να αναπτύξετε γρήγορα την πλατφόρμα χωρίς να αφήνετε τους πελάτες κάτω από τα ερείπια των «αόρατων» αλλαγών.