Basitlik ve verimlilik için tasarlama önerileri

Bu Azure İyi Tasarlanmış Çerçeve Güvenilirliği denetim listesi önerisi için geçerlidir:

Bu kılavuzda, iş yüklerinizi basit ve verimli tutmak için gereksiz karmaşıklığı ve ek yükü en aza indirmeye yönelik öneriler açıklanmaktadır. İş yükünüzün güvenilirliğini iyileştirmek için gerekli iş yükü görevlerini gerçekleştirmek için en iyi bileşenleri seçin. Geliştirme ve yönetim yüklerinizi hafifletmek için platform tarafından sağlanan hizmetlerin sunduğu verimliliklerden yararlanın. Bu tasarım dayanıklı, yinelenebilir, ölçeklenebilir ve yönetilebilir bir iş yükü mimarisi oluşturmanıza yardımcı olur.

Tanımlar

Temel tasarım stratejileri

Güvenilirlik için tasarlamanın önemli bir tenet'i, işleri basit ve verimli tutmaktır. Gereksiz karmaşıklık veya fazla yük riskini azaltmak için iş yükü tasarımınızı iş gereksinimlerini karşılamaya odaklayın. Yalın, verimli ve güvenilir bir iş yükü oluşturmak için tasarımınız hakkında kararlar almanıza yardımcı olması için bu makaledeki önerileri göz önünde bulundurun. Farklı iş yüklerinin kullanılabilirlik, ölçeklenebilirlik, veri tutarlılığı ve olağanüstü durum kurtarma için farklı gereksinimleri olabilir.

Her tasarım kararını bir iş gereksinimiyle gerekçelendirmeniz gerekir. Bu tasarım ilkesi belirgin görünebilir, ancak iş yükü tasarımı için çok önemlidir. Uygulamanız milyonlarca kullanıcıyı mı yoksa birkaç bin kullanıcıyı mı destekliyor? Büyük trafik artışları mı yoksa sabit bir iş yükü mü var? Hangi uygulama kesintisi düzeyi kabul edilebilir? İş gereksinimleri bu tasarım konularını yönlendirir.

Denge: Karmaşık bir çözüm daha fazla özellik ve esneklik sunabilir, ancak daha fazla koordinasyon, iletişim ve bileşenlerin yönetilmesini gerektirdiğinden iş yükünün güvenilirliğini etkileyebilir. Alternatif olarak, daha basit bir çözüm kullanıcı beklentilerini tam olarak karşılamayabilir veya iş yükü geliştikçe ölçeklenebilirlik ve genişletilebilirlik üzerinde olumsuz bir etkiye sahip olabilir.

Proje katılımcılarıyla tasarım alıştırmaları üzerinde işbirliği yapma

Proje katılımcılarıyla birlikte çalışarak:

• İş yükünüzün kullanıcı akışlarına ve sistem akışlarına bir kritiklik düzeyi tanımlayın ve atayın. Gerekli bileşenleri ve gerekli dayanıklılık düzeyine ulaşmak için en iyi yaklaşımı belirlemenize yardımcı olması için tasarımınızı kritik akışlara odakla.

• İşlevsel ve işlev dışı gereksinimleri tanımlayın. Bir uygulamanın görev gerçekleştirip gerçekleştirmediğini belirlemek için işlevsel gereksinimleri göz önünde bulundurun. Uygulamanın bir görevi ne kadar iyi gerçekleştirdiğini belirlemek için işlev dışı gereksinimleri göz önünde bulundurun. Ölçeklenebilirlik, kullanılabilirlik ve gecikme süresi gibi işlev dışı gereksinimleri anladığınızdan emin olun. Bu gereksinimler tasarım kararlarını ve teknoloji seçimlerini etkiler.

• İş yüklerini bileşenler halinde ayrıştırma. Tasarımınızda basitlik, verimlilik ve güvenilirlik önceliklerini belirleyin. Akışlarınızı desteklemek için ihtiyacınız olan bileşenleri belirleyin. Bazı bileşenler birden çok akışı destekler. Bir bileşenin kavramsal olarak hangi sınamayı ele alacağınızı belirleyin ve tam işlevsellik sağlamaya devam ederken genel tasarımı basitleştirmek için bileşeni ayrı akışlardan kaldırmayı göz önünde bulundurun. Daha fazla bilgi için bkz . Hata modu analizi gerçekleştirmeye yönelik öneriler.

• Tek hata noktalarını ve olası riskleri belirlemek için hata modu analizini kullanın. Olası olmayan durumları, örneğin bölgedeki tüm kullanılabilirlik alanlarını etkileyen büyük bir doğal afetle karşılaşan bir coğrafi alanı hesaba eklemeniz gerekip gerekmediğini göz önünde bulundurun. Pahalıdır ve bu yaygın olmayan riskleri azaltmak için önemli dengeler içerir. İşletmenizin risklere olan toleransını net bir şekilde anlayın. Daha fazla bilgi için bkz . Hata modu analizi gerçekleştirmeye yönelik öneriler.

• İş yükünüzün mimarisini bilgilendirmek için akışlarınız için kullanılabilirlik ve kurtarma hedefleri tanımlayın. İş ölçümleri hizmet düzeyi hedeflerini (SLO'lar), hizmet düzeyi sözleşmelerini (SLA'lar), ortalama kurtarma süresini (MTTR), hata arasındaki ortalama süreyi (MTBF), kurtarma süresi hedeflerini (GPO'lar) ve kurtarma noktası hedeflerini (RPO'lar) içerir. Bu ölçümler için hedef değerleri tanımlayın. Bu alıştırma, her ekibin hedeflerinin iş hedeflerine uygun ve gerçekçi olmasını sağlamak için teknoloji ve iş ekipleri arasında uzlaşma ve karşılıklı anlayış gerektirebilir. Daha fazla bilgi için bkz . Güvenilirlik hedeflerini tanımlama önerileri.

Daha basit tasarım seçimlerini tercih edin

Paydaş katılımı olmadan aşağıdaki önerileri gerçekleştirebilirsiniz:

• Tasarımınızda kolaylık ve netlik için çabalayın. Bileşenleriniz ve hizmetleriniz için uygun soyutlama ve ayrıntı düzeyini kullanın. Çözümünüzde fazla mühendislik kullanmaktan veya yetersiz mühendislik kullanmaktan kaçının. Örneğin, kodunuzu birden çok küçük işleve bölerseniz anlamak, test etmek ve bakımını yapmak zordur.

• Hataların düzeltilmesi, yeni özelliklerin veya teknolojilerin uygulanması veya mevcut sistemlerin daha ölçeklenebilir ve dayanıklı hale getirilmesi gibi tüm başarılı uygulamaların zaman içinde değiştiğini unutmayın.

• Mümkün olduğunda hizmet olarak altyapı (IaaS) yerine hizmet olarak platform (PaaS) seçeneklerini kullanın. IaaS, parçalar içeren bir kutu gibidir. Herhangi bir şey oluşturabilirsiniz, ancak kendiniz birleştirmeniz gerekir. PaaS seçeneklerini yapılandırmak ve yönetmek daha kolaydır. Sanal makineleri (VM) veya sanal ağları ayarlamanız gerekmez. Ayrıca düzeltme eklerini ve güncelleştirmeleri yükleme gibi bakım görevlerini de gerçekleştirmeniz gerekmez.

• İleti üreticisini tüketiciden ayrıştırmak için zaman uyumsuz mesajlaşmayı kullanın.

• Altyapıyı etki alanı mantığından uzakta soyutlayın. Etki alanı mantığının mesajlaşma veya kalıcılık gibi altyapıyla ilgili işlevleri engellemediğinden emin olun.

• Geniş kapsamlı kritik konuları ayrı bir hizmete boşaltın. Farklı işlevlerde kodu yineleme gereksinimini en aza indirin, hizmetleri farklı bileşenler tarafından kolayca tüketilebilen iyi tanımlanmış arabirimlerle yeniden kullanmak tercih edin. Örneğin, çeşitli hizmetlerin isteklerin kimliğini doğrulaması gerekiyorsa, bu işlevi kendi hizmetine taşıyabilirsiniz. Ardından kimlik doğrulama hizmetini geliştirebilirsiniz. Örneğin, onu kullanan hizmetlere dokunmadan yeni bir kimlik doğrulama akışı ekleyebilirsiniz.

• Yaygın desenlerin ve uygulamaların ihtiyaçlarınıza uygunluğunu değerlendirin. Bağlamınız veya gereksinimleriniz için en uygun olmayabilecek eğilimleri veya önerileri takip etmekten kaçının. Örneğin mikro hizmetler karmaşıklık, ek yük ve bağımlılık sorunlarına neden olabileceğinden her uygulama için en iyi seçenek değildir.

Yeterli kod geliştirme

Kolaylık, verimlilik ve güvenilirlik ilkeleri geliştirme uygulamalarınız için de geçerlidir. Gevşek bir şekilde bağlanmış, bileşenleştirilmiş bir iş yükünde, bir bileşenin sağladığı işlevselliği belirleyin. Bu işlevden yararlanmak için akışlarınızı geliştirin. Geliştirme uygulamalarınız için şu önerileri göz önünde bulundurun:

• İş gereksinimlerinizi karşılarken platform özelliklerini kullanın. Örneğin, geliştirme ve yönetimi boşaltmak için bulut sağlayıcınız tarafından sunulan düşük kodlu, kodsuz veya sunucusuz çözümleri kullanın.

• Kitaplıkları ve çerçeveleri kullanın.

• Bir geliştirme uygulaması olarak çift programlama veya ayrılmış kod gözden geçirme oturumlarını tanıtın.

• Geçersiz kodu tanımlamak için bir yaklaşım uygulayın. Otomatikleştirilmiş testlerinizin kapsamayacağı koda şüpheyle bakın.

Doğru veri depoyu seçin

Geçmişte birçok kuruluş tüm verilerini büyük ilişkisel SQL veritabanlarında depolamıştı. İlişkisel veritabanları, ilişkisel veri işlemleri için atomik, tutarlı, yalıtılmış ve dayanıklı (ACID) garantileri sağlar. Ancak bu veritabanlarının dezavantajları vardır:

• Sorgular pahalı birleşimler gerektirebilir.

• Verileri normalleştirmeniz ve yazma işlemindeki şema için yeniden yapılandırmanız gerekir.

• Kilit çekişmesi performansı etkileyebilir.

İlişkisel veritabanlarının alternatifleri

Büyük bir çözümde, tek bir veri deposu teknolojisi büyük olasılıkla tüm ihtiyaçlarınızı karşılamaz. İlişkisel veritabanlarının alternatifleri şunlardır:

• Anahtar-değer depoları

• Belge veritabanları

• Arama motoru veritabanları

• Zaman serisi veritabanları

• Sütun ailesi veritabanları

• Graf veritabanları

Her seçeneğin avantajları ve dezavantajları vardır. Farklı veri türleri, farklı veri deposu türleri için daha uygundur. Verilerinize ve bunları nasıl kullandığınıza en uygun depolama teknolojisini seçin.

Örneğin, bir ürün kataloğunu esnek şemayı destekleyen Azure Cosmos DB gibi bir belge veritabanında depolayabilirsiniz. Her ürün açıklaması, bağımsız bir belgedir. Kataloğun tamamında sorgular için kataloğu dizine alabilir ve dizini Azure Bilişsel Arama depolayabilirsiniz. Veriler ACID garantisi gerektirdiği için ürün envanteri bir SQL veritabanına gidebilir.

Öneriler

• Diğer veri depolarını göz önünde bulundurun. İlişkisel veritabanları her zaman uygun değildir. Daha fazla bilgi için bkz . Veri deposu modellerini anlama.

• Verilerin kalıcı uygulama verilerinden fazlasını içerdiğini unutmayın. Bunlara ek olarak uygulama günlükleri, olaylar, iletiler ve önbellekler de içerir.

• Çok teknolojili kalıcılığı veya veri deposu teknolojilerinin birleşimini kullanan çözümleri benimseyin.

• Sahip olduğunuz veri türünü göz önünde bulundurun. Örneğin, mağaza:

  • SQL veritabanındaki işlem verileri.

  • Belge veritabanındaki JSON belgeleri.

  • Zaman serisi veritabanında telemetri.

  • uygulama günlükleri Azure Bilişsel Arama.

  • Azure Blob Depolama bloblar.

• Tutarlılık yerine kullanılabilirliği önceliklendirme. CAP teoremi, dağıtılmış bir sistemde kullanılabilirlik ve tutarlılık arasında dengeler elde etmek zorunda olduğunuzu gösterir. CAP teoreminin diğer bileşeni olan ağ bölümlerinden tamamen kaçınamazsınız. Ancak daha yüksek kullanılabilirlik elde etmek için nihai tutarlılık modelini benimseyebilirsiniz.

• Geliştirme ekibinizin beceri kümesini göz önünde bulundurun. Çok yönlü kalıcılık kullanmanın avantajları vardır, ancak aşırıya kaçmak mümkündür. Yeni bir veri depolama teknolojisini benimsemek için yeni beceri kümeleri gerektirir. Teknolojiden en iyi şekilde yararlanmak için geliştirme ekibinizin şunları yapması gerekir:

  • Sorguları iyileştirin.

  • Performans için ayarlama yapın.

  • Uygun kullanım desenleriyle çalışma.

Bir depolama teknolojisi seçerken şu faktörleri göz önünde bulundurun:

• Telafi işlemleri kullanın. Çok yönlü kalıcılık sayesinde tek bir işlem birden çok depoya veri yazabilir. Bir hata varsa, tamamlanan adımları geri almak için telafi işlemlerini kullanın.

• Etki alanı odaklı bir tasarım kavramı olan sınırlanmış bağlamları göz önünde bulundurun. Sınırlanmış bağlam, etki alanı modelinin etrafındaki açık bir sınırdır. Sınırlanmış bağlam, modelin etki alanının hangi bölümleri için geçerli olduğunu tanımlar. Bir sınırlanmış bağlam, ideal olarak iş etki alanının alt etki alanlarından biriyle eşlenir. Sisteminizdeki sınırlanmış bağlamlar için çok teknolojili kalıcılığı göz önünde bulundurun. Örneğin, ürünler ürün kataloğu alt etki alanında ve ürün envanteri alt etki alanında görünebilir. Ancak büyük olasılıkla, bu iki alt etki alanı ürünleri depolamak, güncelleştirmek ve sorgulamak için farklı gereksinimlere sahiptir.

Azure kolaylaştırma

Azure aşağıdaki hizmetleri sunar:

• Azure İşlevleri, minimum kodla düzenleme oluşturmak için kullanabileceğiniz sunucusuz bir işlem hizmetidir.

• Azure Logic Apps , GUI ile düzenleme oluşturmak veya yapılandırma dosyasını düzenleyerek kullanabileceğiniz sunucusuz bir iş akışı tümleştirme platformudur.

• Azure Event Grid , MQTT ve HTTP protokollerini kullanan esnek ileti tüketim desenleri sunan yüksek oranda ölçeklenebilir, tam olarak yönetilen bir yayımlama-abone olma ileti dağıtım hizmetidir. Event Grid ile cihaz verileriyle veri işlem hatları oluşturabilir, olay odaklı sunucusuz mimariler oluşturabilir ve uygulamaları tümleştirebilirsiniz.

Daha fazla bilgi için bkz.

• Azure işlem hizmeti seçme
• Mikro hizmetler için işlem seçeneği belirleme
• Veri seçeneklerinizi gözden geçirme

Örnek

Bileşenleri ve bunların özelliklerini gereksinimlere göre belirleyen örnek bir iş yükü için bkz . Reliable Web App deseni.

İlgili bağlantılar

• Azure sunucusuz
• Bulutta yerel uygulamalar
• Azure'da veritabanı türleri

Güvenilirlik denetim listesi

Öneriler kümesinin tamamına bakın.