Microservice Nedir, Avantajları Nelerdir?
Merhabalar,
Mediumdaki ilk postumda sizinle microservice mimarisini ve yapısını, servislerinin birbirleriyle nasıl haberleştiklerini, avantajlarını, monolitik yapıyla olan farklılıklarını tartışıcaz.
Microservice Nedir?
Öncelikle yazılım dünyasındaki çoğu kişinin microservice konusunda biraz fikir sahibi olduğuna eminim. Microservice yaklaşımından önceki projelerimiz monolithic (dikey büyüyen ve tek bir solution altında farklı katmanlardan oluşan) yapıdaydı. Yani proje ekibindeki herkes aynı proje üzerinde çalışıp version control toolları (git, tfs, svn..) üzerinden kodlarımızı paylaşıyorduk. Projemizde en ufak bug bile olsa veya küçük bir feature eklendikten sonrasında komple projemizi build edip tekrardan deploy etmek zorunda kalıyorduk. Bu da bize scale etmede güçlük ve maintane aşamasında bazı sıkıntılar yaşatıyordu. İşte microservice yapısı bizi bu dertlerden kurtarıp tamamen SOA (Service Oriented Architecture) tabanlı ve SOC (Seperate of Concern) prensibini tamamen karşılayan bir mimaridir.
Organise around the business capabilites, don’t technologies.
Yukardaki yaklaşım bizden microservice mimarisinde teknoloji yerine iş yeteneklerine ve kurallarına odaklanmamızı ve organize etmemizi bekler.
Microservice mimarisinde, uygulamamız; birbirinden tamamen bağımsız farklı servislerinden oluşur. Teknolojiler ve platformlar birbirinden bağımsızdır. Her bir servisin kendine ait iş kuralları ve domaini vardır. Servisler birbirleriyle olan iletişimi farklı mimariyle kurarlar. Bunlardan en çok kullanılanı Olay Güdümlü Mimari ( Event Driven Architecture)dır. Bu mimariye aşağıda değiniyor olacağım.
Microservice Kullanımının Avantajları
- DB Bağımsızlığı: Yukarıda belirttiğim gibi microservisler birbirinden tamamen bağımsızdılar. Her serviste birbirinden farklı teknolojiler ve veri tabanı kullanabilirsin ve bu tercih size kalmış. Örneğin bir ecommerce projesini microservis mimarisi ile servislere ayırdığımızı farzedelim bunlar da Order, Basket, Catalog, Marketing servisleri olsun. Order servisinin datalarını MsSql Server’da tutarken, Basket servisinin datalarını Redis’te veya NoSql’de tutabiliriz. Bu tamamen sizin seçiminize kalmış. Microservisin güzelliği burda ortaya çıkmaya başlıyor aslında :)
- Teknoloji Serbestliği: Yukarıda servislerin database yapılarından bahsettik. Microservislerimiz için ayrı ayrı ekiplerimiz olduğunu varsayalım. Bir ekibimiz DotnetCore Web Api ile endpointlerimizi hazırlarken diğer bir ekip Django veya Flask ile Rest Apileri hazırlayabiliyor. Teknoloji seçimize de tamamen bize kalıyor. Gördüğümüz üzere çok esnek ve bağımsız bir yapı karşımıza çıkıyor.
- Ölçeklendirilebilirlik: Daha ölçeklendirilebilir bir yapıya sahiptir. Çünkü yaptığımız bir değişiklik tüm proje yerine sadece ilgili servisi ilgilendirir ve böylece büyük bir projeyi deploy etmekten kurtulmuş oluruz
- Otomatik CI/CD Süreçleri Her bir ekip kendi servisini geliştirip test edip deploy edebilir. Tamamen platform bağımsızdır. Her bir servis otomatize edilerek belirli aşamalardan geçerek(Unit Test, Integration Tests, Automation Test) deploy edilmelidir. ( Continous Integration — Continous Deployment) Bu da projedeki kaliteyi artıran bir etmendir.
- Hata İzolasyonu — Projenin herhangi bir servisinde oluşacak bir sorun, projenin diğer servislerini etkilemez. Sistem hala ayaktadır ve çalışmaya devam eder. Sistemin bütünlüğünü her hangi bir şekilde sekteye uğratmaz
Event Driven Architecture Nedir?
Event Driven mimari, bir birleriyle haberleşmesi gereken servislerin dağıtık sistemde, event fırlatarak ve bu event’i handle ederek süreci tamamlayabilmesini amaçlamaktadır. Servisler arası event’ler merkezi bir Event Bus ile gerçekleştirilir. Bu mimarideki event bus aracı olarak message queue’lar tercih edilirler. Aşağıda gördüğünüz gibi bir publisher ve publisherın event fırlattığı anda o eventtan haberdar olup, o eventi handle edecek bir veya birden fazla subscriberlar vardır. Tüm mesaj trafiği, tüm pub/sub işlemleri event bus üzerinden yürütülür.
Message Queues ile Event Driven Mimari
Yukarıdaki örneği biraz açalım.
- maddede client tarafından fiyatı güncellemeye dair bir istek gelir.
- maddede DB tarafında fiyat update olur.
- maddede fiyatın güncellediğine dair bir event publish edilip subscriberların bundan haberdar olması sağlanır.
- Bu eventla ilgili olan tüm subscriberlar event fırlatıldığı anda bu işlemden haberdar olurlar ve gerekli işlemleri servis tarafında yürütürler.
Event Driven mimari kullanmak istediğinizde çok fazla event driven implementasyonu bulabilirsiniz. Ben RabbitMq tercih ediyorum. Hem monitoring açısından, hem de lightweight olmasından daha tercih edilebilir buluyorum. Fakat hem Azure’un hem AWS’nin Service Bus çözümleri bulunuyor. ( Azure Servis Bus- Aws Event-Bridge)
Bu mimaride dikkat edilmesi gereken en önemli nokta; sistemin Event Bus’a bağımlı olmasıdır. Event Bus’da meydana gelecek bir kesinti durumunda, transaction bütünlüğü kaybolabilir ve servisler arası iletişim kopabilir.
Event driven mimariyi kurgularken farklı pattern’lardan da yararlanabilirsiniz. Örneğin, SAGA veya yaygın kullanımı olan Event Sourcing paternleri incelenebilir.
Api Gateway Nedir?
Çok basit bir şekilde anlatacak olursak: Clienttan requestleri alıp onları uygun microservislere yönlendirmektir. Bir requestle arkada birden çok servis çağırıp sonuçları toplayıp dönebilir.
Diyelim ki client mobilden veya webten gelen bi client üzerinden localhost:5000e istek attı.
Örneğin farklı portlarda koşan 3 farklı servisimiz olsun
localhost:5001 OrderApi Service, (http://localhost:5001/orderapi/getAllOrders)
localhost:5002 CustomerApiService,(http://localhost:5002/customerApi/getAllCustomers)
localhost:5003 BasketApiService,(http://localhost:5003/basketApi/getAllProductsByCustomerId)
ApiGateway ile yapacağımız configurasyon ile client, localhost:5000 üzerinden yukarıda gördüğünüz tüm endpointlere erişiyor hale gelebilecek.
http://localhost:5000/orderapi/getAllOrders endpointe istek atan client OrderApi Servisine erişiyor olabilecek.
Bu sayede client için en uygun apiyi API GATEWAY üzerinden hazırlayıp sunabiliriz.
En büyük avantajı ise clientın tek bir request-response ile birden fazla servise erişmelerini sağlar. Daha az request ise maliyetlerin azalmasını anlamına gelir.
DotnetCore için en çok kullanılan Api Gateway kütüphanesi Ochelot tur.
Kaynaklar:
