Strangler Fig pattern nedir, eski sistem geçişinde neden gerekir?
Strangler Fig pattern, eski bir uygulamanın işlevlerini ortak giriş noktası arkasında parça parça yenileme yöntemidir. İstek, taşınan işlev için yeni uygulamaya; kalan işler için eski uygulamaya gider. Kullanıcı aynı adresi kullanırken arka tarafta farklı parçalar değişebilir. Microsoft'un Strangler Fig deseni bu kademeli yönlendirmeyi ve eski bağımlılıklar kalmadığında sistemin kaldırılmasını anlatır. Amaç, büyük bir geçişin riskini daha küçük, ölçülebilir adımlara bölmektir.
Bir vekil sunucu kurmak bütün geçiş planını oluşturmaz. Yeni bileşenin hangi iş kuralını uyguladığı, hangi veriyi yazdığı ve hata durumunda eski uygulamanın devam edip edemeyeceği belirlenmelidir. İsteklerin önüne girilemiyorsa, gerekli eski kod değiştirilemiyorsa veya eski sistemin hızla tamamen kaldırılması gerekiyorsa kademeli geçiş uygun olmayabilir. Küçük ve kolay değiştirilebilir bir uygulama için iki sistemi birlikte işletmek gereksiz yük de yaratabilir.
Geçişte eski ve yeni sistem bir süre birlikte yaşar. Bunun altyapı, izleme ve destek maliyetini baştan planlayın. Her adımın tamamlanma koşulu olmalı; yalnızca yeni kodun yayınlanmasıyla ilerleme ölçülmemelidir. Eski rota, mobil istemci ya da gece çalışan görev tarafından hâlâ çağrılıyorsa iş bitmemiştir. Geçici mimarinin kalıcı ikinci ürüne dönüşmesini engelleyen şey, rota bazında sahiplik ve kapanış kanıtıdır.
Rota bazında kademeli geçiş planı
İstemci, giriş rotası, kimlik doğrulama, arka plan görevi ve veri yazımı arasındaki bağı çizerek başlayın. Ölçülebilir yararı ve yönetilebilir hata maliyeti olan tek iş yeteneğini seçin. Salt okunur katalog, ödeme veya stok etkisi bulunmadığı için sipariş oluşturmadan daha kolay başlangıç olabilir. Aşağıdaki tablo bir sipariş portalı için örnek plan iskeletidir; bütün rotaların aynı projede taşınması önerisi değildir.
| Rota veya iş | Geçiş kapısı | Geri dönüş |
|---|---|---|
| Ürün kataloğu | Alanlar ve filtreler aynı | Eski okuma rotası |
| Sipariş geçmişi | Yetki ve sayfalama doğrulandı | Grup yönlendirmesini kapat |
| Günlük rapor | Tutarlar ve güncellik uzlaştı | Eski raporu etkinleştir |
| Sipariş oluşturma | Tek yazar ve tekrar güvenliği | Yeni kayıtları eskiye aktar |
| Gece mutabakatı | Çalışma döngüsü ve bağımlılıklar doğrulandı | Eski görevi kontrollü aç |
Her satırın ayrıntılı kaydında rota kimliği, iş sahibi, teknik sorumlu, çağıran istemciler, veri sahibi, aşama, kabul ölçütü, geri alma anahtarı ve son eski trafik tarihi bulunsun. Test kanıtını ve kapıyı açan kişinin kararını ilişkilendirin. Tablodaki geri dönüş sütunu, yazma rotaları için yalnızca bir hatırlatmadır; yeni kayıtların dönüşümü ve sıra koruması ayrıca denenmelidir. Çözülmemiş ortak bir işlem (transaction) varsa o rota açılmaz.
Giriş noktası ve davranış sözleşmesi nasıl kurulur?
Yönlendirme katmanında önce bütün trafiği eski sisteme gönderin. Bu değişikliğin kendi gecikmesini ve arıza davranışını ölçün; yeni işlev henüz açılmadığı için sorunsuz olacağını varsaymayın. Rota ve kullanıcı grubu eşlemesini sürümlü yapılandırmada saklayın. Aynı kullanıcının aynı akışta eski ve yeni yollar arasında rastgele dolaşmasını engelleyin. Oturum, yetki kontrolü, istek kimliği ve destek kaydı her iki yolda aynı kullanıcı işlemini izleyebilmelidir.
İstek ve yanıt sözleşmesini yazın: zorunlu alanlar, boş değerler, hata kodları, zaman dilimi, para birimi, sıralama ve sayfalama. Eski davranışın hangisinin korunacağını, hangisinin bilinçli değişeceğini iş sahibi onaylasın. Sipariş geçmişinde kayıtların aynı olması yetmez; kullanıcının yalnızca kendi siparişlerini görmesi ve sayfa geçişlerinde kaydın tekrarlanmaması veya atlanmaması da gerekir. Eski veriyle yeni veri modeli arasındaki anlam farklarını ayrı test örnekleriyle gösterin.
Microsoft'un anti-corruption layer deseni, farklı anlamlar kullanan sistemler arasına dönüşüm katmanı koyar. Örneğin eski sistemde tek durum kodu olan teslimat, yeni modelde gönderildi ve teslim edildi olarak ayrılabilir. Dönüşümü iş mantığının her yerine dağıtmak yerine belirli bir sınırda tutun. Bu katmanın gecikmesini, hatalarını ve kaldırılma koşulunu da izleyin; yanlış anlamı temiz bir API adıyla taşımak modernizasyon sağlamaz.
Veri sahipliği, gölge trafik ve aşamalı açılış
Her aşamada tek yetkili yazarı açıkça belirtin. Yeni uygulama eski veritabanını geçici okuyabilir, bir API kullanabilir veya eşitlenen okuma modeliyle çalışabilir. Hangi seçenek seçilirse seçilsin, verinin kaynağını, güncellik sınırını ve kopuk bağlantıda davranışı kaydedin. Yeni sistemin eski tablolara süresiz doğrudan bağımlılığı, taşınmış kodun yanında eski şema bağımlılığını da yaşatır. Geçici erişimin bitiş koşulu olmalıdır.
Gölge trafik yalnızca güvenle tekrar edilebilir okuma ve yan etkisiz hesaplama için kullanılmalıdır. Aynı sipariş oluşturma isteğini iki uygulamada çalıştırmak iki sipariş veya ödeme doğurabilir. Yazma akışlarını önce yan etkileri kapalı test ortamında ve temsilî kayıtlarla sınayın. Canlı geçişte yeni yazımların eski uygulamayla nasıl uzlaştırılacağını, tekrarlanan mesajların nasıl ayırt edileceğini ve iptallerin hangi sırayla işleneceğini belirleyin. Kayıt sayısının eşitliği, tutarların ve durumların doğruluğunu tek başına kanıtlamaz.
Microsoft'un güvenli dağıtım rehberi, küçük kullanıcı gruplarıyla aşamalı açılışı ve her aşamada sağlık kontrolünü önerir. Grup büyüklüğünü trafik ve iş riskine göre seçin. Gözlem süresi normal kullanımın, yoğun saatin ve ilgili toplu işin çalışmasına yetecek kadar uzun olmalıdır. İstek gelmeyen bir grupta hata görülmemesi başarı kanıtı değildir. Açılma, durma ve geri dönüş yetkisini isimlendirin.
Varsayımsal örnek: sipariş geçmişini taşıma
Örneğin bir portal günlük 30.000 sipariş geçmişi sorgusu alsın. Eski rotada p95 gecikmesi 900 milisaniye, hata oranı %0,4 olsun. Yeni yol, eski sistemin API'sinden beslenen okuma modelini kullansın ve en fazla 60 saniye güncellik gecikmesine izin verilsin. Bu rakamlar varsayımsaldır; bir müşteri ölçümü veya her sistem için uygun eşik değildir. İlk aşamanın iş sahibi destek ekibi, teknik sorumlusu portal ekibi olarak kaydedilir.
2.000 temsilî okuma isteği gölgede karşılaştırılır. Kimlik, yetki, toplam, sıra ve sayfalama sınanır. Ardından 100 iç kullanıcı yeni yola alınır; bir tam iş günü ve gece eşitlemesi gözlenir. Açıklanamayan kayıt farkı yoksa dış kullanıcıların %5'i açılır. Bu örnekte hedef p95 gecikmesinin 900 milisaniyeyi ve hata oranının %0,4'ü aşmamasıdır. Veri gecikmesi 60 saniyeyi geçtiğinde açılış durur, yapılandırma eski okuma yoluna çevrilir.
Son aşamada tüm trafik yeni yola gitse bile eski rota hemen silinmez. Ay sonu raporunun bu rotayı çağırdığı görülürse plan güncellenir. Tamamlanma için ilgili iş döngüsü boyunca çağrı kalmaması, veri uzlaşması ve geri dönüş tatbikatı gerekir. Son eski trafik zamanı kaydedilir; bağımlılık kaldırılmadan rota kaydı tamamlandı olarak işaretlenmez.
Geçiş kapıları için test planı
- Sözleşme: Eski ve yeni yolda aynı temsilî girdileri çalıştırın; amaçlı değişiklikleri hata listesinden ayrı tutun ve onay kaydı ekleyin.
- Yetki: Farklı kullanıcı ve rollerle aynı rota çağrısını sınayın; yeni yönlendirme eski erişim sınırını genişletmemelidir.
- Arıza: Yeni hizmeti ve dönüşüm katmanını durdurun. Anahtarın çalıştığını, eski yol kapasitesini ve devam eden işlemlerin sonucunu doğrulayın.
- Veri: Gecikmiş güncelleme, tekrar, iptal ve eşitleme kesintisini deneyin; tutar, durum ve kayıt kimliğini uzlaştırın.
- Açılış: Rota ve gruba göre hata, p95 gecikmesi, iş sonucu ve trafik sayısını izleyin; kapıyı yalnızca yeterli kullanım kanıtıyla açın.
- Kapatma: Mobil istemci, dosya aktarımı ve arka plan görevlerinin eski bağımlılığını kontrol edin; kaldırmadan önce yedek ve yeniden kurma yolunu doğrulayın.
Sık yapılan hatalar
- Vekil sunucuyu geçiş planı sayıp iş ve veri sahibini belirsiz bırakmak.
- Sıkı bağlı birkaç rotayı birlikte taşıyarak geri dönüş sınırını gereksiz büyütmek.
- Yazma isteklerini iki sistemde gölgede çalıştırıp yan etkileri çoğaltmak.
- Bir açılış yüzdesini bütün trafik seviyelerine uygulamak ve kullanılmayan grubu başarılı saymak.
- Eski kodu yalnızca ön yüz trafiğine bakarak silip gece işleri ile mobil istemcileri atlamak.
Hatson Tech bunu nasıl kuruyor?
Özel yazılım geliştirme çalışmalarında geçişi rota envanteri, veri sahipliği ve kabul kapılarıyla kapsamlandırıyoruz. Seçilecek sınırı monoliti ne zaman servislere ayırmalı rehberindeki alıştırmayla değerlendirebilir, bütün uygulamanın hangi parçalarının korunacağını uygulama modernizasyonu karar rehberinden belirleyebilirsiniz. İlk çıktıda rota planı, sorumlular, test kanıtı ve geri dönüş adımları birlikte görünür. Bir aday akışı ve mevcut bağımlılıklarını paylaşmanız, geçişin ilk denemesini somutlaştırır.