Mikroservis Mimarisi ve Bulut Tabanlı Kurumsal Yazılım Nedir, Nasıl Geliştirilir?

Günümüzün yüksek trafikli dijital ekonomisinde kurumsal yazılımların yalnızca işlevsel olması yeterli değildir; aynı zamanda saniyede yüz binlerce isteği karşılayacak kadar esnek (elastic), bir modülde hata çıktığında tüm sistemi durdurmayacak kadar dayanıklı (resilient) ve iş gereksinimleri değiştikçe günde onlarca kez canlıya alınabilecek (continuous deployment) kadar çevik olması gerekir. Özellikle Antalya gibi turizm sezonunda işlem hacminin kış aylarına kıyasla on katına çıktığı, uluslararası rezervasyon ağlarının, lojistik operasyonların, sağlık turizmi platformlarının ve sınır ötesi ticaret sistemlerinin 7/24 kesintisiz çalıştığı bir iş ekosisteminde, geleneksel tek parça (monolitik) yazılımlar hızla darboğaza girmektedir. İşte bu mühendislik problemini kökten çözen yaklaşım mikroservis mimarisi ve bulut tabanlı (Cloud-Native) kurumsal Uygulama- Yazılım geliştirme metodolojisidir. Teknoloji Ofis tarafından hazırlanan bu kapsamlı mimari rehberde, mikroservislerin ne olduğunu, monolitik yapılarla arasındaki teknik farkları ve sıfırdan bulut tabanlı bir kurumsal sistemin adım adım nasıl inşa edildiğini inceliyoruz.

Mikroservis Mimarisi ve Bulut Tabanlı (Cloud-Native) Yazılım Nedir?

Mikroservis mimarisi (Microservices Architecture); büyük ve karmaşık bir kurumsal yazılım uygulamasının, her biri tek bir iş yeteneğine (Business Capability) odaklanan, kendi veritabanına sahip olan, bağımsız olarak geliştirilebilen, dağıtılabilen (deploy) ve ölçeklenebilen küçük, otonom servisler topluluğu olarak tasarlanmasıdır. Bu servisler birbirleriyle doğrudan veritabanı tablolarını paylaşarak değil; iyi tanımlanmış, hafif iletişim protokolleri (RESTful API, gRPC, GraphQL) veya asenkron mesaj kuyrukları (Apache Kafka, RabbitMQ, NATS) üzerinden haberleşir.

Bulut tabanlı (Cloud-Native) yazılım ise yalnızca bir sunucuyu veri merkezinden alıp buluta taşımak (Lift and Shift) değildir; yazılımın bulut bilişimin doğasına uygun olarak konteynerler (Containers), dinamik orkestrasyon (Kubernetes), sunucusuz hesaplama (Serverless), altyapının kod olarak yazılması (Infrastructure as Code - IaC) ve kesintisiz CI/CD boru hatları üzerine inşa edilmesidir. Bu mimari yaklaşım, Web3 ve Merkezsiz Web: Geleceğin Siteleri Nasıl Olacak? analizimizde incelediğimiz dağıtık sistem evriminin kurumsal dünyadaki en sağlam temel taşıdır.

Antalya İş ve Teknoloji Ekosisteminde Neden Mikroservis Mimarisine İhtiyaç Duyulur?

Antalya Teknokent, Akdeniz Üniversitesi AR-GE merkezleri ve Muratpaşa, Konyaaltı ile Organize Sanayi Bölgesi'ndeki kurumsal şirketlerin bilgi işlem departmanları, mevsimsel ve operasyonel yük dalgalanmalarını yönetmek için mikroservis mimarisine hızla geçiş yapmaktadır. Bölgedeki temel kullanım senaryoları şunlardır:

• Turizm, OTA ve Küresel Rezervasyon Motorları: Yaz sezonu öncesi erken rezervasyon dönemlerinde Belek, Kemer, Lara ve Alanya otellerinin müsaitlik sorgulamaları dakikada yüz binlerce API isteği üretir. Mikroservis mimarisinde tüm otel yönetim sistemini büyütmek yerine yalnızca Arama ve Müsaitlik Servisi (Search & Availability Service) yatayda 50 kopyaya (pod/replica) ölçeklenir; muhasebe veya insan kaynakları servisi ise minimum kaynakla çalışmaya devam eder. Bu sistemlerin uçtan uca kurgusu Antalya Turizm ve Otelcilik Sektöründe Yapay Zeka Otomasyonu Nasıl Kurulur? rehberimizdeki yapay zeka katmanının da omurgasını oluşturur.
• Sınır Ötesi E-Ticaret ve Çoklu Kanal Lojistik Platformları: Farklı ülkelerden gelen siparişleri, gümrük hesaplamalarını ve kargo takibini yöneten Antalya İşletmeleri İçin Sınır Ötesi E-Ticaret ve E-İhracat Altyapısı Nasıl Kurulur? mimarisinde, ödeme servisi ile katalog servisinin birbirinden izole olması gerekir. Katalogda yapılan bir güncelleme, ödeme ve tahsilat akışını asla kesintiye uğratmamalıdır.
• Akıllı Şehir, Tarım Teknolojileri (AgriTech) ve IoT Veri İşleme: Antalya'nın seralarından, enerji santrallerinden ve şehir sensörlerinden saniyede binlerce telemetri verisi akan Akıllı Şehir Teknolojileri, IoT Sensör Ağları ve Dijital Altyapı Sistemleri Nasıl Çalışır? projelerinde, zaman serisi (Time-Series) veri toplama servisi yüksek veri işleme (throughput) odaklı Go veya Rust diliyle yazılırken, anomali tespiti yapan makine öğrenmesi servisi Python ile geliştirilebilir.
• Hızlı Büyüyen Teknoloji Girişimleri (Scale-up): Antalya'da kurulan ve küresel pazara açılan bir SaaS girişiminin yatırımcı teknik incelemesinden (Technical Due Diligence) başarıyla geçmesi için ölçeklenebilir bir bulut mimarisine sahip olması şarttır. Bu süreçteki kurumsal hazırlık adımları için Antalya Teknoloji Vadisi ve Girişimcilik Ekosisteminde Teknoloji Girişimi Nasıl Kurulur? ve Teknoloji Girişimlerinde Tohum Yatırım Hazırlığı ve Değerleme Analizi Nasıl Yapılır? yazılarımız önemli birer referanstır.

Monolitik Mimari, Modüler Monolit ve Mikroservis Mimarisi Karşılaştırması

Her yazılım projesi doğrudan mikroservis olarak başlamak zorunda değildir. Projenin ölçeğine, ekip büyüklüğüne ve iş alanı karmaşıklığına göre doğru mimariyi seçmek için aşağıdaki karşılaştırma tablosunu inceleyebilirsiniz:

Mimari Kriter	Geleneksel Monolitik Mimari	Modüler Monolit (Modular Monolith)	Bulut Tabanlı Mikroservis Mimarisi
Kod Tabanı ve Dağıtım (Deployment)	Tek bir kod tabanı, tek bir çalıştırılabilir paket olarak derlenir ve dağıtılır	Tek dağıtım paketi içinde keskin sınırlarla ayrılmış bağımsız modüller	Her servis kendi deposunda (repo) veya monorepo içinde bağımsız konteyner olarak dağıtılır
Veritabanı Yönetimi	Tüm modüllerin ortak kullandığı tek bir merkezi ilişkisel veritabanı	Aynı veritabanı motoru içinde şema (schema) düzeyinde ayrıştırılmış tablolar	Servis başına bağımsız veritabanı (Polyglot Persistence: PostgreSQL, MongoDB, Redis, Qdrant)
Ölçeklenebilirlik (Scalability)	Yalnızca tüm uygulamanın kopyası çoğaltılarak ölçeklenebilir (yüksek donanım gereksinimi)	Uygulama bütünüyle ölçeklenir ancak darboğaz yaratan modül kolayca mikroservise ayrılabilir	Yalnızca yük binen spesifik servis (ör. Ödeme veya Arama) saniyeler içinde otomatik ölçeklenir
Teknoloji Çeşitliliği	Tek bir programlama dili ve çerçevesine (Framework) bağımlılık	Genellikle tek dil ve çalışma zamanı (Runtime) kullanılır	Her servis kendi işine en uygun dille (Go, Java, .NET, Node.js, Python, Rust) yazılabilir
Hata İzolasyonu (Fault Isolation)	Bellek sızıntısı (Memory Leak) veya kritik bir hata tüm sistemi kapatabilir	Modül sınırları mantıksal koruma sağlasa da aynı süreç (process) paylaşılır	Devre kesici (Circuit Breaker) desenleri ile hata tek serviste izole edilir, sistem ayakta kalır

Adım Adım Rehber: Bulut Tabanlı Mikroservis Mimarisi Nasıl Geliştirilir?

Kurumsal bir yazılımı sıfırdan mikroservis olarak tasarlamak veya mevcut monolitik bir sistemi (Legacy System) modernize etmek için uygulanması gereken 7 mühendislik adımı şunlardır:

1. Adım: Alan Güdümlü Tasarım (Domain-Driven Design - DDD) ve Sınırlandırılmış Bağlamlar (Bounded Contexts)

Mikroservis sınırlarını çizerken yapılan en büyük hata, servisleri teknik katmanlara göre bölmektir. Bunun yerine Eric Evans'ın Domain-Driven Design (DDD) metodolojisi kullanılarak iş alanı Sınırlandırılmış Bağlamlara (Bounded Contexts) ayrılmalıdır. Örneğin bir e-ticaret ve lojistik platformunda "Müşteri (Customer)" kavramı; Sipariş Bağlamında yalnızca teslimat adresi ve alıcı kimliğiyken, Finans Bağlamında fatura unvanı ve cari hesap bakiyesidir, Destek Bağlamında ise talep geçmişidir. Her Bounded Context, potansiyel bir mikroservis sınırını temsil eder. Eğer mevcut bir monolitik sistemi dönüştürüyorsanız, sistemi bir gecede baştan yazmak yerine Strangler Fig (Boğucu İncir) Deseni ile kenardaki modülleri adım adım mikroservise ayırarak ilerlemelisiniz.

2. Adım: API Gateway, BFF (Backend for Frontend) ve İletişim Protokolleri

İstemci uygulamaların (Web arayüzü, iOS/Android mobil uygulama veya üçüncü parti entegratörler) arka plandaki 30 farklı mikroservisin IP adresini ve portunu bilmesi hem güvenlik hem de performans açısından imkansızdır. Bu nedenle sistemin en önüne bir API Gateway (Kong, Envoy, AWS API Gateway, Apisix) yerleştirilir. API Gateway; hız sınırlama (Rate Limiting), SSL sonlandırma, kimlik doğrulama (OAuth2 / OpenID Connect / JWT doğrulaması) ve istek yönlendirme (Routing) işlemlerini üstlenir.

Ayrıca Çoklu Platform Mobil Uygulama Geliştirme ve Performans Optimizasyonu Nasıl Yapılır? rehberimizde vurguladığımız gibi, mobil cihazların bant genişliği ve ekran ihtiyaçları masaüstü web uygulamasından farklıdır. Bu yüzden BFF (Backend for Frontend) deseni uygulanarak Mobil uygulama için ayrı, Web paneli için ayrı birer toplulaştırıcı (Aggregator) API katmanı oluşturulur. Servislerin kendi aralarındaki iç iletişimde (East-West Traffic) ise JSON serileştirme yükünü ortadan kaldırmak için ikili (binary) protokol kullanan gRPC (Protocol Buffers) tercih edilerek gecikme süreleri 1-2 milisaniye seviyesine indirilir.

3. Adım: Dağıtık Veri Yönetimi, Saga Deseni ve Outbox Pattern

Mikroservis mimarisinin altın kuralı Database-per-Service (Her Servisin Kendi Veritabanı Olması) ilkesidir. Sipariş Servisi doğrudan Stok Servisinin veritabanı tablosuna JOIN atamaz veya UPDATE sorgusu çalıştıramaz. Peki bir sipariş oluşturulduğunda hem sipariş kaydının açılması, hem ödemenin alınması hem de stoğun düşülmesi (dağıtık işlem - Distributed Transaction) nasıl garanti altına alınır?

Dağıtık sistemlerde iki aşamalı onay (2PC - Two-Phase Commit) sistemleri kilitlenmeye (deadlock) yol açtığı için bunun yerine Saga Deseni (Choreography veya Orchestration Saga) kullanılır:

1. Sipariş Servisi kendi veritabanında siparişi PENDING (Beklemede) statüsünde oluşturur ve Transactional Outbox Pattern kullanarak aynı yerel işlem içinde OrderCreated olayını (event) mesaj kuyruğuna (Kafka/RabbitMQ) yazar.
2. Ödeme Servisi bu olayı dinler, tahsilatı gerçekleştirir (örneğin Açık Bankacılık API Mimarisi ve Gömülü Finans (Embedded Finance) Nedir, Nasıl Çalışır? altyapısıyla) ve PaymentSucceeded olayını yayınlar.
3. Stok Servisi PaymentSucceeded olayını alır ve ürünü rezerve eder. Eğer stok yetersizse StockReservationFailed olayı fırlatılır ve telafi edici işlemler (Compensating Transactions) tetiklenerek ödeme otomatik iade edilir ve sipariş iptal statüsüne çekilir.

Ayrıca karmaşık raporlama ve okuma sorgularını hızlandırmak için CQRS (Command Query Responsibility Segregation) deseni uygulanır; yazma işlemleri (Command) normalize edilmiş ilişkisel veritabanında yapılırken, okuma işlemleri (Query) Elasticsearch veya Redis gibi yüksek hızlı okuma kopyalarından servis edilir. Kurumsal yapay zeka aramaları için ise sisteme Kurumsal Bilgi Yönetiminde RAG Mimarisi ve Vektör Veritabanı Entegrasyonu Nasıl Yapılır? rehberimizdeki gibi bir vektör veritabanı mikroservisi eklenir.

4. Adım: Konteynerleştirme (Docker) ve Orkestrasyon (Kubernetes)

"Benim bilgisayarımda çalışıyordu ama sunucuda çalışmıyor" sorununu tamamen ortadan kaldırmak için her mikroservis tüm bağımlılıklarıyla birlikte çok aşamalı (Multi-Stage) Docker imajları haline getirilir. Güvenlik ve hız için Distroless veya Alpine tabanlı minimal imajlar kullanılır. Ardından bu yüzlerce konteynerin hangi fiziksel sunucuda (Node) çalışacağını, trafik arttığında nasıl otomatik çoğalacağını (Horizontal Pod Autoscaler - HPA) ve çöken bir konteynerin saniyeler içinde nasıl yeniden başlatılacağını (Self-Healing) yönetmek için Kubernetes (K8s) orkestrasyon platformu devreye alınır.

5. Adım: Dayanıklılık (Resilience) Mühendisliği ve Service Mesh

Dağıtık bir sistemde ağ her zaman güvenilmezdir; bir servis yanıt vermekte gecikebilir. Bir servisteki yavaşlamanın diğer tüm servisleri domino taşı gibi devirmesini (Cascading Failure) önlemek için şu dayanıklılık desenleri uygulanır:

• Devre Kesici (Circuit Breaker): Bir hedef servis üst üste belirli bir oranda hata döndürürse devre kesici açılır ve bir süre o servise istek göndermek yerine anında varsayılan (Fallback) yanıt döndürülür.
• Üstel Geri Çekilme ile Yeniden Deneme (Retry with Exponential Backoff & Jitter): Geçici ağ kopmalarında isteği hemen arka arkaya göndermek yerine 100ms, 200ms, 400ms gibi artan sürelerle yeniden dener.
• Bölmeleme (Bulkhead Pattern): Gemilerdeki su geçirmez bölmeler gibi, bağlantı havuzlarını (Connection Pools) birbirinden ayırarak bir entegrasyonun tüm sunucu iş parçacıklarını (threads) tüketmesini engeller.
• Service Mesh (Istio / Linkerd): Bu dayanıklılık kurallarını ve servisler arası karşılıklı şifreli iletişimi (mTLS) uygulama kodunu kirletmeden altyapı düzeyinde (Sidecar Proxy) yönetir.

6. Adım: Gözlemlenebilirlik (Observability): Loglama, Metrikler ve Dağıtık İzleme

Bir kullanıcının isteği arka planda 8 farklı mikroservisten geçiyorsa ve işlem yavaş sürüyorsa, darboğazın hangi serviste olduğunu bulmak için Gözlemlenebilirliğin (Observability) 3 Sütunu kurulmalıdır:

1. Merkezi Loglama (Centralized Logging - OpenSearch / ELK / Grafana Loki): Tüm servislerin ürettiği yapılandırılmış (JSON) loglar tek bir merkezde toplanır ve her isteğe benzersiz bir Correlation-ID (Trace-ID) atanır.
2. Metrik İzleme (Prometheus & Grafana): CPU/RAM kullanımı, saniyedeki istek sayısı (RPS), hata oranları ve P95/P99 gecikme süreleri gerçek zamanlı panellerde izlenir.
3. Dağıtık İzleme (Distributed Tracing - OpenTelemetry & Jaeger/Tempo): Bir isteğin API Gateway'den girip hangi serviste kaç milisaniye harcadığı, hangi SQL sorgusunda beklediği şelale (waterfall) grafiği olarak görselleştirilir.

7. Adım: DevSecOps, Shift-Left Güvenlik ve CI/CD Otomasyonu

Kod depoya (Git) gönderildiği andan itibaren çalışan otomatik boru hatları (GitHub Actions, GitLab CI, ArgoCD ile GitOps) kurulur. Güvenlik kontrolleri projenin sonuna bırakılmaz; Shift-Left Security yaklaşımıyla derleme aşamasında Statik Kod Analizi (SAST - SonarQube), Bağımlılık Güvenlik Taraması (SCA - Trivy/Snyk) ve Dinamik Uygulama Güvenlik Testleri (DAST) otomatik çalıştırılır. Canlıya geçişlerde sıfır kesinti (Zero-Downtime Deployment) sağlamak için Blue-Green Deployment veya Canary Release (yeni sürümü önce trafiğin yalnızca yüzde 5'ine açıp hata yoksa yüzde 100'e yayma) stratejileri uygulanır.

Mimari Altın Kural: Dağıtık bir monolit (Distributed Monolith) yaratmaktan kaçının! Eğer iki mikroservisi aynı anda canlıya almak zorunda kalıyorsanız veya bir servisteki veri şeması değişikliği diğer beş servisin kodunu bozuyorsa, servis sınırlarınız (Bounded Context) yanlış çizilmiş demektir. Servisler kendi içlerinde yüksek uyumlu (High Cohesion), birbirleriyle ise gevşek bağlı (Loose Coupling) olmalıdır.

Antalya Kurumsal Yazılım Ekosisteminde Monolitten Mikroservise Geçiş Senaryoları

Antalya'da uzun yıllardır faaliyet gösteren köklü turizm grupları, özel hastaneler ve sağlık turizmi merkezleri, tarım ihracatçıları, organize sanayi kuruluşları ve perakende zincirleri genellikle 10-15 yıl önce geliştirilmiş masaüstü veya tek parça (monolitik) ERP/CRM yazılımlarına sahiptir. Bu sistemleri bir gecede kapatıp sıfırdan mikroservis yazmaya çalışmak (Big Bang Rewrite) yüksek operasyonel risk taşır. Bunun yerine Antalya Teknokent ve yerel Teknoloji ekiplerinin uyguladığı aşamalı modernizasyon stratejisi şu dört fazda yürütülür:

1. Faz: Anti-Corruption Layer (ACL - Bozulma Önleyici Katman) İnşası

Eski monolitik sistemin veritabanı yapısı ve iç mantığı, yeni yazılacak modern mikroservislere sızmamalıdır. Bu nedenle eski sistem ile yeni bulut ortamı arasına bir Anti-Corruption Layer (ACL) adaptörü yerleştirilir. Bu katman, eski sistemin karmaşık tablo yapılarını modern Domain-Driven Design (DDD) nesnelerine ve standart JSON/Protobuf şemalarına tercüme eder.

2. Faz: Değişiklik Veri Yakalama (CDC - Change Data Capture) ile Gerçek Zamanlı Senkronizasyon

Eski sistemin kaynak koduna dokunulamadığı durumlarda, veritabanı işlem günlüklerini (Transaction Logs - WAL/Binlog) okuyan Debezium ve Apache Kafka tabanlı bir CDC (Change Data Capture) hattı kurulur. Örneğin Muratpaşa'daki merkez ofiste çalışan eski muhasebe programına yeni bir stok kartı eklendiğinde, CDC katmanı bunu milisaniyeler içinde yakalar ve buluttaki yeni mikroservislere olay (event) olarak fırlatır.

3. Faz: Yüksek Yük Alan ve Sık Değişen Modüllerin Öncelikli Ayrıştırılması

Tüm modülleri aynı anda taşımak yerine, işletmeye en hızlı operasyonel verimlilik ve yatırım getirisi sağlayacak modüller ilk sırada mikroservise dönüştürülür. Örneğin bir turizm acentesinde "Online B2B/B2C Arama ve Dinamik Paketleme" modülü veya bir e-ticaret firmasında "Sadakat Kuralları ve Bildirim Motoru" ilk olarak bulut tabanlı mikroservise ayrılır. Böylece dış dünyadan gelen yoğun trafik modern Kubernetes kümesinde karşılanırken, arka plandaki çekirdek kayıtlar kontrollü şekilde işlenir.

4. Faz: Çoklu Bulut (Multi-Cloud) ve Hibrit Bulut (On-Premise + Cloud) Topolojisi

Regülasyonlar, KVKK gereksinimleri veya tesis içi (On-Premise) donanım yatırımları nedeniyle bazı verilerin Antalya'daki yerel sunucu odalarında kalması gerekebilir. Bu durumda yerel veri merkezindeki Kubernetes kümesi (örneğin Rancher veya OpenShift) ile küresel bulut sağlayıcılar arasında şifreli WireGuard / IPSec VPN veya Direct Connect tünelleri kurularak hibrit bir bulut mimarisi oluşturulur. Hassas kişisel veriler yerel sunucuda işlenirken, küresel ölçekleme gerektiren ön yüz ve Yapay Zeka çıkarım (Inference) servisleri bulut üzerinde esnek biçimde çalıştırılır. Yapay zeka servislerinin kurumsal süreçlere nasıl entegre edildiğini daha geniş perspektiften incelemek için Yapay Zeka İş Süreçlerini Nasıl Dönüştürüyor? yazımıza göz atabilirsiniz.

Mikroservislerde Performans Mühendisliği, Önbellekleme (Caching) ve Veritabanı Optimizasyonu

Bir sistemi mikroservislere böldüğünüzde, tek bir kullanıcı ekranını oluşturmak için arka planda birden fazla servisin verisi gerekebilir. Ağ gecikmelerini (Network Latency) ve veritabanı darboğazlarını önlemek için kurumsal bulut mimarilerinde şu performans katmanları uygulanır:

• Çok Katmanlı Önbellekleme (Multi-Tier Caching): Statik içerikler CDN uç noktalarında (Edge Cache), API Gateway yanıtları kısa süreli (TTL: 5-30 saniye) ağ geçidi önbelleğinde, sık sorgulanan referans verileri (ülke listeleri, oda tipleri, yetkilendirme rolleri) ise dağıtık Redis veya Dragonfly bellek içi (In-Memory) kümelerinde tutulur.
• Bağlantı Havuzlama (Connection Pooling - PgBouncer / ProxySQL): Kubernetes üzerinde 50 farklı mikroservis kopyasının (pod) her biri doğrudan PostgreSQL veritabanına 20'şer bağlantı açarsa veritabanı bağlantı limiti hızla dolar. Bunun önüne geçmek için servisler ile veritabanı arasına hafif bağlantı havuzlayıcılar yerleştirilerek binlerce sanal bağlantı birkaç düzine fiziksel bağlantıya çoklanır (multiplexing).
• Asenkron İş İşleme (Background Workers & Event Streaming): PDF fatura oluşturma, e-posta/SMS gönderimi, büyük Excel raporlarının hazırlanması veya görüntü boyutlandırma gibi zaman alan işlemler asla kullanıcının HTTP isteğini bekletmez. Bu görevler mesaj kuyruğuna bırakılarak arka plandaki işçi (Worker) pod'ları tarafından asenkron olarak tamamlanır ve tamamlandığında WebSocket veya Server-Sent Events (SSE) ile kullanıcı ekranına anlık bildirim düşürülür.

FinOps ve Bulut Kaynak Planlaması: Altyapı Kapasitesi Nasıl Optimize Edilir?

Bulut tabanlı sistemlerde esnek ölçeklenebilirlik büyük bir güç sunarken, kontrolsüz bırakılan kaynaklar gereksiz altyapı kapasitesi tüketimine yol açabilir. Bu nedenle modern yazılım ekiplerinde FinOps (Bulut Kaynak ve Kapasite Yönetimi) kültürü uygulanır. Kubernetes üzerinde her mikroservis için requests (başlangıçta garanti edilen CPU/RAM) ve limits (tüketebileceği maksimum CPU/RAM) değerleri yük testleri (k6 / Locust) sonuçlarına göre hassas biçimde tanımlanır. Ayrıca gece saatlerinde veya düşük sezonlarda geliştirme (Dev) ve test (Staging) ortamlarındaki sunucu kümelerini otomatik olarak uyku moduna alan (Scale-to-Zero / Karpenter Node Autoscaling) kurallar devreye alınarak donanım gereksinimi ve enerji tüketimi en verimli seviyede tutulur.

Mikroservislerde API Güvenliği ve Sıfır Güven (Zero Trust) Mimarisi

Monolitik bir uygulamada modüller arası çağrılar aynı bellek (memory) içinde gerçekleşirken, mikroservislerde her çağrı ağ üzerinden (Network Call) geçer. Bu durum saldırı yüzeyini genişlettiği için Zero Trust (Sıfır Güven - "Asla Güvenme, Her Zaman Doğrula") mimarisi uygulanmalıdır:

• Merkezi Kimlik ve Erişim Yönetimi (IAM - Keycloak / OAuth 2.1 / OIDC): Kullanıcı kimlik doğrulaması tek bir merkezi kimlik sağlayıcıda (Identity Provider) yapılır ve kısa ömürlü JWT (JSON Web Token) erişim anahtarları üretilir.
• Servisler Arası Karşılıklı Kimlik Doğrulama (mTLS & SPIFFE/SPIRE): Küme içindeki bir mikroservisin diğerine istek atabilmesi için kriptografik servis kimliğine sahip olması zorunludur. Örneğin "Blog/İçerik Servisi", "Ödeme Veritabanı Servisi"ne asla ağ isteği gönderemez; Kubernetes NetworkPolicy kuralları bu trafiği varsayılan olarak (Default Deny) engeller.
• Gizli Bilgilerin Yönetimi (Secrets Management - HashiCorp Vault): Veritabanı bağlantı dizgileri, API anahtarları ve şifreleme sertifikaları asla Git depolarında veya düz metin dosyalarda tutulmaz; çalışma zamanında (Runtime) dinamik olarak üretilip otomatik rotasyona tabi tutulur.

Mikroservislerde Test Stratejileri: Sözleşme Testleri (Contract Testing) ve Kaos Mühendisliği

Yirmi farklı yazılım geliştiricinin on beş ayrı mikroservis üzerinde eşzamanlı kod geliştirdiği bir kurumsal ortamda, bir ekibin yaptığı API değişikliğinin diğer ekibin servisini bozup bozmadığını yalnızca canlıya geçiş anında (Production) fark etmek büyük bir operasyonel risktir. Klasik uçtan uca (End-to-End - E2E) testler ise tüm servislerin aynı anda test ortamında ayağa kaldırılmasını gerektirdiği için yavaş ve kırılgandır. Bu mühendislik ikilemini çözmek için Tüketici Güdümlü Sözleşme Testleri (Consumer-Driven Contract Testing - Pact) uygulanır:

1. Tüketici Beklentisinin Tanımlanması: Örneğin "Sipariş Servisi" (Tüketici), "Müşteri Servisi"nden (Sağlayıcı) yalnızca customerId, fullName ve shippingAddress alanlarını beklediğini belirten bir JSON sözleşmesi (Pact dosyası) üretir.
2. CI/CD Hattında Otomatik Doğrulama: Müşteri Servisi ekibi kodunda bir değişiklik yapıp Git deposuna gönderdiği anda, CI boru hattı bu sözleşmeyi çalıştırır. Eğer bir geliştirici yanlışlıkla shippingAddress alanının adını addressLine olarak değiştirmişse, derleme (Build) aşaması anında hata verir ve bozuk kodun test veya canlı ortama çıkması engellenir.
3. Testcontainers ile Gerçekçi Entegrasyon Testleri: Birim testlerde (Unit Tests) sahte (Mock) veritabanları kullanmak yerine, geliştiricinin bilgisayarında veya CI sunucusunda saniyeler içinde gerçek bir PostgreSQL, Redis veya Kafka konteyneri ayağa kaldıran Testcontainers kütüphaneleri kullanılarak SQL sorgularının ve mesaj kuyruğu tüketicilerinin gerçek davranışları doğrulanır.

Akdeniz Üniversitesi ve Antalya Teknokent Mühendislik Ekosisteminde Bulut Dönüşümü

Antalya'daki yazılım mühendisliği takımları, hem yerel holdinglerin dijital dönüşüm projelerinde hem de Avrupa ve Kuzey Amerika merkezli teknoloji şirketlerine verdikleri yazılım ihracatı hizmetlerinde bulut tabanlı mikroservis mimarilerini standart olarak uygulamaktadır. Konyaaltı, Muratpaşa ve Teknokent yerleşkesindeki AR-GE merkezlerinde düzenlenen yazılım mimarisi çalıştayları, Kubernetes topluluk buluşmaları ve açık kaynak katkıları, şehrin nitelikli mühendislik kapasitesini her geçen gün ileri taşımaktadır. İşletmenizin kurumsal yazılım ihtiyaçlarında dışa bağımlılığı azaltmak, Yatırım değerlemesini yükseltmek ve küresel standartlarda bir dijital ürün inşa etmek için mikroservis prensiplerini doğru mühendislik disipliniyle hayata geçirmek en stratejik adımdır.

Kurumsal Bulut ve Mikroservis Mimarisi Kurulum Kontrol Listesi

Yazılım mühendisliği ekibinizle mikroservis dönüşümüne başlarken aşağıdaki teknik kontrol listesini rehber edinebilirsiniz:

• İş alanı Domain-Driven Design (DDD) çalıştayları (Event Storming) ile analiz edilerek Bounded Context sınırları netleştirildi mi?
• Tüm servisler 12-Factor App prensiplerine uygun olarak durumsuz (Stateless) tasarlandı ve ortam değişkenleri (ConfigMap / Vault) koddan tamamen ayrıldı mı?
• Asenkron olay güdümlü iletişimde aynı mesajın iki kez gelmesi ihtimaline karşı tüm tüketici (Consumer) servisler Idempotent (Etkisiz/Tekrarlanabilir) olarak kodlandı mı?
• Altyapı kaynakları (VPC, Kubernetes kümeleri, veritabanları, yük dengeleyiciler) manuel tıklamalarla değil, Terraform veya OpenTofu kullanılarak kod olarak (IaC) versiyonlandı mı?
• OpenTelemetry standartlarında dağıtık izleme (Tracing) ve sağlık kontrol uç noktaları (/health/live ve /health/ready) her servise eklendi mi?
• Felaket kurtarma (Disaster Recovery) senaryoları kapsamında farklı coğrafi bölgelere (Multi-AZ / Multi-Region) otomatik yedekleme ve kaos mühendisliği (Chaos Engineering) testleri yapıldı mı?

Sıkça Sorulan Sorular (SSS)

Yeni başlayan bir yazılım projesi doğrudan mikroservis mimarisiyle mi kurulmalıdır?

İş alanı sınırları henüz netleşmemiş erken aşama projelerde doğrudan mikroservisle başlamak operasyonel karmaşıklık yaratabilir. Bu durumda en doğru mühendislik yaklaşımı Modüler Monolit (Modular Monolith) ile başlamaktır. Kod tabanı içinde modüller birbirinden kesin sınırlarla ayrılır; ileride yüksek trafik alan veya bağımsız ölçeklenmesi gereken modüller (örneğin bildirim motoru, görüntü işleme veya ödeme modülü) birkaç gün içinde kolayca bağımsız mikroservise dönüştürülür.

Mikroservis mimarisinde farklı servislerdeki verileri birleştirerek nasıl rapor alırız?

Servislerin kendi operasyonel veritabanlarına doğrudan çapraz sorgu atılmaz. Bunun yerine API Composition (küçük sorgular için) veya CQRS / Veri Gölü (Data Lake / Read Model) yaklaşımı kullanılır. Her servis ürettiği olayları (Event) mesaj kuyruğuna yayınlar; raporlama ve analitik servisi bu olayları dinleyerek kendi okuma odaklı veritabanında (örneğin ClickHouse, PostgreSQL Read Replica veya Elasticsearch) birleştirilmiş rapor tablolarını gerçek zamanlı günceller.

Bulut sağlayıcı bağımlılığından (Vendor Lock-in) nasıl korunabiliriz?

Bulut sağlayıcıların kapalı ve taşınamaz servislerine doğrudan uygulama kodundan bağlanmak yerine, Kubernetes, PostgreSQL, Apache Kafka, Redis ve OpenTelemetry gibi açık kaynaklı (CNCF - Cloud Native Computing Foundation) standartları tercih ederek uygulamanızı istediğiniz zaman farklı bir bulut sağlayıcıya veya kendi veri merkezinize (On-Premise / Hybrid Cloud) kolayca taşıyabilirsiniz.

Oyun ve yüksek etkileşimli gerçek zamanlı sistemlerde de mikroservis kullanılır mı?

Kesinlikle. Çok oyunculu çevrimiçi Oyun sunucularında eşleştirme (Matchmaking), liderlik tablosu (Leaderboard), oyuncu envanteri ve sohbet sistemleri tamamen bağımsız mikroservisler olarak çalışır. Bu alandaki mimari detaylar için Oyun Motoru Mimarisi ve Bağımsız Oyun Stüdyosu Üretim Hattı Nasıl Kurulur? rehberimizi inceleyebilirsiniz.

Sonuç: Geleceğe Dayanıklı Kurumsal Yazılım Altyapısı İnşa Etmek

Mikroservis mimarisi ve bulut tabanlı yazılım mühendisliği, Antalya'daki turizm devlerinden e-ihracat liderlerine, finansal teknoloji girişimlerinden endüstriyel üretim tesislerine kadar tüm kurumlara sınırsız ölçeklenebilirlik, kesintisiz çalışma süresi (High Availability) ve hızlı inovasyon yeteneği kazandırır. Doğru sınırlandırılmış bağlamlar, olay güdümlü iletişim, konteyner orkestrasyonu ve güçlü gözlemlenebilirlik araçlarıyla kurgulanan bir sistem, işletmenizin gelecekteki büyümesini sırtlayan en değerli teknolojik varlığa dönüşür. Teknoloji Ofis olarak, kurumsal yazılım mimarisi ve bulut dönüşümü süreçlerinizde en güncel mühendislik standartlarını paylaşmaya devam ediyoruz.