HangiKredi’nin Microservice Yolculuğu — 1

HangiKredi Ne İş Yapar?

HangiKredi kredi, kredi kartı, mevduat ürünleri ve internet tarifeleri karşılaştırması yapan(şimdilik :)) bir web sitesidir. Mimari açıdan monolithic uygulama olarak tasarlanmış .Net Framework 4.5, ASP.Net MVC, PostreSQL, Redis, ELK, Jenkins gibi framework ve araçlarla donatılmıştı. Günden güne artan kullanıcı sayısı artık HangiKredi ile ilgili ciddi kararlar almamıza neden oldu.

Sonuç: Uygulamayı yeniden yazalım!

Production ortamında yer alan bir uygulamayı yeniden yazmak her yazılımcının hayalidir. Bu hayali gerçekleştirmek için Eylül 2019 tarihinde HangiKredi ailesine katıldım. Bu büyük aileye katıldıktan sonra bizim için hangi mimarinin daha uygun olduğunu ekip içerisinde tartışmaya başladık. Uzun tartışmalar sonucunda microservice mimarisinde karar kıldık. Peki nedir bu microservice mimarisi? Microservice mimarisi ile hayatımızda neler değişecekti?

Microservice Mimarisi Nedir?

Adından anlaşılacağı üzere servisler mikro seviyelerde parçalanarak her servisin kendi işini yapması ve diğer servisler ile bağlantısı olmayan uygulamalardır.

Microservice Mimarisi Nasıl Olmalı ve Avantajları Nelerdir?

• Herhangi bir servis kendi başına çalışabilmeli,
• Herhangi bir servis diğer bir servis ile iletişime geçmemeli,
• Herhangi bir servisteki hata durumu diğer servisleri etkilememeli,
• Herhangi bir servis bağımsız bir şekilde deploy edilebilmeli,
• Herhangi bir servis yoğunluğa göre ölçeklenebilmeli ve genişlemeli,
• Servisler ayrı ayrı uygulamalar olduğu için istenilen yazılım dilinde ve istenilen teknolojiler ile yazılabilmelidir.

Genel olarak microservice mimarisinin nasıl olması gerektiğini ve avantajlarını bu maddeler altında toplayabiliriz.

HangiKredi’de Microservice Mimarisini Nasıl Uygulamaya Başladık?

Microservice mimarisini uygulamak için öncelikle kendimize bir kurban seçmemiz gerekiyordu. Bu kurban anasayfaydı :). Anasayfayı microservice mimarisine geçirip böylece microservice yolculuğumuzu başlatacaktık.

İlk olarak domainlerimizi çıkartmaya başladık. Bu domainlerimizde ortak kullanılacak nuget paketler yayınlamaya başladık.

Nuget Packages

• Logging Package: Servislerin oluşturacağı logları basmak için bir nuget paket geliştirdik. Logların basılması, monitör edilmesi için ELK tercih ettik.
• Cache Package: Store tarafına vereceğimiz dataların servislerde cachelenmesi için bir nuget paket geliştirdik. Object cache için Redis tercih ettik.
• Queue Package: Servislerin birbiri ile konuşması yasak olduğu için bir service bus konumlandırmamız gerekiyordu. Bunun için bir nuget paket yayınladık. Service bus için RabbitMQ tercih ettik.
• MongoDB Package: Servislerde MongoDB’yi rahatça implemente etmek için bir nuget paket yayınladık.
• Configuration Package: Servislerin kendine özgü ayarlarını almak için bir nuget paket yayınladık.

Microservice APIs

Çıkarttığımız domainlere göre microserviceler ayağa kaldırmaya başladık. Tabiki bu microserviceler için bir standart belirledik. Bu standartlara göre boilerplate API yayınladık. Sadece Anasayfa için 10 tane microservice ayağa kaldırdık. Tüm microserviceleri .Net Core ile geliştirdik. Tüm servislerimiz için ayrı databaseler oluşturduk. Kimi servis PostreSQL kullanırken, kimi servis MongoDB, kimi serviste ise ikisini de kullanmaya başladık.

• İhtiyaç Kredisi Mikroservisi (ConsumerLoan API)
• Konut Kredisi Mikroservisi (HousingLoan API)
• KOBİ Kredisi Mikroservisi (SMELoan API)
• Taşıt Kredisi Mikroservisi (VehicleLoan API)
• Mevduat Mikroservisi (Deposit API)
• Müşteri Mikroservisi (Customer API)
• İçerik Mikroservisi (Content API)
• Sabit Değerler Mikroservisi (Lookup API)
• Kampanya Mikroservisi (Campaign API)
• Ayar Mikroservisi (Configuration API)

İki tane ayrı mimari olmasının en büyük sorunlarından birisi, veritabanındaki dataların her iki sistemin de çalışmasını garantilemek için sürekli eşlenik durumda olma zorunluluğudur. Database lerin senkron olması için birçok Data.Sync uygulaması yazdık.

Gateway

Ayağa kaldırmış olduğumuz microserviceleri storefront katmanına göndermeden önce datayı aggregate etmek için bir gateway’e ihtiyacımız vardı. Burada Ocelot Gateway’inden yararlandık. Open Source olan bu gatewayi alıp kendimize göre özelleştirdik.

StoreFront Katmanı(User Interface)

Backend tarafında bu kadar değişiklik yaparken frontend tarafında değişiklik yapmamak ayıp olurdu :) StoreFront(User Interface) katmanımızı da bu vesile ile sıfırdan yazmak istiyorduk.

Monolithic uygulamamızdan ayrı bir StoreFront uygulaması ayağa kaldırdık. Bu uygulamanın geliştirmelerini yine .Net Core ile yaptık. HangiKredi için search engine optimization (seo) çok kritik olmasından dolayı herhangi bir javascript frameworku entegre etmedik. Pure javascript ile ilerledik. Ayrıca geliştirdiğimiz modülleri component mantığında yazarak ileride herhangi bir javascript frameworkune rahatlıkla geçebilecek esneklikte bir altyapı oluşturduk.

Peki iki tane storefront uygulaması oluşturduk ama trafiği burada nasıl yöneteceğiz? Bunun için reverse proxy teknolojileri araştırmasını yaptık. Nginx, Varnish gibi teknolojilerin artılarını eksilerini araştırdık. Varnish ile ilerlemeye karar verdik. Gelen requestin url’ine göre ayrım yaparak mevcut uygulamaya ya da yeni uygulamaya trafiği yönlendirmeye başladık.

Artık uçtan uca geliştirmelerimizi tamamladık sıra test adımlarımıza geldik. Testlerimizi dört ana başlığa ayırarak testlerimizi yapmaya başladık.

• Fonksiyonel Testler
• Sistem Testleri
• Yük Testleri
• 3rd Party Testler

Anasayfanın Deploy Edilmesi

Testlerimizi de tamamladıktan sonra uygulamamızı production öncesi DevOps süreçlerine giriş yaptık. Üç tane microservice makinesi, iki tane storefront makinesi ve bir tane de gateway makinesi oluşturduk. Tüm makinelere işletim sistemi olarak Centos kurduk. Böylece Linux dünyasına giriş yapmış olduk. Ayrıca işletim sistemlerinin üzerine kaynağı daha efektif kullanabilmek için Docker kurduk. Tüm uygulamalarımızı Jenkins ile deploy ettik. Sonrasında Varnish tarafında ayarlarımızı yaptık. Anasayfa trafiğini yeni uygulamamıza yönlendirmeye başlamış olduk.

Sonuç

Trafiği yönlendirmeye başladıktan sonra karşılaştırma yapmak için bazı değerleri kontrol ettik. Bunlardan bazıları;

• Lighthouse verilerinin karşılaştırmasını yaptık. Geçiş öncesinde mobile pagespeed değerimiz 40 puan civarında iken geçiş sonrasında bunu 75 puana, desktopta ise pagespeed değerini ise 80 puandan 99 puana çıkarttık.
• Bizim için en kritik verilerden olan sayfa yüklenme süresini(page load time) ise 4 saniye civarından 1 saniye altına çektik. Burada %75lik bir kazancımız oldu.
• Yük testinde kapasitemizi görmüştük. Bunu production ortamında da simile etmek istedik. Çeşitli kanallardan anasayfaya trafik getirdik. Aynı anda anasayfa yaklaşık olarak 7bin kullanıcı gördük. Sunucularımızın ve uygulamalarımızın değerlerini kontrol ettiğimizde ise kaynak tüketimin çok düşük seviyelerde olduğunu gördük.

Bir microservise macerası böylece başlamış oldu. HangiKredi’nin diğer microservice maceralarında görüşmek üzere!