Mikro servis mimarilerinin kaotik ortamında, servisler arası iletişim uygulamanın can damarıdır. Ancak bu etkileşimleri tanımlamak için standart bir yöntem olmadan ekipler, genellikle "önce uygulama" geliştirme tuzağına düşer. Bu yaklaşım, sıkı bağlanma, entegrasyon kabusları ve tüm sisteme yayılan sık sık bozucu değişikliklere yol açar. İşte sözleşme öncelikli geliştirme, tek bir satır iş mantığı yazmadan önce arayüzlerin tanımlanmasını önceliklendiren bir paradigma değişikliği.
Neden Sözleşme Öncelikli Geliştirme Önemlidir?
Geleneksel geliştirme, genellikle organik olarak evrilen ve kırılgan hale gelen "çamur topu" arayüzleriyle sonuçlanır. Genellikle mesajlaşma için OpenAPI (Swagger) veya AsyncAPI gibi araçlardan yararlanan sözleşme öncelikli geliştirme, her servisin dağıtım öncesinde veri yapısı, uç noktalar ve hata kodları konusunda anlaşmasını sağlar. Bu ayrıştırma, ön yüz ve arka yüz ekiplerinin (veya ayrı mikro servis ekiplerinin), sözleşmeden üretilen sahte verileri (mocks) kullanarak uygulamalarını bağımsız olarak test etmek için paralel çalışmasına olanak tanır.
Altın Kaynağı Tanımlama
Bu stratejinin çekirdeği, bir "Altın Kaynak" spesifikasyonunu sürdürmektir. Bu, API'yi tanımlayan sürüm kontrolü altındaki bir YAML veya JSON dosyasıdır. Aşağıda, bir UserService için basitleştirilmiş bir OpenAPI 3.0 spesifikasyon örneği bulunmaktadır:
openapi: 3.0.0
info:
title: User Service API
version: 1.2.0
description: Handles user profile management.
paths:
/users/{userId}:
get:
operationId: getUser
parameters:
- name: userId
in: path
required: true
schema:
type: string
responses:
'200':
description: Successful response
content:
application/json:
schema:
$ref: '#/components/schemas/User'
components:
schemas:
User:
type: object
required:
- id
- name
properties:
id:
type: string
name:
type: string
email:
type: string
format: email
createdAt:
type: string
format: date-time
Bu dosyayı Git'e commit'leyerek tek gerçeklik kaynağı haline gelir. Otomatik CI/CD hatları, ardından linter'lar ve uyumluluk denetleyicileri kullanarak herhangi bir değişikliği bu spesifikasyona karşı doğrulayabilir.
Sürümleme Stratejileri: Yol, Başlık veya Anlamsal?
Bozucu değişiklikler kaçınılmaz olduğunda, sürümleri nasıl yönetiriz? Mikro servislerde üç strateji yaygındır ve her birinin artıları ve eksileri vardır:
- Yol Sürümleme (
/v1/users): Basit ve açık. Halka açık API'ler için harikadır ancak URL karmaşasına yol açabilir. Eski yolların aktif kalması gerektiği için terk etmesi zordur. - Başlık Sürümleme (
X-API-Version: v1): URL'leri temiz tutar. Ancak tarayıcı geçmişinde görünmez ve doğru şekilde önbelleğe alınması zor olabilir. - Özellik Bayraklarıyla Anlamsal Sürümleme: Modern mikro servis yaklaşımı. Tek bir uç noktayı sürdürürsünüz ancak tüketici tarafından bildirilen uyumluluğa göre trafiği yönlendirmek için özellik bayrakları veya servis ızgaraları kullanırsınız. Bu, kademeli dağıtımlara olanak tanır.
CI/CD'de Kararlılığı Uygulama
Sözleşmeyi yazmak savaşın sadece yarısıdır; onu uygulamak diğer yarısıdır. CI hattınızda, openapi-diff veya spectral gibi araçları entegre etmelisiniz. Bu araçlar, ana dal ile bir çekme isteği (pull request) arasındaki farkı analiz ederek bozucu değişiklikleri tespit eder.
Örneğin, bir geliştirici sürümü güncellemeden User şemasına zorunlu bir alan eklerse, hat açık bir mesajla başarısız olmalıdır:
❌ Breaking Change Detected:
Property 'email' in schema 'User' was changed from optional to required.
Action: Bump minor version to 1.3.0 or make field optional.
Sonuç
Sözleşme öncelikli geliştirme sadece bir teknik desen değildir; aynı zamanda kültürel bir disiplindir. API spesifikasyonlarınızı birinci sınıf vatandaşlar olarak görerek bilişsel yükü azaltır, otonom ekip özerkliğini sağlar ve mikro servis ekosisteminizin değişime karşı dayanıklı kalmasını garanti altına alırsınız. Küçük başlayın: kritik bir servisi belgeleyin, doğrulamasını otomatikleştirin ve bu süreci organizasyonunuz genelinde ölçeklendirin.