Bu tarayıcı artık desteklenmiyor.
En son özelliklerden, güvenlik güncelleştirmelerinden ve teknik destekten faydalanmak için Microsoft Edge’e yükseltin.
Bu makalede, Azure'da görev açısından kritik mimariler için önemli bir desen yer alır. Tasarım sürecinizi başlatırken bu düzeni uygulayın ve ardından iş gereksinimlerinize en uygun bileşenleri seçin. Makale, kuzey star tasarım yaklaşımını önerir ve ortak teknoloji bileşenlerine sahip diğer örnekleri içerir.
Temel tasarım alanlarını değerlendirmenizi, temel bileşenleri kullanan kritik kullanıcı ve sistem akışlarını tanımlamanızı ve aşağıdaki özellikleri göz önünde bulundurarak Azure kaynaklarının ve yapılandırmalarının matrisini geliştirmenizi öneririz.
| Özellik | Dikkat edilmesi gerekenler |
|---|---|
| Ömür | Çözümdeki diğer kaynaklara göre kaynağın beklenen ömrü nedir? Kaynak, sistemin veya bölgenin tamamıyla yaşam süresinden daha uzun mu yaşamalıdır, yoksa yaşam süresiyle mi paylaşılmalıdır? |
| Durum | Bu katmandaki kalıcı durumun güvenilirlik veya yönetilebilirlik üzerindeki etkisi nedir? |
| Reach | Kaynağın genel olarak dağıtılması gerekiyor mu? Kaynak, genel olarak veya bu bölge içinde bulunan diğer kaynaklarla iletişim kurabilir mi? |
| Bağımlılıklar | Diğer kaynaklara bağımlılıklar nelerdir? |
| Ölçek sınırları | Bu kaynak için beklenen aktarım hızı nedir? Kaynak tarafından bu talese uyacak şekilde ne kadar ölçek sağlanır? |
| Kullanılabilirlik/olağanüstü durum kurtarma | Bu katmandaki olağanüstü durumların kullanılabilirliği üzerindeki etkisi nedir? Sistemsel bir kesintiye veya yalnızca yerelleştirilmiş kapasite veya kullanılabilirlik sorununa neden olur mu? |
Önemli
Bu makale, Azure Well-Architected görev açısından kritik iş yükü serisinin bir parçasıdır. Bu seriyi bilmiyorsanız görev açısından kritik iş yükü nedir?
Belirli kaynaklar, her bölge içinde dağıtılan kaynaklar tarafından genel olarak paylaşılır. Yaygın örnekler, trafiği birden çok bölgeye dağıtmak, uygulamanın tamamı için kalıcı durumu depolamak ve bunlar için kaynakları izlemek için kullanılan kaynaklardır.
| Özellik | Dikkat edilmesi gerekenler |
|---|---|
| Ömür | Bu kaynakların uzun ömürlü (kısa ömürlü olmayan) olması beklenir. Yaşam süreleri sistemin ömrüne veya daha uzun bir süreye kadar sürer. Kaynaklar genellikle sıfır kapalı kalma süresi güncelleştirme işlemlerini desteklediği varsayılarak yerinde veri ve denetim düzlemi güncelleştirmeleriyle yönetilir. |
| Durum | Bu kaynaklar en azından sistemin ömrü boyunca mevcut olduğundan, bu katman genellikle genel, coğrafi olarak çoğaltılmış durumu depolamakla sorumludur. |
| Reach | Kaynaklar genel olarak dağıtılmalı ve bu kaynakları barındıran bölgelere çoğaltılmalıdır. Bu kaynakların düşük gecikme süresi ve istenen tutarlılık ile bölgesel veya diğer kaynaklarla iletişim kurması önerilir. |
| Bağımlılıklar | Kaynakların kullanılamaması genel hataya neden olabileceğinden, kaynakların bölgesel kaynaklara bağımlılıktan kaçınması gerekir. Örneğin, tek bir kasada tutulan sertifikalar veya gizli diziler, kasanın bulunduğu yerde bölgesel bir hata olması durumunda genel olarak etkilenebilir. |
| Ölçek sınırları | Bu kaynaklar genellikle sistemdeki tekil örneklerdir ve sistemin bir bütün olarak aktarım hızını işleyebilmeleri için ölçeklendirilebilmeleri gerekir. |
| Kullanılabilirlik/olağanüstü durum kurtarma | Bölgesel ve damga kaynakları genel kaynakları kullanabilir. Tüm sistemin sistem durumu için genel kaynakların yüksek kullanılabilirlik ve olağanüstü durum kurtarma ile yapılandırılması kritik önem taşır. |
Damga pulu, iş işlemlerinin tamamlanmasına katılan uygulamayı ve kaynakları içerir. Damga pulu genellikle bir Azure bölgesine yapılan dağıtıma karşılık gelir. Bir bölgede birden fazla damga olabilir.
| Özellik | Dikkat edilmesi gerekenler |
|---|---|
| Ömür | Kaynakların, damga pulu dışındaki bölgesel kaynaklar kalıcı olarak devam ederken dinamik olarak eklenip kaldırılma amacıyla kısa bir yaşam süresine (kısa ömürlü) sahip olması beklenir. Kısa ömürlü doğa, kullanıcılara daha fazla dayanıklılık, ölçek ve yakınlık sağlamak için gereklidir. |
| Durum | Damga pulları kısa ömürlü olduğundan ve her dağıtımda yok edildiğinden, bir damga pulu mümkün olduğunca durum bilgisiz olmalıdır. |
| Reach | Bölgesel ve küresel kaynaklarla iletişim kurabilir. Ancak, diğer bölgeler veya diğer damga damgaları ile iletişimden kaçınılmalıdır. |
| Bağımlılıklar | Damga pulu kaynakları bağımsız olmalıdır. Bölgesel ve genel bağımlılıkları olması beklenir, ancak aynı veya diğer bölgelerdeki diğer damga damgalarındaki bileşenlere güvenmemeleri gerekir. |
| Ölçek sınırları | Aktarım hızı test yoluyla oluşturulur. Genel damga pulu aktarım hızı en düşük performanslı kaynakla sınırlıdır. Damga aktarım hızının başka bir damga puluna yük devretmenin neden olduğu yüksek talep düzeyini tahmin etmesi gerekir. |
| Kullanılabilirlik/olağanüstü durum kurtarma | Damga pullarının geçici yapısı nedeniyle, damga pulunun yeniden dağıtılmasıyla olağanüstü durum kurtarma gerçekleştirilir. Kaynaklar iyi durumda değilse damga pulu bir bütün olarak yok edilebilir ve yeniden dağıtılabilir. |
Bir sistemin bölgede dağıtılan kaynakları olabilir, ancak damga kaynakları uzun sürebilir. Örneğin, pullar da dahil olmak üzere bölgesel düzeyde kaynakları izleyen gözlemlenebilirlik kaynakları.
| Özellik | Değerlendirme |
|---|---|
| Ömür | Kaynaklar bölgenin ömrünü paylaşır ve damga kaynaklarını canlı olarak kullanır. |
| Durum | Bir bölgede depolanan eyalet, bölgenin kullanım ömründen daha uzun süre yaşanamaz. Durumun bölgeler arasında paylaşılması gerekiyorsa genel veri deposu kullanmayı göz önünde bulundurun. |
| Reach | Kaynakların genel olarak dağıtılması gerekmez. Diğer bölgelerle doğrudan iletişimden ne pahasına olursa olsun kaçınılmalıdır. |
| Bağımlılıklar | Kaynakların genel kaynaklara bağımlılıkları olabilir, ancak damga pullarının kısa süreli olması amaçlandığından damga kaynaklarına bağımlılıkları olmayabilir. |
| Ölçek sınırları | Bölge içindeki tüm damgaları birleştirerek bölgesel kaynakların ölçek sınırını belirleyin. |
Bu temel örnekler, görev açısından kritik uygulamalar için önerilen kuzey star mimarisidir. Temel, kapsayıcıya alma ve uygulama platformu için kapsayıcı düzenleyici kullanma önerisinde bulunur. Taban çizgisi Azure Kubernetes Service (AKS) kullanır.
İyi Tasarlanmış görev açısından kritik iş yüklerine bakın: Kapsayıcılı hale getirme.
Görev açısından kritik yolculuğunuza yeni başlıyorsanız bu mimariyi referans olarak kullanın. İş yüküne genel bir uç nokta üzerinden erişilir ve diğer şirket kaynaklarına özel ağ bağlantısı gerektirmez.
Bu mimari temel mimariyi temel alır. Tasarım, İnternet'ten iş yükü kaynaklarına yetkisiz genel erişimi önlemek için katı ağ denetimleri sağlamak üzere genişletilmiştir.
İş yükünü daha geniş bir kuruluşta tümleştirmenin gerekli olduğu bir kurumsal kurulumda dağıtıyorsanız bu mimari uygundur. İş yükü merkezi paylaşılan hizmetleri kullanır, şirket içi bağlantı gerektirir ve kuruluş içindeki diğer iş yükleriyle tümleştirilir. Şirket yönetim grubundan devralınan bir Azure giriş bölgesi aboneliğinde dağıtılır.
Bu mimari, App Services'i birincil uygulama barındırma teknolojisi olarak değerlendirerek temel başvuruyu genişletir ve kapsayıcı dağıtımları için kullanımı kolay bir ortam sağlar.
En iyi çözüme ulaşmak için temel tasarım kararlarına gitmek için sağlanan tasarım kılavuzunu kullanmanızı öneririz. Bilgi için bkz. Temel tasarım alanları nelerdir?
Görev açısından kritik uygulama senaryoları tasarlamak için en iyi yöntemleri gözden geçirin.
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz. https://aka.ms/ContentUserFeedback.
Gönderin ve geri bildirimi görüntüleyin