Uber'ın Domain-Oriented Microservice Architecture yaklaşımı

DOMA, 2200 mikroservise sahip Uber'in, MSA'nın esnekliğini korurken karmaşıklığı azaltmak için benimsediği yaklaşım

• DDD, SOA, OO, CA gibi yaklaşımlardan alınarak büyük organizasyonlardaki geniş ölçekli dağıtık sistemlere uygun biçimde tasarlanmış

• Uzun süre MSA işleten Uber'in yıllara yayılan deneyimini yoğun biçimde yansıtan bir yazı

DOMA'nın temel ilkeleri

1. Mikroservisleri domain bazında koleksiyonlar halinde toplamak

2. Layer adı verilen domain koleksiyonları oluşturup, her katman içinde bağımlılıklara izin vermek → Layer Design

3. Her koleksiyon için tek giriş noktası olarak temiz bir arayüz sunan bir Gateway oluşturmak

4. Her domain diğer domain'lerden bağımsız olmalı. Ancak çoğu zaman başka domain'lerin mantığını içermek gerektiğinden, bunu iyi destekleyen bir Extension mimarisi sunmak

** Uber'in uygulaması

• Domains

→ Mantıksal olarak gruplanmış bir veya daha fazla mikroservisten oluşan topluluk.

→ Bir domain'de 10'dan fazla servis de olabilir, yalnızca bir servis de olabilir

→ Örnek) harita arama, ücretlendirme, eşleştirme platformu (yolcu ve sürücü) birer domain

→ Şirketin organizasyon yapısını takip etmediği için Uber'in harita ile ilgili organizasyonu 3 domain, 80 mikroservis ve 3 gateway'den oluşuyor

• Layer Design

→ "Hangi servis hangi diğer servisi çağırabilir?" sorusunun yanıtı

→ "separation of concerns at scale" veya "dependency management at scale" → Uber 5 Layer'dan oluşuyor

1. Infrastructure : tüm organizasyonun kullanabileceği işlevler. Depolama/ağ gibi

2. Business : iş birimi seviyesinde kullanılabilecek işlevler. Belirli bir ürün kategorisi ya da Rides, Eats, Freight gibi LOB'larla (Line Of Business) sınırlı değil

3. Product : belirli ürün kategorileri ve LOB'larla ilişkili işlevler; ancak birden çok uygulamanın birlikte kullandığı Request a ride gibi özellikler de olabilir

4. Presentation : kullanıcıya yönelik uygulamalarla ilgili işlevler (mobil / web)

5. Edge : Uber servislerini dışarıya güvenli biçimde açan katman. Mobil uygulamalarla da bağlantılı

• Gateways

→ Mikroservislerdeki API Gateway'den çok farklı değil. Ancak bunu bir domain'e bağlanan tek giriş noktası (Single Entry-point) olarak düşünmek gerek

→ İçeride dış dünyaya karşı tek bağımlılık oluştuğu için migration, discovery ve genel sistem karmaşıklığı azalıyor

• Extensions

→ Servis implementasyonunu değiştirmeden veya kararlılığı etkilemeden domain'i genişletmeye yarayan mekanizma

1. Logic genişletmesi : Provider veya Plugin pattern kullanarak servis mantığını genişletmek

2. Data genişletmesi : çekirdek verinin büyümesini önlemek için keyfi veriyi iliştirme mekanizması. Protobuf'un Any tipini kullanıyor

3. Custom genişletmesi : ekiplerin domain'e uygun şekilde kendi pattern'leriyle genişletme yapması

Onboarding süresini %25~50 azaltma etkisi

2200 mikroservis 70 domain'e ayrılmış durumda.

Uber'de mikroservislerin yarı ömrü 1,5 yıl olarak hesaplanmış. Yani her 1,5 yılda mikroservislerin %50'si ortadan kalkıyor.

Gateway olmazsa her kayboluş dalgasında migration cehennemi yaşanıyor.

Uber'de DOMA ile tasarlanan platformların çok daha kolay ölçeklendiği ve bakımının daha kolay olduğu kanıtlanmış.

Diğer şirketler için pratik tavsiyeler

• Startup'lar :

→ "MSA'yı ne zaman benimsemeliyiz?" ve "Organizasyonumuz için uygun mu?" soruları önemli.

→ MSA, çok sayıda mühendise sahip organizasyonlarda operasyonel avantaj sağlayabilir; ancak karmaşıklığı artırarak özellik geliştirmeyi zorlaştırabilir

→ Küçük organizasyonlarda operasyonel faydadan çok mimari karmaşıklık artışı getirebilir ve daha maliyetli olabilir.

→ Yavaş yavaş benimsemek de makul; MSA'ya geçilecekse bunu "büyük ölçekli dağıtık program" gibi düşünerek mikroservisler arasında ayrım yapılmalı.

→ İlk mikroservisler işin temel işlevlerini tanımlarken önemli olacak ve uzun ömürlü kalacaktır

• Orta ölçekli şirketler :

→ Şirket birden çok ekibe bölündüğünde ve platformlar arasında ilgi alanları ayrışmaya başladığında MSA daha faydalı hale gelir

→ Bu aşamada mikroservisler arasında katmanlı yapıyı düşünmek mümkündür; daha fazla servis kullanılmaya başladıkça bağımlılık yönetimi önemli hale gelir

→ Mikroservis sayısı hâlâ çok fazla olmayabilir, bu yüzden clustering anlamlı olmayabilir; ancak domain odaklı düşünmek faydalıdır

• Büyük şirketler :

→ Büyük mühendislik organizasyonlarında yüzlerce mühendis, mikroservis ve bağımlılık bulunduğu için DOMA son derece faydalı

→ Gateway'e sahip domain'ler halinde kolayca gruplanabilir; legacy sistemleri refactor etmek veya yeniden yazmak gerektiğinde de gateway çok işe yarar

Uber'de de giderek daha fazla ekip DOMA'yı benimsiyor. (Uber'in tüm organizasyonundan yaklaşık 60 kişinin birlikte katılıp 2 yılda oluşturduğu söyleniyor.)

[algedian]

https://eng.uber.com/microservice-architecture/

Şu anda düzgün görüntüleniyor gibi ama.. Wayback Machine'dekinde görseller biraz farklı gibi.

[xguru]

Ah, yeniden düzelmiş görünüyor haha. Eski haline geri çevirdim.

Görselde ayrıntılı servis adlarının görünmesi sorunmuş gibi görünüyor.

[jaeyeonling]

Görünüşe göre yazı silinmiş T.T

[xguru]

Ah, gerçekten öyleymiş. Şimdilik Wayback Machine üzerinden görülebiliyor.

https://web.archive.org/web/20200803012939/…

[jaeyeonling]

Teşekkür ederim :)