nedir?

• Bir tür mimari yazılım stilidir.
• Monolitik uygulamalara alternatif olarak tasarlanmıştır.
• Microservisler tek bir uygulama olarak geliştirilen sistemi bir biri ile iletişim halinde olan ve bağımsız olarak çalışabilen küçük servislere ayırmayı hedeflemektedr. Çalışma şekiller aşağıdaki gibidir;
• • Bir uygulama oluşturmak için yazılan küçük servislerdir
• • Her servis birbirinden bağımsız olarak çalışabilmektedir.
• • Http / rest veya message yolu ile açılan protocoller sayesinde birbiri ile konuşabilmektedir
• • Birbirinden bağımsız bir şekilde farklı dillerde de (java, .net) geliştirilebilir, deploy edilebilir veya maintain edilebilir.
• • Business işlemlerini servisler kapsamaktadır. Monolitic de olduğu gibi class veya packageler kapsamaz.
• • Servisler bağımsız bir şekilde upgrade edilebilir.
• Bütün sistem akışının tek bir hatadan tamamen etkilenmesini kısmen önlemek.
• Monolith uygulamalarda yaşanan hatalarda uygulamanın tamamen cevap vermemesi, network split'ler veya efektif olarak resourceların kullanılamaması sorunlarına çözüm olarak microservis mimarileri geliştirilmiştir.
• Uygulamaları daha dayanıklı ve esnek (Resilience) yapmaktadır.

ne değildir?

• SOA gibi değillerdir. SOA birçok enterprise application arasındaki entegrasyonu sağlarken. Microservisler tek bir uygulamanın ayrıştırılmasını sağlar.
• Microservisler risk ve sakıncalara sahip değildir.

current trend

• Twitter moved from Ruby/Ruils monolith to microservices
• Facebook moved from php to microservices
• Netflix moved from java to microservices

Monolithic avantajları?

• Kavraması kolaydır fakat hazmetmesi kolay değildir.
• Belirli bir ölçüye kadar test etmesi kolaydır
• Deploy etmesi kolaydır.
• Belirli bir ölçüye kadar manage etmesi kolaydır.
• Belirli bir ölçüde değişiklikleri yönetmek kolaydır.
• Complexity dil yapısı sayesinde yönetilebilir.

Monolithic dezavantajları?

• Language ve Framework bağımlı durumda bırakır. Gelişmekte olan teknolojileri kullanmaya fırsat tanımaz.
• Bir developer büyük bir kod bloğunu sindirmesi zordur.
• Tek bir takım çok büyük bir uygulamayı yönetmesi zordur.
• Tek bir yerde yapılan değişiklik için tüm uygulamayı deploy etmek zorunda bırakır.
• Yapılan değişiklikler diğer yapılan değişikliklerden dolayı "held-hostage" rehin bölgesinde tutulur.

Microservice

• Küçük servisler kullanılarak oluşturulur.
• Tek bir kod tabanından oluşmaz Monolith gibi değildir.
• Tek bir dil veya framework den oluşmak zorunda değildir.
• Modülleştirilmesi tek bir dil veya frameework'e bağımlı değildir.
• servisler lightweight protocoller kullanılarak iletişim sağlar
• • HTTP, TCP, UDP, Messaging, etc.
• • payloads: Json, Bson, xml, protocol buffers, etc.
• • Net interface tasarımlarını zorunlu kılar.
• Servisleri business kabiliyetlerini kapsamaktadır.
• Yönetmesi kolaydır
• • Anlaması, test etmesi version alması, deploy etmesi kolaydır.
• doğru araç, dil ve framework kullanımına olanak sağlar.
• farklı hız ve ihtiyaçlara göre servisler ayrılabilir.
• Servisler orkestra edilmez, karografi oluşturur (trafikteki araçlar gibi değildir, trafik ışıklarına göre hareket etmezler. Yol üzerindeki yayalar gibi hareket ederler)
• Genişletilmesi kolaydır.

Microservice dezavantajları

• operasyon tarafında karışıklık artar
• Servisler hata verip çalışmayabilirler. Circuit breakers ler kullanılır bunun için.
• Daha fazla monitor edilmeye ihtiyaç duyulur..
• Dışardan servis çağırmak process method çağırmaktan daha maliyetlidir.

Microservis kullanımında üstesinden gelinmesi gerekenler

• Transaction larda ACID (atomicity, consistency, isolation, durability) sağlanmak zorundadır.
• Özellikleri birden fazla servisten oluşabilir.
• Serviste değişiklik yapılması üstesinden gelinmesi gereken farklı durumları ortaya çıkartır.
• • Servis ilişkileri dikkate alınması gerekmektedir.
• • yönetim ve version bağımlılığı dikkate alınmalıdır.
• Module sınırları yeniden düzenlenmelidir.

Microservis yapısı nasıl olmalı

• Yazılımcı için özet olabilecek kadar küçük olmalıdır.
• Küçük bir takım için build edilebilecek ve yönetilebilecek kadar küçük olmalıdır. (Amazon two pizza rule)
• Dokümanlar okunabilecek ve anlaşılabilecek kadar küçük olmalı
• Sınırlı sayıda belirsiz secret key olmalıdır.
• Öngörülebilir ve deneyimlenebilir olmalıdır.

Monolith Microservis olarak nasıl ayrıştırılabilir

• Business fonksiyonlar dikkate alınmalıdır
• • Noun-based (catalog, cart, customer)
• • Verb-based (search, checkout, shipping)
• • Single responsibility principle
• • Bounded Context

Terimler?

Retry Mechanism:

• Uygulamada transient problemler olduğunda tekrar mekanizmasının kurulması ile 2 veya 3 kere işlem tekrarına sokarak başarılı sonuç alınmasını sağlamaktır.
• web kaynaklı bir transient hata meydana gelirse işlem 5'er saniye ile 3 kez tekrarlanır.

Circuit Breaker:

uygulamaların birbirleri ile veya remote servislerle iş birliğinde iken network splits, timeouts veya aşırı yüklenmesi gidi durumlardan kaynaklanan transient hatalarına bir süre sonra dur demek için kullanılır.

• Close: circuit breaker kapalıdır ve tüm requestler başarıyla gerçekleşmektedir.
• Open: circuit breaker açılmıştır ve başarısız gerçekleşen requestleri kendisine set edilen süre kadar kesmiştir.
• Half-Open: circuit breaker hatanın hala devam edip etmediğini anlayabilmek için bir kaç requestin gerçekleşmesine izin vermektedir. Eğer hata sona erdi ise modu'nu close, devam ediyor ise open moduna alır.

Fallback :

• Bir backup stratejisi diyebiliriz.
• Uygulamanın retry mekanizmalarına girmesine rağmen hala hata almaya devam ediyorsa Fallback mekanizması tanımlanması gerekmektedir.

Uygulama