Bağımlılıklar sizi yavaşlatmadan ayrıştırın.

Hayır. İşletim modeli, servislerin sayısına, ölçeklendirmesine ve gereksinimlerine göre belirlenir. Kubernetes uygun olabilir, ancak iş bazında ayrılmış uygulamalar için bir ön koşul değildir.

Hayır. Dağıtık sistemler ek koordinasyon ve işletim yükü getirir. Faydayı gerçek bağımlılıklarınıza ve darboğazlarınıza göre değerlendiririz.

Bağımsız geliştirme yardımcı olabilir, ancak çok sayıda dağıtık servis bunu zorlaştırabilir de. Anlamlı iş sınırlarını inceler ve iletişim, veri sorumluluğu, dağıtım ve işletim dahil olmak üzere uygun bir mimariyi hayata geçiririz.

İş birimiyle birlikte Event Storming ve Bounded Context'lerle domain ayrımı Helm, GitOps dağıtımı ve her ekip için ad alanlarıyla Kubernetes üzerinde platform REST, gRPC veya mesajlar üzerinden hizmet iletişimi; şifreleme ve yönlendirme için Service Mesh ile Dağıtık işlemler için Saga deseni ve Outbox ile her hizmet için ayrı veri tutma Kayıt tutma, yapılandırma, gizli bilgiler ve hata toleransı için işletim kuralları

Hizmet ayrımı ve arayüzlerle domain modeli Kod olarak dağıtım zinciriyle platform Her hizmet için kurallarla işletim kılavuzu

İş birimi ve geliştirme ekibiyle birlikte kavramları, kuralları ve değişiklikleri inceleriz. Düzenli olarak birlikte uyarlanması gereken işlevler dikkatsizce ayrılmamalıdır. Modüler bir monolit, dağıtık işletimi devreye almadan net sınırlar oluşturabilir. Mikroservisler bağımsız ekiplerin, yük profillerinin veya dağıtım döngülerinin gerekçelendirilebilir bir fayda sağladığı yerlerde bir seçenek haline gelir. Karar, yalnızca bir eğilime göre bir mimari seçmek yerine, işletim sonuçlarıyla birlikte belgelenir.

Birden fazla servise yayılan bir işlemde ortak bir veritabanı işlemi (transaction) kendiliğinden bulunmaz. Durum geçişlerini, geçici tutarsızlığı ve telafi edici işlemleri biz planlarız. Bir outbox yöntemi, veri değişikliğini ve yayınlanacak olayı tutarlı şekilde birbirine bağlamaya yardımcı olabilir. Yeniden denemeler iş düzeyinde idempotentlik, yani yeniden işlemede tanımlı bir sonuç gerektirir. Zaman sınırları ve bağımlılıklar, yavaş bir servisin tüm zinciri kilitlememesi için sınırlandırılır. İlgili ekiplerin bu kuralları anlayabilmesi ve test edebilmesi gerekir.

Yeni bir servis sorumluluk, izleme, yapılandırma ve güvenli bir dağıtım süreci gerektirir. Seçilmiş kısmi arızaları test eder ve yalnızca tek tek konteynerleri değil, uçtan uca işlemleri gözlemleriz. Devir mimari kararları, arayüz sözleşmelerini ve runbook'ları kapsar. Mevcut darboğazlar, ekip yapısı ve sürüm bağımlılıkları, ilk değerlendirme için en önemli temellerdir.

Bir uygulamanın hangi bölümlerinin bağımsız olarak değiştirilip işletilmesi gerektiğini inceleriz. Mikroservisler olası mimari kararlardan biridir; belirleyici olan iş sınırları, ekip sorumluluğu ve yönetilebilir işletim süreçleridir.

Her hizmetin adı belirlenmiş veri ve işletim sorumluları vardır. Kısmi arızalar, kontrolsüz yeniden denemeler olmadan ele alınır. Yeni sınır, değişiklik veya işletimde doğrulanabilir bir avantaj sağlar.

Örnek: Belge oluşturma, yük zirvelerinde bir iş uygulamasını yavaşlatır. Bu sürecin iş ve teknik bağımlılıklarını inceler, gerekirse tam olarak bu süreci ayırırız. Sonuç, net tanımlı bir görev durumu üzerinden sunulurken çekirdek süreç kontrollü şekilde çalışmaya devam eder.

Bir hizmetin anlaşılır bir iş görevi olmalıdır. Bileşenler ayrıştırılmadan önce süreçleri, veri sahipliğini ve değişiklik bağımlılıklarını inceleriz. Birden fazla hizmet aynı tabloları paylaşıyor ve her zaman birlikte yayınlanmak zorundaysa, genellikle istenen fayda olmadan yalnızca dağıtık bir bağımlılık ortaya çıkar. Eşzamanlı sorguları, eşzamansız süreç adımlarından ayırırız. Birden çok hizmeti kapsayan iş süreçleri için ara durumlar ve telafi işlemleri açıkça modellenir. Örneğin iptal edilen bir rezervasyon, tüm veritabanlarında rastgele bir teknik geri alma değil, iş düzeyinde bir eylemdir.

Birden fazla hizmetle birlikte ek ağ yolları ve olası kısmi arızalar ortaya çıkar. Zaman aşımlarını, sınırlamaları ve yeniden denemeleri, yavaş bir hizmetin tüm uygulamayı bloke etmeyeceği şekilde planlarız. Otomatik yeniden deneme, bir eylemin istemeden birden çok kez gerçekleştirilmemesini gerektirir. Devreye alma, ölçülebilir faydası olan sınırlı bir alanda gerçekleştirilir. Günlükler, izler, dağıtım ve nöbet için ortak standartlar, her hizmetin kendi işletim kurallarını icat etmesini önler. Beklenen fayda eforu haklı çıkarmıyorsa, açıkça yapılandırılmış modüler bir uygulama daha uygun çözüm olarak kalabilir.

Sistem haritası, veri akışları, darboğazlar İş birimi, BT işletimi, mimari, OTOKO® entegrasyon mimarı Arayüz envanteri, değerlendirilmiş riskler, önceliklendirilmiş entegrasyon durumları

Entegrasyon mimarisi, arayüz kataloğu, işletim modeli Mimari, bilgi güvenliği, veri koruma, iş birimi Hedef mimari, nesne başına veri sahipliği, güvenlik gereksinimleri, işletim modeli