Dağıtım Damgaları Şablonu

Dağıtım Damgaları düzeni, birden çok iş yükünü veya kiracıyı barındırmak ve çalıştırmak için bir grup kaynağı sağlar, yönetir ve izler. Her bir kopya damga veya bazen hizmet birimi, ölçek birimi veya hücre olarak adlandırılır. Çok kiracılı bir ortamda, her damga önceden tanımlanmış sayıda kiracıya hizmet eder. Çözümü neredeyse doğrusal olarak ölçeklendirmek ve artan sayıda kiracıya hizmet vermek için birden çok damga dağıtabilirsiniz. Bu yaklaşım çözümünüzün ölçeklenebilirliğini artırabilir, örnekleri birden çok bölgeye dağıtmanıza ve müşteri verilerinizi ayırmanıza olanak tanır.

Note

Daha fazla bilgi için bkz . Azure'da çok kiracılı çözümler tasarlama.

Bağlam ve sorun

Bir uygulamayı bulutta barındırırken uygulamanızın performansını ve güvenilirliğini göz önünde bulundurun. Çözümünüzün tek bir örneğini barındırıyorsanız aşağıdaki sınırlamalar geçerli olabilir:

• Ölçek sınırları: Uygulamanızın tek bir örneği doğal ölçeklendirme sınırlarına ulaşabilir. Örneğin, kullandığınız hizmetler gelen bağlantı, ana bilgisayar adı, İletim Denetimi Protokolü (TCP) yuvaları veya diğer kaynakların sayısını sınırlayabilir.

• Doğrusal olmayan ölçeklendirme veya maliyet: Çözümünüzün bazı bileşenleri, istek sayısı veya veri miktarıyla doğrusal olarak ölçeklendirilmeyebilir. Bunun yerine, bir eşiği karşıladıktan sonra performans düşebilir veya maliyet yükselebilir. Örneğin, veritabanına daha fazla kapasite eklemenin veya ölçeği artırmanın çok pahalı hale geldiğini ve ölçeği genişletmenin daha uygun maliyetli olduğunu fark edebilirsiniz.

• Müşteri ayrımı: Bir müşterinin verilerini başka bir müşterinin verilerinden ayırmanız gerekebilir. Ayrıca diğerlerinden daha fazla sistem kaynağı kullanan müşterileriniz de olabilir. Bunları farklı altyapı kümelerinde gruplandırabilirsiniz.

• Tek kiracılı ve çok kiracılı örnekler: Bazı büyük müşterilerin çözümünüzün kendi bağımsız örneklerine ihtiyacı olabilir. Daha küçük müşteriler, çok kiracılı bir yapılandırmayı paylaşabilir.

• Karmaşık dağıtım gereksinimleri: Güncelleştirmeleri hizmetinize denetimli bir şekilde dağıtmanız ve farklı zamanlarda müşteri tabanınızın farklı alt kümelerine dağıtmanız gerekebilir.

• Güncelleştirme sıklığı: Bazı müşteriler sık güncelleştirmelere tolerans gösterirken, riskli olmayan müşteriler isteklerine hizmet eden sistemde seyrek güncelleştirmeler yapmak ister. Bu müşterileri yalıtılmış ortamlara dağıtabilirsiniz.

• Coğrafi veya jeopolitik kısıtlamalar: Düşük gecikme süresi elde etmek veya veri hakimiyeti gereksinimlerine uymak için bazı müşterileri belirli bölgelere dağıtabilirsiniz.

Bu sınırlamalar genellikle hizmet olarak yazılım (SaaS) oluşturan ve genellikle çok kiracılı olarak tasarlayan yazılım geliştirme şirketleri için geçerlidir. Aynı sınırlamalar diğer senaryolar için de geçerli olabilir.

Çözüm

Bu sorunlardan kaçınmak için kaynakları ölçek birimleri halinde gruplandırmayı ve damgalarınızın birden çok kopyasını sağlamayı göz önünde bulundurun. Her ölçek birimi kiracılarınızın bir alt kümesini barındırır ve hizmet eder. Damgalar birbirinden bağımsız olarak çalışır ve bunları bağımsız olarak dağıtabilir ve güncelleştirebilirsiniz. Tek bir coğrafi bölge, bölge içinde yatay olarak ölçeği genişleten bir damga pulu veya birden çok damga içerebilir. Her damga pulu, müşterilerinizin bir alt kümesine hizmet eder.

Diyagramda beş yığılmış satır gösterilir. Her satır bir dağıtım damgasını temsil eder. Her satırın sol üst kısmında damgayı ve Azure bölgesini adlandıran bir etiket, sağ üstte damganın hizmet verdiği kiracıları listeleyen bir etiket ve etiketlerin altında solda Azure App Service ve sağda bir SQL veritabanı bulunan iki bileşen bulunur. Yukarıdan aşağıya, damga pulları A, B ve C kiracılarına hizmet veren Batı ABD 2'deki Damga 1'tir; D kiracısı sunan Batı ABD 2'de Damga 2; E, F ve G kiracılarına hizmet veren Doğu ABD'deki Damga 3; H, I ve J kiracılarına hizmet veren Batı Avrupa'daki Damga 4; ve K, L ve M kiracılarına hizmet veren Doğu Avustralya'daki Damga 5. Beş damga aynı iç bileşimi paylaşır, ancak bölge ve kendilerine atanan kiracı kümesinde farklılık gösterir ve Batı ABD 2 bölgesi iki ayrı damga içerirken diğer bölgelerin her biri bir damga içerir.

Çözümünüz, altyapı hizmeti (IaaS) veya platform hizmeti (PaaS) bileşenlerini ya da her ikisinin birleşimini kullanıyor olsun, dağıtım şablonlarını uygulayabilmeniz mümkündür. IaaS iş yükleri genellikle ölçeklendirme için daha fazla müdahale gerektirir, bu nedenle bu desen IaaS yoğun iş yüklerinin ölçeğini genişletmeye yardımcı olabilir.

Dağıtım halkalarını uygulamak için damgaları kullanabilirsiniz. Farklı müşteriler farklı frekanslarda hizmet güncelleştirmeleri istiyorsa, bunları farklı damga pullarına gruplandırın ve her damgaya farklı bir tempoda güncelleştirmeler dağıtın.

Bağımsız çalışan damgalar, verilerinizi örtük olarak parçalar. Tek bir damga, ölçeklendirmek ve elastik kalmak için dahili olarak daha fazla parçalama da kullanabilir.

Aynı bileşenlerin özdeş kopyalarını dağıtmak karmaşıktır, bu nedenle iyi DevOps uygulamaları kritik önem taşır. Her damga pulu dağıtımının tahmin edilebilir ve yinelenebilir olması için altyapınızı kod olarak tanımlayın.

Dağıtım damgaları coğrafi bölgelerle ilgilidir ancak birbirinden farklıdır. Dağıtım damgası mimarisinde, sisteminizin her bağımsız örneği müşterilerinizin ve kullanıcılarınızın bir alt kümesine hizmet eder. Coğrafi mimaride, her örnek herhangi bir kullanıcıdan gelen isteklere hizmet edebilir, ancak bu yaklaşım genellikle tasarım ve derleme için daha karmaşıktır. Ayrıca iki deseni tek bir çözüm içinde birleştirebilirsiniz. Bu makalenin devamında açıklanan trafik yönlendirme yaklaşımı , bu tür bir karma senaryoya örnektir.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulaneceğine karar velarken aşağıdaki noktaları göz önünde bulundurun:

• Dağıtım işlemi: Birden çok damga dağıttığınızda dağıtım işlemlerinizi otomatikleştirin ve tam olarak yineleyin. Damgalarınızı bildirimli olarak tanımlamak ve tanımları tutarlı tutmak için Bicep veya Terraform modüllerini kullanın.

• Çapraz damga işlemleri: Çözümünüzü birden çok damga pulu arasında bağımsız olarak dağıttığınızda, tüm damga pullarınızda kaç müşteriniz olduğunu belirlemek zor olabilir. Her damgayı sorgulamanız ve sonuçları toplamanız gerekebilir. Alternatif olarak, tüm damgaların verileri birleştirilmiş raporlama için merkezi bir veri ambarına yayımlamasını sağlayabilirsiniz.

• Ölçeği genişletme ilkeleri: Damgalar, bir damgaya dağıtılabilecek kiracı sayısı gibi bir proxy ölçümü kullanarak tanımlayabileceğiniz sınırlı kapasitededir. Her damga pulu için kullanılabilir ve kullanılan kapasiteyi izleyin ve yeni kiracıları bunlara yönlendirmek için proaktif olarak daha fazla damga dağıtın.

• En az damga sayısı: Dağıtım Damgaları desenini kullandığınızda, çözümünüzün en az iki damgasını dağıtın. Yalnızca tek bir damga dağıtıyorsanız, kodunuzun veya yapılandırmanızın ölçeğini genişlettiğinizde geçerli olmayan varsayımları kolayca sabit kodlayabilirsiniz.

• Maliyet: Dağıtım DamgaLarı düzeni, altyapı bileşenlerinizin birden çok kopyasını dağıtır ve bu da çözümünüzü çalıştırma maliyetini önemli ölçüde artırır.

• Damga pulları arasında geçiş: Her damga bağımsız olarak çalıştığından, kiracıları damga pulları arasında taşımak zor olabilir. Uygulamanızın müşterinin bilgilerini farklı bir damga puluna iletmek ve ardından kiracının bilgilerini özgün damgadan kaldırmak için özel mantığa ihtiyacı vardır. Bu işlem, damga pulları arasında iletişim kurmak için bir arka plan gerektirebilir ve bu da çözümünüzün karmaşıklığını daha da artırır.

• Trafik yönlendirme: Bu makalede daha önce açıklandığı gibi, trafiği belirli bir istek için doğru damgaya yönlendirmek, kiracıları damgalara çözümleyen ek bir bileşen gerektirebilir. Bu bileşenin yüksek oranda kullanılabilir olması da gerekebilir.

• Damgalar arasında gözlemlenebilirlik: Damga sayısı arttıkça genel sağlık durumunu anlamak ve olayları hızlıca tespit etmek zorlaşır. Azure İzleyici kullanarak ölçümleri, günlükleri, izlemeleri ve uyarıları tüm damgalarda toplayın ve ilişkilendirin. İyi durumda olmayan damgaları belirlemek ve sorunları tanılamak için bu verileri kullanın.

• Bölgesel hata etkisi: Damga pulları bağımsız olarak çalışır, ancak bölgeler arasında doğal olarak yedekli değildir. Bir veya daha fazla damga barındıran bir bölge kullanılamaz hale gelirse, o damgalardaki kiracılar, bölge düzelene veya kiracıları başka bir bölgedeki damgalara geçirene kadar erişimlerini kaybeder. Bu senaryo için planlama yapmak amacıyla kurtarma prosedürlerinizi belgeleyin, kiracı beklentilerini ayarlayın ve kritik kiracıların jeo-redundant damga yerleşim ihtiyacını değerlendirin.

• Paylaşılan bileşenler: Pullar arasında paylaşabileceğiniz bileşenleriniz olabilir. Örneğin, tüm kiracılar için paylaşılan tek sayfalı bir uygulamanız varsa, bunu tek bir bölgeye dağıtın ve genel olarak çoğaltmak için Azure Front Door kenar önbelleğini kullanın.

• İdare ve yapılandırma kayma: Damga sayısı arttıkça güvenlik ilkelerini, rol tabanlı erişim denetimi (RBAC) atamalarını, ağ denetimlerini, gözlemlenebilirlik ayarlarını ve hizmet yapılandırmalarını tutarlı tutmak zorlaşır. Azure İlkesi kullanarak yönetimi kod olarak değerlendirin ve tutarsız davranış ve uyumluluk boşluklarını önlemek için her birimi sürekli olarak izleyin ve doğrulayın.

Bu desen ne zaman kullanılır?

Bu düzeni aşağıdaki durumlarda kullanın:

• Çözümünüz ölçeklenebilirlik konusunda doğal sınırlar sunar. Örneğin, bazı bileşenler belirli sayıda müşteri veya isteğin ötesine ölçeklenemiyorsa veya ölçeklenmemesi gerekiyorsa, ölçeklendirmek için damgaları kullanın.

• Belirli kiracıları diğerlerinden ayırmanız gerekir. Güvenlik endişeleri bazı müşterileri çok kiracılı bir alanına dağıtmanızı engelliyorsa, onları kendi izole edilmiş alanlarına dağıtın.

• Çözümünüzün farklı sürümlerinde aynı anda bazı kiracıları barındırmanız gerekir.

• Her kiracının verilerini ve trafiğini belirli bir bölgeye yönlendirmesi gereken çok bölgeli uygulamalar oluşturursunuz.

• Kesintiler sırasında dayanıklılık elde etmek istiyorsunuz. Damgalar bağımsız olarak çalışır, dolayısıyla bir kesinti tek bir damgayı etkilerse diğer damgalardaki kiracılar etkilenmez. Bu yalıtım, bir olayın veya kesintinin patlama yarıçapını içerir.

Bu düzen aşağıdaki durumlarda uygun olmayabilir:

• Çözümünüz basittir ve yüksek dereceye ölçeklendirilmesi gerekmez.

• Uygulama katmanının boyutunu artırarak veya veritabanları ve depolama katmanı için ayrılmış kapasiteyi artırarak sisteminizin ölçeğini tek bir örnek içinde genişletebilir veya artırabilirsiniz.

• Dağıtılan tüm örneklerde verileri çoğaltmanız gerekir. Bu senaryo için Geode desenini göz önünde bulundurun.

• Yalnızca bazı bileşenleri ölçeklendirmeniz gerekir, diğerlerini ölçeklendirmeniz gerekmez. Örneğin, tüm çözüm bileşenlerinin yeni bir kopyasını dağıtmak yerine veri deponuzu parçalayarak çözümünüzü ölçeklendirin.

• Çözümünüz yalnızca ön uç JavaScript uygulaması gibi statik içeriklerden oluşur. Bu içeriği bir Content Delivery Network ile teslim edin.

İş yükü tasarımı

Azure Well-Architected Framework sütunları kapsamındaki hedefleri ve ilkeleri ele almak için iş yükünün tasarımında Dağıtım DamgaLarı deseninin 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.

Kolon	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.	Damga bağımsız olarak çalıştığından, bir damgadaki hata yalıtılır ve diğer damgalardaki kiracıları etkilemez. Bölgeler arasında birden çok damga dağıtılması, bölgesel kesintilerin patlama yarıçapını azaltan yedeklilik ve kurtarma planlaması için de bir temel sağlar. - RE:05 Yedeklilik - RE:07 Kendini koruma
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 sabit altyapı hedeflerini, gelişmiş dağıtım modellerini destekler ve güvenli dağıtım uygulamalarını kolaylaştırabilir. - Kod olarak OE:05 Altyapısı - OE:11 Güvenli dağıtım uygulamaları
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 desen genellikle iş yükünüzdeki tanımlı ölçek birimlerine hizalanır. Tek bir ölçek biriminin sağladığından daha fazla kapasiteye ihtiyacınız olduğunda, kapasiteyi artırmak için başka bir birimi dağıtırsınız. - PE:05 Ölçeklendirme ve bölümleme

Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.

Örnek

Aşağıdaki örnek mimari, trafiği genel olarak bölgeye özgü bir dizi damgaya yönlendirmek için Azure Front Door, Azure API Management ve Azure Cosmos DB kullanır.

En soldaki Azure Front Door (genel) giriş noktasını temsil eder. Diyagramın sağında, ortasında, Batı ABD 2, Doğu ABD ve Avustralya Doğu için birer tane olmak üzere dikey olarak yığılmış üç bölgesel trafik yönlendirme katmanı yerleştirilmiş bulunur. Her seviyede, bir API Yönetimi örneği solda, bir Azure Cosmos DB örneği sağda yer alır ve "kiracı damgası sorgusu" etiketli çift yönlü bir ok işareti bunları birbirine bağlar. Dikey çift başlı oklar, üzerinde "coğrafi çoğaltma" etiketi bulunan ve üç Azure Cosmos DB örneğini bağlayan bağlantılardır. Azure Front Door, üç API Yönetimi örneğine çift yönlü oklarla bağlanır. En sağda beş pul dikey olarak yığılmış. Her damga pulu adını ve bölgesini, hizmet verdiği kiracıları ve SQL veritabanıyla eşleştirilmiş bir App Service örneğini gösterir. Damga pulları A, B ve C kiracıları için Damga 1 (Batı ABD 2), D kiracısı için Damga 2 (Batı ABD 2), E, F ve G kiracıları için Damga 3 (Doğu ABD), H, I ve J kiracıları için Damga 4 (Batı Avrupa) ve K, L ve M kiracıları için Damga 5 (Avustralya Doğu) şeklindedir. Kavisli oklar API Management örneklerinden sağdaki uygun damgalara yönlendirir.

Bir kullanıcının New York'ta olduğunu varsayalım. Doğu ABD bölgesinde yer alan Stamp 3, verilerini depolar.

Kullanıcı California'ya seyahat eder ve sisteme erişirse, istekte bulunurken bu bölge kendilerine en yakın olduğu için sistem bağlantısını Batı ABD 2 bölgesi üzerinden yönlendirir. Ancak, verilerini depoladığı için, 3. sunucu isteğe nihai olarak hizmet vermelidir. Trafik yönlendirme sistemi isteği doğru damgaya yönlendirir.

Deployment

Bicep veya Terraform kullanarak altyapınızı kod olarak tanımlayın. Bu yaklaşım, her damganın dağıtımının tahmin edilebilir ve yinelenebilir olmasını sağlar. Ayrıca damgalar arasındaki yapılandırmada, yanlışlıkla meydana gelen uyumsuzluklar gibi insan hataları olasılığını da azaltır.

Güncelleştirmeleri tüm damgalara paralel olarak otomatik olarak dağıtabilirsiniz. Bicep gibi teknolojiler altyapınızın ve uygulamalarınızın dağıtımını koordine edebilir. Alternatif olarak, önce bazı damga pullarına yönelik güncelleştirmeleri aşamalı olarak kullanıma sunma ve ardından aşamalı olarak diğer damga pullarına göndermeye karar vekleyebilirsiniz. Her bir hedefe dağıtımları koordine etmek için Azure Pipelines veya GitHub Actions gibi bir yayın yönetim aracı kullanmayı göz önünde bulundurun.

Dağıtımlarınız için Azure aboneliklerinin ve kaynak gruplarının topolojisini dikkatle göz önünde bulundurun:

• Genellikle, bir abonelik tek bir çözüm için tüm kaynakları içerir, bu nedenle tüm damgalar için tek bir abonelik kullanmayı göz önünde bulundurun. Ancak bir Azure hizmeti abonelik genelinde kotalar uygular. Bu düzeni yüksek düzeyde ölçeği genişletmeye izin vermek için kullanırsanız, farklı aboneliklerde damgaları dağıtmanız gerekebilir.

• Kaynak grupları genellikle aynı yaşam döngüsünü paylaşan bileşenler içerir. Güncelleştirmeleri tüm damgalara aynı anda dağıtmayı planlıyorsanız, tüm damgalar için tüm bileşenleri içeren tek bir kaynak grubu kullanabilirsiniz. Her damgaya ait bileşenleri tanımlamak için kaynak adlandırma kurallarını ve etiketlerini kullanın. Alternatif olarak, güncelleştirmeleri her damgaya bağımsız olarak dağıtmayı planlıyorsanız, her damgayı kendi kaynak grubuna dağıtabilirsiniz.

Kapasite planlaması

Belirli bir damganın barındırabileceği yaklaşık yükü belirlemek için yük ve performans testini kullanın. Yük ölçümleri, tek bir damganın barındırabileceği müşteri veya kiracı sayısına veya damga pulundaki hizmetlerin yaydığı ölçümlere bağlı olabilir. Kapasiteye yaklaştığında ölçebilmeniz için her damgayı ölçün ve talebe yanıt vermek için yeni damgaları hızla dağıtabildiğinize emin olun.

Trafik yönlendirme

Dağıtım Damgaları modeli, her damgayı bağımsız olarak ele aldığınızda iyi çalışır. Örneğin, Contoso aynı API uygulamasını birden çok damgaya dağıtırsa Contoso, trafiği ilgili damgaya yönlendirmek için Etki Alanı Adı Sistemi'ni (DNS) kullanabilir:

• unit1.aus.myapi.contoso.com trafiğini Avustralya bölgesindeki bir damgaya unit1 yönlendirir.
• unit2.aus.myapi.contoso.com trafiğini Avustralya bölgesindeki bir damgaya unit2 yönlendirir.
• unit1.eu.myapi.contoso.com trafiği Avrupa bölgesinde damga unit1 üzerine yönlendirir.

Azure bu kayıtları Azure DNS içinde barındırabilir ve her bölge ve damga için tutarlı bir alt etki alanı kuralı kullanabilirsiniz. Bu yaklaşım tahmin edilebilir yönlendirme ve işlemleri korur.

İstemciler doğru damgaya bağlanmakla sorumludur.

Çözümünüz tüm trafik için tek bir giriş noktası gerektiriyorsa, belirli bir istek, müşteri veya kiracının damgasını çözümlemek için bir trafik yönlendirme hizmeti kullanabilirsiniz. Trafik yönlendirme hizmeti istemciyi damga pulu için ilgili URL'ye yönlendirir (örneğin, bir HTTP 302 yanıt durum kodu döndürerek) veya ters proxy işlevi görür ve istemci farkında olmadan trafiği ilgili damgaya iletir.

Merkezi bir trafik yönlendirme hizmeti, özellikle de bir çözüm birden çok bölgede çalıştığında tasarlanması gereken karmaşık bir bileşen olabilir. Potansiyel olarak damgaları barındıran her bölge dahil olmak üzere trafik yönlendirme hizmetini birden çok bölgeye dağıtmayı ve kiracıları damgalarla eşleyen veri deposunu eşitlemeyi göz önünde bulundurun. Trafik yönlendirme bileşeni , Geode deseninin bir örneği olabilir.

Örneğin, trafik yönlendirme hizmeti olarak hareket etmek için API Management'ı dağıtabilirsiniz. API Management, kiracılar ve damgalar arasındaki eşlemeyi depolayan bir Azure Cosmos DB koleksiyonundaki verileri arayarak istek için uygun damgayı belirler. Ardından API Management , arka uç URL'sini ilgili damganın API hizmetine dinamik olarak ayarlar.

İstekleri coğrafi olarak dağıtmak ve trafik yönlendirme hizmeti için coğrafi olarak yedeklilik sağlamak için DEPLoy API Management'ı birden çok bölgede kullanın ve trafiği en yakın API Management ağ geçidine yönlendirmek için Azure Front Door kullanın. Bu topolojide, Azure Front Door origin grupları, sağlık denetimleri ve istekleri iyi durumda olmayan API Management bölgesel ağ geçitlerinden uzağa yönlendirmek için uygun bir yönlendirme yöntemi kullanır. API Management, kiracı-damga eşlemesini ve gerektiğinde damga uç noktaları arasında yük devretme kuralları dahil olmak üzere arka uç yapılandırmasını (veya arka uç havuzlarını) kullanarak uygun damgaya yönlendirir. Uygulamanız HTTP veya HTTPS üzerinden kullanıma sunulmadıysa, gelen çağrıları bölgesel Azure yük dengeleyicilere dağıtmak için cross-region Azure yük dengeleyici kullanabilirsiniz. Eşleme bilgilerini her bölgede güncel tutmak için Azure Cosmos DB global dağıtım özelliğini kullanın.

Çözümünüz bir trafik yönlendirme hizmeti içeriyorsa, bunun bir ağ geçidi gibi davranıp davranmadığını ve belirteç doğrulama, azaltma ve yetkilendirme gibi diğer hizmetler için ağ geçidi boşaltması gerçekleştirip gerçekleştiremeyeceğini göz önünde bulundurun.

Sonraki Adımlar

• Azure Front Door
• Bicep'i Azure Pipelines ile entegre etme
• JSON ARM şablonlarını Azure Pipelines ile tümleştirme

Contributors

Microsoft bu makaleyi korur. Bu makaleyi aşağıdaki katkıda bulunanlar yazdı.

Asıl yazar:

• John Downs | Baş Yazılım Mühendisi, Azure Desenleri ve Uygulamaları

Diğer katkıda bulunanlar:

• Federico Arambarri | Kıdemli Yazılım Geliştirici, Clarius Consulting
• Daniel Larsen | Baş Müşteri Mühendisi, Azure için FastTrack
• Angel Lopez | Kıdemli Yazılım Mühendisi, Azure Desenleri ve Uygulamaları
• Paolo Salvatori | Baş Müşteri Mühendisi, Azure için FastTrack
• Arsen Vladimirskiy | Azure için FastTrack’te Baş Müşteri Mühendisi

Herkese açık olmayan LinkedIn profillerini görmek için LinkedIn'e oturum açın.

İlgili kaynaklar

• Parçalama özelliğini, veri katmanınızın ölçeğini genişletmek için daha basit bir yaklaşım olarak kullanabilirsiniz. Damgalar verilerini örtük olarak parçalar, ancak parçalama için dağıtım damgası gerekmez. Daha fazla bilgi için bkz. Parçalama düzeni.
• Çözümünüz bir trafik yönlendirme hizmeti dağıtıyorsa, bu bileşeni en iyi şekilde kullanmak için Ağ Geçidi Yönlendirme ve Ağ Geçidi Boşaltma desenlerini birleştirebilirsiniz.