Emin olduğum şey: dağıtım en son yapılır
Monolith-first tartışmasına cevap: iki cevap da tasarımı değil dağıtımı anlatıyor. İlk yapılması gereken mantıksal servis sınırlarını bulmak; fiziksel dağıtım ise ayrı ve maliyetli bir karar, ölçekleme, uyumluluk veya release temposu gerektirdiğinde en son verilmesi gereken bir karar.
Kilit noktalar
- Monolith-first ve microservices-first, mantıksal tasarımı değil fiziksel dağıtımı tarif ediyor; bu yüzden seçim çok erken yapılmış oluyor.
- En pahalı hata yanlış yere konan sınır: aradaki mesafe namespace de olsa ağ da olsa, birlikte değişmesi gereken veriyi ikiye bölüyor.
- Her servisi dağıtılmış gibi tasarlayın: kendi verisi, mesaj tabanlı kontratlar, outbox ile eventual tutarlılık, kullanıcıya yakın yerlerde birleştirme.
- NServiceBus'ın yeni non-durable transport'u messaging'i tek süreç içinde bellekte çalıştırıyor; broker eklemeden kalıplarla başlanabiliyor.
- Dağıtımı ayırma gerekçeleri operasyonel veya organizasyonel: bağımsız ölçekleme, güvenlik izolasyonu, hata izolasyonu, release temposu ya da farklı teknoloji yığını.
- Bir servis başka bir servisin tablolarını okumuyorsa, bir bileşeni kendi host'una taşımak yeniden yazım değil sadece dağıtım değişikliği.
Makale, monolith mi microservices mi tartışmasının erken sorulmuş bir soruya cevap verdiğini anlatıyor: iki seçenek de sistemin nasıl tasarlandığını değil, nasıl dağıtıldığını tarif ediyor. Yazar, ilk adımın mantıksal sınırları bulmak olduğunu söylüyor; hangi verilerin birlikte durması ve hangi yeteneklerin birlikte değişmesi gerektiği belirleyici. Aday sınırları iş paydaşlarına test ettirmek için anti-requirements tekniğini öneriyor.
Sınırlar netleşince modüller kendilerini dağıtılmış gibi davranmalı: her servis kendi verisinin sahibi, iletişim command ve event üzerinden, servisler arası tutarlılık outbox ile eventual, birleşik veri ise UI veya gateway tarafında oluşturuluyor. NServiceBus'ın non-durable transport'u broker eklemeden süreç içi messaging sağlıyor. Dağıtımı ayırmak son adım; ölçekleme, uyumluluk, hata izolasyonu veya release temposu gerektirdiğinde yapılıyor ve geri alınabiliyor.
Gerçek dünyada kullanımı
- Sales, Shipping ve Payments'ın tek host'ta ayrı mantıksal servisler olarak çalıştığı, ödeme tarafının ölçeklenmesi veya uyumluluk için izole edilmesi gereken bir online mağaza.
- Broker kurmadan messaging kalıplarını denemek isteyen, tek süreç içinde bellekte çalışan transport'u kullanan bir ekip.
- Okuma modeli birden fazla servisten veri gerektiren ve bunu ortak veritabanında join yerine UI veya gateway tarafında birleştiren bir sistem.
- Release treni darboğaz olan büyüyen bir monolith'te, handler'lara dokunmadan bir bileşenin kendi host'una taşınması.
Neden önemli
Sınırları doğru koymak pahalı ve geri dönmesi zor karar; dağıtım topolojisi ise çevrilebilir bir ayar. Sınırlar temizse bir bileşeni sonradan baskı altında yeniden tasarlamadan kendi sürecine taşıyabilirsiniz.