Servis Odaklı Mimari Neden Gereklidir? | robot_dreams
should_authorize_via_email
email.input_code tel.input_code
 
email.code_actual_for tel.code_actual_for
apply_exit_text
session_ended
to_homepage
Servis Odaklı Mimari Neden Gereklidir?

Servis Odaklı Mimari Neden Gereklidir?

Bir Uygulamayı Modüllere Nasıl Ayırırız?

Geliştirme maliyeti, yeni işlevsellik miktarına bağlıdır. Uygulamada ne kadar çok özellik kullanılacaksa, bunların yapılması bir o kadar fazla zaman alacaktır. Geliştirme maliyeti, hem ürünün teknoloji yığınından hem de ekibin izlediği mimari yaklaşımlardan etkilenir.

Servis odaklı mimari bir uygulamayı gevşek bağlı bileşenlere bölmeye dayanır. Bu makalede, sizlere mantığı modüllere ayırmanın geliştirmeyi nasıl basitleştirdiğini açıklayacağız.

Ayrı Parçalar Halinde Hizmetler

SOA'nın temel birimi belirli bir iş sürecinden sorumlu bir hizmettir. Örneğin, bir uygulamanın aşağıdakiler için ayrı hizmetleri olabilir:

  • Kullanıcı yetkilendirilmesi;
  • Kerestecilik;
  • Uyarılar.

Büyük görevler modüller arasında bölünür. Hizmetin içeriğini ve işlevlerini açıklamak için katı kurallar yoktur. Hizmetin neye ihtiyacı olduğunu ekibin kendisi belirler. Aynı zamanda, hizmetlerin kendisi de sözleşmelere uyar (açık kurallar):

  • Hizmete tam olarak bağlayacak olan nedir;
  • Verilerin hangi protokol ve hangi arayüz aracılığıyla aktarıldığı;
  • Hizmetin hangi verilerle çalıştığı;
  • Hangi işlevlerden sorumlu olduğu;
  • Hizmetin çağrılara yanıt olarak ne döndürdüğü.

Alt düzey modüllerin, kaynaklarla çalıştıkları protokol dışında üst düzey modüllerin uygulanması ile bir alakası yoktur. Servisler sadece veri gönderir ve alır, birbirlerinin metotlarına erişimleri yoktur. Ayrıca, tüm olaylar eşzamansız olarak işlenir. Diğer sistemlerden yanıt bekledikleri için hizmetlerin çalışmadığı durumlar olmamalıdır.

Hizmetler ayrı işlevleri temsil ettiğinden, farklı uygulamalarda yeniden kullanılabilirler. Hizmetlerin daha büyük varlıklarda birleştirilmesi, düzenleme olarak adlandırılır. Geliştirici, uygulamaları oluşturabileceği bir kurucu alır.

Bileşenler, bir olay sırası kullanan protokoller kullanarak birbirleriyle etkileşime girer. Sistem bileşenleri arasında ileti geçişini yöneten yazılım olan Enterprise Service Bus (ESB) aracılığıyla sağlanır.

Katmanlı Mimari

SOA'yi takip eden bir uygulama, her biri belirli bir işten sorumlu olan katmanlara ayrılır:

  • Business Process Layer — hizmetleri birleştirmek ve uygulama sorunlarını çözmeye amaçlayan bir katman;
  • Service — hizmet katmanı;
  • Components — bireysel hizmetleri sağlayan bileşenlere sahip bir katman. Örneğin, bir bileşenin kendi veritabanı yoktur - aynı anda birkaç hizmet tarafından kullanılan bir veritabanına erişir;
  • Integration Layer — ayrı bir modülün bileşenlerini birbirine bağlayan bir katman.

SOA'nın avantajları ve dezavantajları

SOA'nın avantajları:

  • Esneklik sağlar ve modüller ayrı çalışır. Sonuç olarak, mimariye dağıtılır ve platforma bağlı değildir. Farklı bileşenler, farklı programlama dillerinde ve çerçevelerde yazılabilir ve ardından ayrı sunucularda barındırılabilir;
  • Yeni özelliklerin entegresi kolaydır. Yeni bir servis yazılıp ve diğerleriyle etkileşimde bulunmak için hangi protokolleri kullanacağını belirlenmelidir;
  • SOA kapsülleme sağlar. İş fonksiyonları birbirinden izole edilir ve bunun sayesinde hata toleransını artırır. Hizmetlerden birinin değişmesi durumunda, yalnızca onunla etkileşime giren parçaların yeniden başlatılması gerekir. Uygulama, sınırlı işlevselliğe sahip olsa da çalışabilir. E-posta göndermekten sorumlu hizmet çöktüğünde, kullanıcı yetkilendirme hizmeti çalışmaya devam eder;
  • Hizmet bir uygulamaya bağlı olmadığı için başka bir uygulamada kullanılabilir. Bir geliştirici aynı hizmetin iki uygulamasını yazabilir: bunlardan biri ana iş mantığını sağlar ve ikincisi yeni özellikleri test etmek için kullanılır;

SOA'nın dezavantajları:

  • İlgili modüller birbirine bağlıdır;
  • Hizmetler arasında ne kadar çok bağlantı olursa, o kadar çok değişikliği izlemeniz gerekir;
  • Birçok ekip farklı hizmetler üzerinde çalıştığında, ürünü desteklemek ve çeşitli hizmetleri etkileyen değişiklikler yapmak için işbirliği yapmaları zordur. Bu durumda, çevik gelişimin yüksek hızını korumak imkansızdır;
  • Hizmet sayısındaki artışla birlikte ürünün yüksek maliyeti;

Bir mikro hizmet mimarisine geçiş (bir sonraki SOA geliştirme yinelemesi) bu eksiklikleri giderir. Bileşenler küçülür, kendi kaynaklarına ve veri depolarına sahip olur ve iletişim için yalnızca HTTP kullanılır.

Daha fazla makale
Mustafa Çamurlu ile yaptığımız röportajda, yazılım mimarisi alanında mikroservis, serverless ve event-driven mimarilerinin önemi ve yüksek trafikli uygulamalarda karşılaşılan zorlukları konuştuk.
Yüksek Trafikli Yazılım Mimarisi Eğitimimize katılın ve dijital dünyada fark yaratma fırsatını yakalayın!