01Sorun ve çözüm
Monolitten mikroservise geçiş hizmetimizde önce bu ayrışmanın gerçekten gerekli olup olmadığını değerlendiriyoruz. Gerekliyse uygulamanızı iş alanlarına göre analiz edip ayrılmaya en uygun parçayı seçiyor, onu verisiyle birlikte bağımsız bir servise dönüştürüyor ve trafiği kademeli olarak yeni servise aktarıyoruz. Monolit küçülerek çalışmaya devam eder; geçiş bir defada değil, servis servis gerçekleşir.
02Kimler için
Monolitten mikroservise geçiş kimler için anlamlı
Geçişin maliyetini, sağladığı bağımsızlık karşılayabiliyorsa anlamlıdır.
- Birden fazla geliştirme ekibinin aynı kod tabanında çalıştığı ve dağıtımların sıraya girdiği ürün şirketleri
- Belirli modülleri ötekilerden çok daha yoğun yük alan ve bunları ayrı ölçeklemek isteyen platformlar
- Farklı müşteri gruplarına farklı sürüm ve özellik setleriyle hizmet vermesi gereken SaaS ürünleri
- Monolitin bir bölümünü farklı bir teknolojiyle yeniden yazmak zorunda kalan ekipler
- Bir modüldeki arızanın bütün sistemi durdurduğu ve hata yalıtımına ihtiyaç duyan işletmeler
03İhtiyaçlar
Ayrıştırmada en çok zorlanılan konular
Mikroservis projeleri genellikle kod yüzünden değil, veri ve sınır kararları yüzünden zorlaşır.
- 01
Paylaşılan veritabanı
Monolitte her modül her tabloya doğrudan erişir. Servisleri ayırıp veritabanını ortak bırakmak, dağıtık bir monolit üretir: bağımsız dağıtılamayan ama ağ üzerinden konuşan parçalar.
- 02
Yanlış çizilen sınırlar
Teknik katmanlara göre, örneğin bütün raporları bir servise toplayarak yapılan ayrım, servisler arasında yoğun bir çağrı trafiği yaratır. Sınırlar iş alanlarına göre çizilmelidir.
- 03
Dağıtık işlem tutarlılığı
Sipariş, stok ve ödeme farklı servislere ayrıldığında tek bir veritabanı işlemiyle güvence altına alınan tutarlılık kaybolur. Saga ve outbox gibi kalıplarla telafi akışları tasarlanmalıdır.
- 04
Operasyon yükü
Tek bir uygulama yerine birçok servisin izlenmesi, kayıtlarının toplanması ve sürümlerinin yönetilmesi gerekir. Bu altyapı hazır olmadan ayrıştırmaya başlamak, arızaların nedenini bulmayı zorlaştırır.
04Özellikler
Monolitten mikroservise geçiş hizmeti adımları
Her adımın sonunda sistem çalışır durumdadır ve bir önceki duruma dönülebilir.
- 01
Alan analizi ve sınır haritası
Alan güdümlü tasarım yaklaşımıyla iş alanları, aralarındaki bağımlılıklar ve hangi verinin hangi alana ait olduğu çıkarılır. Sonuç, aday servislerin ve ayrılma sırasının yer aldığı bir haritadır.
- 02
Önce modüler monolit
Çoğu durumda ilk adım, monolitin içinde modüller arası sınırları kod düzeyinde sertleştirmektir. Bu adım tek başına ekip bağımsızlığının önemli bir kısmını sağlayabilir ve ayrıştırmayı ucuzlatır.
- 03
İlk servisin ayrılması
Bağımlılığı az, iş değeri net bir modül seçilir; kodu ve verisi ayrı bir servise taşınır. Yönlendirme katmanı ilgili istekleri yeni servise gönderir, monolitteki eski kod devreden çıkar.
- 04
Olay tabanlı iletişim
Servisler arasında anlık yanıt gerekmeyen durumlarda mesaj kuyrukları kullanılır; sipariş oluştuğunda stok ve bildirim servisleri bu olayı kendi hızlarında işler.
- 05
Gözlemlenebilirlik altyapısı
Merkezi kayıt toplama, servisler arası istek izleme ve servis bazlı metrikler, ilk servis ayrılmadan önce kurulur.
05Entegrasyonlar
Geçişte kullanılan altyapı bileşenleri
Bileşen seçimi ekibinizin işletebileceği karmaşıklık düzeyine göre yapılır.
- 01
API ağ geçidi
Dış istemcilerin tek bir adres üzerinden servislere ulaşmasını, kimlik doğrulamanın ve istek sınırlamanın merkezde yapılmasını sağlar.
- 02
Mesaj altyapısı
Apache Kafka ya da RabbitMQ gibi araçlarla olayların güvenilir biçimde iletilmesi ve gerektiğinde yeniden işlenmesi sağlanır.
- 03
Kapsayıcı ve orkestrasyon
Docker imajları ve Kubernetes ya da AWS, Azure, Google Cloud üzerindeki yönetilen kapsayıcı hizmetleriyle her servis bağımsız dağıtılır ve ölçeklenir.
- 04
İzleme ve dağıtık izleme
OpenTelemetry ile toplanan izler, Prometheus ve Grafana gibi araçlarla görselleştirilerek bir isteğin hangi serviste yavaşladığı görülür.
06Süreç
Monolitten mikroservise geçiş hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Mikroservis kararında dürüst değerlendirme
Mikroservis mimarisi bir hedef değil, belirli sorunlara karşı bir araçtır. Tek bir ekibin geliştirdiği ve yük dağılımı dengeli bir uygulamada, servislere ayırmak genellikle teslim hızını artırmaz, aksine ağ gecikmesi, dağıtık hata ayıklama ve altyapı maliyeti ekler. İlk değerlendirmede bu durumu tespit edersek modüler monolit ve dağıtım hattının iyileştirilmesi gibi daha sade seçenekleri öneririz.
Devamını okuDaha az göster
Ekip yapısı mimariyle birlikte düşünülür. Bir servisin sahibi olan ekibin, o servisin kodundan, verisinden ve canlıdaki davranışından sorumlu olması gerekir. Servis sınırları ekiplerin sınırlarıyla örtüşmediğinde, ayrılan kod yine ortak toplantılarda koordine edilmek zorunda kalır.
Güvenlik tarafında servisler arası iletişim şifrelenir, her servis yalnızca ihtiyaç duyduğu veriye erişir ve kimlik bilgileri merkezi bir gizli bilgi yönetim aracında tutulur. Kişisel veri barındıran servisler ayrıca belirlenir; verinin hangi serviste, ne kadar süreyle tutulduğu belgelenir.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Danışmanlık
Saatlik veya günlük teknik danışmanlık
Karar, denetim veya yön belirleme gereken durumlar için.
- Saatlik veya günlük çalışma
- Yazılı rapor ve öneriler
- Ekibinizle birlikte çalışma
09Sık sorulan sorular
Monolitten mikroservise geçiş hakkında sık sorulan sorular
Monolitten mikroservise geçiş fiyatları nasıl belirlenir?
Monolitin büyüklüğü, modüller arası bağımlılık yoğunluğu, ayrılacak servis sayısı, veritabanı ayrıştırmasının zorluğu ve mevcut altyapının olgunluğu belirleyicidir. Çalışma genellikle bir değerlendirme aşamasıyla başlar; ardından servis bazlı teklif verilir.
Bütün uygulamayı mikroservislere bölmek zorunda mıyız?
Hayır. Çoğu sistemde yalnızca ayrı ölçeklenmesi ya da bağımsız geliştirilmesi gereken birkaç alan servise dönüştürülür; geri kalanı iyi düzenlenmiş bir monolit olarak kalabilir.
Geçiş sırasında sistem kapanır mı?
Hayır, planın temel ilkesi sistemin çalışmaya devam etmesidir. Her servis ayrı ayrı devreye alınır ve trafik kademeli olarak aktarılır; sorun çıkarsa istekler yeniden monolite yönlendirilebilir.
Mikroservislere geçmek performansı artırır mı?
Tek başına artırmaz. Doğru ayrılmış bir servisi bağımsız ölçekleyebildiğiniz için yoğun yük altındaki davranış iyileşebilir; ancak servisler arası ağ çağrıları gecikme ekler. Performans sorunu varsa önce darboğazın nerede olduğunu ölçeriz.
Ekibimizin mikroservis deneyimi yok; sonrasında sistemi nasıl yöneteceğiz?
Geçiş boyunca ekibinizle birlikte çalışır, servis şablonları, dağıtım hattı ve izleme panoları üzerinden işletim pratiklerini aktarırız. İlk servisler bizimle, sonrakiler ekibinizin önderliğinde ayrılır.
Monolitten mikroservise geçiş firması olarak hangi teknolojileri kullanıyorsunuz?
Teknolojiyi mevcut ekibinizin dili ve altyapınıza göre seçeriz. Servislerin aynı dilde yazılması zorunlu değildir, ama gereksiz çeşitlilik bakım yükünü artırdığı için sınırlı tutulmasını öneririz.
10İlgili hizmetler