רישום סכמות ואבולוציה של נתונים

למה אני צריך רישום מזימות?

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

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

תבניות ויישומים

סכימת JSON: REST/HTTP Paylads, מסמכים, תצורות.
אברו: אוטובוסים לאירוע (קפקא/פולסר), קומפקטי/אבולוציוני באמצעות זיהוי שדה.
פרוטובוף: gRPC/RPC, תגים בינאריים יעילים, קפדניים.
GraphQL SDL: סכימת סוג והנחיה, אבולוציה באמצעות ”@ decreted”.
SQL DDL כחפץ: אנו מתקנים תצוגות מוסכמות (לדוגמה, חנויות חיצוניות) - בזהירות.

מצבי תאימות

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

• אירועים: לעתים קרובות יותר BETWARD (מפיקה מרחיבה את אפשרויות המטען).
• API ציבורי: מלא או אחורה + קורא סובלני קפדן על לקוחות.
• אב טיפוס פנימי: באופן זמני אף אחד, אבל לא על תא מטען.

בטוח (תוסף) נגד שינויים מסוכנים

• הוסף שדה/סוג אופציונלי.
• סיומת אנום עם ערכים חדשים (עם קורא סובלני).
• הוסף הקרנה חלופית/אירוע (”. enriched”).
• הקלת אילוצים ('minLong', 'maximum' business, אבל לא out).

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

ארגון רישום

שמות ופניות

קבוצות/רווחים: ”תשלומים”, ”קיק”, ”ביקורת”.
שמות: 'תשלום. מורשה. v1 '(אירועים),' תשלומים. V1. בקשה (gRPC), פקודות. V1. סדר '(סכימת JSON).
רב סרן בשם, קטינים בגרסת metadata/schema.

Metadata

”בעל” (פקודה), ”דומיין”, ”סלאס” (SLO/SLA), ”ביטחון”. Tier '(PII/PCI),' שימור ',' תאימות _ mode ',' שקיעה ',' changelog '.

ניהול אופן חיים

Review # Review # Experience # Extreme # Depressed Ac.Sunset.
אימות אוטומטי/לינטרים, עיצוב-סקירה ידנית (API Guild), הערות שחרור.

אינטגרציה לתוך CI/CD

1. קדם-התחייבות: Local linters (כלי ספקטרלי/Buf/Avro).
2. PR-pipeline: schema-diff = בדיקת מצב תאימות; חסימת שבירה.
3. פרסום חפץ: דחוף סכימה עקבית לרישום + צור מודלים/SDK.
4. Runtime-Guard (אופציונלי): Gateway/production מאמת את המטען כנגד התרמית הנוכחית.

• 'Openapi-diff-fail-on-breaking &position
• buf שבירה - agst <ראשי> "
• 'avro-compat - mode BACWARDS &pows
• לייצר דגימות זהב ולבצע בדיקות של המרכז לבקרת מחלות.

• Edvitive-first: optional-first (JSON), optional (proto3), defrice avro.
• מודל הפירמידה הפוך: הליבה יציבה, העשרה קרובה ואופציונלית.
• דו-פולט/דו-כתיבה למייג 'ור: אנו מפרסמים ”v1” ו- ”v2” במקביל.
• תוכנית שקיעה: תאריכים, שימושים, אזהרות, מתאמים.
• קורא סובלני: לקוחות מתעלמים מתחומים לא ידועים ומטפלים נכון בחדשנות.

דוגמאות לתוכניות ובדיקות

סכמת JSON (מקטע, שדה תוסף)

json
{
"$id": "orders.v1.Order",
"type": "object",
"required": ["id", "status"],
"properties": {
"id": { "type": "string", "format": "uuid" },
"status": { "type": "string", "enum": ["created", "paid", "shipped"] },
"risk_score": { "type": "number", "minimum": 0, "maximum": 1 }
},
"additionalProperties": true
}

Avro (ברירת מחדל לתאימות)

json
{
"type": "record",
"name": "PaymentAuthorized",
"namespace": "payment.v1",
"fields": [
{ "name": "payment_id", "type": "string" },
{ "name": "amount", "type": "long" },
{ "name": "currency", "type": "string" },
{ "name": "risk_score", "type": ["null", "double"], "default": null }
]
}

Protobuf (אל תשתמש בתגים)

proto syntax = "proto3";
package payments.v1;

message CaptureRequest {
string payment_id = 1;
int64 amount = 2;
string currency = 3;
optional double risk_score = 4; // additive
}
// tag=4 зарезервирован под risk_score, его нельзя менять/удалять без v2

רישום אירועים ומחיצהName

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

ניהול הגירה

1. הוסף שדות/טבלאות 2) התחל לכתוב/לקרוא שדות חדשים; 3) למחוק ישן לאחר השקיעה.

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

בטיחות ותאימות

תוויות PII/PCI בתרשים: ”x-pii: נכון”, ”x-רגישות: גבוה”.
מדיניות גישה: מי יכול לפרסם/לשנות תרשימים (RBAC), סימן שחרור.
קריפטוגרפיה: חתימה של גרסאות סכימה, רישומי ביקורת בלתי ניתנים לשינוי (WORM).
הזכות להישכח: ציין שדות הדורשים הצפנה/מחיקת קריפטו; הדרכה ברישום.

יכולת תצפית וביקורת

לוחות מחוונים: מספר שינויים, סוגים (מינור/מז 'ור), שיתוף של PRs נדחה, שימוש בגרסה.
עקבות ביקורת: מי שינה את התוכנית, קישורים ליחסי ציבור/ADR, שחרור קשור.
מדדי ריצה: אחוז ההודעות שנכשלו באימות; תקריות תאימות.

כלים (ערימת דוגמיות)

סכימת OpenAPI/JSON: Spectral, OpenAPI Diff, Schemathesis.
פרוטובוף/gRPC: Buf, buf-breaking, protoc linters.
Avro/Events: Confluent/Redpanda Schema Registry, Avro-Actures, Karapace.
GraphQL: מפקח GraphQL, קודגן GraphQL.
רשמים/קטלוגים: רישום חפצים, רישום מבוסס Git, קטלוג מאחורי הקלעים, UI מותאם אישית.
תיעוד: Redocly/Stoplight, Swagger-UI, GraphiQL.

אנטי דפוסים

סוואגר-שטוף: התוכנית אינה משקפת את המציאות של השירות (או להפך).
בדיקת תאימות מנוטרלת: ”דחוף” = הפסקות המוצר.
שימוש חוזר בתגיות פרוטובוף: שחיתות נתונים שקטה.
מצב תאימות יחיד ”לכל דבר”: תחומים שונים דורשים מצבים שונים.
CDC גולמי כתוכניות ציבוריות: הדלפת מודל DB החוצה, הבלתי אפשרי של האבולוציה.

רשימת בדיקות מימוש

[ ] פורמט חפץ מוגדר ומצב תאימות לפי תחום.

[ ] לינטרס וסכימה-diff מוגדרים ב CI, יחסי ציבור חסומים בעת שבירה.

[ ] התאפשר לקורא הסובלני של הלקוחות; 'Add  Properties = נכון' (שבו ישים).

[ שינויים גדולים ] עוברים RFC/ADR, יש תוכנית שקיעה

[ מעגלים ] מסומנים ב-PII/PCI ורמות גישה; הביקורת מתאפשרת.

[ ] שימוש בתרגום ותאימות כשל בלוחות מחוונים.

[ ] יצירת דגמי SDK/מהרישום היא חלק מהצינור.

[ תיעוד ] ודגימות זהב מתעדכנות באופן אוטומטי.

שאלות נפוצות

האם זה אפשרי ללא רישום לאחסן מזימות בג 'יט?
כן, אבל הרישום מוסיף API תואם, חיפוש, metadata, מדיניות מרכזית, ואימות on-the-fly. האפשרות הטובה ביותר היא Git בתור אחסון + UI/מדיניות על גבי.

איך אני בוחר במצב תאימות?
תסתכל על כיוון השינוי: אם היצרן מרחיב את המטען - אחורה. עבור API/SDK - מלא. עבור אבות טיפוס מהירים - באופן זמני NONE (לא על תא מטען).

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

האם אני צריך לאמת מטען בזמן ריצה?
עבור תחומים קריטיים, כן: זה מונע הודעות זבל ומאיץ את האבחנות.

תוצאות

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