GH GambleHub

Sxemlərin reyestri və məlumatların təkamülü

Niyə sxemlərin reyestri lazımdır

Sxemlərin reyestri məlumat müqavilələri (API, hadisələr, axınlar, mesajlar, anbarlar) üçün mərkəzləşdirilmiş həqiqət mənbəyidir və aşağıdakıları təmin edir:
  • Proqnozlaşdırıla bilən təkamül: uyğunluq qaydaları və avtomatik sınaq.
  • Təkrarlanabilirlik və şəffaflıq: versiyalar tarixi, kim/nə vaxt/nə üçün dəyişdi.
  • Standartlaşdırma: vahid adlar, səhv formatları, izləmə sahələri, PII işarələri.
  • CI/CD ilə inteqrasiya: istehsal əvvəl breaking-dəyişikliklər kilidi.

Reyestr Protocol-first və müqavilə uyğunluğunu birləşdirir, dəyişiklikləri sürətli və təhlükəsiz edir.


Formatlar və tətbiq sahələri

JSON Schema: REST/HTTP yük, sənədlər, konfiqurasiyalar.
Avro: hadisə şinləri (Kafka/Pulsar), kompakt/təkamül ID sahələri vasitəsilə.
Protobuf: gRPC/RPC, binar effektiv, sərt etiketlər.
GraphQL SDL: tip sxemi və direktivlər, '@deprecated' vasitəsilə təkamül.
SQL DDL bir artefakt kimi: razılaşdırılmış təqdimatları (məsələn, xarici vitrinlər) qeyd edirik - ehtiyatla.

💡 Bir reyestr bir anda bir neçə növ artefakt saxlaya bilər, lakin ayrı uyğunluq siyasətləri ilə.

Uyğunluq rejimləri

BACKWARD: Yeni sxemlər köhnə məlumat/mesajları oxuyur. Payload additiv genişləndirən prodüser üçün uyğundur.
FORWARD: Köhnə istehlakçılar yeni məlumatları düzgün oxuyurlar (tolerant reader tələb edir).
FULL: Hər ikisini birləşdirir (daha sərt, ictimai müqavilələr üçün daha əlverişlidir).
NONE: yoxlama olmadan - yalnız qum qutuları üçün.

Tövsiyələr:
  • Events: daha tez-tez BACKWARD (prodüser payload əlavə edir).
  • Public API: TAM və ya BACKWARD + müştərilərdə ciddi tolerant reader.
  • Daxili prototiplər: müvəqqəti NONE, lakin trunk deyil.

Təhlükəsiz (additiv) vs. təhlükəli dəyişikliklər

Əlavə (OK):
  • Əlavə sahə/tip əlavə edin.
  • Yeni dəyərlərlə enum genişləndirilməsi (tolerant reader ilə).
  • Alternativ proyeksiyanın/hadisənin əlavə edilməsi ('.enriched').
  • Məhdudiyyətlərin yumşaldılması ('minLength', 'maximum' ↑, lakin ↓ deyil).
Təhlükəli (qırılır):
  • Sahələrin silinməsi/adının dəyişdirilməsi və ya onların növünün/öhdəliyinin dəyişdirilməsi.
  • Status semantikasının/kodeklərin/sıra axınlarının dəyişdirilməsi.
  • Protobuf etiketlərinin yenidən istifadəsi.
  • Hadisələrdə partizan açarının dəyişdirilməsi.

Reyestrin təşkili

Neyminq və ünvan

Qruplar/məkanlar: 'payments', 'kyc', 'audit'.
Adları: 'payment. authorized. v1` (events), `payments. v1. CaptureRequest` (gRPC), `orders. v1. Order` (JSON Schema).
Major adında, minor - metadata/sxem versiyasında.

Metadata

'owner' (komanda), 'domain', 'slas' (SLO/SLA), 'security. tier` (PII/PCI), `retention`, `compatibility_mode`, `sunset`, `changelog`.

Həyat dövrünün idarə edilməsi

Draft → Review → Approved → Released → Deprecated → Sunset.
Avtomatik validatorlar/linterlər, əl design-review (API Guild), release notes.


CI/CD-yə inteqrasiya

1. Pre-commit: lokal linterlər (Spectral/Buf/Euro tools).
2. PR-paypline: schema-diff → yoxlama compatibility mode; breaking bloklayın.
3. Artifact publish: reyestrdə razılaşdırılmış sxem + SDK/modellərin yaradılması.
4. Runtime-guard (isteğe bağlı): Şluz/prodüser cari sxemə qarşı payload təsdiqləyir.

PR addımlarının nümunəsi:
  • `openapi-diff --fail-on-breaking`
  • `buf breaking --against
    `
  • `avro-compat --mode BACKWARD`
  • qızıl samples generation və CDC testlər qaçış.

Sxemlərin təkamülü: təcrübələr

Additive-first: новые поля — `optional/nullable` (JSON), `optional` (proto3), default в Avro.
Əks piramida modeli: nüvə stabil, zənginləşdirmə - yaxınlıqda və isteğe bağlıdır.
major üçün dual-emit/dual-write: paralel olaraq 'v1' və 'v2' dərc edirik.
Sunset planı: tarixlər, istifadə, xəbərdarlıqlar, adapterlər.
Tolerant reader: Müştərilər naməlum sahələrə məhəl qoymur və yeni enumları düzgün emal edirlər.


Sxemlər və yoxlamalar nümunələri

JSON Sxema (fraqment, əlavə sahə)

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
}
💡 Əlavə edilmiş 'risk _ score' isteğe bağlıdır → BACKWARD uyğundur.

Avro (uyğunluq üçün default)

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 (etiketləri təkrar istifadə etməyin)

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

Hadisə reyestri və partizanlaşdırma

Hadisələrin adlandırılması: 'domain. action. v{major}` (`payment. captured. v1`).
Partizan açarı - müqavilənin bir hissəsidir ('payment _ id', 'user _ id').
Core vs Enriched: '.v1' (nüvə) və '.enriched. v1 '(detallar).
Reyestrdə uyğunluq: mövzu/tip səviyyəsində rejimlər; CI uyğun olmayan dəyişiklikləri rədd edir.


Miqrasiya menecmenti

Expand → Migrate → Contract (REST/gRPC):

1. sahələr/cədvəllər əlavə edin; 2) yeni sahələr yazmağa/oxumağa başlamaq; 3) sunset sonra köhnə aradan qaldırılması.

  • Dual-emit (Events): paralel 'v1 '/' v2', konsumer/proyeksiyaların miqrasiyası, sonra 'v1' çıxarılması.
  • Replay: log proyeksiyalarının yeni sxemə yenidən yığılması (yalnız uyğunluq və miqratorlarda).
  • Adapterlər: mürəkkəb müştərilər üçün 'v1 v2' tərcümə gateway/proxy.

Təhlükəsizlik və uyğunluq

Sxemdə PII/PCI etiketləri: 'x-pii: true', 'x-sensitivlik: high'.
Giriş siyasəti: kim çap/sxemləri dəyişdirmək (RBAC), buraxılışları imzalamaq.
Kriptoqrafiya: sxem versiyalarının imzası, dəyişməz audit jurnalları (WORM).
Unudulmaq hüququ: şifrələmə/kriptovalyuta tələb edən sahələri göstərin; reyestrdə guidance.


Müşahidə və audit

Daşbordlar: dəyişikliklər sayı, növləri (minor/major), rədd edilmiş PR payı, versiyaların istifadəsi.
Audit Trail: Kim sxemi dəyişdi, PR/ADR linkləri, Release bağlı.
Runtime-metriklər: təsdiqlənməyən mesajların faizi; uyğunluq hadisələri.


Alətlər (təqribən yığın)

OpenAPI/JSON Schema: Spectral, OpenAPI Diff, Schemathesis.
Protobuf/gRPC: Buf, buf-breaking, protoc linters.
Avro/Events: Confluent/Redpanda Schema Registry, Avro-tools, Karapace.
GraphQL: GraphQL Inspector, GraphQL Codegen.
Reyestrlər/kataloqlar: Artifact Registry, Git-based registry, Backstage Catalog, custom UI.
Sənədləşmə: Redocly/Stoplight, Swagger-UI, GraphiQL.


Antipatternlər

Swagger-wash: sxem xidmətin reallığını əks etdirmir (və ya əksinə).
Bağlanan uyğunluq testi: «təcili lazımdır» → prod qırılır.
Protobuf etiketlərinin yenidən istifadəsi: məlumatların sakit pozulması.
«Hər şey üçün» vahid uyğunluq rejimi: müxtəlif domenlər fərqli rejimlər tələb edir.
İctimai sxemlər kimi xam CDC: DB modelinin xaricə sızması, təkamülün mümkünsüzlüyü.


Giriş çek siyahısı

  • Domenlər üzrə artefaktların formatı və compatibility mode müəyyən edilmişdir.
  • CI-də linterlər və schema-diff konfiqurasiya, PR breaking zaman bloklanır.
  • Müştərilərdə tolerant reader aktiv; 'additionalProperties = true' (uyğun olduqda).
  • Əsas dəyişikliklər RFC/ADR-dən keçir, sunset planı və dual-emit/dual-write var.
  • Sxemlər PII/PCI və giriş səviyyələri ilə qeyd olunur; audit daxildir.
  • Uyğunluq versiyalarının istifadəsi və uğursuzluqları üçün daşbordlar.
  • SDK/modellərin reyestrdən yaradılması paylaynın bir hissəsidir.
  • Sənədlər və golden samples avtomatik olaraq yenilənir.

FAQ

Reyestr olmadan - sxemləri Git-də saxlamaq mümkündürmü?
Bəli, lakin reyestr API uyğunluq, axtarış, meta-məlumat, mərkəzləşdirilmiş siyasət və «on-the-fly» validasiya əlavə edir. Ən yaxşı variant - Git storage + UI/siyasətlər.

Uyğunluq rejimini necə seçmək olar?
Dəyişikliklərin istiqamətinə baxın: əgər prodüser payload - BACKWARD-ı genişləndirirsə. İctimai API/SDK üçün - FULL. Sürətli prototiplər üçün - müvəqqəti NONE (trunk deyil).

Lazım olduqda nə etmək lazımdır?
v2 hazırlayırıq: dual-emit/dual-run, sunset-tarixlər, adapterlər, istifadə telemetriyası, miqrasiya qaydaları.

Payload-ı rentaymda təsdiqləmək lazımdırmı?
Kritik domenlər üçün - bəli: bu, «zibil» mesajlarının qarşısını alır və diaqnozu sürətləndirir.


Yekun

Sxemlərin reyestri məlumatların təkamülünü riskli improvizasiyadan idarə olunan prosesə çevirir: vahid uyğunluq qaydaları, avtomatik yoxlamalar, başa düşülən versiyalar və şəffaf tarix. Ona additive-first, tolerant reader, dual-emit və sunset intizamını əlavə edin - və müqavilələriniz tez, heç bir pozulma və gecə hadisələri olmadan inkişaf edəcək.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.