Mikroservis Yaklaşımı
Last updated
Was this helpful?
Last updated
Was this helpful?
Küçük, bağımsız, otonom, diğer mikroservislerle sıkı sıkıya bağımlılığı bulunmayan, tek başına çalışabilen, kendine ait veri tabanı olan, geliştirme sürecinden kuruluma kadar bağımsız olan, yatayda ve dikeyde kendi başına ölçeklenebilen uygulamalara denir.
Martin Fowler, 2013 yılında bir makale ile tanımladığı mimaridir. SOA mimarisinin kurumsallığına farklı bir bakış açısı getirip daha tanecikli, bağımlılıkları azaltan bir mimari kurgulamıştır.
While Microservice is a useful architecture - many, indeed most, situations would do better with a monolith.
Mr Fowler da dediği gibi mikroservisler kullanışlı olsa da bir çok hatta epey çok senaryoda monolitik çözüm daha iyi olacağını belirtiyor.
Don’t start with a monolith when your goal is a microservices architecture
Tubitak BİLGEM YTE tarafından Ocak 2020 de gerçekleştirilen Mikroservis etkinliğinde konunun detaylarına yönelik bilgiler bulabilirsiniz. Anahtar kelimeleri yakalayarak internette araştırdığınız daha geniş bilgiler elde edebilirsiniz. Sunumları da sitelerinde paylaşıyorlar.
Mikroservis mimariler de yapılan iş/işlemler belirten transaction için 2 temel tasarım kalıbı yöntemlerini (Two-Phase Commit ve Saga) anlatan yazılar.
Güzel bir konu başlığı : f(f(f(f(f(f(f(f(f...(f(x)...))))))))) = f(x)
CAP Teoremi, ACID Prensipleri,
Mikroservis mimarisinde geliştirme yapma sürecimizi hızlandırmak için framework kullanmamız gerekir. Böylece hedefimiz olan uygulamamızı geliştirmeye odaklanabiliriz. Python dili için Django framework veya Flask, Java için JSP (Java Server Pages, Servlet kullanır) veya Servlet, Spring Framework veya Spring Boot, C# dili için .NET Core platformları tercih edilebilir. Tabii seçenekler bu kadarla sınırlı değildir. İnternette ayrıntılı bilgiler ve karşılaştırmalar bulabilirsiniz.
Scale Up (Dikey Ölçekleme), server donanım kaynaklarınızı arttırmak. Örneğin CPU çekirdek sayısı arttırımı, RAM arttırımı gibi.
Scale Out (Yatay Ölçekleme), sisteminize yeni serverlar eklemek.
Kodunuz mevcut kaynaklara göre kendini scale edebilir.
Array içerisinde arama işleminde seçilen algoritma bile önemlidir. Adım adım, sequential yani O(n) adım olur. Scale etmez. Daha büyük arrayler de binary Search kullanırsın. Daha hızlı olabilir. Hep ortaya bakarak bir eleman aranır. Ama verin sort edilmesi de gerekirse? Veri eklenirken mi yoksa okunurken mi zaman kaybedilmeli? Okumayı mı yoksa Yazmayı mı scale edeceksiniz. Okuma daha fazla gerçekleşiyorsa Binary ve Sorted array olması tercih edebilirsiniz.
Array mi Collection mi kullanmak?
Array ler sabit boyutlu ama collection lar kendini kopyalayarak büyüyebilirler. Başlangıçta 100 eleman ile açılırlarken 100 eleman dolunca 200 elemanlı açar ve kendi eskisini içine kopyalar.
Mikroservis Ortamında Scale Etme
Servisleriniz cache tutuyorsa scale edilebiliniyor mu?
Load balancer bir önceki cookie ile hangi servera gittiklerini bilirler. Bunu siz yapmalısınız Kubernetes yapmaz. Servisiniz request based cache tutuyorsa ve bir önceki requestin nereye gittiğini tutmuyorsanız cache bağımlılığınız veya session bilgilerine bağımlılığınız uygulamanızı scale olmasına engel olacak.
Servislerde cache/session bilgisi tutmuyorum gelen gidiyor şeklinde tasarım yaparsak ama gene de bir yerde cache yapacağız. Mesela Redis ile başka bir yerde tutabiliriz. Bu tür tasarımlarda bottleneck (sıkışma) olacaktır. Tasarımlarınızda bunu nereye koyacağınızı düşünmek zorunda kalacaksınızdır. Redis de sıkışma olacak çok sıkışmasın diye başka Redis ler de koyacaksınız.
Çok fazla thread yaparsanız çok fazla context switch yaparsınız. O nedenle thread spin etmeyi tercih edersiniz.
Veri tabanı nasıl scale ederiz?
Okumayı önemsiyorsanız, Balanced Red tree, Red Black Tree (indexing) kullanarak veri tabanlarını daha iyi scale edebilirsiniz. İndexleyince yeni veri eklendikçe indekslerin güncellenmesi de yazma yükü getirecektir.
Mikroservislere geçildiğinde aşağıdaki konular üzerinde de çalışma yapılması gerekir.
Service Discovery
State Management
Service Lifecycle Management
Health Reporting
Resource Usage Reporting
Stateless Services
Database' ler gibi harici depolama biriminde kalıcı olarak state saklayarak
Mevcuttaki web ve worker role uygulamalar
Stateful Services
Replikalar ve local persistence üzerinden state güvenirliğinin sağlanması
Algoritmanın kompleksliğinin azaltılması
Sistemin izlenebilirliği de önemli bir konu olduğundan aşağıdaki mimarileri incelemekte fayda var.
"Clientlardan topladıkları logları elkstack sunucumuza yollamakla yükümlü aracımız Beats , toplanan bu logları bir sunucu içinde derleyip üzerinde yapılması gereken bir dönüştürme ve anlam kazandırma işlemini gerçekleştiren aracımız Logstash ,bu logları indexlendirerek aranabilir ve analiz edilebilir hale dönüştüren aracımız Elasticsearch ve tüm bu yapılan detaylı çalışmayı bizlere görselleştiren aracımız Kibana olarak karşımıza çıkmaktadır." şeklinde güzelce özetleyen aşağıdaki yazıyı incelemeniz faydalı olacaktır.
Sistemimize dışardan erişen client' ların yapımıza tek noktadan erişmesini sağlayan ve arkadaki karmaşık mimariyi bilmesini gerektirmeyen çok kullanılan servislerdendir. Mikroservisler arasında haberleşmeyi, servislerden toplanan bilgilerin bir araya getirilerek (aggregator) sunumlaştırılması gibi temel işlemlerin yaptırılması için kullanılmaktadır. Ayrıca servislerimize ulaşılabilmesi için api gateway üzerinden authentication (Kimlik Doğrulama) ve authorizationunu (Yetkilendirme) yaparak tek bir noktadan güvenlik kontrolleri yapılmış olunur. Ayrıca, service discovery özelliği sayesinde mikroservislerin lokasyonlarının IP bilgileri vs tespit edilmesini sağlar. Böylece servislerin nerede deploy edildiğinin bir önemi kalmamaktadır.
Konuyla ilgili daha ayrıntı bilgiler için aşağıdaki yazılardan faydalanabilirsiniz.
Kısa ve öz güzel başka konulara da değinen alttaki link ve diğer yazılarını da göz gezdirmeniz faydalı olabilir.
Innoq kurucularından da aşağıdaki gibi bir kelamda bulunmuş
