Teslim ve ürün
Mikroservise bir planla geçin
Monolitten çıkma kararı verildi, ama sıra, sınırlar ve platform belli değil. Sınırları bulur, geçişi sıralar ve ilk servisleri ekiplerinizle birlikte teslim ederiz.
- Süre
- 4 ila 12 ay
- Model
- Aşamalı program
- Çıktı
- Üretimde ilk servisler ve sıralı plan
Monolitin ekipleri tuttuğunu gösteren işaretler
Sorun nadiren monolitin kendisidir. Sorun, her ekibin aynı kodu aynı anda değiştirmek zorunda olmasıdır.
- Her özellik aynı kod tabanına ve aynı sürüme dokunduğu için ekipler birbirini bekliyor.
- Tam bir derleme ve test çalıştırması o kadar uzun sürüyor ki mühendisler değişikliklerini biriktiriyor.
- Sistemin bir parçasının ölçeklenmesi gerekiyor, ama tek seçenek hepsini ölçeklemek.
- Mikroservise geçiş duyuruldu, ama hangi servisin önce geleceğini ve nedenini kimse söyleyemiyor.
- İlk servis ayrıldı ama veritabanını hâlâ monolitle paylaşıyor.
- Servis sayısı artıyor, ama dağıtım, izleme ve nöbet düzeni ayak uyduramıyor.
- Farklı ekipler farklı kurallarla servis yazıyor ve sonuç şimdiden dağıtık bir monolite benziyor.
Önce sınırlar, sonra servisler
Başarısız mikroservis geçişlerinin çoğu sistemi teknik katmanlara ya da günün organizasyon şemasına göre böler. Sonuç; birlikte değişmek zorunda olan, birbirini sürekli çağıran ve veriyi paylaşan servislerdir. Bu, fazladan ağ adımları olan dağıtık bir monolittir.
Biz alandan başlarız. Domain-driven design ile veri sahipliğinin ve değişim desenlerinin örtüştüğü bounded context’leri buluruz ve ekiplerinize ne kadar bağımsızlık kazandıracaklarına göre sıralarız. Bazen sistemin bir bölümü için doğru cevap modüler bir monolittir ve bunu açıkça söyleriz.
Geçiş, her ayrıştırma küçük, geri alınabilir ve tek başına faydalı olacak şekilde sıralanır. Dağıtım, gözlemlenebilirlik ve servis şablonları gibi platform ön koşulları servis sayısı artmadan önce kurulur, sonra değil.
Kapsam
Dahildir
- Alan ve bounded context keşfi
- Aday servislerin ekip bağımsızlığı ve riske göre sıralanması
- Her adım için çıkış kriterleriyle geçiş sırası
- Geçiş sırasında veri sahipliğinin ayrılması ve senkronizasyonu
- Servis şablonu: derleme, dağıtım, izleme, güvenlik
- İlk üç servisin ekiplerinizle birlikte teslimi
- Yeni servisler için mimari yönetişim
- Teslim hızının önce ve sonra ölçülmesi
Dahil değildir
- Bütün sistemin tek seferde yeniden yazılması
- Değerine bakılmadan her şeyin servislere bölünmesi
- Ekip yeniden yapılanması ve insan kaynakları kararları
- Devirden sonra servislerin uzun vadeli işletimi
Program nasıl ilerler
- Ay 1 ila 2Sınırları bulun. Event storming ve kod analizi bounded context’leri ortaya çıkarır. Aday servisler sıralanır ve hedef bir bağlam haritası olarak çizilir.
- Ay 2 ila 3Platformu hazırlayın. Her yeni servisin aynı şekilde başlaması için bir servis şablonu, dağıtım hattı ve gözlemlenebilirlik temeli kurulur.
- Ay 3 ila 9Sırayla ayrıştırın. İlk servisler ekiplerinizle birlikte tek tek ayrıştırılır; her birinin kendi verisi ve kanıtlanana kadar bir geri dönüş yolu olur.
- Son aylarYönetişimi kurun ve devredin. Karar kayıtları, inceleme ritmi ve kalan sıra devredilir; ekipleriniz bizsiz devam edebilir.
Elinize geçenler
Servisler, şablon ve plan ilk günden itibaren sizindir.
Bu hizmet kimin için değil
- Tek bir ürün üzerinde çalışan küçük ekipler. İyi yapılandırılmış modüler bir monolit onlara genellikle daha iyi hizmet eder ve bunu öneririz.
- Tüm servislerin bizim tarafımızdan teslim edilmesini bekleyen kurumlar. Hedef, tek başına devam edebilen ekiplerdir.
- Sınırlar bilinmeden bütün sistem için sabit bir bitiş tarihi belirlenmiş geçişler.
Sık sorulanlar
Ya mikroservis bizim için doğru cevap değilse?
O zaman bunu söyleriz. Sistemin bir bölümü ya da tamamı için net iç sınırları olan modüler bir monolit çoğu zaman daha iyi bir seçimdir; bağlam haritası her iki durumda da işe yarar.
Ortak veritabanını nasıl ele alıyorsunuz?
Veri sahipliği her servisle birlikte taşınır. Geçiş sırasında veri olaylarla ya da değişiklik yakalama (CDC) ile senkronize edilir; servis kendi verisinin sahibi olduğunda eski tablolar emekliye ayrılır.
Hangi servis önce gelmeli?
Genellikle sınırları net, bir ekibe gerçek değer katan ve bağımlılığı sınırlı olan. İlk ayrıştırma şablonu ve platformu kanıtlar; bu yüzden düşük riskli bir aday, gösterişli bir adaydan daha değerlidir.
Bunun Sistem Modernizasyonu’ndan farkı ne?
Sistem Modernizasyonu eskiyen kodu sistemi durdurmadan değiştirmeye odaklanır. Bu program ekip bağımsızlığına odaklanır: sınırlar, servisler, platform ve yönetişim.
Ekiplerimizin değişmesi gerekiyor mu?
Servis sınırları en iyi, ekip sahipliğiyle örtüştüğünde çalışır. Nerede ayrıştıklarını ve bunun maliyetini gösteririz; organizasyon kararları sizde kalır.
Önce kısa bir teknik sohbetle başlayalım
Otuz dakika. Monoliti ve etrafındaki ekipleri anlatırsınız, biz ilk sınırın büyük olasılıkla nerede olduğunu söyleriz.