Yazılım Mimari Stilleri
Selamlar,
Fundamentals of Software Architecture kitabında faydalı bulduğum Yazılım Mimari Stillerine kısaca değineceğim.
Aslında bunlar backend ağırlıklı mimari stillerdir.
1. Katmanlı Mimari Stili (Layered Architecture Style)
2. Boru-Hattı Mimarisi Stili (Pipeline Architecture Style)
3. Mikro-Çekirdek Mimari Stili (Microkernel Architecture Style)
4. Servis-Tabanlı Mimari Stili (Service-Based Architecture Style)
5. Olay-Odaklı Mimari Stili (Event-Driven Architecture Style)
6. Alan-Tabanlı Mimari Stili (Space-Based Architecture Style)
7. Orkestrasyon-Odaklı Servis-Yönelimli Mimari (Orchestration-Driven Service-Oriented Architecture)
1. Katmanlı Mimari Stili (Layered Architecture Style)
N-Katmanlı mimari stili olarak da bilinir. En yaygın ortak mimari stillerinden biridir. Basitliği, tanınırlığı ve düşük maliyeti nedeniyle tercih edilir. Katmanlı mimari aynı zamanda, ima yoluyla mimari anti-kalıbı (architecture by implication anti-pattern) ve tesadüfi mimari anti-kalıbını da (accidental architecture anti-pattern) bünyesinde barındırır.
Bir geliştirici veya mimar, hangi mimari tarzı kullandığından emin değilse ve Agile ekibi “kodlamaya bir an önce başla diyorsa”, uyguladıkları şeyin katmanlı mimari stili olma ihtimali çok yüksektir.
Sunum(presentation) katmanı, tüm kullanıcı arayüzünün ve tarayıcı iletişiminin yönetilmesinden sorumlu olacaktır.
İş katmanı(business layer), istekle(request) ilişkili belirli iş kurallarının yürütülmesinden sorumlu olacaktır.
Kalıcılık(persistence) katmanı, verilere karşı iş mantığını gerçekleştirir ve bu bilgiyi sunum katmanına aktarır.
Veritabanı(database) katmanı ise verilerin tutulmasından sorumludur.
Katmanlı mimari, teknik olarak bölümlenmiş bir mimaridir (domain-olarak-bölümlenmiş mimarinin aksine).
Hangi mimarinin kullanılacağının karar verilmediği durumlarda, katmanlı mimari iyi bir başlangıç noktası olabilir. Yazılımcılar işe başlarken, mimarlar ise bu süre içinde farklı mimarileri inceleyip, karar verebilirler.
2. Boru-Hattı Mimarisi Stili (Pipeline Architecture Style)
Borular(pipes) ve filtreler(filters) mimarisi olarak da bilinir. Geliştiriciler ve mimarlar, işlevselliği ayrı parçalara ayırmaya karar verdiklerinde bu modeli takip ederler. Çoğu geliştirici bu mimariyi Unix terminal kabuk(shell) dillerinin ardındaki temel prensip olarak da bilir, Bash gibi.
MapReduce programlama modelini kullanan birçok araç bu temel topolojiyi takip eder.
Borular ve filtreler, filtreler arasında, genellikle noktadan noktaya tek-yönlü iletişim oluşturan borularla koordine edilir.
Örnek bir metin(text) işleme problemi düşünelim. Bir metin dosyasını okuyacak, en çok kullanılan n kelimeyi belirleyecek ve bu kelimelerin kullanılma sıklıklarıyla birlikte sıralanmış halini ekrana yazdıracak. Bunu birçok farklı dilde çok daha uzun şekilde çözebiliriz ama Pipeline modeliyle, çok daha kısa ve öz bir şekilde aşağıdaki gibi çözülür.
Pipeline mimarisi stili, uygulama mantığının filtre türlerine (producer, tester, transformer ve consumer gibi) bölünmesi nedeniyle teknik olarak bölümlenmiş bir mimaridir.
Modülerlik ile birleşen genel maliyet ve basitlik, pipeline mimarisinin güçlü yönlerini oluşturur.
3. Mikro-Çekirdek Mimari Stili (Microkernel Architecture Style)
Mikro-çekirdek(Microkernel) mimarisi stili, eklenti(plugin) mimarisi olarak da bilinir, birkaç on yıl önce ortaya çıktı ve bugün yaygın olarak kullanılıyor.
Microkernel mimari stili, iki mimari bileşenden oluşan nispeten basit bir monolitik mimaridir: çekirdek sistem(core system) ve eklenti(plugin) bileşenleri. Uygulama mantığı, bağımsız eklenti bileşenleri ile temel çekirdek sistem arasında bölünmüş olup, bu sayede sistemin genişletilebilirliği(extensibility), uyarlanabilirliği(adaptability) ve izolasyonu(isolation) sağlanır.
Eclipse IDE, Intellij IDEA, Jira ve Jenkins gibi uygulamalar bu mimarinin örnekleridir.
Chrome ve Firefox gibi web tarayıcıları da benzer mantıkla çalışırlar.
Katmanlı mimari stiline benzer şekilde, basitlik ve genel maliyet, microkernel mimari stilinin temel güçlü yönleridir.
Microkernel mimarisi stili, hem domain olarak bölümlenebilen hem de teknik olarak bölümlenebilen tek mimari stili olması bakımından benzersizdir.
4. Servis-Tabanlı Mimari Stili (Service-Based Architecture Style)
Servis-tabanlı mimari, mikroservis mimarisi tarzının bir karışımıdır ve mimari esnekliği nedeniyle, en pragmatik mimari tarzlarından biri olarak kabul edilir. Servis-tabanlı mimari dağıtık bir mimari olmasına rağmen, mikroservis mimarisiyle aynı seviyede karmaşıklığa ve maliyete sahip değildir. Bu da onu işle ilgili birçok uygulama için çok popüler bir seçim haline getirmektedir.
Servislere, uzak erişim protokolü kullanılarak bir kullanıcı arayüzünden erişilir. REST genellikle kullanıcı arayüzünden servislere erişmek için kullanılsa da mesajlaşma, uzak prosedür çağrısı(RPC) ve hatta SOAP da kullanılabilir.
Servis-tabanlı mimarinin önemli bir yönü, genellikle merkezi olarak paylaşılan bir veritabanı kullanmasıdır. Bu, servislerin SQL sorgularından ortak olarak yararlanmasını, geleneksel monolitik katmanlı mimarinin yaptığı gibi, sağlar.
Aşağıdaki gibi servislerin önüne, proxy veya gateway de ekleyebiliriz.
Servis-tabanlı mimari, domain bölümlü bir mimaridir; bu, yapının teknik bir husustan ziyade domain tarafından yönlendirildiği anlamına gelir.
Servis-tabanlı mimari, domain odaklı tasarım yaparken doğal bir uyum sağlar. Servisler, detaylı olmayan domain kapsamına sahip olduğundan, her domain, ayrı olarak dağıtılan domain servisine güzel bir şekilde uyum sağlar.
Veritabanı işlemlerinin sürdürülmesi ve koordine edilmesi, dağıtık mimarilerde her zaman bir sorundur; çünkü bunlar genellikle geleneksel ACID(atomicity, consistency, isolation, and durability) işlemlerinden ziyade nihai tutarlılığa(eventual consistency) dayanır. Bununla birlikte, servis-tabanlı mimari, domain servislerinin iri-taneli yapısı nedeniyle ACID işlemlerini diğer dağıtık mimarilerden daha iyi korur.
5. Olay-Odaklı Mimari Stili (Event-Driven Architecture Style)
Event-driven mimari stili, yüksek düzeyde ölçeklenebilir ve yüksek performanslı uygulamalar üretmek için kullanılan, popüler bir dağıtık asenkron mimari stilidir.
Event-driven mimari, olayları asenkron olarak alan ve işleyen ayrık olay işleme bileşenlerinden oluşur. Bağımsız bir mimari stili olarak kullanılabilir veya diğer mimari stillerin içine yerleştirilebilir.
Olay-dayalı model belirli bir duruma tepki verir ve bu olaya göre eyleme geçer.
Event-driven mimaride iki temel topoloji vardır: mediator topolojisi ve broker topolojisi.
Broker(Komisyoncu) Topolojisi:
Broker topolojisi, merkezi bir event mediatorünün olmaması nedeniyle mediator topolojisinden ayrılır. Bunun yerine, mesaj akışı, lightweight bir mesaj broker (RabitMQ, ActiveMQ, HornetQ vb. gibi) aracılığıyla zincir benzeri bir yayın tarzında olay işlemcisi bileşenleri arasında dağıtılır. Bu topoloji, nispeten basit bir olay işleme akışınız olduğunda ve merkezi olay orkestrasyon ve koordinasyonuna ihtiyacınız olmadığında, kullanışlıdır.
Mediator(Aracı) Topolojisi:
Event-driven mimarinin mediator topolojisi, önceki bölümde açıklanan broker topolojisinin bazı eksikliklerini giderir. Bu topolojinin merkezinde, birden fazla olay işlemcisinin koordinasyonunu gerektiren, olayların başlatılması için iş akışını yöneten ve kontrol eden bir event mediator bulunur. Mediator topolojisini oluşturan mimari bileşenler, başlatıcı(initiating) bir olay, bir olay kuyruğu(event queue), bir olay mediator, olay kanalları ve olay işlemcileridir.
Broker ve mediator topolojisi arasındaki seçim, esasen iş akışı kontrolü ve hata işleme kapasitesi ile yüksek performans ve ölçeklenebilirlik arasındaki dengeye dayanır. Mediator topolojisinde performans ve ölçeklenebilirlik hala iyi olsa da broker topolojisindeki kadar yüksek değildir.
Event-driven mimari, herhangi bir domainde birden fazla olay işlemcisinin birbirine bağlandığı için, öncelikle teknik olarak bölümlenmiş bir mimaridir. Belirli bir domaindeki değişiklikler genellikle birçok olay işlemcisini, mediatörü ve diğer mesajlaşma araçlarını etkiler.
6. Alan-Tabanlı Mimari Stili (Space-Based Architecture Style)
Space-based mimari tarzı, yüksek ölçeklenebilirlik(scalability), esneklik ve yüksek eşzamanlılık sorunlarını çözmek için özel olarak tasarlanmıştır. Aynı zamanda, değişken ve öngörülemeyen eşzamanlı kullanıcı hacimlerine sahip uygulamalar için de kullanışlı bir mimari stilidir. Aşırı ve değişken ölçeklenebilirlik sorununu mimari olarak çözmek, genellikle bir veritabanının ölçeğini genişletmeye çalışmaktan veya caching(ön belleğe alma) teknolojilerini, ölçeklenemeyen bir mimariye uyarlamaktan daha iyi bir yaklaşımdır.
Space-based mimari, adını, paylaşılan bellek aracılığıyla iletişim kuran birden fazla paralel işlemci tekniği olan, tuple space kavramından alır. Yüksek ölçeklenebilirlik, yüksek esneklik ve yüksek performans, sistemdeki eşzamanlı kısıtlama olarak merkezi veritabanının kaldırılması ve bunun yerine çoğaltılmış in-memory data gridlerin kullanılmasıyla elde edilir.
Space-based mimari, kullanıcı veya istek hacminde yüksek ani artışlar yaşayan uygulamalar ve 10.000'den fazla eşzamanlı kullanıcıya sahip uygulamalar için çok uygundur. Space-based mimariye örnek olarak çevrimiçi konser biletleme sistemleri ve çevrimiçi açık artırma sistemleri gibi uygulamalar verilebilir. Bu örneklerin her ikisi de yüksek performans, yüksek ölçeklenebilirlik ve yüksek düzeyde esneklik gerektirir.
Bu mimari tarzında yüksek düzeyde esneklik, ölçeklenebilirlik ve performans avantajlar olsa da, özellikle genel basitlik ve test edilebilirlik açısından bir dezavantaj oluşturur. Space-based mimari, caching kullanımı ve birincil veri deposunun nihai tutarlılığı nedeniyle çok karmaşık bir mimari tarzıdır.
Bu mimari stili seçerken maliyet başka bir faktördür. Space-based mimari, çoğunlukla, ürünleri caching için lisans ücretleri ve yüksek ölçeklenebilirlik ve esneklik nedeniyle, cloud(bulut) ve on-prem(şirket içi) sistemlerde yüksek kaynak kullanımı nedeniyle, nispeten pahalıdır.
7. Orkestrasyon-Odaklı Servis-Yönelimli Mimari (Orchestration-Driven Service-Oriented Architecture)
Bu mimarideki temel felsefe, kurumsal düzeyde yeniden kullanıma odaklanmaktır. Birçok büyük şirket, yazılımı yeniden yazmaya devam etmek zorunda kalmalarından rahatsız oldular ve bu sorunu yavaş yavaş çözecek bir strateji belirlediler. Sınıflandırmanın her katmanı bu hedefi destekledi.
İş(Business) servisleri, bu mimarinin en üstünde yer alır ve giriş noktasını sağlar. Bu servis tanımları herhangi bir kod içermez; yalnızca giriş, çıkış ve bazen de şema bilgileri içerir. Genellikle iş kullanıcıları tarafından tanımlanırlar, dolayısıyla iş servisleri adı verilir.
Kurumsal(Enterprise) servisler, detaylı ve paylaşılan uygulamalar içerir. Tipik olarak, bir geliştirici ekibi, belirli domainler etrafında atomik davranış oluşturmakla görevlendirilir: CreateCustomer vb. Bu servisler, orkestrasyon engine aracılığıyla birbirine bağlanan detaylı olmayan iş servislerini oluşturan yapı taşlarıdır.
Uygulama(Application) servisleri, tek uygulamalı servislerdir. Örneğin, bir uygulamanın coğrafi konuma ihtiyacı olabilir, ancak kuruluş bunu yeniden kullanılabilir bir servis haline getirmek için çaba harcamak istemez. Genellikle, tek bir uygulama ekibinin sahip olduğu bir uygulama servisi, bu sorunları çözer.
Altyapı(Infrastructure) servisleri izleme(monitoring), loglama, kimlik doğrulama ve yetkilendirme gibi operasyonel konuları sağlar.
Orkestrasyon motoru(orkestrasyon engine), bu dağıtık mimarinin kalbini oluşturur. İşlem koordinasyonu ve mesaj dönüşümü gibi özellikler de dahil olmak üzere, iş servisi uygulamalarını, orkestrasyonu kullanarak birleştirir. Bu mimari genellikle mikro servis mimarilerinde olduğu gibi servis başına bir veritabanı yerine tek bir veya birkaç ilişkisel veritabanına bağlanır. Böylece, işlemsel davranış, veritabanı yerine orkestrasyon motorunda bildirimli olarak ele alınır.
8. Mikroservis Mimarisi (Microservices Architecture)
Mikroservisler son yıllarda önemli bir ivme kazanan son derece popüler bir mimari stilidir.
Mikroservisler, yazılım projeleri için mantıksal bir tasarım süreci olan domain-odaklı tasarımdaki(domain-driven design, DDD) fikirlerden büyük ölçüde ilham almaktadır. Özellikle DDD’den bir konsept olan sınırlı bağlam(bounded context), kesinlikle mikroservislere ilham kaynağı olmuştur. Bounded context kavramı ayrıştırma stilini temsil eder.
Mikroservislerin birincil hedefi, bounded context’in mantıksal kavramını fiziksel olarak modelleyen yüksek düzeyde ayrıştırmadır.
Topolojide görüldüğü gibi, mikroservislerdeki servis büyüklüğü diğer dağıtık mimarilere göre çok daha küçüktük. Nihai olarak tek görevi de budur.
Mimarlar her servisin, veritabanları ve diğer bağımlı bileşenler de dahil olmak üzere, bağımsız olarak çalışabilmesi için gerekli tüm parçaları içermesini bekler.
Mikroservisler dağıtık bir mimari oluşturur: her servis, başlangıçta fiziksel bir bilgisayarda ancak hızla sanal makinelere ve konteynerlere dönüşen kendi sürecinde çalışır.
Mikroservislerin itici felsefesi bounded context kavramıdır: her servis bir domain veya iş akışını modeller.
Mikroservislerin küçüklüğü duruma göre değişir. İlla çok küçük olması gerekiyor diye bir durum yok. Birbiriyle çok alakalı küçükçe servisleri bir araya toplayıp tek bir servis yapılabilir. Önemli olan domain olarak birbiriyle alakalı iş yapmalarıdır.
Mikroservisler, kendi verisiyle izole bir şekilde çalışır.
Genelde backend tarafında kullanılan Yazılım Mimari Stillerinin fazla detayına girmeden bir özetini sunduk. Faydalı olması dileğiyle.
