Uygulama oluşturmak için neden mikro hizmetler yaklaşımını kullanmalısınız?
Yazılım geliştiricileri için bir uygulamayı bileşen parçalarına ayırmak yeni bir şey değildir. Genellikle arka uç deposu, orta katman iş mantığı ve ön uç kullanıcı arabirimi (UI) ile katmanlı bir yaklaşım kullanılır. Son birkaç yılda değişen şey, geliştiricilerin bulut için dağıtılmış uygulamalar oluşturmasıdır.
Değişen iş gereksinimleri şunlardır:
- Yeni coğrafi bölgelerdeki müşterilere ulaşmak için büyük ölçekte oluşturulmuş ve çalıştırılan bir hizmet.
- Müşteri taleplerine çevik bir şekilde yanıt vermek için özelliklerin ve özelliklerin daha hızlı teslimi.
- Maliyetleri azaltmak için geliştirilmiş kaynak kullanımı.
Bu iş gereksinimleri, uygulama oluşturma şeklimizi etkiliyor.
Azure'ın mikro hizmetlere yaklaşımı hakkında daha fazla bilgi için bkz . Mikro hizmetler: Bulut tarafından desteklenen bir uygulama devrimi.
Monolitik ve mikro hizmetler tasarım yaklaşımı karşılaştırması
Uygulamalar zaman içinde gelişir. Başarılı uygulamalar, insanlar için yararlı olarak gelişir. Başarısız uygulamalar gelişmez ve sonunda kullanım dışı bırakılır. İşte şu soru: Bugün gereksinimleriniz hakkında ne kadar bilginiz var ve gelecekte neler olacak? Örneğin, şirketinizdeki bir departman için raporlama uygulaması oluşturduğunuzu varsayalım. Uygulamanın yalnızca şirketinizin kapsamında geçerli olduğundan ve raporların uzun süre tutulmayacağından eminsiniz. Yaklaşımınız, on milyonlarca müşteriye video içeriği sunan bir hizmet oluşturma yaklaşımından farklı olacaktır.
Bazen, kavram kanıtı olarak bir şeyi kapıdan çıkarmak sürüş faktörüdür. Uygulamanın daha sonra yeniden tasarlanabilir olduğunu biliyorsunuz. Hiçbir zaman kullanılmayan bir şeyi aşırı mühendislikle kullanmanın çok az bir anlamı vardır. Öte yandan, şirketler bulut için derleme yaparken beklenti büyüme ve kullanımdır. Büyüme ve ölçek tahmin edilemez. Gelecekteki başarıyı kaldırabilecek bir yolda olduğumuzu bilerek hızlı bir şekilde prototip oluşturmak istiyoruz. Bu, yalın başlangıç yaklaşımıdır: derleme, ölçme, öğrenme ve yineleme.
İstemci/sunucu döneminde, her katmanda belirli teknolojileri kullanarak katmanlı uygulamalar oluşturmaya odaklandık. Bu yaklaşımları açıklamak için monolitik uygulama terimi ortaya çıkmıştır. Arabirimler katmanlar arasında olma eğilimindedir ve her katmandaki bileşenler arasında daha sıkı bir şekilde bağlanmış bir tasarım kullanılmıştır. Geliştiriciler, kitaplıklar halinde derlenmiş ve birkaç yürütülebilir dosya ve DLL'ye birbirine bağlanmış sınıfları tasarlamış ve hesaba katmış.
Monolitik tasarım yaklaşımının avantajları vardır. Monolitik uygulamaların tasarımı genellikle daha kolaydır ve bu çağrılar genellikle işlemler arası iletişim (IPC) üzerinden olduğundan bileşenler arasındaki çağrılar daha hızlıdır. Ayrıca, herkes insan kaynaklarının daha verimli bir kullanımı olma eğiliminde olan tek bir ürünü test eder. Bunun dezavantajı, katmanlı katmanlar arasında sıkı bir bağlantı olması ve bileşenleri tek tek ölçeklendirememenizdir. Düzeltmeler veya yükseltmeler yapmanız gerekiyorsa, başkalarının testlerini bitirmesini beklemeniz gerekir. Çevik olmak daha zordur.
Mikro hizmetler bu dezavantajları ele alır ve önceki iş gereksinimleriyle daha yakından uyum sağlar. Ama aynı zamanda hem yararları hem de yükümlülükleri vardır. Mikro hizmetlerin avantajları, her birinin genellikle ölçeği genişletebileceğiniz veya genişletebileceğiniz, test edip dağıtabileceğiniz ve bağımsız olarak yönetebileceğiniz daha basit iş işlevlerini kapsüllemeleridir. Mikro hizmetler yaklaşımının önemli avantajlarından biri, ekiplerin teknolojiye göre iş senaryolarına göre daha fazla yönlendiriliyor olmasıdır. Daha küçük ekipler, müşteri senaryosunu temel alan bir mikro hizmet geliştirir ve kullanmak istedikleri teknolojileri kullanır.
Başka bir deyişle, kuruluşun mikro hizmet uygulamalarını korumak için teknolojiyi standartlaştırması gerekmez. Hizmetleri olan tek tek ekipler, ekip uzmanlığına veya sorunu çözmek için en uygun olanı temel alarak kendileri için mantıklı olanı yapabilir. Uygulamada, belirli bir NoSQL deposu veya web uygulaması çerçevesi gibi bir dizi önerilen teknoloji tercih edilir.
Mikro hizmetlerin dezavantajı, daha ayrı varlıkları yönetmeniz ve daha karmaşık dağıtımlarla ve sürüm oluşturmayla ilgilenmeniz gerekir. Mikro hizmetler arasındaki ağ trafiği, ilgili ağ gecikme süreleri gibi artar. Çok fazla gevelenek, ayrıntılı hizmet performans kabusu oluşturabilir. Bu bağımlılıkları görüntülemenize yardımcı olacak araçlar olmadan sistemin tamamını görmek zordur.
Standartlar, iletişim kurma ve katı anlaşmalar yerine yalnızca bir hizmetten ihtiyacınız olan şeyleri tolere ederek mikro hizmetler yaklaşımının çalışmasını sağlar. Hizmetler birbirinden bağımsız olarak güncelleştirildiğinden, bu sözleşmeleri tasarımda en önde tanımlamak önemlidir. Mikro hizmet yaklaşımıyla tasarlamaya yönelik başka bir açıklama da "ayrıntılı hizmet odaklı mimari (SOA)" şeklindedir.
En basiti, mikro hizmetler tasarım yaklaşımı, her birinde bağımsız değişiklikler ve iletişim için üzerinde anlaşmaya varılan standartlarla ayrılmış bir hizmet federasyonudur.
Daha fazla bulut uygulaması üretildikçe, insanlar uygulamanın genel olarak bağımsız, senaryo odaklı hizmetlere ayrıştırılmışlığının daha iyi bir uzun vadeli yaklaşım olduğunu keşfetti.
Uygulama geliştirme yaklaşımları arasındaki karşılaştırma
Monolitik bir uygulama, etki alanına özgü işlevler içerir ve normalde web, iş ve veri gibi işlevsel katmanlara ayrılır.
Monolitik bir uygulamayı birden çok sunucuda/sanal makinede/kapsayıcıda kopyalayarak ölçeklendirirsiniz.
Mikro hizmet uygulaması, işlevselliği ayrı küçük hizmetlere ayırır.
Mikro hizmetler yaklaşımı, her hizmeti bağımsız olarak dağıtarak ve bu hizmetlerin örneklerini sunucular/sanal makineler/kapsayıcılar arasında oluşturarak ölçeği genişletir.
Mikro hizmetler yaklaşımıyla tasarım tüm projeler için uygun değildir, ancak daha önce açıklanan iş hedefleriyle daha yakından uyumlu hale gelir. Monolitik bir yaklaşımla başlamak, kodu daha sonra mikro hizmetler tasarımında yeniden çalıştırma fırsatınız olduğunu biliyorsanız mantıklı olabilir. Daha yaygın olarak, monolitik bir uygulamayla başlarsınız ve daha ölçeklenebilir veya çevik olması gereken işlevsel alanlardan başlayarak aşamalı olarak yavaş yavaş bölersiniz.
Mikro hizmetler yaklaşımı kullandığınızda, uygulamanızı birçok küçük hizmetle oluşturursunuz. Bu hizmetler, bir makine kümesine dağıtılan kapsayıcılarda çalışır. Daha küçük ekipler, bir senaryoya odaklanan bir hizmet geliştirir ve tüm uygulamanın gelişebilmesi için her hizmeti bağımsız olarak test eder, sürüm, dağıtır ve ölçeklendirir.
Mikro hizmet nedir?
Mikro hizmetlerin farklı tanımları vardır. Ancak mikro hizmetlerin bu özelliklerinin çoğu yaygın olarak kabul edilir:
- Müşteri veya iş senaryolarını kapsülleme. Hangi sorunu çözüyorsunuz?
- Küçük bir mühendislik ekibi tarafından geliştirilmiştir.
- Herhangi bir programlama dilinde, herhangi bir çerçeve kullanılarak yazılmıştır.
- Her ikisi de bağımsız olarak sürümlendirilen, dağıtılan ve ölçeklendirilen koddan ve isteğe bağlı olarak durumlardan oluşur.
- İyi tanımlanmış arabirimler ve protokoller üzerinden diğer mikro hizmetlerle etkileşime geçin.
- Konumlarını çözümlemek için kullanılan benzersiz adlara (URL' ler) sahip olun.
- Hataların varlığında tutarlı ve kullanılabilir durumda kalır.
Bunu özetlemek için:
Mikro hizmet uygulamaları, iyi tanımlanmış arabirimlere sahip standart protokoller üzerinden birbirleriyle iletişim kuran küçük, bağımsız sürümlü ve ölçeklenebilir müşteri odaklı hizmetlerden oluşur.
Herhangi bir programlama dilinde, herhangi bir çerçeve kullanılarak yazılmıştır
Geliştiriciler olarak becerilerimize ve oluşturduğumuz hizmetin gereksinimlerine bağlı olarak bir dil veya çerçeve seçmekte özgür olmak istiyoruz. Bazı hizmetler için C++'ın performans avantajlarına diğer her şeyin üzerinde değer verebilirsiniz. Diğerleri için, C# veya Java'dan edindiğiniz yönetilen geliştirme kolaylığı daha önemli olabilir. Bazı durumlarda, hizmeti istemcilere ifşa etmek için belirli bir iş ortağı kitaplığını, veri depolama teknolojisini veya yöntemini kullanmanız gerekebilir.
Bir teknoloji seçtikten sonra, hizmetin işletimsel veya yaşam döngüsü yönetimini ve ölçeklendirmesini göz önünde bulundurmanız gerekir.
Kodun ve durumun bağımsız olarak sürümlendirilmesine, dağıtılmasına ve ölçeklendirilmesine izin verir
Mikro hizmetlerinizi, kodu ve isteğe bağlı olarak durumu nasıl yazarsanız yazın, bağımsız olarak dağıtmalı, yükseltmeli ve ölçeklendirmelidir. Bu sorunu çözmek zordur çünkü bu sorun sizin seçtiğiniz teknolojilere kadar uzanır. Ölçeklendirme için hem kodu hem de durumu bölümleme (veya parça) işlemini anlamak zordur. Kod ve durum, günümüzde yaygın olarak kullanılan farklı teknolojiler kullandığında mikro hizmetinizin dağıtım betiklerinin her ikisini de ölçeklendirebilmesi gerekir. Bu ayrım aynı zamanda çeviklik ve esneklikle de ilgili olduğundan, mikro hizmetlerden bazılarını tümünü aynı anda yükseltmek zorunda kalmadan yükseltebilirsiniz.
Şimdi monolitik ve mikro hizmetler yaklaşımlarını bir an için karşılaştırmamıza geri dönelim. Bu diyagramda, durumu depolama yaklaşımlarındaki farklar gösterilmektedir:
İki yaklaşım için durum depolama
Sol taraftaki monolitik yaklaşım tek bir veritabanına ve belirli teknolojilerin katmanlarına sahiptir.
Sağ taraftaki mikro hizmetler yaklaşımında, durumun genellikle mikro hizmet kapsamına alındığı ve çeşitli teknolojilerin kullanıldığı birbirine bağlı mikro hizmetlerin grafiği bulunur.
Monolitik bir yaklaşımda uygulama genellikle tek bir veritabanı kullanır. Tek bir veritabanını kullanmanın avantajı, tek bir konumda olmasıdır ve bu da dağıtmayı kolaylaştırır. Her bileşenin durumunu depolamak için tek bir tablosu olabilir. Ekiplerin durumu kesin olarak ayırması gerekir ve bu bir zorluk. Kaçınılmaz olarak, birisi mevcut bir müşteri tablosuna sütun eklemeye, tablolar arasında birleştirme yapmaya ve depolama katmanında bağımlılıklar oluşturmaya özenecektir. Bu durumda bileşenleri tek tek ölçeklendiremezsiniz.
Mikro hizmetler yaklaşımında her hizmet kendi durumunu yönetir ve depolar. Her hizmet, hizmetin taleplerini karşılamak için hem kodu hem de durumu birlikte ölçeklendirmekle sorumludur. Dezavantajı, uygulamanızın verilerinin görünümlerini veya sorgularını oluşturmanız gerektiğinde birden çok durum deposunda sorgulama yapmanız gerektiğidir. Bu sorun genellikle bir mikro hizmet koleksiyonu genelinde bir görünüm oluşturan ayrı bir mikro hizmet tarafından çözülür. Veriler üzerinde birden çok hazırlıksız sorgu çalıştırmanız gerekiyorsa, her mikro hizmetin verilerini çevrimdışı analiz için bir veri ambarı hizmetine yazmayı düşünmelisiniz.
Mikro hizmetler sürümü oluşturulur. Mikro hizmetin farklı sürümlerinin yan yana çalışması mümkündür. Mikro hizmetin daha yeni bir sürümü yükseltme sırasında başarısız olabilir ve önceki bir sürüme geri alınması gerekir. Sürüm oluşturma, farklı kullanıcıların hizmetin farklı sürümlerini deneyimlediği A/B testi için de yararlıdır. Örneğin, yeni işlevleri daha geniş bir şekilde kullanıma sunmadan önce test etmek üzere belirli bir müşteri kümesi için mikro hizmeti yükseltmek yaygın bir durum olabilir.
İyi tanımlanmış arabirimler ve protokoller üzerinden diğer mikro hizmetlerle etkileşim kurar
Son 10 yılda, hizmet odaklı mimarilerdeki iletişim desenlerini açıklayan kapsamlı bilgiler yayımlanmıştır. Genel olarak hizmet iletişimi, serileştirme biçimi olarak HTTP ve TCP protokolleri ve XML veya JSON ile rest yaklaşımını kullanır. Arabirim açısından bakıldığında, web tasarımı yaklaşımını benimsemektir. Ancak hiçbir şey ikili protokolleri veya kendi veri biçimlerinizi kullanmanızı engellememelidir. Bu protokoller ve biçimler açık bir şekilde kullanılamıyorsa, kişilerin mikro hizmetlerinizi kullanmakta zorlanacağına dikkat edin.
Konumunu çözümlemek için kullanılan benzersiz bir ada (URL) sahiptir
Mikro hizmetinizin çalıştığı her yerde adreslenebilir olması gerekir. Makineleri ve hangisinin belirli bir mikro hizmeti çalıştırdığını düşünüyorsanız, işler hızla kötüye gidebilir.
DNS'nin belirli bir makineye yönelik belirli bir URL'yi çözümlemesi gibi, mikro hizmetinizin geçerli konumunun bulunabilir olması için benzersiz bir ada ihtiyacı vardır. Mikro hizmetler, üzerinde çalıştıkları altyapıdan bağımsız adreslenebilir adlara ihtiyaç duyar. Bu, bir hizmet kayıt defteri olması gerektiğinden, hizmetinizin nasıl dağıtıldığı ve nasıl bulunduğu arasında bir etkileşim olduğu anlamına gelir. Bir makine başarısız olduğunda, kayıt defteri hizmetinin hizmetin nereye taşındığını size söylemesi gerekir.
Tutarlı kalır ve hata durumunda kullanılabilir durumda kalır
Beklenmeyen hatalarla başa çıkmak, özellikle dağıtılmış bir sistemde çözülmesi en zor sorunlardan biridir. Geliştiriciler olarak yazdığımız kodun çoğu özel durumları işlemeye yöneliktir. Test sırasında en fazla zamanı özel durum işlemeye harcarız. İşlem, hataları işlemek için kod yazmaktan daha önemlidir. Mikro hizmetin çalıştığı makine başarısız olduğunda ne olur? Tek başına zor bir sorun olan hatayı algılamanız gerekir. Ancak mikro hizmetinizi de yeniden başlatmanız gerekir.
Kullanılabilirlik için mikro hizmetin hatalara dayanıklı olması ve başka bir makinede yeniden başlatılabilmesi gerekir. Bu dayanıklılık gereksinimlerine ek olarak, verilerin kaybolmaması ve verilerin tutarlı kalması gerekir.
Bir uygulama yükseltmesi sırasında hatalar olduğunda dayanıklılık elde etmek zordur. Dağıtım sistemiyle çalışan mikro hizmetin kurtarılması gerekmez. Tutarlı bir durumu korumak için daha yeni sürüme geçmeye veya önceki bir sürüme geri dönmeye devam edip etmeyeceğini belirlemesi gerekir. İlerlemeye devam etmek için yeterli makinenin kullanılabilir olup olmadığı ve mikro hizmetin önceki sürümlerini nasıl kurtarabileceğiniz gibi birkaç soru göz önünde bulundurmanız gerekir. Bu kararları almak için sistem durumu bilgilerini yaymak için mikro hizmete ihtiyacınız vardır.
Sistem durumunu ve tanılamayı raporlar
Belirgin görünebilir ve genellikle göz ardı edilir, ancak bir mikro hizmetin sistem durumunu ve tanılamasını bildirmesi gerekir. Aksi takdirde, operasyon açısından sistem durumu hakkında çok az içgörüye sahip olursunuz. Tanılama olaylarını bir dizi bağımsız hizmet arasında ilişkilendirmek ve olay sırasını anlamlı hale getirmek için makine saati dengesizlikleriyle ilgilenmek zordur. Üzerinde anlaşmaya varılan protokoller ve veri biçimleri üzerinden bir mikro hizmetle etkileşim kurarken olduğu gibi, sorgulama ve görüntüleme için bir olay deposunda sonuçlanacak sistem durumu ve tanılama olaylarının nasıl günlüğe kaydedileceğini standartlaştırmanız gerekir. Mikro hizmetler yaklaşımıyla, farklı ekiplerin tek bir günlük kaydı biçimi üzerinde anlaşmaları gerekir. Uygulamadaki tanılama olaylarını bir bütün olarak görüntülemek için tutarlı bir yaklaşım olması gerekir.
Sistem durumu tanılamadan farklıdır. Sistem durumu, mikro hizmetin uygun eylemleri gerçekleştirmesi için geçerli durumunu raporlamasıyla ilgili. Kullanılabilirliği korumak için yükseltme ve dağıtım mekanizmalarıyla çalışmak iyi bir örnektir. İşlem kilitlenmesi veya makine yeniden başlatması nedeniyle bir hizmet şu anda iyi durumda olmasa da, hizmet hala çalışır durumda olabilir. İhtiyacınız olan son şey, yükseltme başlatarak durumu daha da kötü hale getirmektir. En iyi yaklaşım, önce araştırmak veya mikro hizmetin kurtarılması için zaman vermektir. Mikro hizmetten gelen sağlık olayları bilinçli kararlar almamıza ve aslında kendi kendini iyileştirici hizmetler oluşturmamıza yardımcı olur.
Azure'da mikro hizmetler tasarlama kılavuzu
Azure'da mikro hizmetler tasarlama ve oluşturma konusunda rehberlik için Azure mimari merkezini ziyaret edin.
Mikro hizmet platformu olarak Service Fabric
Azure Service Fabric, Microsoft genellikle monolitik olan kutulu ürünleri teslim etmeden hizmet sunmaya geçtiğinde ortaya çıktı. Azure SQL Veritabanı ve Azure Cosmos DB gibi şekillendirilmiş Service Fabric gibi büyük hizmetleri oluşturma ve çalıştırma deneyimi. Platform, daha fazla hizmet tarafından benimsendikçe zaman içinde gelişti. Service Fabric'in yalnızca Azure'da değil, tek başına Windows Server dağıtımlarında da çalışması gerekiyordu.
Service Fabric'in amacı, bir hizmet oluşturma ve çalıştırmanın zor sorunlarını çözmek ve altyapı kaynaklarını verimli bir şekilde kullanmaktır, böylece ekipler iş sorunlarını mikro hizmetler yaklaşımını kullanarak çözebilir.
Service Fabric, şunları sağlayarak mikro hizmetler yaklaşımını kullanan uygulamalar oluşturmanıza yardımcı olur:
- Başarısız hizmetleri dağıtmak, yükseltmek, algılamak ve yeniden başlatmak, hizmetleri bulmak, iletileri yönlendirmek, durumu yönetmek ve sistem durumunu izlemek için sistem hizmetleri sağlayan bir platform.
- Kapsayıcılarda veya işlem olarak çalışan uygulamaları dağıtma olanağı. Service Fabric bir kapsayıcı ve işlem düzenleyicidir.
- Uygulamaları mikro hizmet olarak oluşturmanıza yardımcı olacak üretken programlama API'leri: ASP.NET Core, Reliable Actors ve Reliable Services. Örneğin, sistem durumu ve tanılama bilgilerini alabilir veya yerleşik yüksek kullanılabilirlik avantajlarından yararlanabilirsiniz.
Service Fabric, hizmetinizi nasıl derlediğiniz konusunda belirsizdir ve herhangi bir teknolojiyi kullanabilirsiniz. Ancak mikro hizmet oluşturmayı kolaylaştıran yerleşik programlama API'leri sağlar.
Mevcut uygulamaları Service Fabric'e geçirme
Service Fabric, mevcut kodu yeniden kullanmanıza ve yeni mikro hizmetlerle modernleştirmenize olanak tanır. Modernleştirmenin beş aşaması vardır ve herhangi bir aşamada başlayıp durabilirsiniz. Aşamalar şunlardır:
- Geleneksel monolitik bir uygulamayla başlayın.
- Geçirme. Service Fabric'te mevcut kodu barındırmak için kapsayıcıları veya konuk yürütülebilir dosyaları kullanın.
- Modernleştirin. Mevcut kapsayıcılı kodun yanı sıra yeni mikro hizmetler ekleyin.
- Yenilik yapın. Monolitik uygulamayı ihtiyaç temelinde mikro hizmetlere bölün.
- Uygulamaları mikro hizmetlere dönüştürme. Mevcut monolitik uygulamaları dönüştürün veya yeni yeşil alan uygulamaları oluşturun.
Unutmayın, bu aşamalardan herhangi birinde başlayıp durabilirsiniz. Sonraki aşamaya geçmek zorunda değilsiniz.
Şimdi bu aşamaların her biri için örneklere göz atalım.
Geçirme
İki nedenden dolayı, birçok şirket mevcut monolitik uygulamaları kapsayıcılara geçiriyor:
- Mevcut donanımın birleştirilmesi ve kaldırılması ya da uygulamaların daha yüksek yoğunlukta çalıştırılması nedeniyle maliyet azaltma.
- Geliştirme ve operasyonlar arasında tutarlı bir dağıtım sözleşmesi.
Maliyet azaltma işlemleri basittir. Microsoft'ta mevcut uygulamaların çoğu kapsayıcılı hale getirilerek milyonlarca dolar tasarruf sağlanıyor. Tutarlı dağıtımı değerlendirmek daha zordur, ancak aynı derecede önemlidir. Bu, geliştiricilerin kendilerine uygun teknolojileri seçebileceği, ancak işlemlerin uygulamaları dağıtmak ve yönetmek için yalnızca tek bir yöntemi kabul edeceği anlamına gelir. Bu, geliştiricileri yalnızca belirli teknolojileri seçmeye zorlamadan farklı teknolojileri desteklemenin karmaşıklığını ortadan kaldırır. Temel olarak, her uygulama kendi içinde dağıtım görüntüleri halinde kapsayıcılı hale getirilir.
Birçok kuruluş burada durur. Kapsayıcıların avantajları zaten vardır ve Service Fabric dağıtım, yükseltmeler, sürüm oluşturma, geri almalar ve sistem durumu izleme gibi eksiksiz bir yönetim deneyimi sağlar.
Modernleştirme
Modernleştirme, mevcut kapsayıcılı kodla birlikte yeni hizmetlerin eklenmesidir. Yeni kod yazacaksanız mikro hizmetler yolunda küçük adımlar atmak en iyisidir. Bu, yeni bir REST API uç noktası veya yeni iş mantığı eklemek anlamına gelebilir. Bu şekilde, yeni mikro hizmetler oluşturma işlemine başlar ve bunları geliştirme ve dağıtma alıştırması gerçekleştirirsiniz.
Yenilik
Mikro hizmetler yaklaşımı, değişen iş gereksinimlerini karşılar. Bu aşamada, monolitik uygulamayı hizmetlere bölmeye mi yoksa yenilik yapmaya mı başlayacağınıza karar vermeniz gerekir. Burada klasik bir örnek, iş akışı kuyruğu olarak kullandığınız bir veritabanının işleme performans sorununa dönüşüyor olmasıdır. İş akışı isteklerinin sayısı arttıkça, çalışmanın ölçeklendirilmek üzere dağıtılması gerekir. Uygulamanın ölçeklendirmeyen veya daha sık güncelleştirilmesi gereken belirli bir parçasını alıp mikro hizmet olarak ayırıp yenilik yapın.
Uygulamaları mikro hizmetlere dönüştürme
Bu aşamada, uygulamanız tamamen mikro hizmetlerden oluşur (veya ayrılmıştır). Bu noktaya ulaşmak için mikro hizmetler yolculuğunu yaptınız. Buradan başlayabilirsiniz, ancak bunu önemli bir yatırım yapmanıza yardımcı olacak bir mikro hizmet platformu olmadan yapabilirsiniz.
Mikro hizmetler uygulamam için uygun mu?
Belki. Microsoft'ta, iş nedeniyle bulut için daha fazla ekip oluşturmaya başladığından, çoğu mikro hizmet benzeri bir yaklaşım benimsemenin avantajlarını fark etti. Örneğin Bing yıllardır mikro hizmetleri kullanıyor. Diğer ekipler için mikro hizmetler yaklaşımı yeniydi. Ekipler, çekirdek güç alanlarının dışında çözmeleri gereken zor sorunlar olduğunu belirledi. Bu nedenle Service Fabric, hizmet oluşturma teknolojisi olarak çekiş kazandı.
Service Fabric'in amacı, mikro hizmet uygulamaları oluşturmanın karmaşıklıklarını azaltmaktır, böylece çok fazla maliyetli yeniden tasarımdan geçmeniz gerekmez. Küçük bir başlangıç yapın, gerektiğinde ölçeklendirin, hizmetleri kullanımdan kaldırın, yenilerini ekleyin ve müşteri kullanımıyla geliştirin. Ayrıca mikro hizmetleri çoğu geliştirici için daha ulaşılabilir hale getirmek için henüz çözülecek başka birçok sorun olduğunu da biliyoruz. Kapsayıcılar ve aktör programlama modeli, bu yöndeki küçük adımlara örnektir. Mikro hizmetler yaklaşımını kolaylaştırmak için daha fazla yenilik ortaya çıkacağına eminiz.