Her şeyi birbirinden ayırın. Servislerin birbirlerinin çalışma süresi beklentileri üzerinden değil, olaylar aracılığıyla iletişim kurmasını sağlayın.

Monolitinizi bir dağıtım darboğazı haline gelmiş durumda — her değişiklik ekipler arasında koordinasyon gerektiriyor ve faturalandırmadaki bir hata tüm uygulamayı çökertiyor. Ya da farklı yeteneklerin farklı hızlarda geliştiği yeni bir sistem kuruyorsunuz: sipariş yönetimi haftalık değişirken, envanter mantığı üç ayda bir değişiyor. Bağımsız olarak geliştirilebilen, dağıtılabilen ve ölçeklenebilen, basamaklı hata zincirleri oluşturan senkron API çağrıları yerine olaylar aracılığıyla iletişim kuran servislere ihtiyacınız var.
Explore more design patterns and system architectures
Mimarlarımız, bu deseni kullanarak belirli gereksinimleriniz için sistemler tasarlamanıza ve oluşturmanıza yardımcı olabilir.
İletişime GeçinOlay odaklı mikroservisler, bir sistemi, esas olarak eş zamansız olaylar aracılığıyla iletişim kuran, bağımsız olarak dağıtılabilir servislere ayırır. Her servis kendi verisine sahiptir, durum değişikliklerinde domain olayları yayımlar ve diğer servislerden gelen olaylara tepki verir. Bu, zamansal bağımlılığı ortadan kaldırır — Servis A'nın işini yapması için Servis B'nin çalışıyor olması gerekmez. Desen, yazma ve okuma modellerini ayırmak için CQRS (Command Query Responsibility Segregation), durum değişikliklerinin tam geçmişini yakalamak için event sourcing ve dağıtılmış kilitler olmadan çok servisli işlemleri yönetmek için saga orchestration'ı içerir.
Mimari, servisler arasında domain olaylarını yönlendiren bir olay omurgası (Kafka, EventBridge veya NATS) üzerine kuruludur. Her servisin üç sınırı vardır: gelen istekleri işleyen ve olayları yayan bir komut işleyici, okuma için optimize edilmiş projeksiyonlar sunan bir sorgu işleyici ve diğer servislerden gelen olaylara tepki veren bir olay işlemcisi. Bir saga orchestrator, adımlar başarısız olduğunda olayları dinleyerek ve telafi edici komutlar vererek çok adımlı iş süreçlerini (örneğin, sipariş yerine getirme) koordine eder.
| Katman | Teknolojiler |
|---|---|
| Compute | Node.js (NestJS), Python (FastAPI), Go — iş yükü özelliklerine göre servis başına |
| Messaging | Apache Kafka (MSK), AWS EventBridge, NATS JetStream, RabbitMQ |
| Veri | PostgreSQL (transactional), DynamoDB (key-value), Redis (caching/locks), EventStoreDB |
| Orchestration | Temporal (iş akışı orchestrator), AWS Step Functions, özel saga koordinatörü |
| Gözlemlenebilirlik | OpenTelemetry (dağıtılmış izleme), Datadog, Jaeger, correlation ID'li yapısal günlükleme |
| Kullanılacak Durumlar | Kaçınılacak Durumlar |
|---|---|
| Birden çok ekip farklı zaman dilimlerinde bağımsız olarak dağıtım yapmalıysa | Ekibiniz < 5 mühendisten az ise — iyi yapılandırılmış bir monolit işletmesi daha basittir |
| Sistemin farklı bölümleri farklı ölçeklendirme özelliklerine sahipse | Bir MVP geliştiriyorsanız ve hızlı bir şekilde yayınlamanız gerekiyorsa — dağıtılmış sistemlerin inşası yavaştır |
| Güçlü denetim izlerine ve olay tekrar oynatma yeteneklerine ihtiyacınız varsa | Her işlem senkronize, güçlü tutarlı yanıtlar gerektiriyorsa |
| Domain doğal bounded context'lere sahipse (siparişler, ödemeler, envanter) | Domain sıkıca bağlıysa — onu bölmek dağıtılmış bir monolit oluşturur |
MW, teknik katmana göre (API servisi, veri servisi, auth servisi) mikroservislere ayrılmaz. DDD (Domain-Driven Design) bounded context'lerini kullanarak domain sınırları boyunca ayrıştırırız. Kod yazmadan önce, domain olaylarını, komutlarını ve aggregate'lerini haritalamak için bir event storming workshop'u düzenleriz — bu, teknoloji tercihlerini değil, servis sınırlarını belirler. Monolitleri kurumsal müşteriler için olay odaklı mimarilere taşıdık ve en yaygın ders şudur: daha az, daha büyük servislerle başlayın ve daha sonra bölün, tersi değil.
Modeller kendi başlarına çalışmaz. Modellerinizi eğiten, doğrulayan, dağıtan ve izleyen iş akışı asıl üründür; model sadece bir eserdir.
MicrocosmWorks, kesintiler sırasında veri kaybı yaşanmamasını sağlamak amacıyla, tüketiciler onları başarıyla işleyene kadar olayları saklayan Apache Kafka veya Amazon EventBridge gibi kalıcı mesaj aracılarıyla olay odaklı sistemler tasarlar. Başarısız olan bir mikroservisin tüm olay hattını engellememesi için dead-letter queues, exponential backoff retry policies ve circuit breakers uygularız. Aşağı akış hizmeti iyileştiğinde, manuel müdahale olmadan işlenmemiş olaylara otomatik olarak yetişir.
Hizmetlerinizin anında yanıt gerektirmediği, dağıtım döngülerini birbirinden ayırmanız gerektiği veya tek bir eylemin birden fazla sonraki süreci tetiklediği durumlarda olay tabanlı iletişim daha iyi bir seçimdir. MicrocosmWorks, genellikle sipariş işleme, bildirim hatları ve analitik alımı için olay tabanlı desenleri tavsiye ederken, saniyenin altında yanıtlar gerektiren kullanıcıya dönük sorgular için senkron API'leri korur. İnşa ettiğimiz birçok üretim sistemi, senkron okumalar ve asenkron yazmalarla hibrit bir yaklaşım kullanır.
MicrocosmWorks, belirli bir varlık (belirli bir sipariş veya kullanıcı gibi) için tüm olayların aynı consumer instance tarafından sırayla işlenmesini garanti etmek amacıyla Kafka topics içinde partition-key-based ordering kullanır. Varlıklar arası sıralama gerektiren senaryolar için, sırasız mesajları güvenli bir şekilde yeniden işleyebilen idempotent event handler'lara sahip saga orchestrator'lar uygularız. Ayrıca, consumer'ların sıralama çakışmalarını tespit edip giderebilmeleri için event payload'larına vector clocks veya sequence numbers yerleştiririz.
MicrocosmWorks, her bir mikroservisin yerel işlemini tamamladıktan sonra domain events yayınladığı ve aşağı akış hizmetlerinin buna göre tepki verdiği veya başarısızlık durumunda rollback compensations tetiklediği, telafi edici işlemlerle Saga pattern'ini uygulamaktadır. Bunu, olayları iş verileriyle birlikte yerel bir outbox table'a atomik olarak yazan ve daha sonra güvenilir bir şekilde message broker'a yayınlayan bir outbox pattern ile birleştiriyoruz. Bu, two-phase commits'in performans ve güvenilirlik kayıpları olmaksızın eventual consistency sağlar.
MicrocosmWorks, OpenTelemetry kullanarak her olayı korelasyon ID'leri ve dağıtılmış izleme başlıkları ile enstrümante eder; bu da Jaeger veya Grafana Tempo gibi araçlarda tüm katılımcı mikroservisler arasında bir iş işleminin tüm yaşam döngüsünü görselleştirmemizi sağlar. Ayrıca, hizmet başına iş hacmi, tüketici gecikmesi ve işlem gecikmesini gösteren gerçek zamanlı olay akışı gösterge panelleri oluşturarak darboğazları kolayca tespit ederiz. Standart gözlemlenebilirlik yığınımız, olay meta verileriyle yapılandırılmış günlük kaydını içerir, böylece herhangi bir tek olay, üreticiden her tüketiciye saniyeler içinde izlenebilir.