Monolith’ten mikroservise yolculuk -3
Önceki yazılarımızda alacağımız kararları ve olabilecek sonuçları üzerine konuştuk. Hazırlıklarımızı tamamladık. Ayırma işlemimize daha derinden bakabiliriz.
Karar vermemiz gereken ilk şey mevcut monolitik uygulamayı değiştirmeyi planlayıp planlamadığımız. Mevcut sistemde değişiklik yapmaya yetkimizin olması bizim için büyük bir avantaj. Kodumuzu değiştirip güncelleyebileceğimiz bir durumda olduğumuzu düşünerek devam edelim.
Mevcut işlevselliği taşımalı mıyım yoksa tekrardan mı yazmalıyım?
Taşımak istediğimiz alan gerçekten iyi yazılmış olabilir. Buradaki akış değiştirilmeden yeni sisteme geçiş yapabiliyorsak bu durum bizim ileride karşılaşabileceğimiz sıkıntılara karşı bir kaçış olabilir. Yani geri dönme durumunda doğrudan kullanabiliriz. Bu sebeple bize zaman kazandırabileceği gibi 2 uygulamayıda paralel olarak çalıştırmaya olanak sağlayabilir. Taşıma işlemi bittikten sonra monolith kısmını kaldırarak yolumuza devam edebiliriz. Var olan kod yapımız artık eskimiş ve bizi taşımıyor olabilir. Bu durumda kodumuzu refactor etmeliyiz. Burada önemli olan konu ddd tarzı yapılardan faydalanarak elimizdeki yapıyı çok daha sadece anlaşılır ve kolay değiştirilebilir hale getirmemiz gerektiğidir.
Taşınma işlemine başlayalım. Bu işlemlerle için birden çok pattern var. Biz burda en çok kullanılan ve belkide ilk etapta düşünürken herkesin aklına gelebilecek olanı seçtik. Strangler Fig Application olarak bilinen bu yöntem temelde yavaş yavaş ana uygulamayı sarıp onun yerini almayı hedefliyor diyebiliriz.
Yazılımsal olarak düşünecek olursak paralelde yazdığımız servis bizim ana servisimizin yapabileceklerini ilk etapta destekler ve sararak var olan durumdan haberdar olur. Zaman içerisinde yeni servis eski ana servisin yapabileceği bütün özelliklere eriştiğinde ve eskisine gerek kalmadığında geçişi tamamlarız. Bu sistemin bize sağladığı en büyük artılardan birisi yeni sistemin paralel bir şekilde bile olsa çalışmaya başlaması ve hatalarının ortaya daha erken çıkması. Bu durum belkide geçişi duraklatmaya kadar gidebilir ve bizi daha büyük sıkıntılardan kurtarır.
Temelde 3 uygulanış adımı ile bu pattern uygulanabilir.
- Mevcut sistemden taşımak istediğiniz bölümlerin belirlenmesi
- Belirlenen bölümlerden hangilerinin daha önce yeni serviste denenmesi gerektiğinin kararının verilmesi
- Yeni uygulamamız hazır olduğunda monolith kısmından o parçayı kurtarmak.
Bizim sistemimizde karar verdiğimiz ilk domain like (beğeni) bölümüydü. Sisteme anlık olarak en fazla yükün geldiği ve diğer alanlara göre ayrılması en doğru olan kısım olarak bu modeli seçmiştik.
Servisimizin database türü ve yapısını belirledikten sonra ilk olarak yaptığımız şey. Ana servisin yanında bizim servisimizinde çalışması ve en azından gelen bilgilerini store edebiliyor olması bizim için önemliydi. Üzerindeki değişikliklere cevap verebiliyor hale gelebilmesi ki bu patternin bize verdiği en büyük şans belkide paralel çalışan ve birbirini etkilemeyen 2 sistem olması, bizim micro servisimizin yarattığı hataları hemen kapamaya zaman kazandırıyor olmasıydı. Veri saklama ve değişiklikleri tam manası ile yaptığımıza emin olduğumuzda bir sonraki adıma geçip okuma işlemlerinin de yeni servisten gelmesinin sağlanmasıydı. Bu arada çalışan sistem aslında şöyleydi gene veri 2 farklı databasede olması gerektiği gibi kayıt ediliyor ama monolith kısmı artık paralelde herhangi bir sıkıntıda dönebileceğimiz bir koruma alanı yaratıyordu. Bir süre sistemi izledikten sonra yeni servis tamamen bütün işleri devraldı ve eski monolith yapıdan kurtulduk. Böylece anlık gelen yük artık yorgun olan monolith’e değilde daha dinamik ve hızlı olan servisimize gidiyordu.
Bu işlemler yapılırken en çok karşılaştığımız hataları da şuraya bırakmak istiyorum.
- Yeni servise çok fazla gitmek ve arada geçen zamanın normal uygulamamızı çok fazla etkileyemeye başlaması: Yeni servislerin kendi içerisinde lazım olan bilgileri tutması oldukça önemli. Bu bilgiler için sürekli git gelin olması çoğu zaman bir mikroservis için en çok zamanın harcandığı yer oluyor. Unutmayın ne kadar çok network işin içine girerse sistem o kadar yavaşlayacak ve kayıplara sebebiyet verecektir.
- Circuit breaker pattern’nin verimli kullanılmaması: Mikroservisimiz isteklerimize beklediğimizden geç istek vermeye başlaması bizim normal akışlarımızı etkilememesi gerekiyor. Örneğin yaptığımız beğeni servisi geç cevap verdiği durumda ürün satın alınmasını engelleyen bir durumun oluşmasını istemeyiz. Ürünün beğeni sayısı tam ve doğru gözükmese bile diğer ana işlemlerin devam edebiliyor olması oldukça önemlidir.
- Üzerinde çok fazla yük olan sistemlerde cache yapıları önemli rol oynamaktadır. Kullandığımız database türüne ve attığımız sorguların sıklığına göre (elimizdeki verileri kullanarak) cache işlemini göz ardı etmemeliyiz.
Özetle bir servis ayırmaya karar vermeden önce elinizdeki datanın gücünü kullanıp. Kendi iş planınıza uygun ve her zaman hata yapabileceğinizin bilincinde olarak adımlarımızı atmalıyız. Sağlıcakla kalın =)
