Monolitik bir sistemi mikroservislere bölmek, çoğu ekibin sandığından çok daha fazla organizasyonel bir karardır. Dokuz ay süren bir modernizasyon projesinde beş temel hata yaptık; hepsi de teknik değil.
1. Servis sınırlarını veritabanı tablolarına göre çizmek
İlk denememizde servisleri tablo gruplarına göre ayırdık: "kullanıcı servisi", "sipariş servisi", "ürün servisi". Kulağa mantıklı geliyordu. Sonuç: her istekte üç servis birbirini çağırıyor, ağ gecikmesi monolitteki fonksiyon çağrısının yüzlerce katına çıkıyordu.
Alan sınırlarını iş yeteneklerine göre yeniden çizdiğimizde — "sipariş alma", "stok ayırma", "tahsilat" — servisler arası çağrı sayısı üçte bire düştü. Doğru sınır, birlikte değişen şeyleri bir arada tutan sınırdır.
2. Dağıtık transaction beklemek
İki servis arasında ACID garantisi aramak, mikroservis mimarisinin doğasına aykırı. Aylarca iki fazlı commit denemeleriyle uğraştık.
Doğru cevap: olay tabanlı nihai tutarlılık. Sipariş oluşturulur, olay yayınlanır, stok servisi tüketir. İşlem başarısız olursa telafi olayı gönderilir. Tüketicilerin idempotent olması şart — aynı olay iki kez işlense bile sonuç değişmemeli.
3. Gözlemlenebilirliği sona bırakmak
Monolitte hata ayıklamak bir stack trace okumaktır. Dağıtık sistemde bir isteğin altı servis arasında nerede kaybolduğunu bulmak, iz takibi olmadan neredeyse imkânsız.
OpenTelemetry'yi ilk sprintte kurmalıydık. Beşinci ayda kurduk ve o güne kadar harcadığımız hata ayıklama süresinin büyük kısmı boşa gitti.
4. Aynı anda çok fazla servis çıkarmak
Üçüncü ayda dört servisi paralel çıkarmaya çalıştık. Her biri diğerinin bitmesini bekledi, entegrasyon testi yapılamadı, hiçbiri yayına giremedi.
Strangler pattern ile tek tek ilerlemek çok daha güvenli: monolitin önüne bir yönlendirme katmanı koyun, bir yeteneği yeni servise taşıyın, trafiği kademeli çevirin, doğrulayın, sonrakine geçin.
5. Ekip yapısını değiştirmemek
Conway yasası kaçınılmaz: sistemin mimarisi, onu üreten organizasyonun iletişim yapısını yansıtır. Servis sınırları ekip sınırlarıyla örtüşmediğinde her küçük değişiklik üç ekibin onayını gerektirdi ve teslim hızı monolitteki halinden daha yavaş oldu.
Ne zaman mikroservise geçmemeli?
Dürüst olalım: birçok ekip için doğru cevap modüler bir monolittir. Mikroservis; farklı ölçekleme ihtiyacı, bağımsız teslim gerekliliği ve bunu taşıyacak operasyon olgunluğu varsa anlamlıdır. Sadece "modern" olduğu için geçilmez.
