PHP monolitten ödeme modülünü Strangler Fig ile nasıl koparırım?
Soru
Büyük bir PHP monolitim var. "Ödeme" modülünü koparıp Go ile bağımsız bir mikroservise dönüştürmek istiyorum. Kullanıcılar ve mevcut kod fark etmeden trafiği kademeli (%5, %20, %100) yeni servise yönlendirmek istiyorum. API Gateway (Envoy/Nginx) düzeyinde bunu nasıl kurarım? Veritabanlarını ayırırken tutarlılığı nasıl sağlarım?
Cevap
Kısa cevap: Önüne bir facade/gateway (Nginx/Envoy) koy, trafiği ağırlıkla kaydır (5/20/100), monolit fallback kalsın. Ama zor kısım routing değil — veri.
Kısa cevap
Strangler Fig’in mantığı şu: eski modülü bir anda öldürmezsin, etrafını sarıp trafiği yavaşça yeni servise kaydırırsın. Modül koptuğu anda iki taraf arasında bir mesaj sözleşmesi doğar; o sözleşmeyi nasıl kuracağını Laravel ile Go arasındaki mesaj şeması sorusunda ayrıca ele almıştım.
Neden
-
Routing kolay, veri zor. Gateway’de ağırlık değiştirmek tek satır config; paylaşılan tabloları ayırmak aylar sürebilir. Planı ikinciye göre yap.
-
Para söz konusuyken “umarım doğrudur” yoktur. Yeni servisi gerçek para işlemeden önce doğrulamanın tek yolu, çıktıları monolitinkiyle karşılaştırmaktır.
-
Sınırı net olmayan modülü koparmak felaketi hızlandırır. Ödeme modülü monolitin tablolarına dolanmışsa, Strangler Fig o dolanmayı çözmez — üstüne trafik ekler.
Ne yapmalı
-
Gateway’de ağırlıklı yönlendirme kur. Nginx/Envoy önde dursun, ödeme trafiğini
%5 → %20 → %100ağırlıkla yeni Go servisine yolla, geri kalanı monolite. Geri dönüş tek satır config olsun. -
Önce SHADOW çalıştır. Trafiği aynala, çıktıları monolitinkiyle karşılaştır, hiçbir gerçek aksiyon alma. Hesaplar tutuyorsa canlıya al.
-
Tabloları asla paylaşma. Ödeme servisine kendi store’unu ver; aralarına bir anti-corruption layer koy ki monolitin modeli yeni servise sızmasın.
-
Tutarlılığı outbox + events ile sağla. Distributed transaction’a girme; değişikliği kendi DB’sine yaz, aynı transaction’da bir outbox kaydı bırak, event olarak yayınla. Veriyi taşırken dual-write + backfill, sonra reconcile, sonra cutover.
-
Önce dikişi düzelt. Sınır zaten net değilse, koparmadan önce o seam’i temizle.
Sonuç: Ben olsam gateway’de ağırlıklı routing + monolit fallback kurar, yeni Go servisini önce shadow’da gerçek parayla değil aynalanmış trafikle doğrular, sonra kademeli açardım. Asıl işin routing değil veri ayrımı olduğunu unutma: paylaşılan tablo yok, anti-corruption layer var, tutarlılık outbox/event ile geliyor. Mimari derinliği sade.dev’de açıyorum — sınırı temiz olmayan modülü koparmaya kalkma.
İlgili Yazılar
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.