Mikro Servis Mimarisine Geçiş Yapanlar İçin API ve Gateway Geliştirme
Tek uygulamada biriken kod artık küçük bir değişiklik için bile tüm sistemi yeniden yayına zorluyorsa sorun ekip hızı değil, sınırların belirsizliği. Servis sınırlarını veriyle çiziyor, ayrıştırmayı sıraya koyuyor ve her adımı geri alınabilir bırakıyoruz.
- Kademeli ayrıştırma planı
- API gateway ve yönlendirme
- Olay tabanlı iletişim
- Dağıtık izleme kurulumu
Sorun büyüklük değil; her şeyin her şeye bağlı olması.
Mikro servis kararı genellikle mimari bir hevesle değil, gündelik bir tıkanmayla alınır: yayın kuyruğu uzar, küçük bir düzeltme büyük bir riske dönüşür.
- Tek satırlık değişiklik tüm sistemi yayına sokuyorBildirim metnini düzeltmek için ödeme ve sipariş kodunu da içeren aynı paket yeniden yayınlanıyor. Risk, değişikliğin boyutuyla orantısız.
- Ekipler aynı dosyada çarpışıyorİki ekip farklı işler yapıyor ama aynı katmanlara dokunuyor. Birleştirme çakışmaları ve bekleyen incelemeler günlük iş haline geliyor.
- Bir modülün yükü tüm uygulamayı yavaşlatıyorRapor üretimi veya toplu dışa aktarım çalıştığında aynı süreçte duran giriş ekranı da yavaşlıyor. Ölçekleme yalnız topluca yapılabiliyor.
- Veritabanında herkes her tabloya yazıyorHangi alanı hangi kodun güncellediği belirsiz. Bir alanın anlamını değiştirmek, görünmeyen üç yeri birden bozma ihtimali taşıyor.
- Hata nerede başladı, kimse net söyleyemiyorKayıtlar farklı yerlerde, aynı isteğin izini sürecek ortak bir kimlik yok. İnceleme, ekran görüntüsü ve tahminle ilerliyor.
- Servis ayırma denendi, ortaya dağıtık monolit çıktıKod ayrıldı ama veri ve yayın birlikteliği sürdü. Şimdi hem dağıtık sistemin karmaşıklığı hem de monolitin bağımlılığı var.
Önce sınır, sonra sıra, en sonunda kod.
Mikro servis bir teknoloji seçimi değil, bir sahiplik kararıdır. Hangi verinin sahibi kim sorusunu yazılı olarak yanıtlamadan tek satır servis kodu yazmıyoruz.
- Sınır analiziMevcut kodu iş yeteneklerine göre gruplandırıyor, modüller arası çağrı ve tablo paylaşımını çıkarıyoruz. Sınır, koda değil işe göre çiziliyor.TeslimBağımlılık haritasıVeri sahipliği tablosuAday servis listesi
- Ayrıştırma sırasıHer aday servis değişim sıklığı, veri bağımlılığı ve yük profiline göre puanlanır; ilk dalga en çok kazandıran, en az riskli modüllerden seçilir.TeslimDalga planıRisk notlarıGeri alma stratejisi
- Gateway ve yönlendirmeMonolitin önüne tek giriş noktası koyuyoruz. Adres değişmeden trafik kademeli olarak yeni servise kayar; sorun görülürse anında geri döner.TeslimAPI gateway kurulumuYönlendirme kurallarıKimlik doğrulama katmanı
- Servis sözleşmeleriServisler arası her çağrı OpenAPI veya şema ile yazılı hale gelir; sözleşme testleri, bir servisin diğerini sessizce bozmasını engeller.TeslimOpenAPI / şema tanımlarıSözleşme testleriSürümleme politikası
- Olay tabanlı iletişimBeklemeyen işler kuyruğa taşınır. Yeniden deneme, idempotent işleme ve ölü mektup kuyruğu ile geçici hatalar veri kaybına dönüşmez.TeslimKuyruk kurulumuOlay şemasıYeniden deneme kuralları
- Gözlemlenebilirlikİstek kimliği uçtan uca taşınır; dağıtık izleme, metrik ve uyarılar ilk servisten önce kurulur. Kör noktayla canlıya çıkılmaz.TeslimDağıtık izlemeServis metrikleriUyarı eşikleri
Hangi modül önce çıkmalı? Servis sınırı ve sıra seçici
Monolitinizde bulunan modülleri işaretleyin; her biri için değişim sıklığını ve veri bağımlılığını seçin. Araç, bağımsızlık kazancı ile taşıma riskini karşılaştırıp modülleri dalgalara yerleştirir. Hesap tarayıcınızda yapılır, hiçbir veri gönderilmez.
Değişim sıklığı kazancı, veri bağımlılığı riski belirler.
- Bildirim / e-posta / SMSÖncelik: 9
- Dış entegrasyon uçlarıÖncelik: 6
- Raporlama ve dışa aktarımÖncelik: 6
- Arama ve listelemeÖncelik: 2
- Bu dalgada modül yok.
İlk dalgayı bilinçli olarak en fazla üç modülle sınırlıyoruz; kalanlar sıradaki dalgaya kayar.
Bu araç, ayrıştırma tartışmasını hızlandırmak için hazırlanmış basitleştirilmiş bir önceliklendirme modelidir; mimari karar yerine geçmez. Gerçek sıra, kod tabanınızın incelenmesi ve ekip yapınız konuşulduktan sonra belirlenir.
Geçişin görünmeyen yarısı: gateway, kuyruk ve izleme
Servis kodu buzdağının görünen kısmı. Dağıtık bir sistemi yönetilebilir kılan şey, servislerin etrafına kurulan ortak altyapıdır.
- GirişAPI gatewayTek giriş noktası; yönlendirme, kimlik doğrulama, hız sınırı ve sürüm yönetimi burada toplanır.
- GirişKademeli yönlendirmeTrafiğin belirlenen yüzdesi yeni servise gider; sorun görülürse yönlendirme geri alınır.
- SözleşmeServis sözleşmeleriOpenAPI veya şema ile yazılı arayüz; sözleşme testleri sessiz bozulmaları yakalar.
- İletişimOlay kuyruğuBeklemeyen işler kuyruğa düşer; yeniden deneme ve ölü mektup kuyruğu veri kaybını önler.
- İletişimIdempotent işlemeAynı olay iki kez geldiğinde ikinci kez iş yapılmaz; tekrar, hataya dönüşmez.
- VeriVeri sahipliğiHer kaydın tek bir sahibi olur; diğer servisler kopya veya olay üzerinden okur.
- İzlemeDağıtık izlemeİstek kimliği uçtan uca taşınır; bir isteğin geçtiği tüm servisler tek zincirde görünür.
- İzlemeServis metrikleriGecikme, hata oranı ve kuyruk derinliği için eşik tabanlı uyarılar.
Servisleri Node.js ile yazıyor, servisler arası anlık çağrılarda REST veya gRPC, gecikmeye toleranslı işlerde mesaj kuyruğu kullanıyoruz; paylaşılan önbellek ve kilit ihtiyacı için Redis, paketleme için Docker standardımız. Yığının tamamı API geliştirme hizmet sayfasında listeli.
Geçiş kararının teknik olduğu kadar örgütsel bir tarafı var: ekip sayısı, devir alma kapasitesi ve yayın disiplini. Bu tarafı teknik danışmanlık kapsamında konuşuyoruz. Eski bir sistemi taşıyorsanız arayüz tarafı web yazılım geliştirme, mobil istemci varsa sürümleme ve uyumluluk kararları mobil yazılım geliştirme ile birlikte ele alınır. Altyapı seçiminde sunucu ve barındırma farklarını hosting, VPS ve bulut karşılaştırmamızda anlattık.
Mikro servis her zaman doğru cevap değil
Bir mimariyi savunmak yerine sizin durumunuzu değerlendiriyoruz. Aşağıdaki durumlarda geçişi ya sınırlı tutuyoruz ya da hiç önermiyoruz.
- Tek ekip, tek yayın takvimiBağımsız yayın ihtiyacı yoksa, dağıtık sistemin getirdiği işletme yükü kazancı aşar. Modüler monolit çoğu zaman daha iyi bir hedeftir.
- Veri sahipliği netleşmemişAynı tabloya üç servis yazacaksa ayırma, sorunu görünmez hale getirir. Önce sahiplik, sonra ayırma.
- İzleme kurulmamışDağıtık sistemde kör nokta, tek uygulamadakinin katı kadar pahalıya mal olur. İzleme ilk servisten önce kurulur.
- Geri dönüş planı yokHer adımın geri alma yolu yazılı olmalı. Yoksa geçiş, ilk sorunda durma riski taşıyan tek yönlü bir yola dönüşür.
Değerlendirme sonucunda 'şimdilik ayırmayın' dediğimiz projeler oluyor. Bu değerlendirmeyi bağımsız bir gözle yapmamızı isterseniz teknik danışmanlık kapsamında tek başına da alabilirsiniz.
Örnek bir ilk faz: gateway ve iki servis
Aşağıdaki plan, orta ölçekli bir monolitin ilk dalgası için hazırlanmış örnektir. Sizin planınız kod incelemesi ve sınır analizinden sonra çıkar; süre ve sıra sözleşmede yazılı hale gelir.
| Hafta | Ne yapılır | Hafta sonunda elinizde ne olur |
|---|---|---|
| 1–2. hafta | Sınır ve bağımlılık analizi | Bağımlılık haritası, veri sahipliği tablosu |
| 3. hafta | Dalga planı ve geri alma stratejisi | Sıralı servis listesi, risk notları |
| 4. hafta | Gateway ve izleme kurulumu | Tek giriş noktası, uçtan uca izleme |
| 5–6. hafta | İlk servisin çıkarılması | Bağımsız yayınlanabilir servis, sözleşme testleri |
| 7. hafta | Kademeli yönlendirme | Trafiğin kontrollü devri, ölçüm |
| 8–9. hafta | İkinci servis ve olay kuyruğu | Kuyruk, idempotent işleme, ölü mektup kuyruğu |
| 10. hafta | Devir ve dokümantasyon | Çalışma kılavuzu, uyarı eşikleri, ekip devri |
İlk dalga kararlı çalıştıktan sonra ikinci dalga aynı şablonla ilerler: her servis için sınır, sözleşme, yönlendirme ve izleme adımları tekrar eder; altyapı yeniden kurulmaz.
- HizmetAPI GeliştirmeHizmetin tamamı: kapsam, süreç, teslimatlar ve teknoloji yığını.
- HizmetTeknik DanışmanlıkGeçiş kararında bağımsız mimari değerlendirme ve yol haritası.
- HizmetWeb Yazılım GeliştirmeServislerin üstündeki arayüz ve yönetim ekranları tarafı.
- HizmetMobil Yazılım GeliştirmeMobil istemcilerde sürümleme ve geriye uyumluluk kararları.
- ProjeTYS — Teklif Yönetim Sistemi27 modüllü iş uygulaması; entegrasyon katmanı kendi ürünümüzde.
- RehberHosting, VPS, bulut ve dedicated farkıServisleri nerede çalıştıracağınıza karar verirken.
- RehberYazılım firması seçerken dikkat edilmesi gerekenlerMimari dönüşüm teklifi karşılaştırırken sorulacak sorular.
- RehberSızma testi (pentest) nedir?Dışa açık gateway'de bağımsız güvenlik doğrulaması.
Sık sorulanlar
Ayrıştırma sırası, servisler arası iletişim, veri sahipliği ve geçiş sırasında sistemin ayakta kalması hakkında en çok sorulanlar.
Monolitinizi birlikte okuyalım, sınırı birlikte çizelim
Bugün en çok hangi modül yüzünden yayın geciktiğini ve hangi tabloya kimlerin yazdığını anlatın; ilk görüşmede aday servisleri ve gerçekçi bir ilk dalga kapsamını çıkaralım. Keşif görüşmesi ücretsizdir ve sizi bağlamaz.
- ✓ Keşif görüşmesi ücretsiz
- ✓ Kapsam netleşmeden fiyat vermiyoruz
- ✓ Gerekirse 'ayırmayın' deriz
Geçişi tek gecelik bir olay olmaktan çıkaralım
Servis sınırlarını veriyle çiziyor, ayrıştırmayı dalgalara bölüyor, gateway ve dağıtık izlemeyi ilk servisten önce kuruyoruz.