Bir monoliti bölmek zordur. Mikroservisleri geri birleştirmek mi? Daha zor — ve 2026'nın konsolidasyon dalgasında bunu çok daha fazla ekip öğrenmek üzere.

Plan:

  • Birbiriyle ilişkili işler yapan 10 küçük servis
  • 3 domain servisinde birleştirmek
  • Tahmin: 6 hafta

Gerçek: 6 ay.

Tahmin, konsolidasyonun çoğunlukla kod taşımaktan ibaret olduğunu varsayıyordu. Öyle değildi. Her servis sınırı kimsenin yazıya dökmediği örtük sözleşmeler biriktirmişti ve her biri ancak onu silmeye çalıştığımızda ortaya çıktı.

Üç haftaya mal olan bir örnek:

İki servis de müşteri adresinin “sahibiydi”. Profile normalize kaydı tutuyordu; Shipping ise birkaç dakikalık gecikmeyle kuyruk olaylarıyla tazelenen denormalize bir kopya saklıyordu. Birleştirme planı diyordu ki: kopyayı sil, tek tablodan oku. Sonra Shipping kopyasını bilerek okuyan gecelik bir faturalama mutabakat işi bulduk — olay güdümlü gecikmesi onu kazara bir gün sonu anlık görüntüsüne çeviriyordu ve faturalar, adreslerin çalışma ortasında değişmemesine bağlıydı. Mükerrerlik yük taşıyordu. Onu kaldırmak, hiç belgelenmemiş bir gereksinim için hiç var olmamış açık bir snapshot mekanizması tasarlamak demekti.

Keşfettiklerimizden daha fazlası:

  • Üç farklı mesaj kuyruğu deseni — fire-and-forget olaylar, reply kuyruklu RPC-over-queue ve gecikmeli mesajlar — her birinin, süreç içi çağrıların yeniden üretemediği farklı retry ve idempotency semantiği vardı
  • Servis A JSON beklerken Servis B XML gönderiyordu; arası kimsenin sahiplenmediği bir çeviri shim'iyle kapatılmıştı
  • Ancak birleştirilen kod aynı süreci paylaşıp kuyruğun örtük serileştirmesini kaybedince ortaya çıkan race condition'lar
  • Tam bağımlılık grafı kimsede yoktu — trafik yakalamalarından biz oluşturmak zorunda kaldık

Gerçekten işe yarayan: içe dönük Strangler Fig

Big-bang birleştirmeyi bıraktık. Bunun yerine hedef domain servisini boş olarak ayağa kaldırdık ve trafiği API gateway üzerinden her seferinde bir endpoint olmak üzere içine taşıdık: bir kaynağın okumalarını yeni servise yönlendir, yanıtları eskisiyle karşılaştıran shadow modda çalıştır, eşleşince geçir, tekrarla. Her küçük servis, devreden çıkarılmadan önce sıfır trafiğe kadar boğuldu — bir monoliti boğmakla aynı desen, yalnızca facade dışa değil içe yönlendiriyor. İlerleme toplantılarda vaat edilen değil, dashboard'larda ölçülebilen bir şey oldu.

Dersler:

  • Konsolidasyon bir refactor değil, yeniden yazmadır — öyle tahminleyin
  • Servis sözleşmelerini, zamanlama varsayımları dahil, takıntıyla belgeleyin
  • İhtiyacınız olmadan önce canlı bir bağımlılık grafı tutun
  • Servisleri endpoint endpoint boğarak çıkarın; birleştirmeyi asla big-bang yapmayın

Bu yolu tartıyorsanız önce ilk bölmenin nasıl ters gitme eğiliminde olduğunu okuyun — monoliti çok hızlı bölmek — çünkü geri dönüşü pahalı yapan şey kötü sınırlardır. Her iki yöndeki sınır çalışması, deneyimli bir DevOps ve mimari partnerinin hakkını verdiği yerdir.

Ders: Bölmek (bir ölçüde) geri alınabilir. Geri almanın maliyeti, sınırın ayakta kaldığı her yılla katlanır.

← Çıkarılan Dersler'e dön

Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.

Etiketler: #Mikroservisler #Mimari #Risk #Refactoring