- Mikroservislerin üretim ortamında uygulanabilir olması için servislerin, verilerin, dayanıklılığın ve sözleşmelerin dikkatli bir şekilde tasarlanması gerekir.
- Kubernetes/OpenShift, CI/CD ve GitOps, büyük ölçekli dağıtımların, ölçeklendirmenin ve operasyonların otomasyonunu sağlar.
- Sıfır Güven yaklaşımı, sağlam yapılandırma yönetimi ve OpenTelemetry ile gözlemlenebilirlik, platformun temel taşlarıdır.
- Ürün ekibi organizasyonu ve dağıtılmış yönetim, seçilen teknoloji kadar önemlidir.
Gerçek dünya ortamında mikro hizmet mimarisini benimsemek, sadece monolitik bir yapıyı daha küçük parçalara ayırmakla ilgili değildir; altyapıyı, ekipleri, süreçleri, verileri, güvenliği ve operasyonları yeniden düşünmeyi gerektirir . Sistem teoriden üretim kümesine geçtiğinde, hizmet keşfi, ekipler arasındaki sözleşmeler, CI/CD, gözlemlenebilirlik, dayanıklılık ve ölçeklenebilirlik ile ilgili sorunlar ortaya çıkar. Bunlar doğru şekilde ele alınmazsa, mikro hizmetleri dağıtılmış bir kaosa dönüştürebilirler.
İyi haber şu ki, bugün Netflix, Amazon, Google ve üretimde yüzlerce mikro hizmet çalıştıran diğer büyük şirketler gibi kuruluşlardan edinilmiş zengin bir deneyim birikimine sahibiz . Bu derslerden ve Kubernetes ve OpenShift kullanan kurumsal ortamlardaki en iyi uygulamalardan yola çıkarak, kontrolü kaybetmeden büyük ölçekte mikro hizmetlerin tasarlanması, dağıtılması ve işletilmesi için çok sağlam bir yaklaşım geliştirebiliriz.
Mikroservisleri üretim ortamına neden dağıtmalıyız (ve ne zaman buna değmez)?
İyi tasarlanmış bir mikro hizmet mimarisi, uçtan uca bir hizmetin sorumluluğunu üstlenen küçük, özerk ve çok fonksiyonlu ekiplerle çalışmanıza olanak tanır . Her ekip iyi tanımlanmış bir bağlamda faaliyet gösterir, sık sık dağıtım yapabilir ve hizmetinin tüm sorumluluğunu üstlenerek geliştirme döngüsü süresini kısaltır ve yeni özelliklerin sunumunu hızlandırır.
Bir diğer önemli avantaj ise hizmet başına bağımsız ölçeklendirmedir . Sadece katalog, ödeme veya genel API'de trafik artışı yaşanıyorsa, tüm uygulamayı gereğinden fazla büyütmenize gerek kalmaz. Her mikro hizmeti yük modeline göre yatay veya dikey olarak ayarlayabilir, her özelliğin maliyetini doğru bir şekilde ölçebilir ve belirli bir alanda tüketimde ani bir artış yaşansa bile kullanılabilirliği koruyabilirsiniz.
Bu hizmetlerin paketlenme ve dağıtım şekli, sürekli ve düşük riskli uygulamayı kolaylaştırır . Her mikro hizmetin bağımsız olarak yayınlanması, yeni fikirleri test etmeyi ve sorunlu sürümleri geri almayı çok daha basit hale getirir: kademeli dağıtımlar, mavi/yeşil geri alma işlemleri ve otomatik geri alma işlemleri, başarısızlık maliyetini azaltır ve deneme için alan sağlar.
Teknolojik açıdan bakıldığında, mikro hizmetler her hizmet için dil, çerçeve ve veritabanı seçme özgürlüğünü teşvik eder . Tüm ihtiyaçlar aynı teknoloji yığınına uymayabilir: .NET veya Java'da iş hizmetleriniz, Scala/Spark'ta veri işleme, Python veya F#'da özel hizmetler veya R'da yapay zeka mikro hizmetleriniz olabilir. Bu kontrollü çeşitlilik, tüm uygulamayı küresel bir teknolojik değişime zorlamadan, her durum için doğru aracı kullanmanıza olanak tanır.
Ayrıca, sistemi küçük, iyi tanımlanmış parçalara ayırmak, işlevlerin yapı taşları olarak yeniden kullanılmasını kolaylaştırır . Başlangıçta daha büyük bir işlevin parçası olarak oluşturulan bir mikro hizmet, daha sonra mantığı yeniden yazmaya gerek kalmadan sistemin diğer bölümlerinin bir bağımlılığı olarak yeniden kullanılabilir. Ve hizmetler izole edildiğinden, bunlardan birinde meydana gelen bir arıza, dayanıklılık baştan itibaren tasarlanmışsa, genellikle tam bir sistem kesintisine değil, kısmi sistem bozulmasına neden olur.
Mimari ve hizmet tasarımı
Mikroservislerin üretim ortamında iyi çalışması için, servis sınırlarının ve sorumluluklarının dikkatli bir şekilde tasarlanması şarttır . Pratik anlamda, bu genellikle mevcut monolit içindeki kaba taneli servislerin belirlenmesiyle başlar: halihazırda mantıksal olarak ayrılmış büyük fonksiyonel alanlar veya iş alanları (örneğin, siparişler, katalog, kullanıcılar, faturalama).
Bu büyük yapı taşlarından başlayarak, süreç, tutarlı bir veri kümesi üzerinde çalışan , kendi modellerine sahip olan ve diğer hizmetlerden ne okumaları veya onlara ne yazmaları gerektiğini tam olarak bilen, ince taneli mikro hizmetler elde etmek için tasarımı iyileştirmeyi içerir. Bu süreç tipik olarak alan odaklı tasarım (DDD) kavramlarına ve sınırlı bağlamlara dayanır ve bir mikro hizmetin "mini monolit" haline gelmesini önler.
Bu hizmetleri sunan API'lerin iyi tanımlanmış ve istikrarlı sözleşmelere sahip olması gerekir . Bu, titiz bir dokümantasyon (REST için OpenAPI, gRPC için .proto dosyaları vb.), açık sürümleme, mümkün olduğunca geriye dönük uyumluluğun korunması ve üretim aşamasına ulaşmadan önce kırıcı değişiklikleri tespit etmek için sözleşme doğrulamasının otomatikleştirilmesi anlamına gelir.
Düzinelerce veya yüzlerce hizmetin bulunduğu ortamlarda, sistemin kısmi arızalara hazırlıklı olması için tasarım aşamasından itibaren dayanıklılık modellerini dahil etmek çok önemlidir . Devre kesiciler, geri çekilme ile yeniden denemeler, iyi tanımlanmış zaman aşımı süreleri, bölme duvarları ve geri basınç gibi modeller, bir hizmetin arızasının diğerlerini de çökertmesini önlemeye yardımcı olur. ChaosMonkey veya Gremlin gibi kaos mühendisliği araçları, platformun simüle edilmiş kesintiler altında nasıl davrandığını pratik olarak test etmek için kullanışlıdır.
Birçok karmaşık sistem, nispeten basit CRUD hizmetlerini, gelişen iş kurallarını ele alan daha gelişmiş hizmetlerle birleştirir. Tüm mikro hizmetler karmaşık bir iç mimari gerektirmez : bazıları temel veri erişimine sahip basit HTTP denetleyicileri olabilirken, sipariş veya faturalama hizmetleri gibi diğerleri daha gelişmiş kalıplardan (DDD, CQRS, alan olayları vb.) yararlanabilir.
Üretim altyapısı: bulut, konteynerler ve Kubernetes/OpenShift
Gerçek dünya deneyimleri, mikro hizmetlerin izole sanal makineler yerine konteynerler ve orkestrasyon içeren bulut altyapısına dağıtıldığında çok daha iyi performans gösterdiğini ortaya koymaktadır . Kubernetes ve OpenShift gibi platformlar, hizmetleri konteyner olarak paketlemek, ölçeklendirmek, güncellemek, yük dengelemesi yapmak ve yüksek kullanılabilirliği yönetmek için gerekli temel bileşenleri sağlar.
Genellikle, her mikro hizmet, altyapı ekibi tarafından yönetilen kurumsal bir temel imaja (örneğin, Java hizmetleri için OpenJDK 21) dayalı bir konteyner imajı içinde paketlenir. Bu temel imaj, güvenlik yamalarıyla güncel tutulur ve yeni bir sürüm yayınlandığında, geliştirme ekipleri hizmetlerini ilgili ortamlarda yeniden oluşturmaktan ve yeniden dağıtmaktan sorumludur.
Kubernetes/OpenShift'te temel dağıtım birimi , bir veya daha fazla konteyneri kapsayan pod'dur . Tipik olarak, bir mikro hizmet bir pod türüne karşılık gelir ve Deployments (durumsuz hizmetler için) veya StatefulSets (ilişkili durum olduğunda) gibi kaynaklar kullanılarak dağıtılır. Başlangıçtan itibaren, test, ön üretim ve üretim ortamlarının kritikliklerine uygun kullanılabilirlik seviyelerine sahip olmaları için ortam başına minimum sayıda kopya tanımlanır.
Otomatik ölçeklendirme, CPU, bellek veya diğer özel ölçütler gibi metriklere göre kopya sayısını ayarlayan HorizontalPodAutoscaler (HPA) kullanılarak uygulanır . Platform ayrıca, aynı hizmetin kopyalarını farklı düğümlere dağıtmak ve tek bir düğüm arızasının tüm örnekleri devre dışı bırakmasını önlemek için pod anti-affinity kurallarını da yapılandırmalıdır.
Dikey boyutlandırma ile ilgili olarak, resources.requests ve resources.limits , bir pod'un tüketebileceği CPU ve bellek aralığını tanımlamak için kullanılır. Örneğin, bir Java servisi için minimum 100 MB CPU ve 256 MB bellek ayırmak ve sırasıyla 500 MB ve 2 GB'a kadar izin vermek, konteynerin kaynaklarından en iyi şekilde yararlanmak için JVM'yi (Xms, Xmx, Xss) ayarlamak anlamına gelir.
Durum yönetimi: durumsuz ve durumlu mikro hizmetler
Çoğu işletme mikro hizmeti, durumsuz hizmetler olarak tasarlanmıştır . Bu, podun yeniden başlatmalardan sonra da korunması gereken bilgileri saklamadığı anlamına gelir; durum harici veritabanlarında, mesaj kuyruklarında veya diğer depolama alanlarında saklanır. Bu yaklaşım, herhangi bir kopyanın herhangi bir isteği işleyebilmesi sayesinde dinamik yatay ölçeklendirmeyi ve sorunsuz dağıtımları kolaylaştırır.
Ancak, kalıcı birimlerle desteklenen durum bilgisi içeren mikro hizmetlere sahip olmaktan başka alternatifin olmadığı senaryolar da vardır . Bu durum, bazı veritabanları, dağıtılmış dosya sistemleri veya yerel verilerin korunmasını gerektiren bileşenler için geçerlidir. Bu pod'lar genellikle StatefulSet'ler ile dağıtılır, PersistentVolumeClaim'ler kullanılarak PersistentVolume'lara bağlanır ve yatay yerine dikey olarak ölçeklenir.
Bir mikro hizmetin kalıcı depolamaya ihtiyacı olduğunda, boyutu, erişim modu ve kullanım amacı belirtilerek bir Kalıcı Birim Talebi (PVC) istenir ve operasyon ekibi bunu platform politikalarına göre sağlar. Bu PVC, dağıtım manifestinde referans alınır ve hizmetin verileri kalıcı olarak okuyup yazabilmesi için pod üzerine monte edilir.
Belirli durumlarda durum bilgisi içeren modeller gerekli olsa da, genel öneri mümkün olduğunca çok hizmeti durum bilgisi içermeyen şekilde tutmaktır . Bu, dağıtımı, ölçeklendirmeyi, dayanıklılığı ve felaket kurtarmayı basitleştirir ve birçok mikro hizmetin bulunduğu ortamlarda operasyonel karmaşıklığı azaltır.
Veri merkezsizleştirme ve hizmet egemenliği
Geleneksel altyapılarda, verimliliği en üst düzeye çıkarmak için veritabanlarını ve depolamayı merkezileştirmek yaygındır. Mikro hizmetlerde ise bu yaklaşım, ekip özerkliği ve ayrışma ile çelişir . Birçok hizmet aynı ilişkisel şemayı paylaşıyorsa, herhangi bir yapısal değişiklik birden fazla ekibi engelleyebilir ve istemeden uyumluluğu bozabilir.
Bu nedenle, her mikro hizmetin kendi veri modeline ve veritabanına sahip olması önerilir ; ancak geliştirme ortamında bu veritabanı, dağıtımı kolaylaştırmak için küme içinde bir konteyner olarak çalışır. Üretimde ise genellikle bulut tarafından yönetilen örnekler veya diğer yüksek kullanılabilirlik veritabanı sunucuları kullanılır ve her zaman net bir sahiplik sınırı korunur.
Bu, veri entegrasyonunun olmadığı anlamına gelmez; bunun yerine, hizmetler arasındaki tutarlılığın olaylar ve eşzamansız mesajlaşma ile yönetildiği ve makul olduğunda nihai tutarlılığın kabul edildiği anlamına gelir. Mikro hizmetler arasında durum değişikliklerini yaymak ve tek bir veritabanına olan güçlü bağımlılıkları azaltmak için olay veri yolları (RabbitMQ, Azure Service Bus, Kafka vb.) kullanmak yaygındır.
Bulut platformu, ekiplerin tek bir teknolojiye bağlı kalmadan her hizmet için en uygun veritabanı türünü (ilişkisel, belge tabanlı, anahtar-değer, zaman serisi vb.) seçmesini kolaylaştırır . Buradaki kilit nokta, tasarımın diğer hizmetlerle olan sözleşmeleri bozmadan şemaların ve yapıların geçiş olasılığını dikkate alması ve veri kararlarının her mikro hizmetin etki alanı sınırlarıyla uyumlu olarak alınmasıdır.
Dağıtılmış yönetim, ekipler ve organizasyon
Organizasyon yapısını değiştirmeden mikro hizmetlere geçmek sorunlara yol açabilir. Ağlar, sistemler, veritabanları, geliştirme ve operasyonlar gibi klasik fonksiyonel silolar yerine, geliştirme, kalite güvence, DevOps ve uygun olduğu durumlarda iş veya veri analistlerinden oluşan profilleri bir araya getiren ürün ekiplerine dayalı bir yapı teşvik edilmektedir.
Her ekip, aynı fonksiyonel alan içindeki bir veya daha fazla mikro hizmetten sorumludur ve hem geliştirme hem de işletme süreçlerini (siz oluşturursunuz, siz çalıştırırsınız) üstlenir . Bu, ekibin CI/CD süreçlerini yönettiği, belirli ihtiyaçlar için altyapı ile iş birliği yaptığı ve izleme ve olay müdahalesine katıldığı anlamına gelir. Altyapı ve bulut platformu, ortak ve standartlaştırılmış hizmetler sunmaya odaklanır.
Bu dağıtık yönetişimin anarşiye dönüşmesini önlemek için, hafif standartlar ve paylaşılan kataloglar tanımlamak çok önemlidir : onaylanmış temel imajlar, dağıtım modelleri, ad alanları ve hizmetler için adlandırma kuralları, API yönergeleri, Dockerfile ve Kustomize şablonları vb. Bu yönergeler, ekiplerin karar verme yeteneklerini engellemeden onlara yol gösteren "koruyucu bariyerler" görevi görür.
Birçok kurumsal ortamda, her proje veya etki alanı için ayrı ad alanları kullanılır ve her ortam için (geliştirme, ön üretim, üretim) en az bir tane bulunur. Büyük bir proje, iç iletişim doğru şekilde yapılandırıldığı ve güvenlik kurallarına uyulduğu sürece, mikro hizmetlerini birden fazla ad alanına dağıtabilir.
CI/CD, otomasyon ve GitOps modeli
Bir mimari düzinelerce veya yüzlerce mikro hizmetten oluştuğunda, bunların çalışır durumda kalmasının tek yolu uçtan uca otomasyona yoğun yatırım yapmaktır . Bu, tutarlı CI/CD işlem hatlarını, bildirimsel dağıtım tanımlarını, otomatik testleri ve otomatik geri alma mekanizmalarını içerir.
Tipik bir sürekli entegrasyon ve dağıtım (CITD) işlem hattı, kod derleme, test çalıştırma, SonarQube gibi araçlarla kalite analizi yapma , kurumsal Dockerfile'dan konteyner imajı oluşturma ve dağıtım manifestlerini güncelleme işlemlerini gerçekleştirir. Buradan sonra, ArgoCD veya benzeri bir sistem, GitOps yaklaşımını kullanarak değişiklikleri kümeye uygular.
Her mikroservis deposu tipik olarak standartlaştırılmış bir Dockerfile, bir işlem hattı yapılandırma dosyası (örneğin, ci.json) , kalite analizi için özellikler ve ortama göre ayrılmış Kubernetes tanımları (Kustomize veya Helm) içeren bir dağıtım dizini içerir. Deponun web kancaları, etiket gönderme veya birleştirme istekleri gibi olaylar meydana geldiğinde işlem hattını tetikler.
GitOps modeli, Git deposunu altyapı ve dağıtım için doğruluk kaynağı olarak belirler . Dağıtımlar, Hizmetler, ConfigMap'ler, PVC'ler, SealedSecrets ve diğer kaynaklar için manifestler burada sürümlendirilir ve belirli araçlar küme durumunu Git'te tanımlananlarla senkronize etmeyi sağlar. Bu, izlenebilirlik, çekme isteği incelemeleri ve kolay geri alma yetenekleri sağlar.
Ayarlar, sırlar ve güvenlik
Olgun bir mikro hizmet platformunda, yapılandırma yönetimi hassas olmayan parametreler için ConfigMap'lere ve gizli bilgiler için Secrets'lara dayanır . Her mikro hizmetin genellikle kendi ortamına özgü bir ConfigMap'i vardır; bu ConfigMap, bağımlı hizmetlerin URL'leri, işlevsellik bayrakları ve ayar parametreleri gibi özellikleri depolar.
Sırlar (kimlik bilgileri, anahtarlar, belirteçler, sertifikalar) sıkı güvenlik politikalarıyla ele alınır . Daha az kritik ortamlarda, geliştirme ekibi tarafından yönetilen düz metin halinde tutulmaları kabul edilebilir olabilir, ancak ön üretim ve üretim ortamlarında, Sealed Secrets veya belirli bulut tabanlı harici yöneticiler gibi araçlar kullanılarak şifrelenmeleri önerilir.
Birden fazla hizmet arasında paylaşılması gereken bir sır (örneğin, OTEL Collector kimlik bilgileri veya ortak bir anahtar deposu ) olduğunda, bu sır her ad alanı için bir yapılandırma deposunda merkezileştirilebilir. Bu ad alanını paylaşan projeler, gerektiğinde güncellemek için koordinasyon sağlar ve bu kaynakları kimin okuyabileceği veya değiştirebileceği üzerindeki kontrolü korur.
İletişim güvenliği açısından baskın model Sıfır Güven'dir : trafiğin "dahili" olması nedeniyle hiçbir şeyin garanti olmadığı varsayılır. Hem dahili hem de harici hizmetler arasındaki tüm çağrıların, ideal olarak mTLS, JWT belirteçleri veya diğer eşdeğer mekanizmalarla kimlik doğrulaması ve yetkilendirmesi yapılmalıdır. Mikro hizmetler, güvenliği körü körüne API Yöneticisine veya ağa devretmez; kendi kontrollerini de gerçekleştirirler.
Mikro hizmetler, API'ler ve mesajlaşma arasındaki iletişim
Olgun bir mikro hizmet mimarisinde, iletişim katmanı çeşitli durumlara ayrılır. İstemcilerden (tarayıcılar, mobil uygulamalar, üçüncü taraflar) arka uca gelen trafik için, bir API Yöneticisi tarafından yönetilen yayınlanmış API'ler kullanılır . Bu API'ler tipik olarak RESTful (çoğunlukla OpenAPI kullanarak) veya bazı durumlarda bir ağ geçidi aracılığıyla sunulan gRPC'dir.
Aynı ad alanında bulunan veya aynı proje içindeki birden fazla ad alanı arasında yer alan mikro hizmetler arasındaki çağrılar, genellikle dahili DNS'ye sahip dahili Kubernetes hizmetleri tarafından ele alınır . Bu çağrılar, genel API Yöneticisini atlar ancak güvenlik, kimlik doğrulama ve yetkilendirme politikalarına uyar. Bu senaryolar için, ortak politikaları uygulayan bir hizmet ağı veya dahili ağ geçitleri kullanılabilir.
Mikroservisler farklı işlevsel alanlara veya projelere ait olduğunda , iletişim organizasyonel düzeyde "açık" olarak kabul edilir. Bu durumlarda, sözleşmelerin, kotaların, güvenliğin, sürümlemenin ve denetimin yönetildiği ve bağımsız kümeler veya ad alanları arasında doğrudan bağlantının önlendiği bir API Yöneticisi veya birlikte çalışabilirlik veri yolu kullanmak yaygın bir uygulamadır.
Modern API'leri her zaman kullanıma sunmayabilecek eski veya harici sistemlerle entegrasyon söz konusu olduğunda, birlikte çalışabilirlik veri yolu üzerinden belirli bağlantı elemanlarına güvenmek yaygındır . Bu şekilde, mikro hizmetler ortak bir dil konuşur (örneğin, olaylar veya dahili REST API'leri) ve bağlantı elemanı, her zaman gelişmiş güvenlik ile eski sisteme ve eski sistemden çeviriyi yönetir.
Senkron iletişime ek olarak, asenkron mesajlaşma da önemli bir rol oynar . Süreçleri birbirinden ayırmak, ani yük artışlarını absorbe etmek, hizmetler arasında iş olaylarını yaymak ve dayanıklılığı artırmak için kullanılır. Her olay genellikle iyi tanımlanmış ve sürümlendirilmiş bir şemaya sahiptir ve üreticiler ile tüketiciler arasında meydana gelebilecek aksaklıkları önlemek için izleme mekanizmaları bulunur.
Gözlemlenebilirlik, OTEL Toplayıcı ve işletimi
Birçok mikro hizmetten oluşan bir sistemde, iyi gözlemlenebilirlik olmadan bir sorunu teşhis etmek neredeyse imkansızdır. Bu nedenle, metrikler, merkezi günlük kaydı ve dağıtılmış izlemeler tasarım aşamasından itibaren entegre edilerek hem hizmet hem de platform düzeyinde neler olup bittiğinin anlaşılması sağlanır.
Bu şemanın temel bileşenlerinden biri, tüm bileşenlerden metrikleri, günlükleri ve izleri toplamak için ad alanında veya merkezi olarak konuşlandırılan OpenTelemetry Collector'dır (OTEL Collector) . Mikroservislerin yalnızca telemetri verilerini Collector'a göndermeleri gerektiğini bilmeleri yeterlidir; Collector daha sonra servisin ayrıntıları bilmesine gerek kalmadan verileri gözlemlenebilirlik sistemlerine (Prometheus, Grafana, Jaeger, Elastic, vb.) iletir.
Altyapı katmanı için, pod'lardan CPU, bellek, disk, ağ ve log metriklerini toplamak ve bunları sırasıyla Prometheus ve Elasticsearch'e göndermek üzere düğüm düzeyinde toplayıcılar ve dışa aktarıcılar kullanılır . Bu bilgileri görselleştirmek, gösterge panoları oluşturmak ve akıllı eşikler ve ilgili çalışma kılavuzlarıyla uyarılar tanımlamak için Grafana ve Kibana gibi araçlar kullanılır.
Bir proje, ölçümlerinin veya izleme verilerinin çok özel bir şekilde işlenmesini gerektirdiğinde, operasyonel onayı almış olması ve üretim bakım modelinin açık olması koşuluyla, kendi ad alanında OTEL Collector'ın kendi örneğini dağıtabilir.
Test stratejisi, sözleşmeler ve yerel geliştirme deneyimi
Dağıtılmış mikro hizmet mimarisini test etmek, monolit bir mimariyi test etmekten daha karmaşık bir test stratejisi gerektirir . Birim testleri temel önemini korurken, sözleşme testleri (API'ler ve olaylar için), hizmetler arası entegrasyon testleri ve tüm akışları kapsayan uçtan uca testler giderek daha önemli hale geliyor.
Uyumluluk sorunlarını önlemek için, istemcilerin API beklentilerini tanımladığı ve hizmet sağlayıcıların bunları karşıladığı tüketici odaklı sözleşme testleri gibi teknikler kullanılır . Her sözleşme değişikliği, CI işlem hatları içinde otomatik testten geçirilir ve bilinen herhangi bir tüketiciyi bozacak dağıtımların önüne geçilir.
Hizmet sayısı yüzü aştığında, tüm sistemi yerel olarak kopyalamak pratik olmaktan çıkar. Bu nedenle, geliştirme, bağımlı hizmetlerin simülasyonlarına veya uzak ortamlara tünelleme yöntemine dayanır . Geliştiriciler genellikle mikro hizmetlerin yalnızca bir alt kümesini başlatır ve geri kalanını sahte nesneler, taklitler veya simülatörlerle değiştirir veya belirli çağrıları paylaşılan bir entegrasyon ortamına yönlendirir.
Uçtan uca testler giderek daha çok, ilgili işlevselliğe ait hizmetleri içeren izole bir ortam oluşturan, özellik dallarından oluşturulan geçici ortamlar veya "önizlemeler" e dayanmaktadır . Bu, ekipler arasındaki sürtüşmeyi en aza indirir, "benim bilgisayarımda çalışıyor" etkisini azaltır ve entegrasyon sorunlarını ön üretim gibi daha pahalı ortamlara ulaşmadan önce tespit eder.
Üretim ortamında mikroservis dağıtım modelleri
Kubernetes'in ötesinde, izolasyon, maliyet ve olgunluk açısından farklı senaryoları ele aldıkları için üretimde bilinmesi gereken çeşitli mikro hizmet dağıtım modelleri bulunmaktadır . En eski modellerden biri, tek bir fiziksel veya sanal sunucunun genellikle paylaşımlı bir uygulama sunucusunda farklı hizmetlerin birden fazla örneğini çalıştırdığı, sunucu başına birden fazla hizmet örneğidir.
Sanal makine başına hizmet örneği modelinde , her hizmet bir sanal makine imajı (örneğin, bir EC2 AMI) olarak paketlenir ve kendi örneğinde çalışır. Bu, daha yüksek kaynak tüketimi ve daha yavaş başlatma süreleri pahasına güçlü bir izolasyon sağlar. Packer gibi araçlar veya bulut sağlayıcısına özgü çözümler, üretime hazır sanal makine imajları oluşturmayı kolaylaştırır.
Günümüzde en yaygın model , her mikro hizmetin bir konteyner imajı olarak oluşturulduğu ve bir düzenleyiciye (Kubernetes, OpenShift vb.) dağıtıldığı konteyner başına hizmet örneği modelidir . Konteynerler sanal makinelerden daha hafiftir, çok hızlı bir şekilde başlatılır ve hizmet için gereken her şeyi paketlemenize olanak tanıyarak dağıtımları basitleştirir ve otomatik ölçeklendirmeyi mümkün kılar.
Son olarak, AWS Lambda gibi sunucusuz yaklaşımlar popülerlik kazanmıştır. Bu yaklaşımlar, diğer servislerden (S3, DynamoDB, kuyruklar vb.) gelen HTTP isteklerine veya olaylara yanıt veren fonksiyonları paketler ve kullanıcılar yalnızca kullandıkları kadar ödeme yaparlar. Bu model, özellikle çok küçük mikro servisler veya kısa ömürlü olay odaklı görevler için uygundur, ancak gözlemlenebilirlik, soğuk başlatmalar ve yürütme sınırları ile ilgili ek hususlar da getirir.
Pratikte, birçok kuruluş hibrit bir ekosistemle sonuçlanır: sistemin çekirdek kısmı konteynerler ve orkestratörler üzerinde çalışırken, bazı yardımcı bileşenler sunucusuz işlevler veya özel sanal makineler olarak uygulanır; bunların bütüne entegre edilmesi için her zaman net arayüzler ve iyi tanımlanmış protokoller bulunur.
Tüm bunları üretime geçirme söz konusu olduğunda, fark yaratan sadece seçilen teknoloji değil, aynı zamanda hatalara tolerans gösteren, gerektiğinde ölçeklenebilen, otomatik olarak dağıtılan ve gözlemlenebilir bir mimari oluşturmaktır . Ürün odaklı ekipler, iyi yönetilen sözleşmeler, merkezi olmayan veriler ve sağlam bir bulut platformu ile mikro hizmetler, bir vaat olmaktan çıkıp, karmaşık uygulamaları yıllarca geliştirmek için etkili ve sürdürülebilir bir yöntem haline gelir.