Deployment Stamps pattern.md

‏Deployment Stamps pattern

  الگوی Deployment Stamps شامل، مدیریت و نظارت یا مانیتورینگ بر یک گروه ناهمگن از منابع برای میزبانی و بهره‌برداری از workloadها یا tenantهای متعدد است. هر کپی منفرد یک stamp یا یک service unit, scale unit یا cell نامیده می‌شود. در یک محیط دارای چند tenant، هر واحد stamp یا scale می‌تواند به تعداد از پیش تعریف‌شده tenant سرویس‌دهی کند. از stampهای مختلفی می‌توان استفاده کرد تا راه‌حل‌های موردنظر را ساده‌تر کند و به تعداد زیادی از tenant آن سرویس‌دهی کند. این رویکرد می‌تواند مقیاس‌پذیری (scalability) راه‌حل شما را بهبود بخشد و به شما این امکان را می‌دهد که نمونه‌هایی از برنامه را در چندین منطقه مستقر کنید و داده‌های مشتری‌های خود را جداسازی کنید.

 

زمینه و مشکل

  هنگام میزبانی (hosting) یک برنامه در فضای ابری معمولاً ملاحظات خاصی وجود دارد. یکی از نکات کلیدی که باید در نظر داشته باشید عملکرد مناسب و قابلیت اطمینان برنامه شما است. اگر یک نمونه از راه‌حل‌های موردنظر خود را میزبانی می‌کنید، شاید مواجه با محدودیت‌های زیر شوید: ‏* محدودیت‌های مقیاس‌دهی (Scale limits). مستقر کردن یک نمونه از برنامه شما ممکن است منجر به محدودیت‌های مقیاس‌دهی (scaling) به‌صورت طبیعی شود. برای مثال، ممکن است از سرویس‌هایی استفاده کنید که محدودیت‌هایی در تعداد اتصالات ورودی، نام دامنه، سوکت‌های TCP یا منابع دیگر دارند.

  ‏* مقیاس‌بندی غیرخطی یا افزایش هزینه‌ها. برخی از مؤلفه‌های موردنظر شما ممکن است scale خطی نداشته باشند و با افزایش تعداد requestها یا داده‌ها این احتمال افزایش یابد. همین‌طور، زمانی که شرط‌های یک آستانه خاصی برآورده شود این احتمال وجود دارد که کاهش ناگهانی در کارایی برنامه یا افزایش هزینه‌ها وجود داشته باشد. برای مثال، ممکن است از یک پایگاه‌داده استفاده کنید و متوجه شوید که هزینه نهایی اضافه‌کردن ظرفیت بیشتر scaling up گران‌تر می‌شود و راهبُرد scaling out راه‌حل مقرون‌به‌صرفه‌تری است.

  ‏ *جداسازی مشتریان (Separation of customers)**. ممکن است لازم باشد داده‌های مشتریان خاص را از داده‌های مشتریان دیگر جدا نگه دارید. به طور مشابه، ممکن است مشتریانی داشته باشید که به منابع سیستم بیشتری نسبت به سایرین نیاز دارند و آنها را در زیرساخت‌های مختلف گروه‌بندی کنید.

  ‏ رسیدگی به موارد منفرد و چند tenant ای.* ممکن است مشتریان بزرگی داشته باشید که به نمونه‌های مستقل خود از راه‌حل شما نیاز دارند. همچنین ممکن است مجموعه‌ای از مشتریان کوچک‌تر داشته باشید که می‌توانند یک deployment چند tenant را به اشتراک بگذارند.

  ‏ الزامات deployment پیچیده.* ممکن است لازم باشد به‌روزرسانی‌ها را به شیوه‌ای کنترل‌شده در سرویس خود اجرا کنید و در زمان‌های مختلف در زیرمجموعه‌های مختلف زیرساخت‌های مربوط مشتریان خود مستقر کنید.

  ‏ فرکانس به‌روزرسانی Update frequency* ممکن است مشتریانی داشته باشید که به‌روزرسانی‌های مکرر سیستم شما را تحمل می‌کنند، درحالی‌که برخی دیگر ممکن است ریسک‌گریز باشند و بخواهند سیستمی که درخواست‌هایشان را پاسخ می‌دهد به‌روزرسانی‌های نادری انجام شود. ممکن است منطقی باشد که این مشتریان در محیط‌های ایزوله مستقر شوند.

  ‏ محدودیت‌های جغرافیایی یا ژئوپلیتیکی.* برای داشتن یک معماری با تأخیر کم و سرعت مناسب یا رعایت الزامات حاکمیت داده (data sovereignty)، ممکن است موارد خاصی را برای برخی از مشتریان خود در مناطق خاصی مستقر یا deploy کنید.

  این محدودیت‌ها اغلب برای فروشندگان نرم‌افزار مستقل independent software vendors (ISVs) که نرم‌افزار را به‌عنوان سرویس (SaaS) می‌سازند که اغلب برای چند tenant بودن طراحی می‌شوند، اعمال می‌شود. بااین‌حال، همین محدودیت‌ها می‌تواند برای سناریوهای دیگر نیز اعمال شود.

 

راه حل

برای جلوگیری از این مسائل، منابع را در واحدهای مقیاس‌دهی یا scale unitها گروه‌بندی کنید و چندین نسخه از stampهای خود تهیه کنید. هر scale unit میزبان زیرمجموعه‌ای از tenantهای شما خواهد بود و به آنها سرویس‌دهی می‌کند. stampها مستقل از یکدیگر عمل می‌کنند و می‌توانند به طور مستقل deploy و update شوند. یک منطقه جغرافیایی منفرد ممکن است حاوی یک یا چندین stamp باشد تا امکان کاهش مقیاس‌دهی افقی (horizontal scale-out) در داخل منطقه را فراهم کند. stampها شامل زیرمجموعه‌ای از مشتریان شما هستند.

 

    گزینه Deployment stamps چه در حالت استفاده از infrastructure as a service (IaaS) یا platform as a service (Paas)‏ یا حالت‌های ترکیبی از این دو به کار می‌رود. معمولاً workload مورداستفاده در IaaS نیاز به دست‌کاری بیشتری برای scale دارند، بنابراین این الگو ممکن است برای workloadهای سنگین در IaaS مفید باشد تا امکان کاهش مقیاس (scaling out) را فراهم کند. از stampها می‌توان برای اجرای حلقه‌های (deployment rings) استفاده کرد. اگر مشتریان مختلف بخواهند به‌روزرسانی‌های سرویس‌ها را در زمان‌های مختلف دریافت کنند، می‌توان آن‌ها را در stampهای مختلف گروه‌بندی کرد و هر stamp می‌تواند به‌روزرسانی‌هایی را در وزن‌های متفاوتی داشته باشد. ازآنجاکه stampها به طور مستقل از یکدیگر اجرا می‌شوند، داده‌ها به طور ضمنی قطعه(shard) می‌شوند. علاوه بر این، یک stamp می‌تواند از shard شدن بیشتر داده‌ها استفاده کند تا به‌صورت داخلی امکان مقیاس‌پذیری و elasticity درون stamp را فراهم کند. الگوی deployment stamp به‌صورت داخلی توسط بسیاری از سرویس‌های Azure از جمله App Service، Azure Stack و Azure Storage استفاده می‌شود. ‏Deployment stamps با اینکه مربوط به geodes هستند، اما متمایز از آنها نیز هستند. در معماری Deployment stamps، چندین نمونه مستقل از سیستم شما Deploy می‌شوند که شامل زیرمجموعه‌ای از مشتریان و کاربران شما هستند. در geodes، همه نمونه‌ها می‌توانند درخواست‌های هر کاربر را ارائه دهند، اما این معماری اغلب برای طراحی و ساخت پیچیده‌تر است. همچنین ممکن است ترکیب دو الگو را در یک محلول در نظر بگیرید. رویکرد مسیریابی ترافیک که در زیر توضیح داده شده است نمونه‌ای از چنین سناریوی ترکیبی است.

 

Deployment

  به دلیل پیچیدگی که در deployment کپی‌های یکسان از اجزای یکسان وجود دارد، اقدامات خوب یک متخصص DevOps برای اطمینان از موفقیت در اجرای این الگو بسیار مهم است. در نظر بگیرید که زیرساخت خود را به‌صورت کد و اسکریپت‌ها توصیف کنید، مانند استفاده از قالب‌هایBicep, JSON Azure Resource Manager templates (ARM templates), Terraform. با این رویکرد، می‌توانید اطمینان حاصل کنید که deployment هر stamp قابل‌پیش‌بینی و تکرار است. همچنین احتمال خطاهای انسانی مانند عدم تطابق تصادفی در پیکربندی بین stampها را کاهش می‌دهد. می‌توانید به‌روزرسانی‌ها را به طور خودکار برای همه stampها به‌صورت موازی اجرا کنید، در این صورت ممکن است فناوری‌هایی مانند الگوهای Bicep یا Resource Manager را برای هماهنگ‌کردن deployment زیرساخت‌ها و برنامه‌های کاربردی خود در نظر بگیرید. از طرف دیگر، ممکن است تصمیم بگیرید ابتدا به‌روزرسانی‌ها را برای برخی از stampها و سپس به‌تدریج برای برخی دیگر به‌روزرسانی کنید. استفاده از یک ابزار مدیریت انتشار(release management) مانند Azure Pipelines یا GitHub Actions را برای هماهنگ‌کردن Deploymentها در هر stamp در نظر بگیرید. برای اطلاعات بیشتر:

  ‏- ‏Integrate Bicep with Azure Pipelines

  ‏- ‏Integrate JSON ARM templates with Azure Pipelines

  توپولوژی اشتراک‌های (subscriptions) در مورد Azure و resource groups را برای deployment خود بادقت در نظر بگیرید: *‏ به طور معمول یک اشتراک(subscription) شامل کلیه منابع برای یک راه‌حل واحد خواهد بود، بنابراین به‌طورکلی استفاده از یک اشتراک واحد برای همه stampها را در نظر بگیرید. بااین‌حال، برخی از سرویس‌های Azure سهمیه‌های گسترده‌ای را تحمیل (Azure services impose subscription-wide quotas) می‌کنند، بنابراین اگر از این الگوی استفاده می‌کنید تا درجه بالایی از مقیاس را فراهم کنید، ممکن است لازم باشد که stampها را در اشتراک‌های مختلف در نظر بگیرید.

 

• Resource groupها به‌طورکلی برای deployment اجزای مختلف با چرخه عمر مشخص استفاده می‌شوند. اگر قصد دارید به طور هم‌زمان به‌روزرسانی‌ها را برای همه stampهای خود deploy کنید، استفاده از یک منبع گروهی منفرد (single resource group) را در نظر بگیرید تا تمام اجزای مختلف را برای همه stampهای خود داشته باشید و از قراردادها و برچسب‌های نام‌گذاری منابع استفاده کنید تا مؤلفه‌هایی را که متعلق به هر stamp هستند، شناسایی کنید. از طرف دیگر، اگر قصد دارید به‌روزرسانی‌های هر stamp را به طور مستقل مستقر کنید، در نظر بگیرید که هر stamp را در resource group خود deploy کنید.

   

برنامه‌ریزی ظرفیت

  از آزمایش‌های مربوط به load و کارایی برنامه برای تعیین تقریبی load که یک stamp معین می‌تواند تحمل کند، استفاده کنید. متریک‌های مربوط به load ممکن است بر اساس تعداد customers/tenantهایی باشد که یک stamp می‌تواند در خود جای دهد یا متریک‌های مربوط به سرویس‌هایی که اجزای درونی stamp منتشر می‌کنند. اطمینان حاصل کنید که ابزار کافی برای اندازه‌گیری زمانی که یک stamp به ظرفیت نهایی خود نزدیک شده است به همراه توانایی deployment سریع stampهای جدید برای پاسخگویی به تقاضا را دارید.

 

مسیریابی ترافیک

  الگوی Deployment Stamp اگر به هر stamp به طور مستقل پرداخته شود، به‌خوبی کار می‌کند. به‌عنوان‌مثال، اگر شرکتی خاص مثلاً شرکت Contoso یک برنامه API یکسان را در چند stamp deploy کند، ممکن است استفاده از DNS را برای هدایت ترافیک به stamp مربوطه در نظر بگیرد: *‏ ‏unit1.aus.myapi.contoso.com ترافیک را به سمت stamp unit1 در یک منطقه استرالیا هدایت می‌کند.

  *‏ ‏unit2.aus.myapi.contoso.com ترافیک را به سمت stamp unit2 در یک منطقه استرالیا هدایت می‌کند.

  *‏ ‏unit1.eu.myapi.contoso.com ترافیک را به سمت stamp unit1 در یک منطقه اروپایی هدایت می‌کند.

  سپس کلاینت‌ها مسئول اتصال به stamp صحیح هستند. اگر یک نقطه ورودی (ingress) یکسان برای تمام ترافیک عبوری موردنیاز باشد، می‌توان از سرویس مسیریابی ترافیک(traffic routing) برای رفع stamp مربوط به request، مشتری یا tenant استفاده کرد. سرویس مسیریابی ترافیک، مشتری را به URL مربوطه برای stamp هدایت می‌کند (به‌عنوان‌مثال، با استفاده از کد وضعیت پاسخ HTTP 302) یا ممکن است به‌عنوان یک پروکسی معکوس(reverse proxy) عمل کرده و ترافیک را بدون اطلاع مشتری به stamp مربوطه ارسال کند. یک سرویس مسیریابی ترافیک متمرکز می‌تواند جزء پیچیده‌ای برای طراحی باشد، به‌خصوص زمانی که یک راه‌حل در چندین منطقه اجرا می‌شود. مستقر کردن سرویس مسیریابی ترافیک را در چندین منطقه در نظر بگیرید (به طور بالقوه شامل هر منطقه‌ای که stampها در آن مستقر شده‌اند) و سپس اطمینان حاصل کنید که ذخیره داده (نگاشت tenant به stamp) به طور مناسبی هماهنگ‌سازی(synchronized) شده است. مؤلفه مسیریابی ترافیک ممکن است خود نمونه‌ای از الگوی geode باشد. به‌عنوان‌مثال، Azure API Management می‌تواند برای عمل در نقش سرویس مسیریابی ترافیک deploy شود. این گزینه می‌تواند با جستجوی داده‌ها در مجموعه Azure Cosmos DBکه نگاشت(mapping) بین tenantها و stampها را ذخیره می‌کند و در نتیجه stamp مناسب را برای درخواست‌کردن تعیین کند. سپس API Management می‌تواند به‌صورت پویا URL بک‌اند(dynamically set the back-end URL) را روی سرویس API stamp مربوطه تنظیم کند. برای فعال‌کردن توزیع جغرافیایی (geo-distribution) درخواست‌ها و افزونگی جغرافیایی(geo-redundancy) سرویس مسیریابی ترافیک، API Management را می‌توان در چندین منطقه deploy کرد یا از Azure Front Door برای هدایت ترافیک به نزدیک‌ترین نمونه(instance) استفاده کرد. Front Door را می‌توان با یک backend pool پیکربندی کرد و درخواست‌ها را به نزدیک‌ترین نمونه API Management موجود هدایت کرد. اگر برنامه شما از طریق HTTP/S نمایش یا در معرض قرار داده نمی‌شود، می‌توانید از متعادل‌کننده بار Azure بین‌منطقه‌ای(cross-region Azure Load Balancer) برای توزیع تماس‌های دریافتی بین Azure Load Balancer منطقه‌ای استفاده کنید. از ویژگیglobal distribution feature of Azure Cosmos DB می‌توان برای به‌روز نگه‌داشتن اطلاعات نگاشت شده (mapping) در هر منطقه استفاده کرد. اگر یک سرویس مسیریابی ترافیک (traffic-routing) در راه‌حل مورداستفاده شما گنجانده شده است حتماً در نظر بگیرید که آیا به‌عنوان یک gateway عمل می‌کند؟ بنابراین می‌تواند (gateway offloading) را برای سرویس‌های دیگری مانند احراز هویت (authorization) یا throttling و اعتبارسنجی (validation) انجام دهد.

 

نمونه معماری مسیریابی ترافیک

نمونه زیر معماری مسیریابی ترافیک زیر را در نظر بگیرید که از Azure Front Door، Azure API Management و Azure Cosmos DB برای مسیریابی ترافیک سراسری و سپس یک سری از stampهای خاص منطقه استفاده می‌کند:

 

  فرض کنید یک کاربر به طور معمول در نیویورک زندگی می‌کند. داده‌های آنها در stamp 3، در منطقه شرق ایالات متحده ذخیره می‌شود. اگر کاربر به کالیفرنیا سفر کند و سپس به سیستم دسترسی پیدا کند، احتمالاً ارتباط آنها از طریق منطقه West US 2 انجام می‌شود؛ زیرا در هنگام درخواست(request)، این منطقه از نظر جغرافیایی نزدیک‌ترین مکان است. بااین‌حال، درخواست در نهایت باید با stamp 3 ارائه شود، زیرا داده‌های آنها در آنجا ذخیره می‌شود. سیستم مسیریابی ترافیک، اطمینان حاصل می‌کند که درخواست به stamp صحیح هدایت می‌شود.

 

مسائل و ملاحظات

  هنگام تصمیم‌گیری در مورد نحوه اجرای این الگو باید نکات زیر را در نظر بگیرید: ‏ فرایندهای ‏Deployment*. هنگام مستقر کردن چندین stamp، بسیار توصیه می‌شود که فرایندهای deployment خودکار و کاملاً تکرارشونده داشته باشید. استفاده از Bicep, JSON ARM templatesیا ماژول‌های Terraform را در نظر بگیرید تا stamp را به‌صورت ثابت تعریف کنید.

  ‏ عملیات ‏Cross-stamp*. هنگامی که راه‌حل شما به طور مستقل در چندین stamp،‏ مستقر می‌شود، سؤالاتی مانند: «چند مشتری در تمام stampهایمان داریم؟» پاسخ‌دادن را می‌تواند پیچیده‌تر شود. ممکن است لازم باشد کوئری در مقابل هر stamp اجرا شوند و نتیجه‌ها یک‌پارچه شوند. همین‌طور، در نظر بگیرید که تمام stampها داده‌ها را در یک انبار داده(data warehouse) متمرکز برای گزارش منتشر کنند.

  ‏ تعیین خط‌مشی‌های scale-out*. معمولاً ‏stampها ظرفیت محدودی دارند که ممکن است با استفاده از یک متریک یا معیار پراکسی مانند تعدادی tenantهایی که می‌توانند روی stamp،‏ مستقر شوند، تعریف شود. نظارت بر ظرفیت موجود و ظرفیت مورداستفاده برای هر stamp و به‌کارگیری فعال stampهای اضافی برای اجازه‌دادن به فعالیت tenantهای جدید که به سمت آنها هدایت شود بسیار مهم است.

  ‏ حداقل‏ stampها*. هنگامی که از الگوی Deployment Stamp استفاده می‌کنید، توصیه می‌شود حداقل دو stamp از راه‌حل موردنظر خود را مستقر کنید. اگر فقط یک stamp را به کار می‌گیرید، به‌راحتی می‌توانید مفروضاتی را به طور تصادفی در کد یا پیکربندی خود hard-code کنید که در زمان scale out اعمال و اجرا نمی‌شوند.

  ‏ هزینه*. الگوی Deployment Stamp شامل استقرار چندین نسخه از مؤلفه زیرساخت شما است که احتمالاً شامل افزایش قابل‌توجهی در هزینه راه‌حل موردنظر شما خواهد بود.

  ‏ حرکت بین stampها.* ازآنجایی‌که هر stamp به طور مستقل مستقر شده و کار می‌کند، جابه‌جایی tenantها بین stampها می‌تواند دشوار باشد. برنامه شما به منطق سفارشی نیاز دارد تا اطلاعات مربوط به یک مشتری خاص را به stamp دیگری منتقل کند و سپس اطلاعات tenant را از stamp اصلی حذف کند. این فرایند ممکن است به یک صفحه پشتی(backplane) برای ارتباط بین stampها نیاز داشته باشد که پیچیدگی راه‌حل کلی را بیشتر می‌کند.

  ‏ مسیریابی*. همان‌طور که در بالا توضیح داده شد، مسیریابی ترافیکی به stamp صحیح برای یک درخواست معین می‌تواند به یک مؤلفه اضافی برای حل‌وفصل tenantها به stampها نیاز داشته باشد. این مؤلفه، به نوبه خود، ممکن است نیاز داشته باشد که به‌شدت قابل‌دسترس (highly available) باشد.

  ‏ اجزای مشترک(Shared components).* ممکن است اجزایی داشته باشید که بتوان آنها را در stampها به اشتراک گذاشت. به‌عنوان‌مثال، اگر یک برنامه تک‌صفحه‌ای مشترک(shared single-page app) برای همه tenantها دارید، آن را در یک منطقه deploy کنید و از Azure CDN برای تکثیر (replica) آن در سطح جهانی استفاده کنید.

   

چه زمانی از این الگو استفاده کنیم؟

  این الگو زمانی مفید است که: ‏ محدودیت‌های طبیعی در مقیاس‌پذیری.* به‌عنوان‌مثال، اگر برخی از مؤلفه‌ها نمی‌توانند یا نباید از تعداد معینی مشتری یا درخواست به مقدار بیشتری scale شوند پس بهتر است با استفاده از stampها گزینه scaling out را در نظر بگیرید.

  ‏ الزامی برای جداسازی برخی tenantها از دیگران*. اگر مشتریانی دارید که به دلیل نگرانی‌های امنیتی نمی‌توانند در یک stamp چند tenant ای با مشتریان دیگر مستقر شوند، می‌توانند روی stamp جدا شده خودشان مستقر شوند.

  *‏ نیاز به داشتن چند tenant در نسخه‌های مختلف، به طور هم‌زمان.

  *‏ برنامه‌های باقابلیت اجرای چندمنطقه‌ای که در آن داده‌ها و ترافیک هر tenant باید به یک منطقه خاص هدایت شود.

  *‏ دستیابی به انعطاف‌پذیری در هنگام خاموشی یا قطع برق (outages). ازآنجایی‌که stampها مستقل از یکدیگر هستند، اگر قطعی یک stamp را تحت‌تأثیر قرار دهد، tenantها که در stampهای دیگر deploy شده‌اند نباید تحت‌تأثیر قرار گیرند. این جداسازی به مهار «شعاع انفجار(blast radius)» یک حادثه یا قطعی برق/خاموشی کمک می‌کند.

  این الگو برای موارد زیر مناسب نیست: *‏ راه‌حل‌های ساده‌ای که نیازی به مقیاس‌دهی یا scale در درجه بالایی ندارند.

  *‏ سیستم‌هایی که می‌توانند به‌راحتی در یک نمونه ساده scaled out یا scaled up شوند، مانند افزایش اندازه لایه برنامه یا با افزایش ظرفیت رزرو شده برای پایگاه‌های داده و لایه ذخیره‌سازی.

  *‏ راه‌حل‌هایی که در آن داده‌ها باید در تمام نمونه‌های مستقر شده تکرار شوند. الگوی geode را برای این سناریو در نظر بگیرید.

  *‏ راه‌حل‌هایی که در آنها فقط برخی از مؤلفه‌ها باید scale شوند، اما برخی دیگر نه. به‌عنوان‌مثال، در نظر بگیرید که آیا راه‌حل شما می‌تواند با sharding data store به‌جای استقرار یک کپی جدید از تمام اجزای راه‌حل، مقیاس‌دهی شود.

  *‏ راه‌حل‌های موجود برای محتوای استاتیک یا ثابت، مانند یک برنامه JavaScript از نوع front-end تشکیل شده‌اند. برای ذخیره چنین محتوایی در یک storage account و استفاده از Azure CDN را در نظر بگیرید.

 

تکنولوژی‌‌های مورد استفاده

*‏ به‌عنوان‌مثال Infrastructure as code مواردی مثل Resource Manager templates Bicep، Manager، Azure CLI، Terraform، PowerShell، Bash را می‌توان استفاده کرد.

  *‏ ‏Azure Front Door که می‌تواند ترافیک را به یک stamp خاص یا به یک سرویس مسیریابی ترافیک هدایت کند.

 

مثال

  مثال زیر چندین stamp از یک راه‌حل ساده PaaS را با یک سرویس app و یک پایگاه‌داده SQL در هر stamp ، مستقر می‌کند. درحالی‌که stampها را می‌توان در هر منطقه‌ای پیکربندی کرد که از سرویس‌های مستقر شده در الگوی موردنظر پشتیبانی می‌کند. به‌منظور تصور بهتر، این الگو دو stamp را در منطقه ۲ در غرب آمریکا و یک stamp دیگر را در منطقه غرب اروپا مستقر می‌کند. در داخل یک stamp، سرویس برنامه نام میزبان DNS عمومی خود را دریافت می‌کند و می‌تواند اتصالات را مستقل از سایر stampها دریافت کند.

 

هشدار
مثال زیر از SQL Server administrator account استفاده می‌کند. به‌طورکلی استفاده از یک حساب کاربری مدیریتی از برنامه شما کار خوبی نیست. برای یک برنامه واقعی، از یک احراز هویت مدیریت شده برای اتصال از برنامه خود به [پایگاه‌داده SQL استفاده]([database](https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi)) کرده یا از یک حساب با حداقل دسترسی استفاده کنید.

  برای deployment این راه‌حل روی لینک زیر کلیک کنید.

   

توجه داشته باشید
روش‌های جایگزینی برای deployment stampها با الگوی Resource Manager وجود دارد، از جمله استفاده از [الگوهای تودرتو]([nested templates](https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-linked-templates#nested-template)) یا [الگوهای پیوندی](https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-linked-templates#linked-template) برای جداکردن مشخصات هر stamp از تکرار موردنیاز برای مستقر کردن چندین نسخه از برنامه استفاده کنید.

 

Example traffic routing approach

  مثال زیر پیاده‌سازی راه‌حل مسیریابی ترافیک (traffic routing) را به کار می‌گیرد که می‌تواند با مجموعه‌ای از stampهای مستقر شده برای یک برنامه API فرضی استفاده شود. برای اجازه‌دادن به توزیع جغرافیایی درخواست‌های دریافتی، سرویس Front Door در کنار چندین نمونه از API Management در لایه مربوط به مصرف‌کننده deploy می‌شود. هر نمونه API Management شناسه tenant را از request URL می‌خواند و سپس stamp مربوط به request را از یک Azure Cosmos DB data store با توزیع جغرافیایی جستجو می‌کند. سپس درخواست به stamp پشتیبان مربوطه ارسال می‌شود. برای deployment راه‌حل بالا روی لینک زیر کلیک کنید.

 

مشارکت‌کنندگان

  این مقاله توسط مایکروسافت نگهداری می‌شود. در اصل توسط مشارکت‌کنندگان زیر نوشته شده است.

  Principal author:

 

• John Downs | Principal Customer Engineer, FastTrack for Azure

  Other contributors:

 

• Daniel Larsen | Principal Customer Engineer, FastTrack for Azure
• Angel Lopez | Senior Software Engineer, Azure Patterns and Practices
• Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

  To see non-public LinkedIn profiles, sign in to LinkedIn.

 

منابع مرتبط

  *‏ الگوی ‏Sharding می‌تواند به‌عنوان یک روش ساده برای scale out لایه مربوط به داده‌های شما استفاده شود. stampها به طور ضمنی داده‌های خود را shard می‌کنند، هر چند الگوی Sharding نیازی به الگوی Deployment Stamp ندارد. برای اطلاعات بیشتر، الگوی Sharding را ببینید.

  *‏ اگر یک سرویس مسیریابی ترافیک deploy شود، الگوهای Gateway Routing و Gateway Offloading می‌توانند با هم استفاده شوند تا بهترین استفاده را از این مؤلفه داشته باشند.