Programlama

Geçiş Mimarisi

Başarılı bir miras değiştirmenin özü, faydaların erken sunulmasına izin verdiği ve bir Büyük Patlama risklerini ortadan kaldırdığı için, mirasın kademeli olarak yeni yazılımla değiştirilmesidir. Yer değiştirme sırasında eski ve yeni sistemin aynı anda çalışması gerekecek ve davranışın eski ve yeni arasında bölünmesine izin verecek. Dahası, ikisi arasındaki bu iş bölümü, miras ortadan kalktıkça düzenli olarak değişecektir.

Eski ve yeni arasındaki bu etkileşime izin vermek için, zaman içinde değiştikçe bu işbirliğini destekleyen Geçiş Mimarisi oluşturmamız ve geliştirmemiz gerekiyor. Ara konfigürasyonlar, yeni sistemin hedef mimarisinde yeri olmayan entegrasyonlar gerektirebilir.

Veya bunu daha doğrudan söylemek gerekirse – siz niyet çöpe atılacak işe yatırım yapmak zorunda.

Nasıl çalışır

Bir binanın yenilenmesini düşünün. Bir mimar size bitmiş ürünün çizimlerini sağladı ve inşaatçılar başlamak için bekliyorlar. Ancak ilk adım, inşaat alanına iskele kurmaktır.

İskelenin kendisini kiralamak ve inşa etmesi için bir ekibe ödeme yapmak kaçınılmaz bir yatırımdır. Kritik işlerin yapılabilmesini sağlamak için ihtiyaç duyulur ve çalışanların güvenliğini artırarak yenileme sırasında risk azaltıcı satın alır. Hatta yeni seçeneklerin kilidini açabilir – çatı değiştirilirken bacayı tamir etmenize veya sarkan ağaçlara bakmanıza izin verir (metaforu biraz daha uzatmak için). İş bittiğinde, başka bir ekip gelip iskeleyi sökecek ve onu görmekten memnunsunuz.

Eski bir yer değiştirme bağlamında, bu iskele, hedef mimariye yönelik mevcut evrimsel adımı oluşturmayı kolaylaştıran veya mümkün kılan yazılım bileşenlerinden oluşur. İskele gibi, bu yazılım bileşenlerine, hedef mimariye ulaşıldığında ve kaldırılması gerektiğinde ihtiyaç duyulmaz.

Büyük bir eski monoliti tek seferde değiştirmek risklidir ve birkaç adımda değiştirerek iş güvenliğini artırabiliriz. Bunu, aşağıdaki gibi kalıpları kullanarak, işlevselliğin alt kümesiyle veya bir veri alt kümesiyle yapabiliriz.
Değer Akışlarını Çıkarın ve Ürün Hatlarını Çıkarın. Bunlardan herhangi birini yapmak için monoliti parçalamamız gerekir, bu da monolitin parçalarını ayırmak için dikişler eklemeyi gerektirir. Monolite bir bağlantı sağlayan bileşenler Geçiş Mimarisi’dir, çünkü monolit yer değiştirdiğinde mutlaka ortadan kalkarlar, ayrıca monolitin mevcut görevlerini yerine getirmesi için gerekli değildir.

Monolitin farklı bölümlerinin birbirleriyle nasıl iletişim kurduğuna bakarak ve trafiği diğer öğelere yönlendirmek veya çoğaltmak için değiştirdiğimiz iletişim yoluna bir bileşen yerleştirerek bir dikiş oluşturabiliriz. Olay Durdurma bunu olaylar aracılığıyla iletişimle yapar,
Soyutlama ile Dallanma bunu API’ler ile yapar. . Bu dikişleri oluştururken tanıtabiliriz Eski Mimikler
eski iletişim akışlarına yeni bileşenler eklemek.

Eski yer değiştirmeyle ilgili en büyük zorluklardan biri, eski sistemlerin genellikle doğrudan eriştiği verilerle uğraşmaktır. Mümkünse, doğrudan veri erişimini bir API tanıtarak değiştirerek – örneğin depo model. Ancak bunu yapamadığımızda, bir sistemin durumunu kopyalamamız gerekir. Eski Mimikler ve Olay Durdurma her ikisi de bu yola girmemiz gerektiğinde faydalıdır.

Akılda net bir hedef mimarisi olsa bile, oraya ulaşmanın birçok yolu vardır. Bir ekibin izleyebileceği farklı yolların her biri, farklı Geçiş Mimarisi tarafından etkinleştirilecek veya devreye alınmasını gerektirecektir. Bu durumda, seçim üzerinde bir etkisi olup olmadığını görebileceğimiz kadar ayrıntıya kadar her yol için bir maliyet/fayda analizi yapmamız gerekir.

Bir Geçiş Mimarisi kullanmanın bir parçasının, artık gerekmediğinde onu kaldırmak olduğunu unutmayın. Daha sonra kaldırmayı kolaylaştıran olanaklar eklemek için inşa ederken biraz daha fazla yatırım yapmaya değer olabilir. Benzer şekilde, uygun şekilde kaldırıldığından emin olmamız gerekir – gereksiz bileşenler, kullanılmamış olsalar bile, gelecekteki ekiplerin bir sistemi sürdürme ve geliştirme çabalarını karmaşık hale getirebilir.

Ne Zaman Kullanılır

Kimse sıkı çalışmayı boşa harcamayı sevmez ve atmayı düşündüğümüz bir şeyi inşa etmekten bahsettiğimizde bu duygu doğal olarak ortaya çıkar. Tek kullanımlık bir şeyin çok az değeri olduğu sonucuna varmak kolaydır. Ancak bir Geçiş Mimarisi, birkaç yolla değer sağlar ve bu değer, onu inşa etme maliyetiyle karşılaştırılmalıdır.

İlk değer, genellikle bir özelliği işletmeye sunma hızını artırmasıdır. Burada kullanışlı bir metafor, bir duvarı boyarken ressamların bantı döşeme üzerinde kullanmasıdır. Döşemeyi bantlamadan, döşemenin yanında dikkatlice ve yavaşça boyamanız gerekir. Bandı önceden yerleştirmenin ve daha sonra bandı çıkarmanın maliyeti, boyanın yanlış yere bulaşmasını önlemek için gereken artan hız (ve azaltılmış beceri) ile oluşur.

Yazılımdaki bu değiş tokuş, değere dönüşme süresinin önemi ile büyütülür. İşletmenin, değiştirilen eski sistemdeki mevcut verileri yeni sistemlerden gelen verilerle bütünleştiren yeni bir panoya ihtiyacı varsa, yeni panonuzda eski kaynaklı verileri okuyan ve gerekli formatta kaplayan bir ağ geçidi oluşturarak oraya daha hızlı ulaşabilirsiniz. gösterge paneli. Bu ağ geçidi, eski sistem kaldırıldığında atılacaktır, ancak değiştirme gerçekleşmeden önce entegre bir gösterge panosuna sahip olmanın değeri, onu oluşturma maliyetini fazlasıyla aşabilir. Karşılaştırma yakınsa, eski değiştirmenin beklenenden daha uzun sürme olasılığını da düşünmeliyiz.

Geçiş Mimarisinin ikinci değeri, eski yer değiştirme riskini nasıl azaltabileceğidir. Ekleme Olay Durdurma bir müşteri yönetim sistemine geçmek, inşa etmek için bir şeye mal olacak, ancak bir kez inşa edildiğinde, müşterilerin kademeli olarak geçişine izin veriyor (örn. Ürün Hatlarını Çıkarın veya Değer Akışlarını Çıkarın). Bir müşteri alt kümesini taşımak, geçişte bir şeylerin ciddi şekilde yanlış gitme olasılığını azaltır ve armut şeklindeki her şeyin etkisini azaltma eğilimindedir. Ayrıca, gerçekten ciddi bir sorun ortaya çıkarsa, Olay Durdurma önceki duruma geri dönmeyi kolaylaştırır.

Kural olarak, ekipler eski bir yer değiştirme sırasında her zaman Geçiş Mimarisini dikkate almalı ve bu faydaları gerçekleştirebilecek bazı geçici yazılımlar oluşturmanın farklı yollarını beyin fırtınası yapmalıdır. Ekip, daha sonra, bu kısa ömürlü yazılımı oluşturma maliyetine karşı artan değerleme süresinin ve azaltılmış riskin faydalarını değerlendirmelidir. Birçok insanın, geçici yazılımın maliyetini ne sıklıkta geri ödediğine şaşıracağını düşünüyoruz.

Örnek: Mimari Evrim

Bu bölüm, genel bakış makalesinde tanıtılan Ara Katman kaldırma örneğini inceler ve Geçiş Mimarisinin sistemin güvenli evrimini nasıl sağladığını açıklar.

Eski yapılandırma

Genel bakışta açıklandığı gibi, olduğu gibi mimari, ürünlerin bazı Entegrasyon Ara Yazılımları aracılığıyla Legacy Storefront’ta fiyatlandırılmasından ve yayınlanmasından sorumlu ana Legacy sisteminden oluşuyordu. Bu ara yazılım, bir Eski Kuyruktaki olayları yayınlayan ürünü tüketti ve ürünün vitrinde nasıl sunulacağına ilişkin uzun süredir devam eden düzenlemeyi yönetti. Ürün satıldığında, Eski Mağaza Önü, temel paylaşılan Eski Veritabanındaki ürünlerin durumunu güncelleyen ara yazılımı çağırır. Eski Ara Yazılım, dahili durumunu veri ambarı aracılığıyla kritik raporlara beslenen Eski Veritabanında da depoladı. Görmek Kritik Toplayıcı

Hedef Mimari

Hedef mimari içinde Legacy Storefront kalır, ancak sorumluluklarının bir kısmı yeni bir Storefront Manager bileşenine taşınmıştır. Vitrin Yöneticisi, bir ürün satış için o kanala yönlendirildiğinde Varlık İmha Yönlendiricisi tarafından üretilen iş Olaylarını tüketecek ve yeni bir API kullanarak ürünü Storefront’ta yayınlayacaktır. Vitrin Yöneticisi, ürünün Vitrin içinde nasıl görüntülendiğinden sorumlu olacaktır. Ürünler satıldığında, Eski Vitrin, yeni API’yi kullanarak Vitrin yöneticisini çağırır ve bu daha sonra bir alt Varlık Satış İşleme bileşeni tarafından tüketilecek bir iş Etkinliği yayar.

İlk küçük etkinleştirme adımı

Transitional Architecture’ın eklenecek ilk biti Event Router bileşeniydi. Bu bir örnek Olay Durdurma model. Event Router, yeni bileşenler aracılığıyla satılık ürünleri yönlendirmek için kullanılabilecek teknik bir bağlantı oluşturdu.

Vitrin Yöneticisinin Tanıtımı

Sonraki adım, yeni Vitrin Yöneticisini eklemekti. İki çok farklı amaca hizmet eden Geçiş Mimarisi de buraya eklendi. Yani, yeni bileşenleri eski kaygılardan (örneğin veri yapıları ve mesajlar) izole etmek ve eski dünyada ışıkları açık tutmak. Yalıtım için (Yolsuzlukla Mücadele Katmanı), Olay Yönlendiricisi tarafından yönlendirilen Eski Mesajı, Vitrin Yöneticisi tarafından tüketilecek ve hedef mimaride kalıcı olacak yeni ve temiz bir iş etkinliği biçimine dönüştürmek için bir Olay Dönüştürücüsü oluşturuldu. Storefront Manager ve Legacy Storefront, yeni bir API aracılığıyla işbirliği yapacaktı, bu nedenle bu, dahili olduğu kadar eklendi Olay Durdurma böylece bir ürün satıldığında, Eski Mağaza o ürünü yayınlayan sistemi “geri arayacaktır”. Işıkları iki parça Geçiş Mimarisi üzerinde tutmak için gerekliydi. İlk olarak, ürünler satıldığında yeni iş etkinlikleri yayınlandı. Bunlar, Entegrasyon Ara Yazılımını taklit eden ve Eski Veritabanını satış bilgileriyle güncelleyen geçici bir Eski Veritabanı Bağdaştırıcısı tarafından tüketildi. İkinci olarak MI Data Mimic oluşturuldu. Bu hem Olay Durdurucu hem de Eski Taklitçiydi – yeni API içindeki olayları durdurdu ve Eski Veritabanını kritik iş raporlarının gerektirdiği “durum” bilgileriyle güncelledi.

İş sonucu – Eski Ara Yazılımın kullanımdan kaldırılması

Eski Sistem, hangi varlıkların satılabileceğini belirlemekten ve ürünleri yayınlanmak üzere göndermekten hala sorumluydu, ancak zamanla yeni bileşenlere yönlendirilen ürünlerin sayısı arttı (bkz.
Ürün Hatlarını Çıkarın) trafiğin %100’ü Eski Ara Yazılıma güvenilmeden işlenene kadar. Bu noktada, yeni Storefront Manager ve Transitional Architecture bileşenlerini üretimde bırakarak Eski Ara Yazılımı devre dışı bırakmak mümkün oldu.

Varlık İmha Yönlendiricisinin Tanıtımı

Bir süre sonra yeni Varlık İmha Edici Yönlendirici bileşeni devreye alındı. (Bu örneğin bir şekilde basitleştirilmiş olduğunu ve çok daha büyük bir Eski Yer Değiştirme programının deneyimlerinden alındığını hatırlayarak.) Bu bileşen, Vitrin Yöneticisi tarafından tüketilebilecek ürünler için yeni iş Olaylarını yayınladı. Hangi varlıkların elden çıkarılacağını belirleme görevini başka bileşenler üstlendiğinden Event Router’a veya Event Transformer’a artık ihtiyaç yoktu – bu nedenle bu bileşenler hizmet dışı bırakılabilirdi. Eski Ara Katmanın kullanımdan kaldırılması nedeniyle, iş açısından kritik raporlar yeni bileşenlerden gelen verileri kullanacak şekilde değiştirildi (bkz. Kaynağa Dön) ve böylece MI Data Mimic bileşeni de hizmet dışı bırakılabilir.

Hedef mimariye güvenli varış

Bir süre sonra, Legacy System’in son sorumluluklarını devralan (bu örnek kapsamında) yeni Varlık Satış İşleme bileşeni çevrimiçi hale getirildi. O zaman, Geçiş Mimarisinin sonuncusu olan Eski Veritabanı Bağdaştırıcısı kaldırılabilirdi. Vitrin Yöneticisi tarafından üretilen iş Etkinlikleri, Varlık Satış İşleme bileşeni tarafından tüketildi.

İlgili Makaleler

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.

Başa dön tuşu