Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Tek tek birden çok isteği tek bir istekte toplamak için ağ geçidi kullanın. Bu düzen, bir istemcinin bir işlemi gerçekleştirmek için farklı arka uç sistemlerine birden çok çağrı yapması gerektiğinde kullanışlıdır.
Bağlam ve sorun
Tek bir görevi gerçekleştirmek için istemcinin çeşitli arka uç hizmetlerine birden çok çağrı yapması gerekebilir. Bir görevi gerçekleştirmek için birden çok hizmete bağımlı olan bir uygulamanın her istek için kaynak harcaması gerekir. Uygulamaya yeni özellikler veya hizmetler eklendiğinde, kaynak gereksinimlerini ve ağ çağrılarını daha da artıran ek istekler gerekir. İstemci ile arka uç arasındaki bu sohbet, uygulamanın performansını ve ölçeğini olumsuz etkileyebilir. Mikro hizmet mimarileri bu sorunu daha yaygın hale getirmektedir çünkü çok daha küçük hizmetlerin etrafında oluşturulan uygulamaların daha fazla sayıda çapraz hizmet çağrısı vardır.
Aşağıdaki diyagramda, istemci istekleri her hizmete (1, 2 ve 3 numaralı) gönderir. Her hizmet isteği işler ve uygulamaya bir yanıt döndürür (4, 5 ve 6 numaralı). Yüksek gecikme süresine sahip bir hücresel ağ üzerinden tek tek isteklerin bu şekilde gönderilmesi verimsizdir ve bağlantı kaybına veya eksik yanıtlara neden olabilir. Her istek paralel olarak çalıştırılabilir. Ancak uygulamanın yine de ayrı bağlantılarda her istek için veri göndermesi, beklemesi ve işlemesi gerekir ve bu da hata olasılığını artırır.
Çözüm
İstemci ile hizmetler arasındaki iletişim yoğunluğunu azaltmak için bir ağ geçidi kullanın. Ağ geçidi istemci isteklerini alır, istekleri çeşitli arka uç sistemlerine gönderir ve sonuçları istemciye geri göndermeden önce toplar.
Bu düzen, uygulamanın arka uç hizmetlerine yaptığı istek sayısını azaltabilir ve yüksek gecikme süresine sahip ağlarda uygulama performansını artırabilir.
Aşağıdaki diyagramda, uygulama tarafından ağ geçidine bir istek gönderilir (1). İstek, ek isteklerden oluşan bir paket içerir. Ağ geçidi bu istekleri ayrıştırarak her isteği ilgili hizmete (2) göndererek işler. Her hizmet ağ geçidine bir yanıt döndürür (3). Ağ geçidi, her bir hizmetten alınan yanıtları birleştirir ve yanıtı uygulamaya gönderir (4). Uygulama tek bir istek gerçekleştirir ve ağ geçidinden tek bir yanıt alır.
Sorunlar ve dikkat edilmesi gerekenler
Bu düzenin nasıl uygulaneceğine karar velarken aşağıdaki noktaları göz önünde bulundurun:
Ağ geçidi, arka uç servisleri arasında servis bağımlılığına neden olmamalıdır.
Gecikme süresini olabildiğince azaltmak için ağ geçidi arka uç hizmetlerinin yakınında olmalıdır.
Ağ geçidi hizmeti tek bir hata noktasına (SPoF) neden olabilir. Ağ geçidinin uygulamanızın kullanılabilirlik gereksinimlerini karşılayacak şekilde düzgün tasarlandığından emin olun.
Ağ geçidi bir darboğaza neden olabilir. Ağ geçidinin geçerli yükü işlemek için yeterli performansa sahip olduğundan ve beklenen büyümenizi karşılayacak şekilde ölçeklendirilebileceğinden emin olun.
Hizmetler için zincirleme arızalara neden olmadığınızdan emin olmak amacıyla ağ geçidine karşı yük testi gerçekleştirin.
Bölmelendirme, devre kesme, yeniden deneme ve zaman aşımları gibi teknikler kullanarak dayanıklı bir tasarım uygulayın.
Bir veya daha fazla hizmet çağrısı çok uzun sürerse, zaman aşımına uğramak ve kısmi bir veri kümesi döndürmek kabul edilebilir olabilir. Uygulamanızın bu senaryoda nasıl davranacağını göz önünde bulundurun.
Uygulamada performans sorunlarına yol açmaması için arka uçta yaşanan gecikmelere karşı eşzamansız giriş ve çıkış (G/Ç) kullanın.
Her bir çağrıyı izlemek için bağıntı kimliklerini kullanarak dağıtılmış izleme uygulayın.
İstek ölçümlerini ve yanıt boyutlarını izleyin.
Hataların işlenmesine yönelik bir yük devretme stratejisi olarak önbelleğe alınmış verileri döndürmeyi göz önünde bulundurun.
Toplamayı ağ geçidine entegre etmek yerine, ağ geçidinin arkasına bir toplama hizmeti yerleştirmeyi değerlendirin. İstek toplama büyük olasılıkla ağ geçidindeki diğer hizmetlerden farklı kaynak gereksinimlerine sahip olabilir ve ağ geçidinin yönlendirme ve boşaltma işlevselliğini etkileyebilir.
Bu desen ne zaman kullanılır?
Bu düzeni aşağıdaki durumlarda kullanın:
bir işlemin gerçekleştirilmesi için istemcinin birden çok arka uç hizmetiyle iletişim kurması gerekir.
İstemci, hücresel ağlar gibi önemli gecikme süresi olan ağları kullanabilir.
Bu düzen aşağıdaki durumlarda uygun olmayabilir:
Bir istemci ile tek bir hizmet arasında, birden çok işlem boyunca yapılan çağrıların sayısını azaltmak istiyorsunuz. Bu senaryoda, hizmete toplu işlem eklemek daha uygun olabilir.
İstemci veya uygulama arka uç hizmetlerinin yakınında bulunur ve gecikme süresi önemli bir faktör değildir.
İş yükü tasarımı
Azure Well-Architected Framework sütunları kapsamındaki hedefleri ve ilkeleri ele almak için bir iş yükünün tasarımında Ağ Geçidi Toplama düzeninin nasıl kullanılacağını değerlendirin. Aşağıdaki tabloda, bu desenin her bir sütunun hedeflerini nasıl desteklediği hakkında rehberlik sağlanmaktadır.
| Temel | Bu desen sütun hedeflerini nasıl destekler? |
|---|---|
| Güvenilirlik tasarımı kararları, iş yükünüzün hatalı çalışmaya dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma geldiğinden emin olmasına yardımcı olur. | Bu topolojiyle, geçici hata işlemeyi istemciler arasında dağıtılmış bir uygulamadan merkezi bir uygulamaya geçirebilirsiniz. - Geçici hataları işlemeye yönelik öneriler |
| Güvenlik tasarımı kararları, iş yükünüzün verilerinin ve sistemlerinin gizliliğini, bütünlüğünü ve kullanılabilirliğini sağlamaya yardımcı olur. | Bu topoloji genellikle bir istemcinin sistemle sahip olduğu dokunma noktası sayısını azaltır ve bu da genel yüzey alanını ve kimlik doğrulama noktalarını azaltır. Toplanan arka uçlar istemcilerden tamamen ağdan yalıtılmış olarak kalabilir. - SE:04 Segmentlere Ayırma - SE:08 Kaynakları sağlamlaştırma |
| Operasyonel Mükemmellik, standartlaştırılmış süreçler ve ekip uyumu aracılığıyla iş yükü kalitesinin sunulmasına yardımcı olur. | Bu düzen, arka uç mantığının istemcilerden bağımsız olarak gelişmesine olanak tanır. Bu ayırma, istemci dokunma noktalarını değiştirmenize gerek kalmadan zincirlenmiş hizmet uygulamalarını ve hatta veri kaynaklarını değiştirme esnekliği sağlar. - OE:04 Araçlar ve işlemler |
| Performans Verimliliği , ölçeklendirme, veri ve kod iyileştirmeleri aracılığıyla iş yükünüzün talepleri verimli bir şekilde karşılamasını sağlar. | Bu tasarım, istemcinin birden çok bağlantı kurduğu bir tasarımdan daha az gecikmeye neden olabilir. Toplama uygulamalarında önbelleğe alma, arka uç sistemlerine yapılan çağrıları en aza indirir. - PE:03 Hizmetleri seçme - PE:08 Veri performansı |
Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.
Example
Bir müşteri için sipariş özeti deneyimi sağlayan mikro hizmet tabanlı bir uygulama düşünün. Kullanıcı bir sipariş sayfasını açtığında, uygulamanın sipariş hizmeti, sevkiyat hizmeti ve müşteri profili hizmeti gibi birden çok arka uç hizmetinden veri alması gerekir.
Mikro hizmetler mimarisinde bu hizmetler bağımsız olarak uygulanır ve dağıtılır. Toplama olmadan istemcinin her hizmeti doğrudan çağırması gerekir ve bu da gecikme süresini ve karmaşıklığı artırır.
Bu sorunu gidermek için uygulama ağ geçidi toplama katmanı olarak Azure API Management kullanır. İstemci, sipariş bilgileri için toplayıcı görevi gören bir API Management işlemine tek bir istek gönderir. ARDıNDAN API Management, destekleyici arka uç API'lerini çağırır ve istemciye birleşik bir yanıt döndürür.
Birden çok hizmetten veri almak ve birleştirilmiş yanıt oluşturmak için API Management istek gönderme ilkesini kullanarak bu basit bileşimi uygulayabilirsiniz. Bu örnekte arka uç hizmetleri Azure Container Apps ortamında çalışır ve her arka uç hizmetini doğrudan istemci erişiminden gizli kalan bir kapsayıcı uygulaması olarak dağıtırsınız.
Bu mimariye ait bir Visio dosyasını indirin.
İstek akışı şu adımları izler:
İstemci, API Management aracılığıyla kullanıma sunulan bir sipariş özeti uç noktasına istek gönderir.
API Management, arka uç hizmetlerinden sipariş, sevkiyat ve müşteri profili verilerini toplayan bir ilke uygular.
API Management, arka uç yanıtlarını tek bir sipariş özeti yükünde oluşturur.
API Management, istemciye toplu yanıtı döndürür.
Bu toplama katmanını kullanıma sunarak çözüm, istemciden hizmete gidiş dönüşleri azaltır ve istemci etkileşimlerini basitleştirir. Bu katman yanıt vermeyen arka uç hizmetlerini düzgün bir şekilde işlemekten ve hataların toplu yanıt boyunca basamaklanmasını önlemekten sorumlu hale gelir. İstek başına zaman aşımları, koşullu hata işleme ve devre kesicileri kullanarak API Management ilkelerinizi sağlamlaştırın.
Arka uç çağrılarından biri zaman aşımına uğradıysa veya hata döndürüyorsa, API Management işleme en uygun davranışı uygulayabilir. Örneğin eksik veriler kabul edilebilir olduğunda kısmi bir yanıt döndürebilir veya eksiksiz ve tutarlı sipariş verileri gerektiğinde isteğin tamamı başarısız olabilir. İstemcilerin öngörülebilir davranışlar yaşaması için ilke tasarımında bu kararı açıkça belirtin.
Ağ geçidi basit oluşturma, şekillendirme ve yanıt derlemesi gerçekleştirdiğinde bu yaklaşım iyi çalışır. Birleştirme özel alan mantığı, karmaşık dönüşümler veya daha uzun süreli orkestrasyon gerektiriyorsa, bu işlevselliği ağ geçidinin arkasındaki özel bir hizmete yerleştirin.
İzleme için, API Management davranışını arka uç gecikme süresiyle ilişkilendirebilmeniz için tam istek yolunda telemetri toplayın. Tek bir istemci işlemi birden çok arka uç çağrısına bağlı olduğundan ve herhangi bir bağımlılıktaki hatalar veya yavaş yanıtlar nihai toplanan sonucu etkileyebileceğinden, ağ geçidi toplama düzeninde bu görünürlük önemlidir. Merkezi gözlemlenebilirlik platformu olarak Azure İzleyici kullanın. Ağ geçidi ve ilke yürütme yolu için API Management günlüklerini ve ölçümlerini toplayın ve arka uç kapsayıcı uygulamalarından uygulama günlükleri ile ölçümlerini toplamak için Container Apps için izlemeyi etkinleştirin. Birleşik sorgulama, uyarılar ve sorun giderme için API Management'ı ve arka uç telemetrisini bir Log Analytics çalışma alanına yönlendirin. Bu telemetri ile zaman aşımı düzenlerini algılayabilir, kısmi veya başarısız yanıta hangi arka uç bağımlılığının neden olduğunu belirleyebilir ve yükseltilmiş gecikme süresi veya hata oranları için uyarılar oluşturabilirsiniz.