תאימות לאחור

מהי תאימות לאחור

תאימות לאחור - תכונה של המערכת לקבל ולעבד נכון לקוחות/צרכנים ישנים כאשר המערכת מתעדכנת. פשוט יותר: אתם משחררים גרסה חדשה של השירות/אירועים, והאינטגרציה הקיימת ממשיכה לעבוד ללא שינוי.

המפתח: לא להפר הסכמים. כל אבולוציה היא באמצעות הוספת, לא חידוש, אחד שכבר שוחרר.

עקרונות בסיסיים

1. תוסף-ראשון

שדות/שיטות/אירועים חדשים מתווספים באופן אופטי. שום דבר קיים לא הוסר ולא משנה את המשמעות.

2. חוזה אחריות מינימלי (MGC)

הגדר גרעין - קבוצה של שדות/פעולות שבלעדיהם התסריט מאבד את משמעותו. הליבה יציבה. כל השאר הוא הארכות.

3. קורא סובלני

לקוחות מתעלמים משדות לא ידועים ומטפלים נכון בערכי שינון חדשים.

4. מדיניות גרסאות

שבירת שינויים - רק דרך הקו העיקרי ('/v2 ',' תשלומים. אירוע v2 ','. v2 '. מינורי - תוסף.

5. יכולת תצפית - חלק מהחוזה

גרסת הלקוח, הפורמט, דגלי היכולת נראים ברישומים/רצועות ומדדים. זה מאפשר לך לנהל את הנדידה שלך.

בטוח נגד שינויים מסוכנים

בדרך כלל בטוח (BC-OK)

הוספת שדות אופציונליים (JSON/Avro/Protobuf 'optional '/' nullable').
הוסף נקודות סוף/שיטות/אירועים חדשים.
סיומת אנום עם ערכים נוספים (עם קורא סובלני).
החלשה של אימות (מקסימיזציה, תוספת של פורמטים אלטרנטיביים).
הוסף כותרות לא משמעותיות/metadata.

מסוכן (שבירה)

מחיקת/שינוי שם שדות, שינוי סוג או חובה של שדות קיימים.
שינוי סמנטיקה קוד מצב/שגיאה.
השתמש מחדש בתגי פרוטובוף עבור שדות אחרים.
שינוי מפתח החלוקה של האירוע (מפר את סדר הצבירה).
הידוק סלאס/פסק זמן, גורם ללקוחות ישנים להתחיל ליפול.

על ידי סגנונות אינטראקציה

REST/HTTP + JSON

תוספות: שדות חדשים - 'אופציונלי', השרת לא דורש אותם מלקוחות ישנים.
גרסאות: מז 'ור - במעבר ('/v2') או סוג מדיה; מינורי - דרך תוספות ו '? כולל = '/'? שדות = ".
שגיאות: תבנית אחידה; לא מחליפים קודים/סמנטיקה ללא מז 'ור.
עבור עדכונים בטוחים ללא מירוצים.
אידמפוטנטיות: ”Idempotency-Key” ללקוחות פוסט-ישן לא ”להכפיל” את ההשפעה על נסיגות.

gRPC/Protobuf

התגים לא השתנו. אין אפשרות להשתמש מחדש בתוויות שנמחקו.
שדות חדשים - ”אופציונלי ”/” חוזר”; ערכי ברירת המחדל מטופלים נכון על ידי קוד ישן.
הזרמה: אל תשנה את הסדר/חובה של הודעות בתוך מינורי.
שגיאות - קבוצה יציבה של סטטוסים; סמנטיקה חדשה * שיטה/שירות חדש ('.v2').

מונע אירועים (קפקא/NATS/Pulsar) + Avro/JSON/Proto

שמות: "תחום. פעולה. וי מייג 'ור.
ליבה נגד מועשר: ליבה יציבה; העשרה - סוגים/נושאים בודדים (”enriched”).
מצב תאימות סכימה: לעתים קרובות יותר אחורה; בלוקים שינויים בלתי מתאימים.
מחיצה: מפתח (לדוגמה, "תשלום _ id') - חלק מהחוזה; לשנות את זה - לשבור.

GraphQL

הוספת שדות/סוגים - אישור; מחק/שינוי - דרך '@ מפוקפק' וחלון הנדידה.
אל תרימו ”לא ניתן לבטלה” בלי מייג 'ור.
פקח על מורכבות/הגבלת עומק שינוי = שינוי בחוזה.

תבניות כדי לעזור לשמר את לפני הספירה

מודל הפירמידה הפוך: לייצב את הליבה, להתרחב אופטית.
משא ומתן על יכולת: הלקוח מדווח על יכולות נתמכות (”X-Capities ”/Handsake), השרת מתאים את עצמו.
ריצה כפולה/פליטה כפולה: שמור 'v1' ו 'v2' בעת ובעונה אחת במהלך נדידה.
מתאם: proxies/gateways לתרגם ”v1↔v2” בקשות ללקוחות ”כבדים”.
הרחיבו את החוזה (עבור DB): תחילה הוסיפו אחד חדש, התחילו לכתוב/לקרוא, רק לאחר מכן מחקו את הישן.

ממשל ותהליך

1. Catalog (Schema Registry): מקור יחיד של אמת עם מדיניות תאימות.
2. Linters and diff בודק ב CI/CD: OpenAPI-diff, BUF-breaking, Avro/JSON SchEMA תאימות.
3. CDC/צרכן מונע חוזים: ספק נבחן לחוזים צרכניים אמיתיים.
4. דוגמאות זהב: שאילתות התייחסות/תגובות/אירועים עבור רגרסיה.
5. שינוי ניהול: RFC/ADR על שבירה, תוכניות שקיעה, תקשורת.

הפחתה והסרה של גרסאות ישנות

סמן מיושן (”@ distrated”, תיאורים, כותרות ”Deprecation”, ”Sunset”).
חלון נדידה: תאריך שהוכרז מראש, ספסל בדיקה, דוגמאות קוד.
טלמטריה שימוש: מי עוד נמצא על 'v1'? מדדים/יומנים לפי גרסה.
ריצה כפולה לאפס תנועה, ואז למחוק.

תצפית ומדדים תפעוליים

אחוז הבקשות/הודעות לפי גרסה.
שיתוף שגיאות/פסקי זמן ללקוחות מבוגרים לאחר השחרור.
הפרופורציה של מטען בלתי תואם (אימות על ידי סכימה על מסנני השער/זרם).
עיכוב נדידת צרכנים (עוד כמה הקשיבו ל- ”v1”).

בדיקת תאימות לאחור

סכימה-diff: להיכשל ב-design/rename/type-change.
מבחני חוזה: SDKs/לקוחות ישנים מתחרים נגד יישום חדש.
E2E כנרית: חלק מהתנועה הישנה לגרסה החדשה, השוואה של p95/p99, קודים, מגשים מחדש.
שידור חוזר של האירוע: התחזיות נאספות על ידי היגיון חדש מהיומן הישן ללא סתירות.
הזרקת אשמה: עיכובים/תגובות חלקיות - לקוחות ישנים לא נופלים.

דוגמאות

REST (תוסף)

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

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

לקוחות ותיקים, מתעלמים מ-The 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 '- חלקים; צרכני הליבה אינם תלויים בהעשרה.

Antipatterns

סוואגר-שטף: התוכנית עודכנה, אך השירות מתנהג בדרך הישנה (או להפך).
הפסקות נסתרות: שינתה את משמעות השדה/סטטוס ללא גרסה.
שימוש חוזר בתוויות פרוטובוף: שחיתות נתונים ”שקטה”.
לקוחות קשים: ליפול בשדות לא מוכרים/enum; אין קורא סובלני.
מגה-נקודה: אחד-כל-אחד - כל שינוי הופך לגרוטאות פוטנציאליות.

טרום שחרור רשימה

[ שינויים ] הם תוספים; הגרעין (MGC) לא נגע.

[ ] המחאות לינטרס/דיף עברו; אין שבירת דגלים.

[ ] SDKs לקוח עודכנו (או לא נדרשים להארכת התוסף).

[ ] איפשר לקורא סובלני ללקוחות; אנום-גיבוי בדק.

[ ] מטריצות/יומנים מכילים גרסה ודגלי יכולת.

לשבירה פוטנציאלית יש '/v2 ', דו-ריצה ושקיעה תכנית.

[ ] תיעוד/דוגמאות עודכנו, ישנן סדרות זהב.

FAQ

אחורה נגד קדימה - מה ההבדל?
שרתים חדשים עובדים עם לקוחות ותיקים. לקוחות חדשים עובדים נכון עם שרתים ישנים (בזכות קורא סובלני ומחדל מסודר). מעגל מלא - תאימות מלאה.

האם אני תמיד צריך לעשות '/v2 'לשינויים גדולים?
כן, אם אינווריאנטים/סוגים/מפתחות/סמנטיקה לשבור. אחרת, לשמור על הקו ולהתפתח באופן תוסף.

מה בקשר לאנום?
הוסף ערכים חדשים מבלי לשנות את משמעות הישנים. לקוחות חייבים להיות נסוגים בשווי לא ידוע.

מה אם יש לך כבר ”שבור”?
Rollback, מתאם-תיקון חם, 'v2' שחרור עם דו-ריצה, תקשורת ומדריך נדידה.

סך הכל

תאימות לאחור היא הדיסציפלינה של האבולוציה: לייצב את הגרעין, להתרחב באופן תוסף, ליישם קורא סובלני, לבצע בדיקות אוטומטיות ולשמור על הפחתה מודעת. כך תוכלו לפתח במהירות את הפלטפורמה מבלי להשאיר לקוחות תחת ההריסות של שינויים ”בלתי נראים”.