SAGA mikroservis uygulaması - 6

Bu yazıda önceki yazılarda tasarlayıp kodladığımız mikroservis mimarisini çalışır hale getireceğiz. Bunun için tek tek uygulamaları ayağa kaldırmak yerine sistemi anlayıp basit bir run konfigürasyonu hazırlayacağız. Ayrıca projenin gerekliliklerinden ve github 'da nasıl hazırlandığından da bahsedeceğim. Konunun havada kalmaması için büyük resmimiz yine burada dursun.

Minimum gereksinimler

Bu mikroservisi ayağa kaldırmak için olmazsa olmaz bazı gereksinimler var. Önceki yazılardan birinde 2 yıllık junior developer kadar bilgi birikimi gerektirdiğini belirtmiştim. Bu konuda yeni iseniz sorunlarla uğraşarak ve kodları inceleyerek sistemi ayağa kaldırmaya çalışmanızı tavsiye ediyorum. Yemek tarifi modunda gereksinimleri yazayım:

• Bilgisayarınızda JDK 11 kurulu olması
• Maven binary dağıtımının hazır olması ve M2 home gibi değişkenlerin set edilmiş olması
• Spring boot projesi açabilecek ve maven ayarları yapılmış bir IDE (Eclipse, IntelliJ)
• MySql kurulu ve server 'da bir şemanın hazır olması
• Minimum 5 - 6, ideal sistem için 9 - 10 gb kadar boş ram alanı tavsiye edilir :)

Ram konusunda bazı JVM ayarları ile belki sınırlamalar veya düzenlemeler yapılabilir sonuçta tomcat sunucuları tek tek ayağa kalkıyor. Fakat o konuya detaylı girmedim. Ayrıca bütün servisleri tek bir tomcat üzerinde çalıştırmak sanırım mümkün. starter-web bağımlılıkları altında exclusion yazarak spring-boot-starter-tomcat 'i exclude edebiliyorsunuz. Fakat bu durumda projelerin Jar yerine War dosyası oluşturması ideal olacaktır. Bu dosyaların da ortak bir Tomcat deployment klasörüne atılmasını sağlamanız gerekecek Maven ile. Bu konularda CI/CD çözümleri olduğu için üzerine düşmedim. Maven demişken...

Maven

Maven bir derleme aracıdır. Kodlarımızı alıp Javac ile compile edip belli bir klasöre Jar veya War dosyası halinde atar. Spring initializr 'dan oluşturduğumuz bütün projeler otomatik olarak maven projesi şeklinde oluşur. Tabi gradle seçeneği de var ama bi maven kullandık. Bu maven altyapısı sayesinde uygulama POM dosyasında belirtilen bağımlılıkları otomatik olarak getirir ve derler. Bunun dışında maven projelerinin "module" yapısı ile tasarlanması mümkün. Bir top level maven manifestosu hazırlayıp onun altında maven module 'leri şeklinde maven projeleri ekleyebiliyorsunuz. Fakat bu yaklaşımda bütün servisler aynı pom yapısını yani manifestoyu kullanmak zorunda kalır ve bu da gereksiz olurdu. Bu yüzden her proje kendi başına bir maven projesi olarak tasarlandı.

Git

Git bizim yazdığımız kodları takip eden ve ortak repository 'de birden fazla kişi tarafından geliştirme yapılmasına yardımcı olan araçtır. Bütün projeler github 'da aynı proje içerisine yerleştirildi. Bu sayde indirdiğiniz proje aslında bir workspace gibi davranabiliyor ve servislerin kodlarını ayrı ayrı indirmek zorunda kalmıyorsunuz. Aynı zamanda push işleminde isterseniz top level projeyi isterseniz ayrı ayrı projeleri commit ederek kod gönderme imkanınız da oluyor. Bunu sağlamak için bir git repository 'si oluşturup import ettim. Sonra içine diğer proje kodlarımı kopyala yapıştır ile ekledim. Üşengeç olduğum için işi kolaylaştırır diye düşündüm :)

Github 'da ayrıca config server tarafından bağlanılmak üzere konfigürasyonları tuttuğumuz bir private repository olması gerekiyor. Config server bizim servislerimize gerekli ayar dosyalarını github 'dan alıp iletiyordu. Buradaki dosya isimleri de servislerin isimleri ile (application.name-<profile>) uyumlu olmak zorunda. Private olduğu için benimkini indiremeyeceksiniz fakat bu dosyalarda gerekli ayarları önceki yazılarda belirtmiştim. Dilerseniz buradan repository kodlarını indirip kendi reponuza atabilirsiniz.

Import

Projelerin hepsi maven projesi olduğu için github 'dan indirildiğinde rahatlıkla import edebilirsiniz. Elinizde import edeceğiniz 11 adet proje var. Eclipse ile "Import -> Existing Maven Project" işlemi ile import edebilirsiniz.

MySql

MySql bir veritabanı teknolojisi ve sunucusudur. Projelerin ayağa kalkması için MySql gerekliliği bulunuyor. Çünkü 3 servisin (userservice, activityservice ve paymentservice) JPA ve MySql bağımlılığı bulunuyor. JPA bağımlılığı olduğu için veritabanı bağlantı property 'leri olmadan ve bu veritabanına bağlanmadan çalışmayacaktır. Gerekli veritabanı ayarlarını github 'daki private repository 'den alabilirsiniz.

Tek tuşla run

Gelelim işin en masraflı kısmına :) Toplamda 11 tane spring projesi ve ayrı tomcat 'ler ayağa kaldırmış olacaksınız. Ben kendi bilgisayarımda söylemesi ayıp 32 gm ram olduğu için sorun yaşamadım fakat bu sistem ayağa kalktığında Eclipse dahil 9 - 10 gb kadar ram kapayabiliyor. Bütün projeler (ab-util hariç) spring boot starter web ile gelen TOMCAT sunucusunda web uygulaması olarak çalışıyor çünkü. Projeleri import ettiğinizde aşağıdaki gibi bir ekran görüntüsü oluşması gerekiyor.

Sol altta görüğünüz eclipse ile gelen spring boot dashboard. Burada spring boot projelerini run, restart, debug ve stop işlemlerini yapabiliyorsunuz. Ama öncelikle bütün projeleri 1 kere üstteki proje listesinde sağ tıklayıp "run as -> spring boot application" ile çalıştırmalısınız. Eureka -> Config Server -> Gateway ve diğerleri şeklinde başlatabilirsiniz. Eureka 'nın önce ayağa kalkması servislerin ayağa kalkarken ona bağlanabilmesi için şart. Config server 'da eureka 'ya kendini kaydettiği için hemen sonrasında geliyor. Diğerleri de ayarlarını config server 'dan alabilsin diye config server ayağa kalktıktan sonra başlatılıyor. Minik servislerimizi birden fazla kere ayağa kaldırmak isterseniz sol alttaki dashboard 'dan yapamıyorsunuz. Projeyi 2 kere run as -> spring boot application yapmanız gerekiyor. Bu da benim gibi üşengeç birisi için tabi ki işkence :)

Bütün sistemi ayağa tek bir komutla kaldırmak için bir launch group oluşturabiliyoruz. Bu sayede eclipse 'de run as yaptığımız bütün işlemleri (1 kere yapmıştık) sıraya koyabiliyoruz. Konfigürasyonu aşağıdaki gibi tanımlayacağız.

Sol tarafta launch group içerisinde new launch configuration oluşturuyoruz. Sonra aşağıda gördüğümüz spring boot run işlemlerini her proje için sırası ile ekliyoruz. Fakat Eureka ayağa kalkmadan Config Server ayağa kalkmamalı. Aynı şekilde diğerleri de Config Server 'ı beklemeli. Bunun için konsolda bir ifade yazılana kadar bekletiyoruz. Bu ayarı post launch action ile tanımlıyoruz. Yani launch başlatıldıktan sonra ne yapacak şeklinde. Çünkü run işleminin sonucu beklenmiyor örneğin maven install gibi. Bu ayarı yapabilmek için de aşağıdaki gibi edit ekranına girebilirsiniz.

Buradaki reqular expression 'ı kendinize göre belirleyebilirsiniz. Ben uygulama ayağa kalkınca main sınıfını application olarak yazdırdığı için isimle kontrol ettirebildim. ".*Started AldimbiletEurekaApplication.*" yazdığımda konsolda bir yerde "Started AldimbiletEurekaApplication" geçiyorsa run işlemi bitmiş oluyor. Config server için de benzer şekilde ".*Started AldimbiletConfigApplication.*" yazarak diğer işlemleri beklemeye alabiliyorum. Bu ikisi ayağa kalkınca Gateway hariç istediğiniz servisi birden fazla kere ayağa kaldırabilirsiniz. Bunu yapmak için run listesine 2 kere eklemeniz yeterli olacaktır. 2 kere run as -> spring boot application işlemini gerçekleştirecektir. Bu şekilde konfigürasyonu tamamladığınızda eureka konsolunda aşağıdaki görüntüyü elde edebilirsiniz.

Bu sayede eclipse ile tek bir run as işlemi ile bütün servisleriniz ve MVC uygulamanız ayağa kalkabiliyor. MVC uygulamanız localhost:80 'de çalışabiliyor. Başta belirttiğim gibi failover 'lar dahil bütün servisleriniz ayağa kalkarsa 9 - 10 GB kadar ram kaplıyor.

Run mikroservis run

Böylece mikroservis kodlama maceramız http://localhost adresinde son bulmuş oluyor :) Bu noktaya kadar takip ederek mikroservisi ayağa kaldırdıysanız iyisi ile kötüsü ile elinizle yazdığınız bir mikroservis uygulamanız olmuş oluyor. Bu süreçte kendi karşılaştığım sorunlardan ve olası sıkıntılardan da bahsettim ve "bu kodu böyle yazıyoruz" yaklaşımından kaçınmaya çalıştım. Böylece umarım çalışan bir uygulamanız ve bu uygulamayı değiştirebilecek bilgi birikimiz de oluşmuştur.

Serinin son yazısında alternatif teknolojilere ve ne yapılabilirdi, ne yaptık veya doğru yaptık mı gibi sorulara kafa yoracağız. İlk yazıda belirtmiştim, mikroservisler konusunda tek bir genel geçer doğrumuz yok. Alternatiflerimiz ve ödünleşimlerimiz var. Sonunda benim projem hakkında "böyle mikroservis mi olur" yorumu da getirebilirsiniz. Ama bir sonraki yazıda kendimi savunmama izin verin :)