Java için Modern Web Uygulaması düzeni

Bu makalede Modern Web Uygulaması düzeninin nasıl uygulandığı açıklanmaktadır. Modern Web App düzeni, bulut web uygulamalarını modernleştirmeyi ve hizmet odaklı bir mimariyi tanıtmayı tanımlar. Desen, Azure Well-Architected Frameworkilkeleriyle uyumlu açıklayıcı mimari, kod ve yapılandırma yönergeleri sağlar. Bu düzen,Reliable Web App deseni üzerinde derlemektedir.

Modern Web Uygulaması desenini neden kullanmalısınız?

Modern Web Uygulaması düzeni, web uygulamanızın yüksek talep alanlarını iyileştirmenize yardımcı olur. Maliyet iyileştirme için bağımsız ölçeklendirmeyi etkinleştirmek üzere bu alanları ayırmaya yönelik ayrıntılı yönergeler sağlar. Bu yaklaşım, kritik bileşenlere ayrılmış kaynaklar ayırmanıza olanak tanır ve bu da genel performansı artırır. Ayrıştırılabilir hizmetlerin ayrıştırılması, uygulamanın bir bölümündeki yavaşlamaların diğerlerini etkilemesini önleyerek güvenilirliği artırabilir. Ayrıca, tek tek uygulama bileşenlerinin bağımsız sürüm oluşturmasını da sağlar.

Modern Web Uygulaması desenini uygulama

Bu makale, Modern Web Uygulaması düzenini uygulamaya yönelik yönergeler içerir. İhtiyacınız olan belirli yönergelere gitmek için aşağıdaki bağlantıları kullanın:

• Mimarisi kılavuzu. Web uygulaması bileşenlerini modülerleştirmeyi ve uygun hizmet olarak platform (PaaS) çözümlerini seçmeyi öğrenin.
• Kod kılavuzu. Ayrılmış bileşenleri iyileştirmek için dört tasarım deseni uygulayın: Strangler Fig, Queue-Based Yük Dengeleme, Rakip Tüketiciler ve Sağlık Uç Noktası İzleme.
• Yapılandırma kılavuzu. Ayrılmış bileşenler için kimlik doğrulaması, yetkilendirme, otomatik ölçeklendirme ve kapsayıcıya alma yapılandırma.

Mimari kılavuzu

Modern Web Uygulaması düzeni, Reliable Web App deseni üzerine inşa eder. Birkaç ek mimari bileşen gerektirir. Aşağıdaki diyagramda gösterildiği gibi bir ileti kuyruğuna, kapsayıcı platformuna, depolama hizmetine ve kapsayıcı kayıt defterine ihtiyacınız vardır:

Modern Web Uygulaması düzeninin temel mimarisini gösteren

Daha yüksek bir hizmet düzeyi hedefi (SLO) için web uygulaması mimarinize ikinci bir bölge ekleyebilirsiniz. yük dengeleyicinizi, iş gereksinimlerinize bağlı olarak etkin-etkin veya etkin-pasif yapılandırmayı destekleyecek şekilde trafiği ikinci bölgeye yönlendirecek şekilde yapılandırın. Bir bölgenin merkez sanal ağına sahip olması dışında iki bölge aynı hizmetleri gerektirir. Ağ güvenlik duvarı gibi kaynakları merkezileştirmek ve paylaşmak için merkez-uç ağ topolojisi kullanın. Hub sanal ağı üzerinden kapsayıcı deposuna erişin. Sanal makineleriniz varsa, bunları gelişmiş güvenlikle yönetmek için merkez sanal ağına bir savunma konağı ekleyin. Aşağıdaki diyagramda bu mimari gösterilmektedir:

İkinci bölge içeren Modern Web Uygulaması desen mimarisini gösteren

Mimariyi ayırma

Modern Web Uygulaması düzenini uygulamak için mevcut web uygulaması mimarisini ayırmanız gerekir. Mimariyi ayırmak için monolitik bir uygulamanın, her birinin belirli bir özellik veya işlevden sorumlu daha küçük, bağımsız hizmetlere ayrılmasını gerektirir. Bu işlem geçerli web uygulamasını değerlendirmeyi, mimariyi değiştirmeyi ve son olarak web uygulaması kodunu bir kapsayıcı platformuna ayıklamayı içerir. Amaç, ayrıştırılmaktan en çok yararlanan uygulama hizmetlerini sistematik olarak tanımlamak ve ayıklamaktır. Mimarinizi ayrıştırmak için şu önerileri izleyin:

• Hizmet sınırlarını belirleme. Monolitik uygulamanızdaki sınırlanmış bağlamları tanımlamak için etki alanı odaklı tasarım ilkeleri uygulayın. Her sınırlanmış bağlam bir mantıksal sınırı temsil eder ve ayrıştırma için bir adaydır. Farklı iş işlevlerini temsil eden ve daha az bağımlılığı olan hizmetler iyi adaylardır.

• Hizmet avantajlarını değerlendirme. Bağımsız ölçeklendirmeden en çok yararlanan hizmetlere odaklanın. Örneğin, LOB uygulamasındaki bir e-posta hizmet sağlayıcısı gibi bir dış bağımlılık hatadan daha fazla yalıtım gerektirebilir. Sık sık güncelleştirme veya değişiklik yapılan hizmetleri göz önünde bulundurun. Bu hizmetlerin ayrıştırılması bağımsız dağıtıma olanak tanır ve uygulamanın diğer bölümlerini etkileme riskini azaltır.

• Teknik fizibiliteyi değerlendirin. Ayırma işlemini etkileyebilecek teknik kısıtlamaları ve bağımlılıkları belirlemek için geçerli mimariyi inceleyin. Hizmetler arasında verilerin nasıl yönetileceğini ve paylaşileceğini planlayın. Ayrılmış hizmetler kendi verilerini yönetmeli ve hizmet sınırları boyunca doğrudan veritabanı erişimini en aza indirmelidir.

• Azure hizmetlerini dağıtma. Ayıklamayı planladığınız web uygulaması hizmetini desteklemek için ihtiyacınız olan Azure hizmetlerini seçin ve dağıtın. Yönergeler için bu makalenin Doğru Azure hizmetlerini seçme bölümüne bakın.

• Web uygulaması hizmetini birbirinden ayırma. Yeni ayıklanan web uygulaması hizmetlerinin sistemin diğer bölümleriyle etkileşime geçmek için kullanabileceği açık arabirimler ve API'ler tanımlayın. Her hizmetin kendi verilerini yönetmesine izin veren ancak tutarlılık ve bütünlük sağlayan bir veri yönetimi stratejisi tasarlar. Bu ayıklama işlemi sırasında kullanılacak belirli uygulama stratejileri ve tasarım desenleri için Kod kılavuzu bölümüne bakın.

• Ayrılmış hizmetler için bağımsız depolama alanı kullanın. Sürüm oluşturma ve dağıtımı basitleştirmek için, ayrıştırılmış her hizmetin kendi veri depolarına sahip olduğundan emin olun. Örneğin, başvuru uygulaması e-posta hizmetini web uygulamasından ayırır ve hizmetin veritabanına erişme gereksinimini ortadan kaldırır. Bunun yerine, hizmet e-posta teslim durumunu bir Azure Service Bus iletisi aracılığıyla web uygulamasına geri iletir ve web uygulaması veritabanına bir not kaydeder.

• Ayrılmış her hizmet için ayrı dağıtım işlem hatları uygulayın. Ayrı dağıtım işlem hatları uygularsanız, her hizmet kendi zamanlamasına göre güncelleştirilebilir. Şirketinizdeki farklı ekipler veya kuruluşlar farklı hizmetlere sahipse, ayrı dağıtım işlem hatlarını kullanmak her takıma kendi dağıtımları üzerinde denetim sağlar. Bu işlem hatlarını ayarlamak için Jenkins, GitHub Actions veya Azure Pipelines gibi sürekli tümleştirme ve sürekli teslim (CI/CD) araçlarını kullanın.

• Güvenlik denetimlerini düzeltin. Güvenlik denetimlerinizin güvenlik duvarı kuralları ve erişim denetimleri de dahil olmak üzere yeni mimariyi hesaba katacak şekilde güncelleştirildiğinden emin olun.

Doğru Azure hizmetlerini seçin

Mimarinizdeki her Azure hizmeti için İyi Tasarlanmış Çerçeve'deki ilgili Azure hizmet kılavuzuna başvurun. Modern Web Uygulaması düzeni için, zaman uyumsuz mesajlaşmayı desteklemek için bir mesajlaşma sistemine, kapsayıcı oluşturmayı destekleyen bir uygulama platformuna ve bir kapsayıcı görüntüsü deposuna ihtiyacınız vardır.

• bir ileti kuyruğu seçin. İleti kuyruğu, hizmet odaklı mimarilerin önemli bir bileşenidir. Zaman uyumsuz mesajlaşmayı etkinleştirmek için ileti gönderenleri ve alıcıları birbirinden ayırıyor. Tasarım gereksinimlerinizi destekleyen bir Azure mesajlaşma sistemi seçmek için Azure mesajlaşma hizmeti seçme yönergelerini kullanın. Azure'da üç mesajlaşma hizmeti vardır: Azure Event Grid, Azure Event Hubs ve Service Bus. Service Bus ile başlayın ve Service Bus ihtiyaçlarınızı karşılamıyorsa diğer iki seçeneknden birini kullanın.

  Hizmet	Kullanım örneği
  Service Bus	Kurumsal uygulamalarda yüksek değerli iletilerin güvenilir, sıralı ve muhtemelen işlemsel teslimi için Service Bus'ı seçin.
  Event Grid	Çok sayıda ayrık olayı verimli bir şekilde işlemeniz gerektiğinde Event Grid'i seçin. Event Grid, çok sayıda küçük, bağımsız olayın (kaynak durumu değişiklikleri gibi) düşük gecikme süreli yayımlama-abone olma modelinde abonelere yönlendirilmesi gereken olay temelli uygulamalar için ölçeklenebilir.
  Event Hubs	Telemetri, günlükler veya gerçek zamanlı analiz gibi yüksek performanslı veri alımı için Event Hubs'ı seçin. Event Hubs, toplu verilerin sürekli olarak alınması ve işlenmesi gereken akış senaryoları için iyileştirilmiştir.

• Kapsayıcı hizmeti uygulama. Kapsayıcıya almak istediğiniz uygulamanızın öğeleri için kapsayıcıları destekleyen bir uygulama platformuna ihtiyacınız vardır. Azure kapsayıcı hizmeti seçin kılavuzu birini seçmenize yardımcı olabilir. Azure'da üç temel kapsayıcı hizmeti vardır: Azure Container Apps, Azure Kubernetes Service (AKS) ve Azure Uygulaması Hizmeti. Container Apps ile başlayın ve Container Apps ihtiyaçlarınızı karşılamıyorsa diğer iki seçenekten birini kullanın.

  Hizmet	Kullanım örneği
  Container Apps	Olay temelli uygulamalarda kapsayıcıları otomatik olarak ölçeklendiren ve yöneten sunucusuz bir platforma ihtiyacınız varsa Kapsayıcı Uygulamaları'nı seçin.
  AKS	Kubernetes yapılandırmaları ve ölçeklendirme, ağ ve güvenlik için gelişmiş özellikler üzerinde ayrıntılı denetime ihtiyacınız varsa AKS'yi seçin.
  Kapsayıcılar için Web Uygulaması	En basit PaaS deneyimi için App Service'te Kapsayıcılar için Web Uygulaması'nı seçin.

• Bir kapsayıcı deposu uygulayın. Kapsayıcı tabanlı işlem hizmeti kullandığınızda, kapsayıcı görüntülerini depolamak için bir deponuz olması gerekir. Docker Hub gibi bir genel kapsayıcı kayıt defterini veya Azure Container Registry gibi yönetilen bir kayıt defterini kullanabilirsiniz. Azure'da Kapsayıcı kayıt defterlerine giriş kılavuzu birini seçmenize yardımcı olabilir.

Kod kılavuzu

Bağımsız bir hizmeti başarıyla ayırıp ayıklamak için web uygulaması kodunuzu şu tasarım desenleriyle güncelleştirmeniz gerekir: Strangler Fig, Queue-Based Yük Dengeleme, Rakip Tüketiciler, Sistem Durumu Uç Noktası İzleme ve Yeniden Deneme. Aşağıdaki diyagramda bu desenlerin rolleri gösterilmektedir:

Modern Web Uygulaması desen mimarisindeki tasarım desenlerinin rolünü gösteren

1. Strangler Fig deseni: Strangler Fig deseni, monolitik bir uygulamadan ayrılmış hizmete işlevselliği artımlı olarak geçirir. Trafiği uç noktalara göre yönlendirerek işlevselliği aşamalı olarak bağımsız hizmetlere geçirmek için ana web uygulamasında bu düzeni uygulayın.

2. Kuyruk Tabanlı Yük Dengeleme düzeni: Kuyruk Tabanlı Yük Dengeleme düzeni, bir kuyruğu arabellek olarak kullanarak üretici ile tüketici arasındaki ileti akışını yönetir. Kuyruk kullanarak ileti akışını zaman uyumsuz olarak yönetmek için ayrılmış hizmetin üretici bölümüne bu düzeni uygulayın.

3. Rakip Tüketiciler deseni: Rakip Tüketiciler düzeni, ayrılmış bir hizmetin birden çok örneğinin aynı ileti kuyruğundan bağımsız olarak okumasını ve iletileri işlemek için rekabete girmesini sağlar. Görevleri birden çok örneğe dağıtmak için ayrılmış hizmette bu düzeni uygulayın.

4. Sistem Durumu Uç Noktası İzleme düzeni: Sistem Durumu Uç Noktası İzleme düzeni, web uygulamasının farklı bileşenlerinin durumunu ve durumunu izlemek için uç noktaları kullanıma sunar. (4a) Bu düzeni ana web uygulamasında uygulayın. (4b) Ayrıca, uç noktaların durumunu izlemek için ayrılmış hizmette de uygulayın.

5. Yeniden deneme düzeni: Yeniden deneme düzeni, aralıklı olarak başarısız olabilecek işlemleri yeniden deneyerek geçici hataları işler. (5a) Bu düzeni ana web uygulamasında, ileti kuyruğuna yapılan çağrılar ve özel uç noktalar gibi diğer Azure hizmetlerine yapılan tüm giden çağrılarda uygulayın. (5b) Özel uç noktalara yapılan çağrılarda geçici hataları işlemek için bu düzeni ayrılmış hizmette de uygulayın.

Her tasarım deseni, Well-Architected Framework'ün bir veya daha fazla yapı taşıyla uyumlu avantajlar sağlar. Aşağıdaki tabloda ayrıntılar sağlanmaktadır.

Strangler Fig desenini uygulama

İşlevselliği monolitik kod tabanından yeni bağımsız hizmetlere aşamalı olarak geçirmek için Strangler Fig desenini kullanın. Mevcut monolitik kod tabanından yeni hizmetleri ayıklayın ve web uygulamasının kritik bölümlerini yavaşça modernleştirin. Strangler Fig desenini uygulamak için şu önerileri izleyin:

• Yönlendirme katmanı ayarlama. Monolitik web uygulaması kod tabanında trafiği uç noktalara göre yönlendiren bir yönlendirme katmanı uygulayın. Trafiği yönlendirmeye yönelik belirli iş kurallarını işlemek için gerektiğinde özel yönlendirme mantığını kullanın. Örneğin, monolitik uygulamanızda bir /users uç noktanız varsa ve bu işlevi ayrılmış hizmete taşırsanız, yönlendirme katmanı tüm istekleri yeni hizmete /users yönlendirir.

• Özellik dağıtımlarını yönetme.Ayrılmış hizmetleri aşamalı olarak kullanıma almak için özellik bayrakları ve aşamalı dağıtım uygulayın. Mevcut monolitik uygulama yönlendirmesi, ayrılmış hizmetlerin kaç istek alacağını denetlemelidir. İsteklerin küçük bir yüzdesiyle başlayın ve hizmetin kararlılığı ve performansına güven kazandıkça zaman içinde kullanımı artırın.

  Örneğin, başvuru uygulaması e-posta teslim işlevselliğini tek başına bir hizmete ayıklar. Hizmet, Contoso destek kılavuzları içeren e-posta gönderme isteklerinin daha büyük bir yüzdesini işlemek için aşamalı olarak tanıtılabilir. Yeni hizmet güvenilirliğini ve performansını kanıtladıkça, sonunda tüm e-posta sorumluluklarını monolith'ten devralarak geçişi tamamlayabilir.

• Cephe hizmeti kullanın (gerekirse). Cephe hizmeti, tek bir isteğin birden çok hizmetle etkileşim kurması gerektiğinde veya temel alınan sistemin karmaşıklığını istemciden gizlemek istediğinizde kullanışlıdır. Ancak, ayrılmış hizmetin genel kullanıma yönelik API'leri yoksa, bir cephe hizmeti gerekli olmayabilir.

  Monolitik web uygulaması kod tabanında, istekleri uygun arka uca (monolith veya mikro hizmet) yönlendirmek için bir cephe hizmeti uygulayın. Yeni ayrılmış hizmetin, cephe üzerinden erişildiğinde istekleri bağımsız olarak işleyebileceğinden emin olun.

Kuyruk Tabanlı Yük Dengeleme desenini uygulama

Anında yanıt gerektirmeyen görevleri zaman uyumsuz olarak işlemek için ayrılmış hizmetin üretici bölümüne Kuyruk Tabanlı Yük Dengeleme desenini uygulayın. Bu düzen, iş yükü dağıtımlarını yönetmek için bir kuyruk kullanarak genel sistem yanıt hızını ve ölçeklenebilirliğini artırır. Ayrılmış hizmetin istekleri tutarlı bir hızda işlemesini sağlar. Bu düzeni etkili bir şekilde uygulamak için şu önerileri izleyin:

• engelleyici olmayan ileti kuyruğa alma özelliğini kullanın. Kuyruğa ileti gönderen işlemin, ayrılmış hizmetin kuyruktaki iletileri işlemesini beklerken diğer işlemleri engellemediğinden emin olun. İşlem, ayrılmış hizmet işleminin sonucunu gerektiriyorsa, kuyruğa alınan işlemin tamamlanmasını beklerken durumu işlemek için alternatif bir yol uygulayın. Örneğin, Spring Boot'ta, çağrı iş parçacığını engellemeden iletileri zaman uyumsuz olarak kuyruğa yayımlamak için StreamBridge sınıfını kullanabilirsiniz:

  private final StreamBridge streamBridge;
  
  public SupportGuideQueueSender(StreamBridge streamBridge) {
      this.streamBridge = streamBridge;
  }
  
  // Asynchronously publish a message without blocking the calling thread
  @Override
  public void send(String to, String guideUrl, Long requestId) {
      EmailRequest emailRequest = EmailRequest.newBuilder()
              .setRequestId(requestId)
              .setEmailAddress(to)
              .setUrlToManual(guideUrl)
              .build();
  
      log.info("EmailRequest: {}", emailRequest);
  
      var message = emailRequest.toByteArray();
      streamBridge.send(EMAIL_REQUEST_QUEUE, message);
  
      log.info("Message sent to the queue");
  }
  

  Bu Java örneği, iletileri zaman uyumsuz olarak göndermek için kullanır StreamBridge . Bu yaklaşım, ayrılmış hizmet kuyruğa alınan istekleri yönetilebilir bir hızda işlerken ana uygulamanın yanıt vermeye devam etmesini ve diğer görevleri eşzamanlı olarak işleyebilmesini sağlar.

• İleti yeniden deneme ve kaldırma uygulama. Başarıyla işlenemedi kuyruğa alınan iletilerin işlenmesini yeniden denemek için bir mekanizma uygulayın. Hatalar devam ederse, bu iletiler kuyruktan kaldırılmalıdır. Örneğin, Service Bus yerleşik yeniden deneme ve teslim edilemeyen kuyruk özelliklerine sahiptir.

• Bir kez etkili ileti işlemeyi yapılandırın. Kuyruktaki iletileri işleyen mantığın, bir iletinin birden çok kez işlenebileceği durumları işlemek için bir kez etkili olması gerekir. Spring Boot'ta, yinelenen işlemeyi önlemek için veya @StreamListener benzersiz bir ileti tanımlayıcısıyla kullanabilirsiniz@KafkaListener. İsterseniz, spring cloud stream ile işlevsel bir yaklaşımla çalışmak için iş sürecini düzenleyebilirsiniz. Burada consume yöntem, tekrar tekrar çalıştığında aynı sonucu veren bir şekilde tanımlanır. İleti tüketiminin davranışını yöneten ayarların listesi için bkz. Service Busile Spring Cloud Stream .

• Kullanıcı deneyimindeki değişiklikleri yönetin. Zaman uyumsuz işleme kullandığınızda, görevler hemen tamamlanamayabilir. Beklentileri belirlemek ve karışıklığı önlemek için, kullanıcıların görevlerinin ne zaman işlendiğini bilmelerini sağlayın. Bir görevin devam ettiğini belirtmek için görsel ipuçlarını veya iletileri kullanın. Kullanıcılara, görevleri tamamlandığında e-posta veya anında iletme bildirimi gibi bildirimler alma seçeneği verin.

Rakip Tüketiciler desenini uygulama

İleti kuyruğundan gelen görevleri yönetmek için ayrılmış hizmette Rakip Tüketiciler desenini uygulayın. Bu düzen, görevlerin ayrılmış hizmetlerin birden çok örneğine dağıtılmasını içerir. Bu hizmetler kuyruktan gelen iletileri işler. Desen yük dengelemeyi geliştirir ve sistemin eşzamanlı istekleri işleme kapasitesini artırır. Rakip Tüketiciler deseni aşağıdaki durumlarda etkilidir:

• İleti işleme sırası kritik değildir.
• Kuyruk, hatalı biçimlendirilmiş iletilerden etkilenmez.
• İşleme işlemi bir kez etkili olur ve bu da ilk uygulamadan sonra sonucu değiştirmeden birden çok kez uygulanabileceği anlamına gelir.

Rakip Tüketiciler desenini uygulamak için şu önerileri izleyin:

• Eşzamanlı iletileri işleme. Hizmetler kuyruktan ileti aldığında, eşzamanlılığı sistem tasarımıyla eşleşecek şekilde yapılandırarak sisteminizin tahmin edilebilir şekilde ölçeklendirildiğinden emin olun. Yük testi sonuçları, işlenecek uygun sayıda eşzamanlı ileti belirlemenize yardımcı olabilir. Sistemin performansını ölçmek için bir taneden başlayabilirsiniz.

• Önceden hazırlamayı devre dışı bırakın. Tüketicilerin yalnızca hazır olduklarında iletileri getirmesi için iletilerin önceden eklenmesini devre dışı bırakın.

• Güvenilir ileti işleme modlarını kullanın. İşleme başarısız olan iletileri otomatik olarak yeniden denenen Peek-Lock gibi güvenilir bir işleme modu kullanın. Bu mod, silme öncelikli yöntemlerden daha fazla güvenilirlik sağlar. Bir çalışan bir iletiyi işleyemezse, ileti birden çok kez işleniyor olsa bile başka bir çalışanın hata olmadan bu iletiyi işleyebilmesi gerekir.

• Hata işlemeyi uygulayın. Hatalı biçimlendirilmiş veya işlenemez iletileri ayrı bir teslim edilemeyen ileti kuyruğuna yönlendirin. Bu tasarım tekrarlanan işlemeyi engeller. Örneğin, ileti işleme sırasında özel durumları yakalayabilir ve sorunlu iletileri ayrı kuyruğa taşıyabilirsiniz. Service Bus ile iletiler, belirtilen sayıda teslim girişiminden sonra veya uygulama tarafından açıkça reddedildikten sonra ölü leter kuyruğuna taşınır.

• Sıra dışı iletileri işleme. Tüketicileri sıra dışı gelen iletileri işleyebilecek şekilde tasarlar. Birden çok paralel tüketiciniz olduğunda, iletiler sıra dışı olarak işlenebilir.

• Kuyruk uzunluğuna göre ölçeklendirin. Kuyruktan gelen iletileri kullanan hizmetler, kuyruk uzunluğuna göre otomatik ölçeklendirme yapmalıdır. Ölçek tabanlı otomatik ölçeklendirme, gelen iletilerin ani artışlarının verimli bir şekilde işlenmesini sağlar.

• İleti yanıt kuyruğu kullanın. Sisteminiz ileti sonrası işleme için bildirim gerektiriyorsa, ayrılmış bir yanıt veya yanıt kuyruğu ayarlayın. Bu kurulum, işlemsel mesajlaşmayı bildirim işlemlerinden ayırır.

• Durum bilgisi olmayan hizmetleri kullanın. Kuyruktan gelen istekleri işlemek için durum bilgisi olmayan hizmetleri kullanmayı göz önünde bulundurun. Bunu yapmak kolay ölçeklendirme ve verimli kaynak kullanımı sağlar.

• Günlüğe kaydetmeyi yapılandırın. günlüğe kaydetmeyi ve belirli özel durum işlemeyi ileti işleme iş akışı içinde tümleştirin. Serileştirme hatalarını yakalamaya ve bu sorunlu iletileri bir teslim edilemeyen harf mekanizmasına yönlendirmeye odaklanın. Bu günlükler sorun giderme için değerli içgörüler sağlar.

Başvuru uygulaması, Service Bus kuyruğundan gelen e-posta teslim isteklerini işlemek için Container Apps'te çalışan durum bilgisi olmayan bir hizmette Rakip Tüketiciler desenini kullanır.

İşlemci, sorun giderme ve izleme konusunda yardımcı olması için ileti işleme ayrıntılarını günlüğe kaydeder. Seri durumdan çıkarma hatalarını yakalar ve hata ayıklama sırasında yararlı olabilecek içgörüler sağlar. Hizmet, kuyruk uzunluğuna göre ileti ani artışlarının verimli bir şekilde işlenmesini sağlamak için kapsayıcı düzeyinde ölçeklendirilir. Kod şu şekildedir:

@Configuration
public class EmailProcessor {

    private static final Logger log = LoggerFactory.getLogger(EmailProcessor.class);

    @Bean
    Function<byte[], byte[]> consume() {
        return message -> {

            log.info("New message received");

            try {
                EmailRequest emailRequest = EmailRequest.parseFrom(message);
                log.info("EmailRequest: {}", emailRequest);

                EmailResponse emailResponse = EmailResponse.newBuilder()
                        .setEmailAddress(emailRequest.getEmailAddress())
                        .setUrlToManual(emailRequest.getUrlToManual())
                        .setRequestId(emailRequest.getRequestId())
                        .setMessage("Email sent to " + emailRequest.getEmailAddress() + " with URL to manual " + emailRequest.getUrlToManual())
                        .setStatus(Status.SUCCESS)
                        .build();

                return emailResponse.toByteArray();

            } catch (InvalidProtocolBufferException e) {
                throw new RuntimeException("Error parsing email request message", e);
            }
        };
    }
}

Sistem Durumu Uç Noktası İzleme desenini uygulama

Uygulama uç noktalarının durumunu izlemek için ana uygulama kodunda ve ayrılmış hizmet kodunda Sistem Durumu Uç Noktası İzleme desenini uygulayın. AKS veya Container Apps gibi düzenleyiciler hizmet durumunu doğrulamak ve iyi durumda olmayan örnekleri yeniden başlatmak için bu uç noktaları yoklayabilir. Spring Boot Aktüatör sistem durumu denetimleri için yerleşik destek sağlar. Veritabanları, ileti aracıları ve depolama sistemleri gibi önemli bağımlılıklar için sistem durumu denetimi uç noktalarını kullanıma sunar. Sistem Durumu Uç Noktası İzleme düzenini uygulamak için şu önerileri izleyin:

• Sistem durumu denetimlerini uygulayın. Sistem durumu denetimi uç noktaları sağlamak için Spring Boot Aktüatör'lerini kullanın. Aktüatör, yerleşik sistem durumu göstergelerini ve çeşitli bağımlılıklar için özel denetimleri içeren bir /actuator/health uç noktasını kullanıma sunar. Sistem durumu uç noktasını etkinleştirmek için pom.xml veya build.gradle dosyanıza spring-boot-starter-actuator bağımlılığını ekleyin:

  <!-- Add Spring Boot Actuator dependency -->
  <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
  

  Başvuru uygulamasında gösterildiği gibi application.properties'da sistem durumu uç noktasını yapılandırın:

      management.endpoints.web.exposure.include=metrics,health,info,retry,retryevents
  

• Bağımlılıkları doğrulayın. Spring Boot Aktüatör veritabanları, ileti aracıları (RabbitMQ veya Kafka) ve depolama hizmetleri gibi çeşitli bağımlılıklar için sistem durumu göstergelerini içerir. Azure Blob Depolama veya Service Bus gibi Azure hizmetlerinin kullanılabilirliğini doğrulamak için, bu hizmetler için sistem durumu göstergeleri sağlayan Azure Spring Apps veya Micrometer gibi teknolojileri kullanın. Özel denetimlere ihtiyacınız varsa, özel bir HealthIndicator çekirdeği oluşturarak bunları uygulayabilirsiniz:

  import org.springframework.boot.actuate.health.Health;
  import org.springframework.boot.actuate.health.HealthIndicator;
  import org.springframework.stereotype.Component;
  
  @Component
  public class CustomAzureServiceBusHealthIndicator implements HealthIndicator {
      @Override
      public Health health() {
          // Implement your health check logic here (for example, ping Service Bus).
          boolean isServiceBusHealthy = checkServiceBusHealth();
          return isServiceBusHealthy ? Health.up().build() : Health.down().build();
      }
  
      private boolean checkServiceBusHealth() {
          // Implement health check logic (pinging or connecting to the service).
          return true; // Placeholder. Implement the actual logic.
      }
  }
  

• Azure kaynaklarını yapılandırma. Azure kaynağını, canlılığı ve hazır olma durumunu onaylamak için uygulamanın sistem durumu denetimi URL'lerini kullanacak şekilde yapılandırın. Örneğin, Terraform kullanarak Container Apps'e dağıtılan uygulamaların canlılığını ve hazır olma durumunu onaylayabilirsiniz. Daha fazla bilgi için bkz . Container Apps'te sistem durumu yoklamaları.

Yeniden Deneme desenini uygulama

Yeniden Deneme düzeni uygulamaların geçici hatalardan kurtulmasını sağlar. Bu düzen Reliable Web App deseninin merkezinde yer alır, bu nedenle web uygulamanız zaten Yeniden Deneme desenini kullanıyor olmalıdır. Yeniden Deneme desenini, web uygulamasından ayıkladığınız ayrılmış hizmetler tarafından verilen ileti sistemlerine ve isteklere uygulayın. Yeniden Deneme desenini uygulamak için şu önerileri izleyin:

• Yeniden deneme seçeneklerini yapılandırın. İleti kuyruğuyla etkileşimlerden sorumlu istemciyi uygun yeniden deneme ayarlarıyla yapılandırıldığından emin olun. Yeniden deneme sayısı üst sınırı, yeniden denemeler arasındaki gecikme ve en fazla gecikme gibi parametreleri belirtin.

• Üstel geri alma kullanın. Yeniden deneme girişimleri için üstel geri alma stratejisini uygulayın. Bu strateji, her yeniden deneme arasındaki süreyi üstel olarak artırmayı içerir ve bu da yüksek hata oranları dönemlerinde sistem üzerindeki yükü azaltmaya yardımcı olur.

• SDK yeniden deneme işlevini kullanın. Service Bus veya Blob Depolama gibi özelleştirilmiş SDK'ları olan hizmetler için yerleşik yeniden deneme mekanizmalarını kullanın. Bu yerleşik mekanizmalar hizmetin tipik kullanım örnekleri için iyileştirilmiştir, yeniden denemeleri daha etkili bir şekilde işleyebilir ve daha az yapılandırma gerektirir.

• HTTP istemcileri için standart dayanıklılık kitaplıklarını kullanın. HTTP istemcileri için Resilience4j'yi Spring RestTemplate veya WebClient ile birlikte kullanarak HTTP iletişimlerindeki yeniden denemeleri işleyebilirsiniz. Geçici HTTP hatalarını etkili bir şekilde işlemek için RestTemplate'ı Resilience4j'nin yeniden deneme mantığıyla sarmalayabilirsiniz.

• İleti kilitlemeyi işleme. İleti tabanlı sistemler için, veri kaybı olmadan yeniden denemeleri destekleyen ileti işleme stratejileri uygulayın. Örneğin, kullanılabilir olduklarında göz atma kilidi modlarını kullanın. Başarısız iletilerin etkili bir şekilde yeniden denendiğinden ve yinelenen hatalardan sonra bir teslim edilemeyen ileti kuyruğuna taşındığından emin olun.

Yapılandırma kılavuzu

Aşağıdaki bölümlerde yapılandırma güncelleştirmelerini uygulamaya yönelik yönergeler sağlanır. Her bölüm, Well-Architected Framework'ün bir veya daha fazla sütunuyla uyumludur.

Kimlik doğrulama ve yetkilendirmeyi yapılandırma

Web uygulamasına eklediğiniz tüm yeni Azure hizmetlerinde (iş yükü kimlikleri) kimlik doğrulamasını ve yetkilendirmeyi yapılandırmak için şu önerileri izleyin:

• Her yeni hizmet için yönetilen kimlikleri kullanın. Her bağımsız hizmetin kendi kimliği olmalıdır ve hizmet-hizmet kimlik doğrulaması için yönetilen kimlikleri kullanmalıdır. Yönetilen kimlikler, kodunuzdaki kimlik bilgilerini yönetme gereksinimini ortadan kaldırır ve kimlik bilgisi sızıntısı riskini azaltır. Bunlar, bağlantı dizeleri gibi hassas bilgileri kodunuz veya yapılandırma dosyalarınıza dahil etmekten kaçınmanıza yardımcı olur.

• Her yeni hizmete en az ayrıcalık verin. Her yeni hizmet kimliğine yalnızca gerekli izinleri atayın. Örneğin, bir kimliğin yalnızca kapsayıcı kayıt defterine göndermesi gerekiyorsa, ona çekme izinleri vermeyin. Bu izinleri düzenli olarak gözden geçirin ve gerektiği gibi ayarlayın. Dağıtım ve uygulama gibi farklı roller için farklı kimlikler kullanın. Bunun yapılması, bir kimliğin gizliliğinin tehlikeye atılmış olması durumunda olası hasarı sınırlar.

• Kod olarak altyapı (IaC) kullanın. Bulut kaynaklarınızı tanımlamak ve yönetmek için Bicep'i veya Terraform gibi benzer bir IaC aracını kullanın. IaC, dağıtımlarınızda güvenlik yapılandırmalarının tutarlı bir şekilde uygulanmasını sağlar ve altyapı kurulumunuzu sürüm denetimine almanızı sağlar.

Kullanıcılarda (kullanıcı kimlikleri) kimlik doğrulamasını ve yetkilendirmeyi yapılandırmak için şu önerileri izleyin:

• Kullanıcılara en az ayrıcalık verin. Hizmetlerde olduğu gibi, kullanıcıların yalnızca görevlerini gerçekleştirmek için ihtiyaç duydukları izinlere sahip olduğundan emin olun. Bu izinleri düzenli olarak gözden geçirin ve ayarlayın.

• Düzenli güvenlik denetimleri gerçekleştirin. Güvenlik kurulumunuzu düzenli olarak gözden geçirin ve kontrol edin. Yanlış yapılandırmaları ve gereksiz izinleri arayın ve bunları hemen düzeltin veya kaldırın.

Başvuru uygulaması, eklenen hizmetlere yönetilen kimlikler ve her kimliğe belirli roller atamak için IaC kullanır. Kapsayıcı Kayıt Defteri gönderimleri ve çekmeleri için roller tanımlayarak dağıtım için rolleri ve izin erişimini tanımlar. Kod şu şekildedir:

resource "azurerm_role_assignment" "container_app_acr_pull" {
  principal_id         = var.aca_identity_principal_id
  role_definition_name = "AcrPull"
  scope                = azurerm_container_registry.acr.id
}

resource "azurerm_user_assigned_identity" "container_registry_user_assigned_identity" {
  name                = "ContainerRegistryUserAssignedIdentity"
  resource_group_name = var.resource_group
  location            = var.location
}

resource "azurerm_role_assignment" "container_registry_user_assigned_identity_acr_pull" {
  scope                = azurerm_container_registry.acr.id
  role_definition_name = "AcrPull"
  principal_id         = azurerm_user_assigned_identity.container_registry_user_assigned_identity.principal_id
}


# For demo purposes, allow the current user to access the container registry.
# Note: When running as a service principal, this is also needed.
resource "azurerm_role_assignment" "acr_contributor_user_role_assignement" {
  scope                = azurerm_container_registry.acr.id
  role_definition_name = "Contributor"
  principal_id         = data.azuread_client_config.current.object_id
}

Bağımsız otomatik ölçeklendirmeyi yapılandırma

Modern Web Uygulaması düzeni monolitik mimariyi ayırmaya başlar ve hizmet ayırmayı tanıtır. Bir web uygulaması mimarisini ayırırken, ayrılmış hizmetleri bağımsız olarak ölçeklendirin. Azure hizmetlerini web uygulamasının tamamı yerine bağımsız bir web uygulaması hizmetini destekleyecek şekilde ölçeklendirmek, talepleri karşılarken ölçeklendirme maliyetlerini iyileştirir. Kapsayıcıları otomatik ölçeklendirmek için şu önerileri izleyin:

• Durum bilgisi olmayan hizmetleri kullanın. Hizmetlerinizin durum bilgisi olmayan olduğundan emin olun. Web uygulamanız işlem içi oturum durumu içeriyorsa redis gibi dağıtılmış bir önbellekle veya SQL Server gibi bir veritabanıyla dışlayın.

• Otomatik ölçeklendirme kurallarını yapılandırın. Hizmetleriniz üzerinde en uygun maliyetli denetimi sağlayan otomatik ölçeklendirme yapılandırmalarını kullanın. Kapsayıcılı hizmetler için Kubernetes Event-Driven Autoscaler (KEDA) gibi olay tabanlı ölçeklendirme genellikle olay ölçümlerine göre ölçeklendirmenizi sağlayan ayrıntılı denetim sağlar. Container Apps ve AKS, KEDA'yi destekler. App Service gibi KEDA'yı desteklemeyen hizmetler için platformun kendisi tarafından sağlanan otomatik ölçeklendirme özelliklerini kullanın. Bu özellikler genellikle ölçüm tabanlı kurallara veya HTTP trafiğine göre ölçeklendirmeyi içerir.

• En düşük çoğaltmaları yapılandırın. Soğuk başlatmaları önlemek için otomatik ölçeklendirme ayarlarını en az bir çoğaltmayı koruyacak şekilde yapılandırın. Soğuk başlangıç, hizmetin durdurulmuş durumdan başlatılmasıdır. Soğuk başlangıç genellikle yanıtı geciktirmektedir. Maliyetleri en aza indirmek öncelikliyse ve soğuk başlatma gecikmelerine tolerans gösterebiliyorsanız, otomatik ölçeklendirmeyi yapılandırırken en düşük çoğaltma sayısını 0 olarak ayarlayın.

• Bir bekleme süresi yapılandırın. Ölçeklendirme olayları arasında gecikmeye neden olmak için uygun bir bekleme süresi uygulayın. Amaç, geçici yük artışları tarafından tetiklenen aşırı ölçeklendirme etkinliklerini önlemektir.

• Kuyruk tabanlı ölçeklendirmeyi yapılandırın. Uygulamanız Service Bus gibi bir ileti kuyruğu kullanıyorsa, otomatik ölçeklendirme ayarlarınızı istek iletisi kuyruğunun uzunluğuna göre ölçeklendirilecek şekilde yapılandırın. Ölçekleyici, kuyruktaki her N iletisi için hizmetin bir çoğaltmasını korumayı dener (yukarı yuvarlatılır).

Örneğin, başvuru uygulaması Service Bus keda ölçeklendiricisini kullanarak Container App'i Service Bus kuyruğunun uzunluğuna göre otomatik olarak ölçeklendirir. service-bus-queue-length-ruleadlı ölçeklendirme kuralı, belirtilen Service Bus kuyruğundaki ileti sayısına göre hizmet çoğaltmalarının sayısını ayarlar. messageCount parametresi 10 olarak ayarlanır ve ölçekleyiciyi kuyruktaki her 10 ileti için bir çoğaltma ekleyecek şekilde yapılandırılır. En fazla çoğaltma sayısı (max_replicas) 10 olarak ayarlanır. Geçersiz kılınmadığı sürece en düşük çoğaltma sayısı örtük olarak 0'dır. Bu yapılandırma, kuyrukta ileti olmadığında hizmetin ölçeğinin sıfıra düşürülmesini sağlar. Service Bus kuyruğunun bağlantı dizesi, Azure'da, Service Bus'ta ölçekleyicinin kimliğini doğrulamak için kullanılan azure-servicebus-connection-stringadlı bir gizli dizi olarak depolanır. Terraform kodu şu şekildedir:

    max_replicas = 10
    min_replicas = 1

    custom_scale_rule {
      name             = "service-bus-queue-length-rule"
      custom_rule_type = "azure-servicebus"
      metadata = {
        messageCount = 10
        namespace    = var.servicebus_namespace
        queueName    = var.email_request_queue_name
      }
      authentication {
        secret_name       = "azure-servicebus-connection-string"
        trigger_parameter = "connection"
      }
    }

Hizmet dağıtımlarını kapsayıcıya alma

Kapsayıcıya alma, uygulamanın ihtiyaç duyduğu tüm bağımlılıkların çok çeşitli konaklara güvenilir bir şekilde dağıtılabilen basit bir görüntüde kapsüllenmesidir. Dağıtımı kapsayıcılı hale getirmek için şu önerileri izleyin:

• Etki alanı sınırlarını belirleme. Monolitik uygulamanızdaki etki alanı sınırlarını belirleyerek başlayın. Bunu yapmak, uygulamanın hangi bölümlerini ayrı hizmetlere ayıklayabileceğinizi belirlemenize yardımcı olur.

• Docker görüntüleri oluşturun. Java hizmetleriniz için Docker görüntüleri oluşturduğunuzda resmi OpenJDK temel görüntülerini kullanın. Bu görüntüler yalnızca Java'nın çalıştırması gereken en düşük paket kümesini içerir. Bu görüntülerin kullanılması hem paket boyutunu hem de saldırı yüzeyi alanını en aza indirir.

• Çok aşamalı Dockerfiles kullanın. Derleme zamanı varlıklarını çalışma zamanı kapsayıcı görüntüsünden ayırmak için çok aşamalı bir Dockerfile kullanın. Bu dosya türünü kullanmak, üretim görüntülerinizin küçük ve güvenli kalmasına yardımcı olur. Ayrıca önceden yapılandırılmış bir derleme sunucusu kullanabilir ve JAR dosyasını kapsayıcı görüntüsüne kopyalayabilirsiniz.

• Kök olmayan kullanıcı olarak çalıştırın. Java kapsayıcılarınızı kök olmayan bir kullanıcı olarak (kullanıcı adı veya UID $APP_UID aracılığıyla) çalıştırarak en az ayrıcalık ilkesiyle uyumlu hale getirin. Bunun yapılması, güvenliği aşılmış bir kapsayıcının olası etkilerini sınırlar.

• 8080 numaralı bağlantı noktasını dinleyin. Kapsayıcıları kök olmayan bir kullanıcı olarak çalıştırdığınızda, uygulamanızı 8080 numaralı bağlantı noktasını dinleyecek şekilde yapılandırın. Bu, kök olmayan kullanıcılar için yaygın bir kuraldır.

• Bağımlılıkları kapsülleme. Uygulamanın ihtiyaç duyduğu tüm bağımlılıkların Docker kapsayıcı görüntüsünde kapsüllenmiş olduğundan emin olun. Kapsülleme, uygulamanın çok çeşitli konaklara güvenilir bir şekilde dağıtılmasını sağlar.

• Doğru temel görüntüleri seçin. Seçtiğiniz temel görüntü dağıtım ortamınıza bağlıdır. Örneğin Container Apps'e dağıtım yapıyorsanız Linux Docker görüntülerini kullanmanız gerekir.

Başvuru uygulaması, Java uygulamasını kapsayıcıya alma için bir Docker derleme işlemini gösterir. Dockerfile, gerekli Java çalışma zamanı ortamını sağlayan OpenJDK temel görüntüsü (mcr.microsoft.com/openjdk/jdk:17-ubuntu) ile tek aşamalı bir derleme kullanır.

Dockerfile aşağıdaki adımları içerir:

1. Birim bildiriyor. Geçici birim (/tmp) tanımlanır. Bu birim, kapsayıcının ana dosya sisteminden ayrı geçici dosya depolama alanı sağlar.
2. Yapıtlar kopyaleniyor. Uygulamanın JAR dosyası (email-processor.jar), izleme için kullanılan Application Insights aracısı (applicationinsights-agent.jar) ile birlikte kapsayıcıya kopyalanır.
3. Giriş noktasını ayarlama. Kapsayıcı, Application Insights aracısı etkinken uygulamayı çalıştıracak şekilde yapılandırılır. Kod, çalışma zamanı sırasında uygulamayı izlemek için java -javaagent kullanır.

Dockerfile, yalnızca çalışma zamanı bağımlılıklarını ekleyerek görüntüyü küçük tutar. Linux tabanlı kapsayıcıları destekleyen Container Apps gibi dağıtım ortamları için uygundur.

# Use the OpenJDK 17 base image on Ubuntu as the foundation.
FROM mcr.microsoft.com/openjdk/jdk:17-ubuntu

# Define a volume to allow temporary files to be stored separately from the container's main file system.
VOLUME /tmp

# Copy the packaged JAR file into the container.
COPY target/email-processor.jar app.jar

# Copy the Application Insights agent for monitoring.
COPY target/agent/applicationinsights-agent.jar applicationinsights-agent.jar

# Set the entrypoint to run the application with the Application Insights agent.
ENTRYPOINT ["java", "-javaagent:applicationinsights-agent.jar", "-jar", "/app.jar"]

Başvuru uygulamasını dağıtma

Java için Modern Web Uygulaması Deseni'nin başvuru uygulamasını dağıtın. Depoda hem geliştirme hem de üretim dağıtımı yönergeleri vardır. Uygulamayı dağıttığınızda tasarım desenlerinin simülasyonunu yapabilir ve gözlemleyebilirsiniz.

Aşağıdaki diyagramda başvuru uygulamasının mimarisi gösterilmektedir:

Bu mimarinin Visio dosyasını indirin.