תאימות קדימה

מהי תאימות קדימה

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

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

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

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

הקורא מתעלם משדות/כותרות לא ידועים ומאפשר ערכי אנום חדשים עם הגיבוי הנכון.
הכותב אינו שולח דבר שהשרת לא הכריז עליו במפורש כנתמך (יכולות).

2. משא ומתן על יכולות

החלפה מפורשת של יכולות (תכונות/גרסאות/סוגי מדיה) בשלב לחיצת היד. הלקוח מתאים את התנהגותו לתגובת השרת.

3. פירוק ברירת המחדל

התכונות החדשות נחשבות אופציונליות: אם השרת/צרכן אינו תומך בהן, התסריט עדיין יסתיים עם מינימום שימושי (MGC).

4. ליבה יציבה (MGC)

חוזה האחריות המינימלי לא השתנה; חידושים חיים בהרחבה.

5. חוזי שגיאה כחלק מהפרוטוקול

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

6. גרסאות ללא הפתעות

קווי מז 'ור מופרדים; הרחבות קטנות לא דורשות שדרוג שרת/צרכן.

איפה זה משנה

API ציבורי עם אינטגרציות ארוכות חיים (שותפים, SDKs ביישומים ניידים).
פלטפורמות אירועים עם צרכנים עצמאיים רבים.
לקוחות ניידים שמתעדכנים לאט יותר מהחלק האחורי.
Edge/IOTT, שבו חלק של צי המכשיר הוא לעתים רחוקות הבזק.

תבניות יישום לפי סגנון

REST/HTTP

• 'קבל '/סוגי מדיה עם פרמטרים (' application/vnd. דוגמא. סדר + ג 'סון; v = 1; פרופיל = סיכון ').
• 'מעדיף: לכלול =... בלוקים אופציונליים.
• כותרת איקס יכולות: risk_score,item_details_v2'.

• שולח בקשה בפורמט בסיסי, הרחבות - רק אם השרת אישר יכולת (באמצעות OPPLICES/desc/Lead endpoint).
• כאשר ”415/406/501” מגולגל אוטומטית בחזרה לפורמט/שיטה נתמכת.
• תגובת שרת: פרמטרים לא ידועים - להתעלם; שדות נוספים מותרים; תבנית שגיאה יציבה ('סוג/קוד/פרט/עקבות _ id').

gRPC/Protobuf

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

GraphQL

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

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

תאימות קדימה של התוכנית במרשם: צרכנים ישנים יכולים לקרוא הודעות שנכתבו על ־ ידי התוכנית החדשה.
שדות עם ברירות מחדל: יצרנים חדשים לא שוברים צרכנים ישנים.
Core vs. Triched: הליבה נשארה זהה, מידע חדש מתפרסם ב- 'enriched' או כשדות אופציונליים.

פרקטיקות עיצוב

1. חוזה בקשה מינימלית (MGC)

למבצע צריך להיות ”צוואר צר” שכל השרתים יתמכו בו במשך שנים רבות.

2. תווי דגלים ברמת חוזה

תאר את התכונות כשמות: ”סיכון _ ציון”, ”תמחור _ v2”, ”strong _ idempotency”. הלקוח כולל אותם במפורש.

3. קודי שגיאה מפורשים עבור ”לא נתמכים”

HTTP: "501 לא מיושם", "415 לא נתמך מדיה סוג", essociated 'von' בעיה + json ".
GRPC: ”Unimplemented ”/” נכשל” PRECONDATION.
אירועים: מסלול ב- DLQ עם 'Reason = לא נתמך _ feature ".

4. אין להסתמך על סדר/רשימות שלמות

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

5. זיהוי יציב ופורמטים

אל תשנה את הפורמט של מפתחות זיהוי/מחיצה בתוך הקו - זה פורץ קדימה בצד של הקוראים.

6. תיעוד ”ניתן לקריאה במכונה”

תיאורי מארח: OpenAPI/ASyncAPI/Proto Descriptors/GraphQL SDL. הלקוחות יכולים לאמת תמיכה בתכונה.

בדיקת תאימות קדימה

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

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

אחוז הבקשות/הודעות עם תכונות לא נתמכות וגלגולים האוטומטיים שלהם.
הפצה על ידי גרסאות לקוח (User-Agent/metadata/agains).
'UNIMLEMENTED/501/415&fospost שגיאות ומסלולים ב DLQ עם' לא נתמך _ תכונה.
זמן הידרדרות: p95/p99 עבור תגובה MGC נגד ”מורחבת”.

מצבי תאימות בתרשים הרישום

קדימה: הכניסה החדשה מתאימה לקורא הישן (יש צורך ברירות מחדל, אופציונליות).
מלא: BULTOFORD, BULTWARD; נוח לחוזים ציבוריים.
המלצה: לאירועים - אחורה עבור היצרן והקדימה עבור הצרכן (באמצעות קורא סובלני), עבור API - מלא.

דוגמאות

REST (יכולות + הידרדרות)

1. הלקוח מבצע "GET/meta/pactions' *" sance _ score ":" price_v2": נכון ".
2. על ”POST/פקודות” שולח שדות בסיס; ”risk _ score” לא מבקש, כי השרת לא יכול לעשות את זה.
3. אם בטעות נשלח "העדפה: כוללת" = סיכון _ ציון ", השרת מגיב עם 200 ללא שדה" סיכון _ ציון "(או" העדפה יישומית: אף אחד ") - הלקוח אינו מתרסק.

GRPC (תגלית)

'Get Capities ()' חזרה רשימת שיטה/תכונה. הלקוח אינו קורא ל-V2 אם הוא אינו נוכח - במקום להשתמש ב ”לכידה” ולהמיר באופן מקומי את הקלט לתצוגה נתמכת.

אירועים (קדימה ברישום)

המפיק הוסיף את השדה ”risk _ score” (nullable עם ברירת מחדל). הצרכן הישן מתעלם ממנו; ההיגיון שלה משתמש רק בשדות גרעין יציבים.

Antipatterns

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

רשימת יישומים

[ ] MGC; מאפיינים חדשים מסומנים כאופציונליים.

[ משא ומתן ] יכולת (endpoint/metadata/hand shake) מתואר ומיושם.

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

[ חוזי שגיאה ] לוכדים ”לא נתמכים” באופן צפוי (HTTP/gRPC/Event).

[ ] הרישום של סכימה מוגדר לפורוורד/FULL עבור החפצים המתאימים.

[ ] Autotests: schema-diff (קדימה), לקוח נגד מבחני חוזה שרת ישן, כנרית.

[ ] Metrics: גרסת לקוח, כשל בתכונה, שיעור השפלה, p95 MGC.

[ ] Documentation/SDKs מפרסמים רשימה של תכונות ודוגמאות להשפלה.

FAQ

מה ההבדל בין קדימה לאחור בפועל? ‏

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

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

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

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

סך הכל

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