Sign in

External Configuration

Bir servis tipik olarak farklı servisleri ve veritabanlarını kullanabilir. Dev, QA, UAT, prod gibi her ortam için uç nokta URL’si veya bazı yapılandırma özellikleri farklı olabilir. Bu özelliklerin herhangi birindeki bir değişiklik, servisin yeniden derlenmesi ve yeniden dağıtılmasını gerektirebilir.


Log Aggregation

Bir uygulamanın birden çok servisten oluştuğu bir kullanım örneği düşünün. İstekler genellikle birden çok servis örneğini(instance) kapsar.


Mikro servisler için veritabanı mimarisini tanımlamak için aşağıdaki noktaları dikkate almamız gerekir.

  • Servisler gevşek bir şekilde(Loosely Coupled) birleştirilmelidir. Bağımsız olarak geliştirilebilir, dağıtılabilir ve ölçeklenebilirler.
  • Bazı ticari işlemlerin birden çok servise ait verileri sorgulaması gerekir.
  • Veritabanlarının ölçeklenebilmesi için bazen çoğaltılması ve paylaşılması gerekir.
  • Farklı servislerin farklı veri depolama gereksinimleri vardır.

Database per Service

Yukarıdaki maddeleri çözmek için mikro servis başına bir veritabanı tasarlanmalıdır; yalnızca bu servise özel olmalıdır. Yalnızca mikro servis API’si tarafından erişilmelidir. Doğrudan diğer servisler tarafından erişilemez. Örneğin, ilişkisel veritabanları için, servis başına özel tablolar, servis başına şema veya servis başına veritabanı sunucusu kullanabiliriz.


Bir mikro servis mimarisi oluştururken, karşılaşacak zorluklar çokta farklı değildir; birden çok uygulama teknolojisi, bir ağ tarafından fiziksel olarak ayrılır ve birbiriyle iletişim kurması gerekir. Mikro servis entegrasyonu, son kullanıcı açısından sorunsuz bir deneyim oluşturmada hayati bir rol oynar.

API Gateway Pattern

Bir uygulama daha küçük mikro servislere bölündüğünde, ele alınması gereken birkaç sorun vardır.

  • Farklı kanallar tarafından birden çok mikro servis için birden fazla çağrı yapılabilir.
  • Farklı tipte Protokolleri işlemeye ihtiyaç vardır.
  • Farklı tüketiciler(consumers), farklı bir yanıt formatına(soap,rest..) ihtiyaç duyabilir.

Decompose by Business Capability

Mikro servisler, tek sorumluluk ilkesini(single responsibility principle) uygulayarak servisleri gevşek bir şekilde(loosely coupled) birleştirmekle ilgilidir. İş yeteneklerine(Business Capability) göre ayrışır. İş yeteneğine karşılık gelen servisleri tanımlamak istersek, bir iş konusu, iş mimarisi(Business Arch.) modellemesinden gelen bir kavramdır. Diğer bir yandan değer üretmek için yaptığı bir işlem veya tamamlayıcı servistir. Bir iş konusu genellikle bir iş nesnesine(Business Object) karşılık gelir.


Mikro servisler, iyi dizayn edilmiş ara birimler ve işlemlerle tek işlevli modüller oluşturmaya odaklanan yazılım sistemleri geliştirmenin yenilikçi bir yöntemidir.

Organizasyonlar daha çevik olmaya, DevOps’a ve sürekli testlere doğru ilerledikçe, trend son yıllarda daha da popüler hale geldi.

Mikro servislerin Agile ve DevOps ekipleri için pek çok avantajı var. Netflix, Amazon, Twitter ve diğer teknoloji yıldızlarının tümü monolitik yapılardan mikro servis mimarisine evrildi.

Mikro servislerin aksine, monolitik bir uygulama tek, otonom bir birim olarak oluşturulmuştur. Bu, tüm sistemi etkilediği için uygulamadaki değişiklikleri yavaşlatır. Küçük bir kod bölümünde yapılan bir değişiklik, tamamen yeni bir yazılım sürümü oluşturmayı ve dağıtmayı gerektirebilir. …

mmyuksel

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store