Aracılığıyla paylaş

Mimari stilleri

  • Makale

Mimari stili, bazı özellikleri ortak olan bir mimari ailesidir. Örneğin, N katmanı yaygın bir mimari stilidir. Son zamanlarda, mikro hizmet mimarileri daha fazla kabul görmeye başlamıştır. Mimari stillerinin belirli teknolojileri kullanması gerekmez; ama bazı teknolojiler belirli mimarilere daha uygundur. Örneğin, kapsayıcılar mikro hizmetlere doğal bir şekilde uyum gösterir.

Bulut uygulamalarında yaygın olarak bulunan bir dizi mimari stili belirledik. Her stilin makalesi şunları içerir:

  • Stilin açıklaması ve mantıksal diyagramı.
  • Bu stilin ne zaman seçileceğine ilişkin öneriler.
  • Avantajlar, zorluklar ve en iyi deneyimler.
  • Uygun Azure hizmetlerini kullanarak önerilen dağıtım.

Stillerde hızlı bir gezinti

Bu bölümde, belirlediğimiz mimari stillerinde hızlı bir gezinti yapabilir ve bunların kullanımında dikkate alınacak bazı üst düzey noktaları bulabilirsiniz. Listenin kapsamlı olmadığını lütfen unutmayın. Diğer ayrıntılar için bağlantısı verilen konuları okuyun.

N katmanı

N katmanlı mimari stilinin mantıksal diyagramı.

N katmanı kurumsal uygulamalara yönelik geleneksel bir mimaridir. Bağımlılıklar, uygulamayı sunu, iş mantığı ve veri erişimi gibi mantıksal işlevler gerçekleştiren katmanlara ayırarak yönetilir. Katman, yalnızca altındaki katmanlara çağrı yapabilir. Öte yandan, bu yatay katmanlama bir sınırlama getirebilir. Uygulamanın kalan bölümlerine dokunmadan bir bölümünde değişiklikler yapmak zor olabilir. Bu da sık sık güncelleştirme yapmayı güçleştirebilir ve yeni özelliklerin çabuk eklenmesini kısıtlayabilir.

N katmanı, zaten katmanlı bir mimari kullanan mevcut uygulamaların geçişi için doğal olarak uygundur. Bu nedenle, N katmanı hizmet olarak altyapı (IaaS) çözümlerinde veya IaaS ile yönetilen hizmetlerin karma kullanıldığı uygulamalarda en sık görülen mimari stilidir.

Web Kuyruğu Çalışanı

Web-Queue-Worker mimari stilinin mantıksal diyagramı.

Tam bir PaaS çözümü için, Web Kuyruğu Çalışanı mimarisini göz önünde bulundurun. Bu stilde, uygulamanın HTTP isteklerini işleyen bir web ön ucu ile yoğun CPU kullanılan görevleri ve uzun süre çalışan işlemleri gerçekleştiren arka uç çalışanı vardır. Ön uç, zaman uyumsuz bir ileti kuyruğu üzerinden çalışanla iletişim kurar.

Web kuyruğu çalışanı, bazı kaynak yoğun görevleri olan görece basit etki alanlarına uygundur. N katmanında olduğu gibi, mimari kolayca anlaşılır. Yönetilen hizmetlerin kullanılması dağıtımı ve işlemleri basitleştirir. Ama karmaşık etki alanlarında, bağımlılıkları yönetmek zor olabilir. Ön uç ve çalışan kolayca bakımı ve güncelleştirmesi zor, büyük ve tek parça bileşenlere dönüşebilir. N katmanında olduğu gibi, bu da güncelleştirmelerin sıklığını azaltabilir ve yeniliklere kısıtlama getirebilir.

Mikro hizmetler

Mikro hizmetler mimarisi stilinin mantıksal diyagramı.

Uygulamanızın etki alanı daha karmaşıksa, Mikro hizmetler mimarisine geçmeyi göz önünde bulundurabilirsiniz. Mikro hizmetler uygulaması birçok küçük, bağımsız hizmetten oluşur. Her hizmet tek bir iş özelliği gerçekleştirir. Hizmetler arasında gevşek bir bağ vardır ve API sözleşmeleri aracılığıyla iletişim kurarlar.

Her hizmet küçük, konuya odaklanmış bir geliştirme ekibi tarafından oluşturulabilir. Tek tek hizmetlerin dağıtımında ekipler arasında fazla eşgüdüm olması gerekmez ve bu da sık sık güncelleştirme yapılabilmesini teşvik eder. Mikro hizmet mimarisini oluşturmak ve yönetmek, N katmanı veya web kuyruğu çalışanına göre daha karmaşık bir işlemdir. Olgunlaşmış bir geliştirme ve DevOps kültürü gerektirir. Ama doğru yapıldığında, bu stil daha yüksek sürüm hızı, daha hızlı yenilikler ve daha dayanıklı bir mimari getirir.

Olay denetimli mimari

Olay temelli mimari stilinin diyagramı.

Olay Denetimli Mimariler bir yayınla-abone ol (pub-sub) modeli kullanır; yapımcılar olayları yayımlar ve tüketiciler bunlara abone olur. Yapımcılar tüketicilerden bağımsızdır ve tüketiciler de birbirinden bağımsızdır.

IoT çözümleri gibi çok büyük miktarlarda veri alıp işleyen, gecikme süresi çok kısa uygulamalarda olay denetimli mimariyi kullanmayı göz önünde bulundurun. Bu stil, farklı alt sistemlerin aynı olay verileri üzerinde farklı işleme türleri gerçekleştirmesi gereken durumlarda da kullanışlıdır.

Big Data, Big Compute

Büyük veri mimarisi stilinin mantıksal diyagramı.

Big Data ve Big Compute, belirli özel profillere uyan iş yüklerine yönelik özelleştirilmiş mimari stilleridir. Big Data, analiz ve raporlama amacıyla çok büyük bir veri kümesini öbeklere ayırır ve kümenin tamamı üzerinde paralel işlem gerçekleştirir. Yüksek performanslı bilgi işlem (HPC) olarak da adlandırılan Big Compute, çok büyük sayılardaki (binlerce) çekirdek üzerinde paralel hesaplamalar yapar. Etki alanları benzetimleri, modellemeyi ve 3-B işlemeyi içerir.

Kısıtlama olarak mimarisi stilleri

Mimari stili tasarıma, görüntülenecek öğe kümesi ve bu öğeler arasında izin verilen ilişkiler gibi kısıtlamalar getirir. Kısıtlamalar, seçenekler evrenini daraltarak mimarinin "şekline" yön verir. Mimari belirli bir stilin kısıtlamalarına uyduğunda, bazı cazip özellikler ortaya çıkar.

Örneğin, mikro hizmetlerin kısıtlamaları şunlardır:

  • Bir hizmet, tek bir sorumluluğu temsil eder.
  • Her hizmet diğerlerinden bağımsızdır.
  • Veriler, bunların sahibi olan hizmete özeldir. Hizmetleri verileri paylaşmaz.

Bu kısıtlamalara uyulduğunda, hizmetlerin birbirinden bağımsız olarak dağıtılabildiği, hataların yalıtıldığı, sık güncelleştirmelerin mümkün olduğu ve uygulamaya yeni teknolojilerin eklenmesini kolaylaştıran bir sistem ortaya çıkar.

Her mimari stilinin kendi dengeleri vardır. Bu nedenle, herhangi bir mimari stili seçmeden önce, bu stilin temel ilkelerini ve kısıtlamalarını anladığınızdan emin olun. Aksi takdirde, yüzeysel olarak stile uyan ancak o stilin potansiyelinden tam olarak yararlanmayan bir tasarım elde edebilirsiniz. Belirli bir mimari stili nasıl uygulayabileceğinizden daha çok neden seçtiğinize dikkat etmeniz gerekir. Pragmatik olmak da önemlidir. Bazı durumlarda mimari saflığa bağlı kalmakta ısrar etmek yerine bir kısıtlamayı gevşetmek daha iyi olabilir.

Uygun bir mimari stili seçmek, bilinçli iş yükü paydaşlarının fikir birliğine varılmasıyla ideal bir şekilde yapılmalıdır. İş yükü ekibi öncelikle çözmeye çalıştıkları sorunun niteliğini belirlemelidir. Daha sonra iş etmenlerini ve buna karşılık gelen mimari özelliklerini (işlevsel olmayan gereksinimler olarak da bilinir) tanımlamalı ve önceliklerini belirlemelidir. Örneğin, pazara daha kısa bir süreye ihtiyaçları varsa, hızlı dağıtım özellikleriyle sürdürülebilirliği, test edilebilirliği ve güvenilirliği önceliklendirebilirler. İş yükü ekibinin bütçesi kısıtlanmışsa, fizibilite ve basitliğe öncelik verebilir. Mimari stili seçmek ve korumak tek seferlik bir etkinlik değil, sürekli bir yaklaşımdır: mimari zaman içinde sürekli ölçülmeli, doğrulanmalı ve ince ayarlanmalıdır. Mimari stilin değiştirilmesinde genellikle önemli maliyetler söz konusu olduğundan, uzun vadeli ekip verimliliği ve risk azaltma için önceden daha fazla çaba gösterilebilir.

Aşağıdaki tabloda, her stilin bağımlılıkları nasıl yönettiği özetlenir ve her birine en iyi uyan etki alanı türleri verilir.

Mimari stili Bağımlılık yönetimi Etki alanı türü
N katmanlı Alt ağa göre bölünmüş yatay katmanlar Geleneksel iş etki alanı. Güncelleştirmelerin sıklığı düşüktür.
Web kuyruğu çalışanı Zaman uyumsuz iletilerle ayrılmış, ön ve arka uç işleri. Bazı kaynak yoğun görevlerin gerçekleştirildiği görece basit bir etki alanı.
Mikro hizmetler API'ler aracılığıyla birbirini çağıran, dikey (işlevsel) olarak ayrılmış hizmetler. Karmaşık etki alanı. Sık güncelleştirmeler.
Olay temelli mimari Yapımcı/tüketici. Alt sistem başına bağımsız görünüm. IoT ve gerçek zamanlı sistemler.
Büyük veri Çok büyük bir veri kümesini küçük öbeklere ayırın. Yerel veri kümeleri üzerinde paralel işleme. Toplu ve gerçek zamanlı veri analizi. ML kullanılarak tahmine dayalı analiz.
Büyük işlem Verileri binlerce çekirdeğe ayırma. Benzetim gibi bilgi işlem kullanımı yoğun etki alanları.

Güçlükleri ve avantajları göz önünde bulundurun

Kısıtlamalar güçlükler de doğurur, dolayısıyla bu stillerden herhangi birini benimserken güçlüklerle avantajların nasıl dengelendiğini anlamak önemlidir. Bu alt etki alanı ve sınırlanmış bağlam için, mimari stilinin avantajlarının güçlüklerine ağır bastığından emin olun.

İşte, mimari stilini seçerken dikkate alınması gereken bazı güçlük türleri:

  • Karmaşıklık. Mimarinin karmaşıklığı etki alanınız için uygun mu? Tersine, stil etki alanınız için fazla mı basit kalıyor? Bu durumda, mimari bağımlılıkları net bir şekilde yönetmenize yardımcı olmadığından sonunda "big ball of mud" olarak adlandırılan bir çamur deryası elde etme riskiniz vardır.

  • Zaman uyumsuz iletiler ve nihai tutarlılık. Zaman uyumsuz iletiler hizmetleri ayırmak, güvenilirliği (çünkü iletiler yeniden denenebilir) ve ölçeklendirilebilirliği artırmak için kullanılabilir. Ancak bu, son tutarlılığın sağlanmasına ve yinelenen ileti oluşması ihtimaline yönelik zorluklar da yaratır.

  • Hizmetler arası iletişim. Uygulamayı ayrı ayrı hizmetlere ayırdığınızda, hizmetler arasındaki iletişimin kabul edilemez bir gecikmeye neden olması veya ağda tıkanıklık yaratması riski vardır (örneğin, mikro hizmetler mimarisinde).

  • Yönetilebilirlik. Uygulamayı yönetmek, izlemek, güncelleştirmeleri dağıtmak, vb. ne kadar zor?