Cloud And Servers
Published in

Cloud And Servers

SoundCloud’ın Mikroservis’e Geçişi

SoundCloud Microservices

Geçen gün microXchg 2016 videolarını izlerken karşıma çıkan bir video. Bora Tunca SoundCloud mikroservis yapısına nasıl geçirdiklerini , karşılaştıkları zorlukları, BFF Patterni ile hangi problemleri çözdüklerini anlatıyor. Vakti olanların mutlaka izlemelerini tavsiye ediyorum.

Ben yine bir kaç ekran görüntüsü ile kısaca Video’dan çıkardığım dersleri , yorumlarımı aşağıda yazayım.

İlk başta SoundCloud Monolitic/Layered bir Mimaride Geliştiriliyor

SoundCloud vb.. çok kişiye hizmet veren projelerde gördüğüm en baştan sistemlerini mikroservis’in üzerine kurmamışlar. İlk önce bilinen mimari yöntemle geliştirip Örn : Monolithic/Layer mimari. Sonradan bu mimarinin yetmediği , yeni ihtiyaçların gereksinimlerin çıktığı için mikroservis yapısına geçmişler.

Monolithic/Layered
Mothership CodeBase

İlk Microservis Denemelerini Ana Mimarileri Üzerinde Gerçekleştiriyorlar

Biraz öncede bahsettiğim gibi sistemi oturup baştan Mikroservis bir yapıda tasarlamıyorlar. Public API’nin arkasına yeni gelen istekler ve ihtiyaçlar doğrultusunda bazı servislerini mikroservis olarak yazmışlar.

Microservis Sayısı Arttıkça Mikroservis Problemleri İle Karşılaşmaya Başlıyorlar.

Mikroservis sayısı az iken herşey güllük gülüstanlık. Herkes istediği teknoloji , patternleri, frameworkleri seçerek geliştirme yapabiliyor, geliştiriciler mutlu. Fakat mikroservis sayısı artmaya başladıktan sonra 60–70 mikroservise ulaştıklarında birçok problemlerle karşılaşmaya başlamışlar;

  • Organizasyon Problemleri
  • Production çalışan birçok mikroservis var ve bir bütün olarak sistemin nasıl çalıştığını ve davrandığını anlama problemleri
  • İlk baştaki sistem her mikroservis’in her mikroservis ile rahatça iletişim kurabildiği bir ortam olduğu için ortaya Kaotik ortamlar çıkmış. (Zaten ilerde Patternlerle bu sorunları nasıl aşmaya çalıştıklarını anlatacaklar)

Organizasyonel Problemleri Çözebilmek için Engineering Organization Üzerinde Kullandıkları Yöntem (Humane Registry) ve Servis Visibility’si için (Service Directory)

Geçmiş yazılarımda Conway yasasından bahsetmiştim. Organizasyon Yapınız sizin ne şekilde ürün geliştireceğinizi belirler.

  • Kaç tane mikroservis var. ?
  • Hangi takımlar bu mikroservis üzerinde çalışıyor ?
  • Mikroservis’in Sahibi kim ?
  • Ürün Production gittikten sonra Takımlar değişip herkes yeni Feature odaklantıktan sonra tekrar doğru kişiyi(mikroservisin o içeriği konusunda deneyimli) nasıl ulaşabiliriz ?
  • Servislerin Neler olduğu
  • Servislerin hangi teknolojileri kullandığı
  • Servislerin hangi servisleri bağımlı olduğu ?

İhtiyaçlardan Dolayı (Business Use Case’lerden Dolayı) öncelikle dışarıya servis veren Tek Public API çoklamışlar.

BFF Pattern’i ve SoundCloud Bunu Nasıl Uyguluyor ?

Bu konuyu ilerleyen yazılarımda daha detaylı anlatacağım. Bu konu başlı başına bence ayrıca bir yazı. Onun için sadece videodan 1 ,2 ekran görüntüsü ekleyerek bu kısmı geçiyorum.

Monitoring için Hangi Araçları Kullanıyorlar ?

Monitoring için aşağıdaki Slayt’da gösterilen gereksinimlerden dolayı kendi monitoring araçlarları Prometheus geliştirmişler.

Monitoring

Distributed Tracing için hangi araçları kullanıyorlar ?

Hangi servislerde nekadar zaman harcandı bilgisini Zipkin aracı kullanarak takip ediyorlar.

Service Level Objectives

Mikroservisin SLA belirleyip canlı ortamda bu beklentileri karşılayıp , karşılamadığı konusunda bilgileri görüntüleyebiliyorlar.

Okumaya Devam Et 😃

Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.

--

--

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