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, geliştiricilerin bulut için dağıtılmış uygulamalar oluşturmaları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 etkiler.
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, kişiler için yararlı olarak gelişir. Başarısız uygulamalar gelişmez ve sonunda kullanım dışı bırakılır. İşte soru: Bugün gereksinimleriniz hakkında ne kadar bilginiz var ve gelecekte ne 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şturmaktan 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ılmamış bir şeyin aşırı mühendislikle kullanılması çok az şey ifade eder. Ö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 odaklanma eğilimindeyiz. 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ıklara derlenmiş ve birkaç yürütülebilir dosya ve DLL'ye bağlanmış sınıflar tasarlayıp hesaba katmış.
Monolitik tasarım yaklaşımının avantajları vardır. Monolitik uygulamaların tasarımı genellikle daha kolaydır ve bileşenler arasındaki çağrılar genellikle işlemler arası iletişim (IPC) üzerinden olduğundan daha hızlıdır. Ayrıca herkes tek bir ürünü test eder ve bu da insan kaynaklarının daha verimli bir şekilde kullanılmasına neden olur. 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 sorumlulukları vardır. Mikro hizmetlerin avantajları, her birinin genellikle ölçeği genişletebileceğiniz veya daraltabileceğiniz, bağımsız olarak test edip dağıtabileceğiniz ve yönetebileceğiniz daha basit iş işlevlerini kapsüllemeleridir. Mikro hizmetler yaklaşımının önemli avantajlarından biri, ekiplerin teknolojiye göre daha çok iş senaryoları tarafından 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. Hizmetlere sahip olan tek tek ekipler, ekip uzmanlığına veya sorunu çözmek için en uygun olan şeye göre kendileri için mantıklı olanı yapabilir. Uygulamada, belirli bir NoSQL deposu veya web uygulaması çerçevesi gibi önerilen teknolojiler 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 gerekmelerinden kaynaklanır. Mikro hizmetler arasındaki ağ trafiği, buna karşılık gelen ağ gecikme süreleri gibi artar. Gevevelemeli, ayrıntılı hizmetlerin çoğu 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, katı anlaşmalar yerine iletişim kurma ve hizmetten yalnızca ihtiyacınız olan şeylere tolerans sağlamayı belirterek 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 öne doğru tanımlamak önemlidir. Mikro hizmetler yaklaşımıyla tasarlamaya yönelik bir diğer açıklama da "ayrıntılı hizmet odaklı mimari (SOA)" şeklindedir.
En basiti, mikro hizmet 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 federasyonu hakkındadır.
Daha fazla bulut uygulaması üretildikçe, insanlar uygulamanın genel olarak bağımsız, senaryo odaklı hizmetlere ayrıştırılmışlığının uzun vadeli daha iyi bir 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 sunucuya/sanal makineye/kapsayıcıya 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 uyum sağlar. Monolitik bir yaklaşımdan başlayarak kodu daha sonra bir mikro hizmet 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ını kullandığınızda, uygulamanızı birçok küçük hizmette 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 uygulamanın tamamının gelişebilmesi için her hizmeti bağımsız olarak test eder, sürüme alır, 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 durumlarından 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 olur.
- Hataların varlığında tutarlı ve kullanılabilir durumda kalın.
Bunu özetlemek için:
Mikro hizmet uygulamaları, iyi tanımlanmış arabirimlerle standart protokoller üzerinden birbirleriyle iletişim kuran küçük, bağımsız sürüme sahip 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 göstermek 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ümüne dönüştürülmesini, dağıtılmasını ve ölçeklendirilmesini sağlar
Mikro hizmetlerinizi nasıl yazarsanız yazın, kod ve isteğe bağlı olarak durum bağımsız olarak dağıtılmalı, yükseltilmelidir ve ölçeklendirilmelidir. Bu sorunu çözmek zordur çünkü sizin seçtiğiniz teknolojilere iner. Ölçeklendirme için hem kodu hem de durumu bölümlemeyi (veya parçalamayı) anlamak zordur. Kod ve durum farklı teknolojiler kullandığında (bugün yaygın olarak görülür) 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 hizmet yaklaşımlarının karşılaştırmasına geri dönelim. Bu diyagramda, durumu depolama yaklaşımlarındaki farklılıklar 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ğ tarafta mikro hizmetler yaklaşımı, durumun genellikle mikro hizmet kapsamına alındığı ve çeşitli teknolojilerin kullanıldığı birbirine bağlı mikro hizmetler grafiğine sahiptir.
Monolitik bir yaklaşımda, uygulama genellikle tek bir veritabanı kullanır. Tek bir veritabanını kullanmanın avantajı, veritabanının tek bir konumda olmasıdır ve bu da dağıtımı kolaylaştırır. Her bileşenin durumunu depolamak için tek bir tablosu olabilir. Ekiplerin durumu kesin olarak ayırması gerekir. Bu bir zorluk. Kaçınılmaz olarak, birisi mevcut bir müşteri tablosuna sütun eklemek, tablolar arasında birleştirme yapmak ve depolama katmanında bağımlılıklar oluşturmak için cazip olacaktır. 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. Bunun 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ı göz önünde bulundurmalısınız.
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ımlandı. Hizmet iletişimi genellikle 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, insanların mikro hizmetlerinizi kullanmakta zorlandığını unutmayın.
Konumunu çözümlemek için kullanılan benzersiz bir ad (URL) var
Mikro hizmetinizin çalıştığı her yerde ele alınabilmesi 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 makine için belirli bir URL'yi çözümlemesiyle aynı şekilde, 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ıdır ve hata durumunda kullanılabilir durumdadı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? Hatayı algılamanız gerekir ve bu da kendi başına zor bir sorundur. 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.
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 bir sürüme geçmeye devam edip etmeyeceğini veya önceki bir sürüme geri dönüp dönemeyeceğini belirlemesi gerekir. İlerlemeye devam etmek için yeterli makinenin kullanılabilir olup olmadığı ve mikro hizmetin önceki sürümlerinin nasıl kurtarılması gerektiği 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
Açıkça 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 mikro hizmetle etkileşimde olduğunuz gibi, sorgulama ve görüntüleme için bir olay deposunda sonlanacak 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üğe kaydetme biçimi üzerinde anlaşmaları gerekir. Uygulamada 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 olmayabilir, ancak hizmet hala çalışır durumda olabilir. İhtiyacınız olan son şey, bir 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 vermemize 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'un genellikle monolitik olan kutulu ürünleri teslim etmeden hizmet sunmaya geçişiyle ortaya çıktı. Azure SQL Veritabanı ve Azure Cosmos DB gibi büyük hizmetleri oluşturma ve çalıştırma deneyimi, şekillendirilmiş Service Fabric. Platform, daha fazla hizmet tarafından benimsendikçe zaman içinde gelişti. Service Fabric'in yalnızca Azure'da değil, aynı zamanda tek başına Windows Server dağıtımlarında da çalışması gerekiyordu.
Service Fabric'in amacı, bir hizmeti oluşturma ve çalıştırmanın zor sorunlarını çözmek ve altyapı kaynaklarını verimli bir şekilde kullanmaktır, böylece ekipler mikro hizmet yaklaşımını kullanarak iş sorunlarını çö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.
- Mikro hizmet olarak uygulamalar 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 oluşturduğunuzdan bağımsızdır ve herhangi bir teknolojiyi kullanabilirsiniz. Ancak mikro hizmetler 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. Uygulama modernleştirmenin beş aşaması vardır ve herhangi bir aşamada başlayıp durabilirsiniz. Aşamalar şunlardır:
- Geleneksel bir monolitik uygulamayla başlayın.
- Geçirme. Mevcut kodu Service Fabric'te 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. Monolitik uygulamayı ihtiyaç temelinde mikro hizmetlere bölün.
- Uygulamaları mikro hizmetlere dönüştürün. 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. Bir sonraki aşamaya geçmek zorunda değilsiniz.
Şimdi bu aşamaların her biri için örneklere göz atalım.
Geçiş
İki nedenle, birçok şirket mevcut monolitik uygulamaları kapsayıcılara geçiriyor:
- Mevcut donanımın birleştirilmesi ve kaldırılması veya 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 birçok uygulama kapsayıcılı hale getirilerek milyonlarca dolar tasarruf sağlanıyor. Tutarlı dağıtımın değerlendirilmesi 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ığıyla ilgilenmek zorunda kalmaktan kaynaklanan işlemleri azaltır. Temel olarak, her uygulama kendi içinde dağıtım görüntülerine 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 alma ve sistem durumu izleme dahil olmak üzere 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 yapma
Mikro hizmetler yaklaşımı, değişen iş gereksinimlerini karşılar. Bu aşamada, monolitik uygulamayı hizmetlere bölmeye mi yoksa yenilikler 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, işin ölçek için 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 mikro hizmetlere ayrılır). Bu noktaya ulaşmak için mikro hizmetler yolculuğunu yaptınız. Buradan başlayabilirsiniz, ancak önemli bir yatırım yapmanıza yardımcı olacak bir mikro hizmet platformu olmadan bunu 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 hizmetler kullanıyor. Diğer takımlar için mikro hizmetler yaklaşımı yeniydi. Ekipler, temel güç alanlarının dışında çözülmesi gereken zor sorunlar olduğunu belirledi. Bu nedenle Service Fabric, bina hizmetleri için teknoloji 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 çözülecek daha birçok sorun olduğunu da biliyoruz. Kapsayıcılar ve aktör programlama modeli, bu yöndeki küçük adımlara örnek olarak verilebilir. Mikro hizmetler yaklaşımını kolaylaştırmak için daha fazla yenilik ortaya çıkacağına eminiz.