Merhaba,
Bugünkü yazımda Mikroservis mimarisine giriş yapıp, python yazılım dili özelinde bazı incelemeler yapmaya çalışacağım.
Mikroservis mimarisine geçmeden önce Monolitik uygulama mimarisine bakmakta fayda görüyorum.
Fakat uygulama büyürse ve codebase e yeni özellikler eklemek gerekirse ne olacak?
Projenin yönetimi ile ilgili çeşitli zorluklar baş gösterecektir. Ayrıca projede hızlı bir büyüme ve çeşitlenme ölçeklenebilirlikle ilgili sıkıntıları ortaya çıkaracaktır. Codebase çok büyürse farklı codebaselere bölünerek farklı takımlar halinde ilerlemek ve kurulum aşamasında codebaselerin birleştirilmesi gibi bir çözüm düşünülebilir fakat buda ekstra efor ve iş yükü anlamına gelecektir.
- Monolitik yapıdaki en büyük sıkıntılardan biri ise uygulama çok büyüdüğünde bir hata keşfedilirse, hatanın düzeltilmesi, etki analizi ve testlerinin yapılması sıkıntılara neden olacaktır. Küçük bir bug tespitinde bile kapsamlı testler yapılması ve tüm uygulamanın tekrar dağıtılması gerekecektir.
- Her güncelleme uygulamanın bütünüyle tekrar deploy edilmesine sebep olur. Küçük değişikliklerde bile kapsamlı regresyon testi gerekir.
- Monolitik yapılarda genellikle tek bir dil kullanıldığı için çözüm ve modülerite gereken noktalarda o dile bağımlı durumda kalırsınız.
- Bu yapıda çok büyüyen projelerde yeni dahil olan mühendislerin uygulamaya hakim olma süreci de uzayacaktır.
- Monolitik mimaride geliştirilmiş bir uygulamanın herhangi bir bileşeni kullanıcılar tarafından çok yük ile karşı karşıya bırakılırsa performansı arttırmak için yazılımın sadece bu bileşenini ayırıp ikinci sunucuya koymamız mümkün değildir. Bu anlamda bir performans artışı için tüm yazılımı ikinci sunucuya kurmak gerekecektir. Fakat ikinci sunucuya diğer tüm bileşenleri de tekrar kurmuş olacaksınız. Bu da kaynakların verimsiz tüketilmesine de sebep olacaktır.
- Herhangi bir modüldeki hata tüm sistemi etkileyecektir.
- Yeni teknolojileri alıp kullanma konusunda birtakım bariyerlere sahiptir. Çünkü kullanılan dil ve frameworkteki değişiklikler tüm uygulamayı etkilemektedir. Yeni bir teknolojiyi bir bileşende entegre etmeye çalışmak, işi tüm uygulamayı yeniden yazmaya kadar götürebilir.
Mikroservis mimarisinde ise "Böl ve Yönet" sloganını aklımıza getirebiliriz. Küçük ve birbirinden bağımsız çalışabilen ama gerektiğinde birbiri ile konuşabilen uygulamalardan oluşan bu mimari, genişlemeye ve yatay büyümeye oldukça açıktır. Büyümeye açık olması çok iyi bir dizaynı da gerekli kılar. Yapılacak dizayn anlaşılabilir, yönetilebilir ve uzun vadede bu yönetilebilirliğini koruyabilmelidir.
- Bu mimaride problemlerin kök kaynağı ve etki ettikleri noktalar hızlıca tespit edilebilir ve daha hızlı müdahale edilerek yeni geliştirme gereken durumlarda daha hızlı deploy sağlanabilir.
- Sistemin daha yönetilebilir alt parçalar olan servislere ayırmak karmaşıklık probleminin üstesinden gelmemizi sağlar.
- Farklı mikroservisler için farklı yazılım dilleri rahatlıkla kullanılabilir. Servisi kullanacak taraflar için servisin geliştirildiği yazılım dili önemli değildir. Karşı taraf sadece servisin arayüzünü kullanacaktır. Buda uygulama geliştirmeye büyük bir esneklik ve modülerlik getirir.
- Sisteme yeni bir özellik eklemek çok kolaydır. Yeni eklenen özellik için sistemin tamamının test edilmesine gerek duyulmaz, sadece etki edilen ve birbiri ile konuşan ve bağımlılığı olan mikroservislerin test edilmesi yeterlidir.
- Her bir mikroservisin tek bir işe odaklanmış olması sistem yapısını anlamamızı ve sorun tespitini kolaylaştırır. Ayrıca bu sayede daha performanslı çalışan bir sistem geliştirilmesine olanak sağlar.
- Tek ve büyük bir codebase içine gereken deploy süresi ile kıyaslarsak mikroservislerin bağımsız deploy ediliyor olması büyük avantajdır. Yani yeni bir özellik ekliyorsanız sadece yeni mikroservisi ve gerekiyorsa sadece yeni mikroservis ile konuşacak mikroservisi deploy etmeniz yeterli olacaktır.
- Ekibi tek bir codebase i öğrenecek şekilde yönlendirmek yerine parçalara bölüp her servis ve altındaki mikroservisleri farklı geliştiricilerin yönetmesi sağlanabilir. Buda herkesin yaptığı işte hakimiyetini arttıracaktır. Ayrıca yeni katılan kişi tüm yapı yerine kendisi ile ilgili servisi detaylı öğrenmek zorunda olacağı için adaptasyonu çok hızlı olacaktır. Mühendisler sistemin geneli hakkında bilgi sahibi olmakla birlikte kendilerine atanan mikroservisler konusunda uzman olacaktır.
- Her servis bir takım tarafından diğer takımların seçim ve karar makanizmalarından ve kullanılan dillerden bağımsız olarak geliştirilir. Bir takım X teknolojisini kullanıyorsa diğerleri bunu kullanmak zorunda değildir. Önemli olan son durumda servislerin birbirleri ile, müşteri ike ve veri kaynakları ile konuşabiliyor olmasıdır.
- Önemli noktalardan birisi ise bir mikroserviste bir sorun olduğunda sadece bu mikroservis ve hizmet ettiği mikroservisler etkilenir. Yazılım kalan mikroservisleri çalışmaya devam eder. Örnek vermek gerekirse bir web sitesinde arama işlevini yöneten 3 mikroservisten biri çökebilir ve bu 3 mikroservis etkilenerek arama servisi durabilir. Fakat diğer mikroservisler çalıştığı için web sitesindeki login, alışveriş, analitik, upload, yorumlama... gibi diğer servisleri hizmet vermeye devam ederler. Yani web sitesi %10 kullanılmaz hale gelirken %90 işlevsel kalacaktır.
- Cassandra gibi sistemler ile her mikroservisi ayrı veritabanı yapısı ile çalıştırmanız da mümkündür. Buda veritabanlarında çıkacak sorun yada yapılacak güncellemeler sırasında diğer servislerin etkilenmesini önleyecektir.
Düzgün şekilde dizayn edilen mikroservis mimarisi yatayda ölçeklendirmeye imkan verecektir. Yatayda ölçeklemeden kastımız daha çok makine üzerinde loadbalancing yaparak mikroservisin birden fazla örneğinin çalıştırılmasıdır. Yani dikey ölçekleme yapıp tek bir sunucuda çalıştırıp ölçekleme gerektiğinde makineyi upgrade etmek yerine daha maliyetsiz küçük sistemlerde uygulamayı çalıştırarak yatayda genişlemiş oluyoruz.
- Küçük bir örnek vermek gerekirse. Web sitesinde arama yapan bir bileşen kullanıcılardan çok talep alıyor ve sunucuyu yormaya başladı ise bunu çözmenin iki yolu olacaktır. Ya sunucuyu dikey ölçekleme ile ram cpu yönünden upgrade edeceksiniz yada bir loadbalancer arkasına bu arama bileşenininden mikroservis olarak 5 tane koyarak yatay ölçekleme yapacaksınız. Sanallaştırma ve container teknolojileri ile birlikte yatay ölçekleme maliyetler açısında daha uygun olabilmekle birlikte birtakım risklerin bertaraf edilmesine de fayda sağlayacaktır. Kurulan 5 mikroservis aynı işi yaptığı için bir tanesi çökse bile loadbalancer üzerinde diğer 4 tanesi hizmet vermeye devam edecektir. Yani dikey ölçekleme yaparak, düşerse sistemi durduracak 1 servis ile hizmet vermek yerine, yatayda genişleyerek 5 tane aynı işi yapan servisi koşturarak servisi yedeklemek sureti ile hizmetin durma riskini minimize etmiş olacaksınız. Biryandan da performans sorununuzu çözmüş olacaksınız.
Mikroservisler için spesifik olarak şu sunucuda şu ortamda çalışsın gibi bir zorunluluk bulunmamaktadır. Kubernetes ve Docker teknolojileri ile birlikte bunu kolaylıkla sağlamak mümkündür. Mikroservisler stateless yapıda geliştirilirler. Çalıştıkları diskte veri saklamazlar. Böylece restart edilselerde, başka bir makinede çalıştırılsalarda işlerini yapmaya devam ederler. Verileri dışarıda sakladıkları için statefull servislere oranla daha kolay ölçeklenebilirler.
Son yıllarda gelişen teknolojilere ve taleplere bakıldığında tabiki mikroservis mimarisi daha tercih edilebilir durmaktadır. Ama bu her durumda mikroservis mimarisini tercih etmemiz gerektiği anlamına gelmemektedir. Monolit mimarinin de avantajlı olduğu ve tercih edilmesi gereken projeler de olacaktır. Uygulamanız küçük ve çok fazla iş mantığı içermiyor ise ileriye dönük çok fazla ölçeklenebilirlik gerektirmiyor ise monolitik yapı kullanmak avantajlı olabilir. Karmaşık yapıda mikroservis mimari kuracak bilgi birikimi ve tecrübeniz yoksa aynı zamanda ekibiniz küçük ise yine monolitik mimaride başlamak avantajlı olabilir.
Sıfırdan bir projeyi microservis mimari işe geliştirmek nispeten daha kolay olacaktır. Fakat monolit ağırlıklı yapıda halihazırda çalışan bir yapıyı mikroservis yapısına geçirmek her açıdan maliyetli ve sancılı olabilir. Evet son durumda harika bir yapıya sahip olacaksınız, peki bedel ödemeye hazır mısınız?
Bugün tam performans ile kesintisiz çalışan Netflix firması tamda bahsettiğimize benzer bir bedel ödemişe benziyor. 2008 yılında 3 gün civarında hizmet veremeyen Netflix firması sorunun veritabanı sıkıntısı sebebi ile oluştuğunu keşfetmiştir.
- Netflix'in devasa sistemi tek bir veritabanına bağımlıydı. Takdir edersiniz ki bu veritabanı ile ilgili herhangi bir sıkıntı tüm sistemi etkileme potansiyeline sahiptir. Normal şartlarda firmalar düzgün çalışan sistemlerine pek dokunmak istemezler. Heleki anlık kesintilerin bile olay olabileceği Netflix gibi bir firma. Genelde de bu bakış açısı ciddi bir çöküntüye kadar devam eder ve bu çöküntü firmayı yeni bir arayışa ve önlem almaya iter. İşte 4 günlük kesinti Netflix için tamda böyle olmuştu. Netflix'in mikroservis mimariye geçiş kararını 2008 yılında aldı. Peki microservis mimariye tam geçiş nekadar sürede tamamlandı ? 2016 yılında. Yani tam 8 sene. Gerçekten bir bedel ödenmişe benziyor. Fakat sonuçta tüm dünyaya hizmet verebilecek yatay genişlemeye sahip mikroservis mimarisi üzerine kurulmuş bir yapıya kavuşuyorlar. Günümüzdeki pekçok büyük firmanın projelerine monolitik bir mimaride başladığını fakat ölçekleme ve yönetimsel problemlerden dolayı günümüzde mikroservis mimari ile devam ettiğini söyleyebiliriz.
Mikroservis mimariye geçiş birçok değişimi de beraberinde getirebiliyor. Mikroservis mimaride alışık olduğunuz legacy DB'i yeni mimariye uyumlu hale getirmek için birçok sorguda değişiklik yapılması gerekebilir. Tabloları ve şemaları mikroservislere göre yapılandırmanız gerekecektir. Yapılacak bu ayrımlar ve ek join işlemleri sistemi yönetilmesi zor hale sokmakla birlikte performans sorunlarını da beraberinde getirebilir. Bu sebeple legacy veritabanınızdan vazgeçmeniz de gerekebilir. Mikroservis mimariye daha uyumlu bir veritabanı yapısı kullanmak daha mantıklı olabilir.
Tıpkı Apache Cassandra gibi. Cassandra açık kaynak kodlu olmakla birlikte NoSQL ve dağıtık mimaride kullanılabilecek bir yapıya sahiptir. Tamda mikroservis mimarinin aradığı şey değil mi? Yatay ölçeklemeye çok uygun olan Cassandra, Netflix tarafından da yeni mikroservis yapısı içinde yoğun kullanılmaktadır.
Tabiki bu bir projede sadece NoSQL yada sadece RDBMS sistemleri tercih etmemiz gerekiyor anlamına gelmiyor. Çeşitli kriterleri göz önüne alarak detaylı incleme ve dizayn yapmamız gerekiyor. Evet bir proje sadece NoSQL bir DB ile çalışabilir, yada RDBMS bir sistem ile. Ama önemli olan anlık ve ileriye dönük ihtiyaçlara uygun bir dizayndır. Çok fazla mikroservisin birarada çalıştığı bir mimaride bazı servisleri NoSQL, bazı servisleri ise RDBMS sistemleri ile çalıştırarak karma bir veritabanı altyapısı kullanmak da mümkündür. Mikroservis mimarisinde tavsiye edilen noktalardan birisi de mümkünse her mikroservisin kendine ayrı veritabanı olmasıdır. Böylece veritabanlarından birine bakım yaptığınızda diğer mikroservisleri etkilememiş olacaksınız. Yada veritabanı çöktüğünde bütün mikroservisleriniz çökmemiş oluyor.
Mikroservis mimarisinin getirdiği bazı dezavantajlar da yok değildir.
- Mikroservis mimarisinin kurulduğu sistemlerde networkün düzgün ve performanslı çalışması çok önemlidir. Çünkü olay mikroservislerin, müşterilerin ve veritabanlarının network üzerinde birbirilerinin konuşması üzerine kurgulanmıştır. Network sistemleri üzerinde yapılması gerekebilecek iyileştirmeler ek maliyetlere neden olabilir.
- Bir mikroservisin doğru çalıştığının test edilmesi monolitik yapıda yapılan testlere göre daha karmaşık olabilir. Özellikle entegrasyon testleri. Servisin test edilmesi için konuştuğu diğer servisler ile birlikte test edilmesi gerekecektir. İyi bir otomasyon ile bu işin altından kalkılabilir.
- Mikroservis mimarilerinde otomasyonun daha etkin kullanımı ve bu konuda ekstra efor gerekir.
- Veri tutarlılığını sağlayabilmek için çok iyi bir dizayn ve ekstra efor gerekecektir.
- Mikroservis mimaride güvenlik konusunda daha fazla efor ve bütçe sarfetmemiz gerekecektir. Çünkü mikroservisler birbirleri ile ve veritabanları ile haberleşirken monolitik yapılara göre daha fazla saldırılara müsait haldedir. Çünkü ağ üzerinde çok fazla noktadan akan veri trafiği mevcuttur.
- Servis ve veritabanı sayısı arttıkça monitoring işlemi daha maliyetli ve karmaşık hale gelebilir.
{
"acan": {
"id":1,
"name":"Ali Can",
"job":"Muhendis",
"tel":"034275654235"
},
"msert": {
"id":2,
"name":"Mehmet Sert",
"job":"Yonetici",
"tel":"03567567234235"
},
"cselman": {
"id":3,
"name":"Cem Selman",
"job":"Muhendis",
"tel":"03423867864235"
},
"malan": {
"id":4,
"name":"Murat Alan",
"job":"Mimar",
"tel":"03429455674235"
}
}
@app.route("/", methods=["GET"])
@app.route("/lists", methods=["GET"])
@app.route("/lists/<user>", methods=["GET"])
app.run(port=6111, debug=True)
- http://127.0.0.1:6111/
- http://127.0.0.1:6111/lists
- http://127.0.0.1:6111/lists/msert
from flask import Flask, jsonify, make_response
import json
import os
app = Flask(__name__)
database_path = os.path.dirname(os.path.dirname(os.path.realpath(__file__)))
file = "{}\data\\jobs.json".format(database_path)
with open(file, "r") as jsf:
job_list = json.load(jsf)
@app.route("/", methods=["GET"])
def hello():
"""Welcome Screen"""
return "JOBS Service Running"
@app.route("/lists", methods=["GET"])
def show_lists():
"""LIST"""
users_lists = []
for user in job_list:
users_lists.append(job_list[user])
return jsonify(lists=users_lists)
@app.route("/lists/<user>", methods=["GET"])
def user_list(user):
"""Get User Based Info"""
if user not in job_list:
return "Not Found"
return jsonify(job_list[user])
if __name__ == "__main__":
app.run(port=6111, debug=True)
Ve son olarak da kodumuzda tanımlanmamış bir URL nin hata vereceğini görüyoruz.
- Django Rest framework çok daha karmaşık geliştirmeler yapabileceğiniz ve yine mikroservisler oluşturabileceğiniz bir yapı olarak karşımıza çıkmakta ve büyük projelerde yoğunlukla kullanılmaktadır.
- Yine minimalist yapıda olan python Fast API ve Falcon Web Framework hızlı bir şekilde yüksek performanslı mikroservisler yazmak isteyenlerin tercihi olmaktadır.
- Bunların yanısıra popüler frameworkler arasından Connexion, Hug, Eve, Bottle, Turbo Gears, Tornado ve Cornice'i sayabiliriz.
- Daha farklı alanlarda yapacağınız çalışmalar için de microservis geliştirebileceğiniz kütüphaneler bulunmaktadır. Bunlardan ilginç olanlarından biri ise ArcGIS API dir. Haritalama, mekansal analiz, veri bilimi, yapay zeka ve otomasyon için güçlü bir Python kütüphanesi sağlamaktadır.
- Hızlı, ölçeklenebilir, güvenli ve taşınabilir veri tabanına dayalı web tabanlı uygulamaların hızlı bir şekilde geliştirilmesi için ise Web2PY i tavsiye edebiliriz. Web2PY nin avantajlarından birisi, veritabanı soyutlama katmanının, SQLite, MySQL, PostgreSQL, Oracle, DB2, MSSQL, MongoDB ve birçok popüler veritabanını destekleyen bir dizi sürücü ile birlikte çalışmasıdır.
