Mikro hizmetler değerlendirmesi ve hazır olma durumu

  • Makale

Mikro hizmetler mimarisi, uygulamalarınız için çeviklik, ölçeklenebilirlik ve yüksek kullanılabilirlik gibi birçok avantaj sağlayabilir. Bu mimari, bu avantajların yanı sıra güçlükler de sunar. Mikro hizmet tabanlı uygulamalar oluştururken veya mevcut uygulamaları bir mikro hizmet mimarisine dönüştürürken, iyileştirme gerektiren alanları belirlemek için geçerli durumunuzu analiz edip değerlendirmeniz gerekir.

Bu kılavuz, bir mikro hizmet mimarisine geçiş yaparken göz önünde bulundurmanız gereken bazı noktaları anlamanıza yardımcı olur. Uygulamanızın, altyapınızın, DevOps'unuzun, geliştirme modelinizin ve daha fazlasının olgunluğunu değerlendirmek için bu kılavuzu kullanabilirsiniz.

İş önceliklerini anlama

Mikro hizmet mimarisini değerlendirmeye başlamak için önce işletmenizin temel önceliklerini anlamanız gerekir. Temel öncelikler çeviklik, değişiklik benimseme veya hızlı geliştirme gibi durumlarla ilgili olabilir. Mimarinizin temel önceliklerinize uygun olup olmadığını analiz etmeniz gerekir. İş önceliklerinin zaman içinde değişebileceğini unutmayın. Örneğin yenilik, startup'lar için en önemli önceliktir, ancak birkaç yıl sonra temel öncelikler güvenilirlik ve verimlilik olabilir.

Dikkate alınması gereken bazı öncelikler şunlardır:

  • Yenilik
  • Güvenilirlik
  • Verimlilik

Değerlendirmenize kılavuzluk edecek bir kuruluş taahhüdü sağlamak için uygulamanızın çeşitli bölümleriyle uyumlu SLA'ları belgeleyin.

Mimari kararları kaydetme

Mikro hizmetler mimarisi, ekiplerin otonom hale gelmesine yardımcı olur. Ekipler teknolojiler, metodolojiler ve altyapı bileşenleri hakkında kendi kararlarını verebilir. Ancak bu seçimlerin, ekipler arasında mikro hizmetlere yönelik daha geniş kapsamlı stratejinin nasıl ele alındığı konusunda anlaşmayı ifade eden, paylaşılan idare olarak bilinen resmi olarak kabul edilen ilkelere saygı duyması gerekir.

Şu faktörleri göz önünde bulundurun:

  • Paylaşılan idare yerinde mi?
  • Kararları ve bunların dengelerini bir mimari günlüğünde mi izlersiniz?
  • Ekibiniz mimari günlüğünüze kolayca erişebilir mi?
  • Araçları, teknolojileri ve çerçeveleri değerlendirme süreciniz var mı?

Ekip oluşturma değerlendirme

Ekipler arasında gereksiz iletişimlerden kaçınmak için uygun ekip yapısına sahip olmanız gerekir. Mikro hizmetler mimarisi, küçük, odaklanmış, işlevsel ekiplerin oluşturulmasını teşvik eder ve takım yeniden yapılandırmasından önce olması gereken bir düşünce değişikliği gerektirir.

Şu faktörleri göz önünde bulundurun:

  • Ekipleriniz, etki alanı odaklı tasarım (DDD) ilkelerine göre alt etki alanları temelinde bölünmüş mü?
  • Ekipleriniz, ilgili mikro hizmetleri bağımsız olarak oluşturmak ve çalıştırmak için yeterli kapasiteye sahip işlevsel mi?
  • Projeyle ilgili olmayan geçici etkinliklerde ve görevlerde ne kadar zaman harcanır?
  • Ekipler arası işbirliği için ne kadar zaman harcandı?
  • Teknik borcu belirlemek ve en aza indirmek için bir süreciniz var mı?
  • Dersler nasıl öğrenilir ve deneyim ekipler arasında nasıl iletilir?

Twelve-Factor metodolojisini kullanma

Mikro hizmet mimarisi seçmenin temel amacı, çevik uygulamaları izleyerek daha hızlı değer sunmak ve değişikliğe uyarlamalı olmaktır. Twelve-Factor uygulama metodolojisi, sürdürülebilir ve ölçeklenebilir uygulamalar oluşturmaya yönelik yönergeler sağlar. Bu yönergeler değişmezlik, kısa ömürlülük, bildirim temelli yapılandırma ve otomasyon gibi öznitelikleri yükseltir. Bu yönergeleri ekleyerek ve yaygın tuzaklardan kaçınarak, gevşek bir şekilde bağlanmış, bağımsız mikro hizmetler oluşturabilirsiniz.

Ayrıştırma yaklaşımını anlama

Monolitik bir uygulamayı mikro hizmetler mimarisine dönüştürmek zaman alır. Uç hizmetlerle başlayın. Edge hizmetlerinin diğer hizmetlere bağımlılığı daha azdır ve sistemden bağımsız hizmetler olarak kolayca ayrıştırılabilir. Tüm hizmetler ayrı mikro hizmetlere bölünene kadar monolitik uygulamayı çalışma durumunda tutmak için Strangler Fig ve Anti-corruption Layer gibi desenleri kesinlikle öneririz. Ayrıştırma sırasında DDD ilkeleri, ekiplerin alt etki alanları temelinde monolitik uygulamadan bileşen veya hizmet seçmesine yardımcı olabilir.

Örneğin, bir e-ticaret sisteminde şu modüllere sahip olabilirsiniz: sepet, ürün yönetimi, sipariş yönetimi, fiyatlandırma, fatura oluşturma ve bildirim. Uygulamanın diğer modüllere bağımlılıkları olmadığından bildirim modülüyle dönüştürmeyi başlatmaya karar verirsiniz. Ancak, diğer modüller bildirim göndermek için bu modüle bağlı olabilir. Bildirim modülü kolayca ayrı bir mikro hizmete ayrılabilir, ancak yeni bildirim hizmetini çağırmak için monolitik uygulamada bazı değişiklikler yapmanız gerekir. Sonraki adımda fatura oluşturma modülünü dönüştürmeye karar vereceksiniz. Bu modül, bir sipariş oluşturulduktan sonra çağrılır. Bu dönüşümü desteklemek için Strangler ve Anti-corruption gibi desenleri kullanabilirsiniz.

Veri eşitleme, hem monolitik hem de mikro hizmet arabirimlerine çoklu yazma, veri sahipliği, şema ayrıştırma, birleştirmeler, veri hacmi ve veri bütünlüğü veri dökümünü ve geçişi zorlaştırabilir. Paylaşılan veritabanını mikro hizmetler arasında tutma, iş özelliğine veya etki alanına göre bir hizmet grubundan veritabanlarını ayırma ve hizmetlerden veritabanlarını yalıtma gibi kullanabileceğiniz çeşitli teknikler vardır. Önerilen çözüm, her veritabanını her hizmetle ayrıştırmaktır. Pek çok durumda, bu pratik değildir. Bu gibi durumlarda, Veritabanı Görünümü düzeni ve Veritabanı Sarmalama Hizmeti deseni gibi desenler kullanabilirsiniz.

DevOps hazırlığını değerlendirme

Bir mikro hizmet mimarisine geçtiğinizde DevOps yetkinliğinizi değerlendirmeniz önemlidir. Mikro hizmetler mimarisi, kurumsal çevikliği artırmak için uygulamalarda çevik geliştirmeyi kolaylaştırmaya yöneliktir. DevOps, bu yetkinliğe ulaşmak için uygulamanız gereken temel uygulamalardan biridir.

DevOps özelliğinizi bir mikro hizmet mimarisi için değerlendirirken şu noktaları aklınızda bulundurun:

  • Kuruluşunuzdaki kişiler DevOps'un temel uygulamalarını ve ilkelerini biliyor mu?
  • Ekipler kaynak denetim araçlarını ve CI/CD işlem hatlarıyla tümleştirmelerini anlıyor mu?
  • DevOps uygulamalarını düzgün uyguluyor musunuz?
    • Çevik uygulamaları takip ediyor musunuz?
    • Sürekli tümleştirme uygulandı mı?
    • Sürekli teslim uygulandı mı?
    • Sürekli dağıtım uygulandı mı?
    • Sürekli izleme uygulanıyor mu?
    • Kod Olarak Altyapı (IaC) var mı?
  • CI/CD'yi desteklemek için doğru araçları kullanıyor musunuz?
  • Hazırlama ve üretim ortamlarının yapılandırması uygulama için nasıl yönetilir?
  • Araç zincirinin topluluk desteği ve destek modeli var mı? Uygun kanallar ve belgeler sağlanıp sağlanmıyor mu?

Sık değişen iş alanlarını belirleme

Mikro hizmetler mimarisi esnektir ve uyarlanabilir. Değerlendirme sırasında, iş arkadaşlarınızın sık sık değişeceğini düşündüğü alanları belirlemek için kuruluşta bir tartışmayı yönlendirin. Mikro hizmetler oluşturmak, ekiplerin müşterilerin istediği değişikliklere hızlı bir şekilde yanıt vermesini ve regresyon testi çalışmalarını en aza indirmesini sağlar. Monolitik bir uygulamada, bir modüldeki bir değişiklik çok sayıda regresyon testi düzeyini gerektirir ve yeni sürümlerin yayınlanmasındaki çevikliği azaltır.

Şu faktörleri göz önünde bulundurun:

  • Hizmet bağımsız olarak dağıtılabilir mi?
  • Hizmet DDD ilkelerine uyuyor mu?
  • Hizmet SOLID ilkelerine uyuyor mu?
  • Veritabanı hizmete özel mi?
  • Desteklenen mikro hizmetler kasa desenini kullanarak hizmeti derlediniz mi?

Altyapı hazırlığını değerlendirme

Mikro hizmetler mimarisine geçiş yaptığınızda altyapı hazırlığı dikkate alınması gereken kritik bir noktadır. Altyapı düzgün ayarlanmamışsa veya doğru hizmetler veya bileşenler kullanılmadıysa uygulamanın performansı, kullanılabilirliği ve ölçeklenebilirliği etkilenir. Bazen tüm önerilen yöntemler ve yordamlarla bir uygulama oluşturulur, ancak altyapı yeterli değildir. Bu, performansın ve bakımın düşmesine neden olur.

Altyapı hazırlığınızı değerlendirirken şu faktörleri göz önünde bulundurun:

  • Altyapı, dağıtılan hizmetlerin ölçeklenebilirliğini sağlıyor mu?
  • Altyapı, CI/CD aracılığıyla otomatikleştirilebilir betikler aracılığıyla sağlamayı destekliyor mu?
  • Dağıtım altyapısı kullanılabilirlik için bir SLA sunuyor mu?
  • Olağanüstü durum kurtarma (DR) planınız ve rutin tatbikat zamanlamalarınız var mı?
  • Veriler DR için farklı bölgelere çoğaltıldı mı?
  • Veri yedekleme planınız var mı?
  • Dağıtım seçenekleri belgelendi mi?
  • Dağıtım altyapısı izleniyor mu?
  • Dağıtım altyapısı hizmetlerin kendi kendini düzeltmesini destekliyor mu?

Yayın döngülerini değerlendirme

Mikro hizmetler, sürüm döngülerini kısaltmak ve müşterilere daha fazla değer kazandırmak için çevik geliştirmeden yararlanmaya uyarlanabilir. Yayın döngülerinizi değerlendirirken şu faktörleri göz önünde bulundurun:

  • Uygulamaları ne sıklıkta derleyip yayınlarsınız?
  • Dağıtımdan sonra yayınlarınız ne sıklıkta başarısız oluyor?
  • Kesintiden sonra sorunları kurtarmak veya düzeltmek ne kadar sürer?
  • Uygulamalarınız için anlamsal sürüm oluşturma kullanıyor musunuz?
  • Farklı ortamlar mı kullanıyorsunuz ve aynı yayını bir sırayla mı yayacaksınız (örneğin, önce hazırlamaya, sonra üretime)?
  • API'leriniz için sürüm oluşturma kullanıyor musunuz?
  • API'ler için uygun sürüm oluşturma yönergelerine uyuyor musunuz?
  • BIR API sürümünü ne zaman değiştirirsiniz?
  • API sürümü oluşturma yaklaşımınız nedir?
    • URI yolu sürümü oluşturma
    • Sorgu parametresi sürüm oluşturma
    • İçerik türü sürüm oluşturma
    • Özel üst bilgi sürümü oluşturma
  • Olay sürümü oluşturma konusunda bir alıştırmanız var mı?

Hizmetler arasındaki iletişimi değerlendirme

Mikro hizmetler, iş senaryolarını ele almak için süreç sınırları boyunca birbirleriyle iletişim kuran bağımsız hizmetlerdir. Güvenilir ve güvenilir bir iletişim elde etmek için uygun bir iletişim protokolü seçmeniz gerekir.

Şu faktörleri dikkate alın:

  • API'lerin birinci sınıf vatandaşlar olarak ele alındığı API öncelikli bir yaklaşımı mı izliyorsunuz?
  • Birden çok hizmetin zaman uyumlu iletişim protokolü üzerinden sırayla iletişim kurabileceği uzun zincirli işlemleriniz var mı?
  • Sistemin herhangi bir yerinde zaman uyumsuz iletişimi dikkate almış mıydınız?
  • İleti aracısı teknolojisini ve özelliklerini değerlendirdiniz mi?
  • Hizmetlerin aldığı ve işlediği iletilerin aktarım hızını anlıyor musunuz?
  • Doğrudan istemciden hizmete iletişimi kullanıyor musunuz?
  • İletileri ileti aracısı düzeyinde kalıcı hale getirmeniz gerekiyor mu?
  • Mikro hizmetlerin sohbet davranışını ele almak için Gerçekleştirilmiş Görünüm desenini mi kullanıyorsunuz?
  • Güvenilir iletişim için Retry, Circuit Breaker, Exponential Backoff ve Jitter uyguladınız mı? Bunu işlemenin yaygın bir yolu, Büyükelçi desenini kullanmaktır.
  • Mikro hizmetler arasındaki iletişimi kolaylaştırmak için etki alanı olayları tanımlamış mıydınız?

Hizmetlerin istemcilere nasıl açık olduğunu değerlendirme

API ağ geçidi, mikro hizmet mimarisindeki temel bileşenlerden biridir. Hizmetleri doğrudan istemcilere sunma, yönetilebilirlik, denetim ve güvenilir iletişim açısından sorunlar oluşturur. API ağ geçidi, trafiği kesen ve arka uç hizmetlerine yönlendiren bir ara sunucu görevi görür. Trafiği IP adresine, yetkilendirmeye, sahte yanıtlara vb. göre filtrelemeniz gerekiyorsa, hizmetlerde herhangi bir değişiklik yapmadan API ağ geçidi düzeyinde bunu yapabilirsiniz.

Şu faktörleri dikkate alın:

  • Hizmetler doğrudan istemciler tarafından mı tüketiliyor?
  • Tüm hizmetler için bir cephe işlevi gören bir API ağ geçidi var mı?
  • API ağ geçidi kota sınırları, sahte yanıtlar ve IP adreslerini filtreleme gibi ilkeler ayarlayabilir mi?
  • Mobil uygulamalar, web uygulamaları ve iş ortakları gibi çeşitli istemci türlerinin ihtiyaçlarını karşılamak için birden çok API ağ geçidi mi kullanıyorsunuz?
  • API ağ geçidiniz, istemcilerin Azure API Management'taki bir geliştirici portalı gibi hizmetleri keşfedebileceği ve hizmetlere abone olabileceği bir portal sağlıyor mu?
  • Çözümünüz, API ağ geçidiyle birlikte L7 yük dengeleme veya Web Uygulaması Güvenlik Duvarı (WAF) özellikleri sağlıyor mu?

İşlem işlemeyi değerlendirme

Dağıtılmış işlemler, birden çok işlemin tek bir iş birimi olarak yürütülmesini kolaylaştırır. Mikro hizmetler mimarisinde sistem çok sayıda hizmete ayrılır. Tek bir iş kullanım örneği, tek bir dağıtılmış işlemin parçası olarak birden çok mikro hizmet tarafından ele alınır. Dağıtılmış bir işlemde komut, bir olay gerçekleştiğinde başlatılan bir işlemdir. Olay, sistemde bir işlemi tetikler. İşlem başarılı olursa başka bir komut tetikleyebilir ve bu komut başka bir olayı tetikleyebilir ve işlemin başarılı olup olmadığına bağlı olarak tüm işlemler tamamlanana veya geri alınana kadar bu şekilde devam eder.

Aşağıdaki noktaları dikkate alın:

  • Sistemde kaç dağıtılmış işlem var?
  • Dağıtılmış işlemleri işleme yaklaşımınız nedir? Saga deseninin kullanımını düzenleme veya koreografi ile değerlendirin.
  • Birden çok hizmete kaç işlem yayılsın?
  • Veri tutarlılığı ve bütünlüğü elde etmek için ACID veya BASE işlem modelini mi takip ediyorsunuz?
  • Birden çok hizmete yayılan işlemler için uzun zincirleme işlemleri mi kullanıyorsunuz?

Hizmet geliştirme modelinizi değerlendirme

Mikro hizmet mimarilerinin en büyük avantajlarından biri teknoloji çeşitliliğidir. Mikro hizmet tabanlı sistemler, ekiplerin seçtikleri teknolojileri kullanarak hizmet geliştirmesine olanak tanır. Geleneksel uygulama geliştirmede, yeni bileşenler oluştururken mevcut kodu yeniden kullanabilir veya geliştirme çalışmalarını azaltmak için bir iç geliştirme çerçevesi oluşturabilirsiniz. Birden çok teknolojinin kullanılması kodun yeniden kullanılmasını engelleyebilir.

Şu faktörleri göz önünde bulundurun:

  • Yeni hizmet geliştirmeyi başlatmak için bir hizmet şablonu kullanıyor musunuz?
  • Twelve-Factor uygulama metodolojisini takip ediyor ve mikro hizmetler için tek bir kod tabanı kullanıyor, bağımlılıkları yalıtıyor ve yapılandırmayı dışlaştırıyor musunuz?
  • Hassas yapılandırmayı anahtar kasalarında mı tutuyorsunuz?
  • Hizmetlerinizi kapsayıcıya mı ayıracaksınız?
  • Veri tutarlılığı gereksinimlerinizi biliyor musunuz?

Dağıtım yaklaşımınızı değerlendirme

Dağıtım yaklaşımınız, uygulamanızın çeşitli dağıtım ortamlarında sürümlerini yayınlama yönteminizdir. Mikro hizmet tabanlı sistemler, sürümleri geleneksel uygulamalarla yapabileceğinizden daha hızlı yayınlama çevikliği sağlar.

Dağıtım planınızı değerlendirirken şu faktörleri göz önünde bulundurun:

  • Hizmetlerinizi dağıtmak için bir stratejiniz var mı?
  • Hizmetlerinizi dağıtmak için modern araçlar ve teknolojiler mi kullanıyorsunuz?
  • Hizmetleri dağıtırken ekipler arasında ne tür bir işbirliği gerekir?
  • Kod Olarak Altyapı (IaC) kullanarak altyapıyı hazırlar mısınız?
  • Dağıtımları otomatikleştirmek için DevOps özelliklerini kullanıyor musunuz?
  • Twelve-Factor uygulama metodolojisi tarafından önerilen aynı derlemeleri birden çok ortam için yayıyor musunuz?

Barındırma platformunuzu değerlendirme

Ölçeklenebilirlik, mikro hizmet mimarilerinin temel avantajlarından biridir. Bunun nedeni mikro hizmetlerin iş etki alanlarına eşlenmesidir, böylece her hizmet bağımsız olarak ölçeklendirilebilir. Tek parçalı bir uygulama, barındırma platformunda tek bir birim olarak dağıtılır ve bütünsel olarak ölçeklendirilmesi gerekir. Bu, kapalı kalma süresine, dağıtım riskine ve bakıma neden olur. Monolitik uygulamanız, tek tek iş etki alanlarını ele alan bileşenlerle iyi tasarlanmış olabilir. Ancak süreç sınırlarının olmaması nedeniyle, tek sorumluluk ilkelerini ihlal etme potansiyeli daha zor hale geliyor. Bu, sonunda spagetti koduyla sonuçlanır. Uygulama tek bir barındırma işlemi olarak oluşturup dağıtıldığından ölçeklenebilirlik zordur.

Mikro hizmetler, ekiplerin ölçeklenebilirlik gereksinimlerini desteklemek için doğru barındırma platformunu seçmesini sağlar. Otomatik ölçeklendirme, elastik sağlama, daha yüksek kullanılabilirlik, daha hızlı dağıtım ve kolay izleme gibi özellikler sağlayarak bu zorlukları gidermek için çeşitli barındırma platformları kullanılabilir.

Şu faktörleri göz önünde bulundurun:

  • Hizmetlerinizi (sanal makineler, kapsayıcılar, sunucusuz) dağıtmak için hangi barındırma platformlarını kullanıyorsunuz?
  • Barındırma platformu ölçeklenebilir mi? Otomatik ölçeklendirmeyi destekliyor mu?
  • Barındırma platformunuzu ölçeklendirmek ne kadar sürer?
  • Çeşitli barındırma platformlarının sağladığı SLA'ları anlıyor musunuz?
  • Barındırma platformunuz olağanüstü durum kurtarmayı destekliyor mu?

Hizmetleri izlemeyi değerlendirme

İzleme, mikro hizmet tabanlı bir uygulamanın önemli bir öğesidir. Uygulama bağımsız olarak çalışan bir dizi hizmete ayrıldığından, sorun giderme hataları göz korkutucu olabilir. Hizmetlerinizi izlemek için uygun semantiği kullanırsanız ekipleriniz hataları kolayca izleyebilir, araştırabilir ve yanıtlayabilir.

Şu faktörleri göz önünde bulundurun:

  • Dağıtılan hizmetlerinizi izliyor musunuz?
  • Günlüğe kaydetme mekanizmanız var mı? Hangi araçları kullanıyorsunuz?
  • Dağıtılmış izleme altyapınız var mı?
  • Özel durumları kaydeder misiniz?
  • Sorunların hızlı bir şekilde tanımlanması için iş hata kodlarını kullanıyor musunuz?
  • Hizmetler için sistem durumu yoklamaları kullanıyor musunuz?
  • Anlam günlüğü kullanıyor musunuz? Önemli ölçümler, eşikler ve göstergeler uyguladınız mı?
  • Günlüğe kaydetme sırasında hassas verileri maskeler misiniz?

Bağıntı belirteci atamasını değerlendirme

Bir mikro hizmet mimarisinde, bir uygulama bağımsız olarak barındırılan ve çeşitli iş kullanım örneklerine hizmet vermek için birbirleriyle etkileşim kuran çeşitli mikro hizmetlerden oluşur. Bir uygulama bir işlemi gerçekleştirmek için arka uç hizmetleriyle etkileşime geçtiğinde, isteğe bağıntı belirteci olarak bilinen benzersiz bir sayı atayabilirsiniz. Hataları gidermenize yardımcı olabileceği için bağıntı belirteçlerini kullanmayı göz önünde bulundurmanızı öneririz. Bir sorunun kök nedenini belirlemenize, etkiyi değerlendirmenize ve sorunu düzeltmek için bir yaklaşım belirlemenize yardımcı olur.

Bağıntı belirtecini içeren ve içermeyen hizmetleri belirleyerek istek izini almak için bağıntı belirteçlerini kullanabilirsiniz. Bu istek için bağıntı belirtecini olmayan hizmetler başarısız oldu. Bir hata oluşursa işlemi daha sonra yeniden deneyebilirsiniz. Eşzamanlılığı zorunlu kılmak için yalnızca bağıntı belirtecine sahip olmayan hizmetler isteğe hizmet eder.

Örneğin, çok sayıda hizmet içeren uzun bir işlem zinciriniz varsa, hizmetlere bağıntı belirteci geçirmek, bir işlem sırasında hizmetlerden herhangi birinin başarısız olması durumunda sorunları kolayca araştırmanıza yardımcı olabilir. Her hizmetin genellikle kendi veritabanı vardır. Bağıntı belirteci veritabanı kaydında tutulur. İşlem yeniden yürütmesi durumunda, veritabanlarında bu bağıntı belirtecini içeren hizmetler isteği yoksayar. Yalnızca belirteci olmayan hizmetler isteğe hizmet sağlar.

Şu faktörleri göz önünde bulundurun:

  • Bağıntı belirtecini hangi aşamada atayabilirsiniz?
  • Bağıntı belirtecini hangi bileşen atar?
  • Bağıntı belirteçlerini hizmetin veritabanına kaydeder misiniz?
  • Bağıntı belirteçlerinin biçimi nedir?
  • Bağıntı belirteçlerini ve diğer istek bilgilerini günlüğe kaydeder misiniz?

Mikro hizmetler kasası çerçevesi gereksinimini değerlendirme

Mikro hizmetler kasası çerçevesi, günlüğe kaydetme, özel durum işleme, dağıtılmış izleme, güvenlik ve iletişim gibi çapraz kesme konularına yönelik özellikler sağlayan bir temel çerçevedir. Bir kasa çerçevesi kullandığınızda, altyapı işlevselliğiyle etkileşime olmaktan çok hizmet sınırını uygulamaya odaklanırsınız.

Örneğin, bir sepet yönetimi hizmeti oluşturduğunuzu varsayalım. Gelen belirteci doğrulamak, günlük veritabanına günlük yazmak ve hizmetin uç noktasını çağırarak başka bir hizmetle iletişim kurmak istiyorsunuz. Mikro hizmetler kasa çerçevesi kullanıyorsanız geliştirme çalışmalarını azaltabilirsiniz. Dapr, çapraz kesme endişelerini uygulamaya yönelik çeşitli yapı taşları sağlayan bir sistemdir.

Şu faktörleri göz önünde bulundurun:

  • Mikro hizmetler kasası çerçevesi kullanıyor musunuz?
  • Çapraz kesme endişeleriyle etkileşime geçmek için Dapr kullanıyor musunuz?
  • Kasa çerçevesi diliniz belirsiz mi?
  • Kasa çerçeveniz genel olduğundan her türlü uygulamayı destekliyor mu? Kasa çerçevesi uygulamaya özgü mantık içermemelidir.
  • Kasa çerçeveniz, seçilen bileşenleri veya hizmetleri gerektiği gibi kullanmak için bir mekanizma sağlıyor mu?

Uygulama testi yaklaşımınızı değerlendirme

Geleneksel olarak, geliştirme tamamlandıktan sonra test yapılır ve uygulama kullanıcı kabul testi (UAT) ve üretim ortamlarına sunulmaya hazırdır. Şu anda bu yaklaşımda, uygulama geliştirme yaşam döngüsünde testi erken (solda) taşımaya yönelik bir değişiklik var. Tasarım, geliştirme ve geliştirme sonrası aşamalar dahil olmak üzere uygulama geliştirme yaşam döngüsünün her aşamasında test yapıldığından, sola kaydırma testi uygulamaların kalitesini artırır.

Örneğin, bir uygulama oluştururken bir mimari tasarlayarak işe başlarsınız. Sola kaydırma yaklaşımını kullandığınızda, Microsoft Tehdit Modellemesi gibi araçları kullanarak güvenlik açıklarının tasarımını test edersiniz. Geliştirmeye başladığınızda, statik uygulama güvenliği testi (SAST) gibi araçları çalıştırarak ve sorunları ortaya çıkarmak için diğer çözümleyicileri kullanarak kaynak kodunuzu tarayabilirsiniz. Uygulamayı dağıttığınızda, barındırılırken test etmek için dinamik uygulama güvenlik testi (DAST) gibi araçları kullanabilirsiniz. İşlevsel test, kaos testi, sızma testi ve diğer test türleri daha sonra gerçekleşir.

Şu faktörleri göz önünde bulundurun:

  • Geliştirme yaşam döngüsünün tamamını kapsayan test planları yazıyor musunuz?
  • Test edicileri gereksinimler toplantılarında ve uygulama geliştirme yaşam döngüsünün tamamına dahil misiniz?
  • Test temelli tasarım mı yoksa davranış temelli tasarım mı kullanıyorsunuz?
  • Kullanıcı hikayelerini test ediyor musunuz? Kullanıcı hikayelerinize kabul ölçütleri dahil ediyor musunuz?
  • Microsoft Threat Modeling gibi araçları kullanarak tasarımınızı test ediyor musunuz?
  • Birim testleri yazıyor musunuz?
  • Kod kalitesini ölçmek için statik kod çözümleyicileri veya diğer araçları kullanıyor musunuz?
  • Uygulamaları test etmek için otomatikleştirilmiş araçlar kullanıyor musunuz?
  • Güvenli DevOps uygulamaları uyguluyor musunuz?
  • Tümleştirme testi, uçtan uca uygulama testi, yük/performans testi, sızma testi ve kaos testi yapıyor musunuz?

Mikro hizmet güvenliğini değerlendirme

Hizmet koruması, güvenli erişim ve güvenli iletişim, mikro hizmet mimarisi için dikkat edilmesi gereken en önemli noktalar arasındadır. Örneğin, birden çok hizmete yayılan ve her hizmet için belirteç doğrulaması kullanan mikro hizmet tabanlı bir sistem uygun bir çözüm değildir. Bu sistem, genel sistemin çevikliğini ve hizmetler arasında uygulama kayma olasılığını etkiler.

Güvenlik endişeleri genellikle API ağ geçidi ve uygulama güvenlik duvarı tarafından işlenir. Ağ geçidi ve güvenlik duvarı gelen istekleri alır, belirteçleri doğrular ve trafiği kesmek için OWASP İlk 10 ilkelerini uygulama gibi çeşitli filtreler ve ilkeler uygular. Son olarak, isteği arka uç mikro hizmetlere gönderir. Bu yapılandırma, geliştiricilerin güvenlikle ilgili çapraz kesme endişesi yerine iş gereksinimlerine odaklanmalarına yardımcı olur.

Şu faktörleri göz önünde bulundurun:

  • Hizmet için kimlik doğrulaması ve yetkilendirme gerekiyor mu?
  • Belirteçleri ve gelen istekleri doğrulamak için API ağ geçidi mi kullanıyorsunuz?
  • Hizmet iletişimi için güvenlik sağlamak için SSL mi yoksa mTLS mi kullanıyorsunuz?
  • Hizmetler arasında gerekli iletişime izin vermek için ağ güvenlik ilkeleriniz var mı?
  • İç ve dış iletişimler için güvenlik sağlamak için uygun olduğunda güvenlik duvarları (L4, L7) kullanıyor musunuz?
  • Trafiği denetlemek için API Gateway'de güvenlik ilkeleri kullanıyor musunuz?

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazarlar:

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar