در دسترس بودن بالا در طراحی سایت چیست؟

به عنوان مثال، یک سرویس می‌تواند به درخواست‌های کاربر با صفحات وب استاتیک پاسخ دهد و رفتار پویا را که پردازش آن هزینه بیشتری دارد، موقتاً غیرفعال کند. این رفتار در الگوی شکست گرم از Compute Engine تا Cloud Storage به تفصیل آمده است. یا، این سرویس می‌تواند به عملیات فقط خواندنی اجازه دهد و به‌روزرسانی داده‌ها را موقتاً غیرفعال کند.

باید به اپراتورها اطلاع داده شود تا هنگام تنزل سرویس، وضعیت خطا را تصحیح کنند.

جلوگیری و کاهش افزایش ترافیک

درخواست ها را بین مشتریان همگام نکنید. تعداد زیادی از مشتریانی که ترافیک را در همان لحظه ارسال می کنند باعث افزایش ترافیک می شود که ممکن است باعث خرابی های آبشاری شود.

استراتژی‌های کاهش سنبله را در سمت سرور اجرا کنید، مانند throttling، صف‌بندی، کاهش بار یا قطع شدن مدار، تخریب زیبا و اولویت‌بندی درخواست‌های حیاتی.

استراتژی‌های کاهش در مشتری شامل مهار سمت مشتری و عقب‌نشینی نمایی با جیتر است.

ورودی ها را ضدعفونی و تأیید کنید

برای جلوگیری از ورودی‌های اشتباه، تصادفی یا مخرب که باعث قطع سرویس یا نقض امنیت می‌شوند، پارامترهای ورودی APIها و ابزارهای عملیاتی را پاکسازی و اعتبارسنجی کنید. به عنوان مثال، Apigee و Google Cloud Armor می توانند به محافظت در برابر حملات تزریق کمک کنند.

به طور منظم از تست فازی استفاده کنید، جایی که یک مهار تست عمداً APIهایی را با ورودی های تصادفی، خالی یا خیلی بزرگ فراخوانی می کند. این تست ها را در یک محیط تست ایزوله انجام دهید.

ابزارهای عملیاتی باید به طور خودکار تغییرات پیکربندی را قبل از اجرای تغییرات تأیید کنند و در صورت عدم موفقیت باید تغییرات را رد کنند.

ایمن از کار افتادن به گونه ای که عملکرد را حفظ کند

اگر به دلیل مشکلی نقصی وجود داشته باشد، اجزای سیستم باید به نحوی از کار بیفتند که به کل سیستم اجازه دهد به کار خود ادامه دهد. این مشکلات ممکن است یک اشکال نرم افزاری، ورودی یا پیکربندی نامناسب، قطعی نمونه برنامه ریزی نشده یا خطای انسانی باشد. فرآیند خدمات شما به تعیین اینکه آیا باید بیش از حد سهل‌گیرانه یا بیش از حد ساده‌گرا باشید، به جای اینکه بیش از حد محدودکننده باشید، کمک می‌کند.

سناریوهای نمونه زیر و نحوه پاسخگویی به شکست را در نظر بگیرید:

معمولاً بهتر است یک مؤلفه فایروال با پیکربندی بد یا خالی باز نشود و اجازه دهد ترافیک شبکه غیرمجاز برای مدت کوتاهی از آن عبور کند در حالی که اپراتور خطا را برطرف می کند. این رفتار سرویس را در دسترس نگه می‌دارد، نه اینکه شکست بخورد و 100% ترافیک مسدود شود. این سرویس باید به بررسی های احراز هویت و مجوز بیشتر در پشته برنامه تکیه کند تا در حین عبور تمام ترافیک از مناطق حساس محافظت کند.
با این حال، بهتر است یک جزء سرور مجوز که دسترسی به داده‌های کاربر را کنترل می‌کند بسته نشود و همه دسترسی‌ها را مسدود کند. این رفتار وقتی که پیکربندی خراب است باعث قطع سرویس می شود، اما از خطر نشت اطلاعات محرمانه کاربر در صورت باز نشدن آن جلوگیری می کند.
در هر دو مورد، خرابی باید یک هشدار با اولویت بالا ایجاد کند تا اپراتور بتواند شرایط خطا را برطرف کند. مؤلفه‌های سرویس باید در جهت باز نشدن خطا باشند، مگر اینکه خطرات شدیدی برای کسب‌وکار به همراه داشته باشد.

فراخوانی های API و دستورات عملیاتی را طوری طراحی کنید که قابل امتحان مجدد باشند

APIها و ابزارهای عملیاتی باید فراخوانی را تا آنجا که ممکن است ایمن کنند. یک رویکرد طبیعی برای بسیاری از شرایط خطا، تکرار عمل قبلی است، اما ممکن است ندانید که آیا اولین تلاش موفقیت آمیز بوده است یا خیر.

معماری سیستم یا طراحی سایت با معماری میکروسرویس شما باید اکشن‌ها را بی‌توان می‌سازد – اگر عمل یکسان را دو یا چند بار پشت سر هم روی یک شی انجام دهید، باید همان نتایجی را ایجاد کند که یک فراخوانی منفرد است. اقدامات غیر توانمند به کد پیچیده تری نیاز دارند تا از خراب شدن وضعیت سیستم جلوگیری شود.

وابستگی های سرویس را شناسایی و مدیریت کنید

طراحان و صاحبان خدمات باید فهرست کاملی از وابستگی ها به سایر اجزای سیستم را حفظ کنند. طراحی سرویس همچنین باید شامل بازیابی از خرابی‌های وابستگی، یا اگر بازیابی کامل امکان‌پذیر نباشد، کاهش قابل توجهی داشته باشد. وابستگی‌ها به سرویس‌های ابری استفاده شده توسط سیستم شما و وابستگی‌های خارجی، مانند APIهای سرویس شخص ثالث را در نظر بگیرید، با توجه به این که هر وابستگی سیستم دارای نرخ خرابی غیر صفر است.

هنگامی که اهداف قابلیت اطمینان را تعیین می کنید، متوجه شوید که SLO برای یک سرویس از نظر ریاضی توسط SLOهای همه وابستگی های حیاتی آن محدود شده است. شما نمی توانید از پایین ترین SLO یکی از وابستگی ها قابل اعتمادتر باشید. برای اطلاعات بیشتر، محاسبات در دسترس بودن خدمات را ببینید.

وابستگی های استارت آپی

خدمات در هنگام راه اندازی در مقایسه با رفتار حالت پایدارشان رفتار متفاوتی دارند. وابستگی های راه اندازی می تواند به طور قابل توجهی با وابستگی های زمان اجرا حالت پایدار متفاوت باشد.

به عنوان مثال، در هنگام راه اندازی، یک سرویس ممکن است نیاز به بارگیری اطلاعات کاربر یا حساب از یک سرویس فوق داده کاربر داشته باشد که به ندرت دوباره آن را فراخوانی می کند. هنگامی که بسیاری از کپی‌های سرویس پس از خرابی یا تعمیرات معمولی راه‌اندازی مجدد می‌شوند، کپی‌ها می‌توانند به شدت بار وابستگی‌های راه‌اندازی را افزایش دهند، به‌ ویژه زمانی که حافظه‌های پنهان خالی هستند و باید دوباره پر شوند.

راه‌اندازی و طراحی استارتاپ سرویس را تحت بار آزمایش کنید و وابستگی‌های راه‌اندازی را بر این اساس ارائه دهید. طرحی را در نظر بگیرید

o با ذخیره یک کپی از داده‌هایی که از وابستگی‌های حیاتی راه‌اندازی بازیابی می‌کند، به‌خوبی تنزل دهید. این رفتار به سرویس شما اجازه می‌دهد تا با داده‌های بالقوه قدیمی راه‌اندازی مجدد شود، نه اینکه وقتی یک وابستگی حیاتی قطع می‌شود، قادر به راه‌اندازی نباشد. سرویس شما می‌تواند بعداً در صورت امکان، داده‌های تازه را بارگیری کند تا به عملکرد عادی بازگردد.

هنگامی که یک سرویس را در یک محیط جدید بوت استرپ می کنید، وابستگی های راه اندازی نیز مهم هستند. پشته برنامه خود را با معماری لایه ای، بدون وابستگی چرخه ای بین لایه ها طراحی کنید. وابستگی‌های چرخه‌ای ممکن است قابل تحمل به نظر برسند زیرا تغییرات تدریجی یک برنامه را مسدود نمی‌کنند. با این حال، وابستگی‌های چرخه‌ای می‌تواند راه‌اندازی مجدد را پس از اینکه یک فاجعه کل پشته سرویس را از بین ببرد، دشوار یا غیرممکن کند.

وابستگی های حیاتی را به حداقل برسانید

تعداد وابستگی های حیاتی سرویس خود را به حداقل برسانید، یعنی سایر مؤلفه هایی که خرابی آنها به طور اجتناب ناپذیری باعث قطعی سرویس شما می شود. برای اینکه سرویس خود را در برابر خرابی یا کندی سایر مؤلفه‌ها مقاوم‌تر کنید، تکنیک‌ها و اصول طراحی سایت مثال زیر را برای تبدیل وابستگی‌های بحرانی به وابستگی‌های غیر بحرانی در نظر بگیرید:

سطح افزونگی را در وابستگی های بحرانی افزایش دهید. افزودن کپی های بیشتر احتمال اینکه یک جزء کامل در دسترس نباشد کمتر می شود.
به جای مسدود کردن پاسخ، از درخواست‌های ناهمزمان برای سرویس‌های دیگر استفاده کنید یا از پیام‌های انتشار/اشتراک برای جدا کردن درخواست‌ها از پاسخ‌ها استفاده کنید.
پاسخ‌های کش از سایر سرویس‌ها برای بازیابی از عدم دسترسی کوتاه مدت وابستگی‌ها.
برای اینکه خرابی یا کندی سرویس شما برای سایر اجزای وابسته به آن آسیب کمتری داشته باشد، تکنیک ها و اصول طراحی مثال زیر را در نظر بگیرید:

از صف‌های درخواست اولویت‌دار استفاده کنید و به درخواست‌هایی که کاربر منتظر پاسخ است، اولویت بیشتری بدهید.
برای کاهش تأخیر و بارگذاری، پاسخ‌ها را از حافظه پنهان ارائه کنید.
ایمن از کار افتادن به گونه ای که عملکرد را حفظ کند.
هنگامی که ترافیک بیش از حد وجود دارد، به زیبایی تنزل دهید.
اطمینان حاصل کنید که هر تغییری را می توان به عقب برگرداند
اگر هیچ راه مشخصی برای لغو انواع خاصی از تغییرات در یک سرویس وجود ندارد، طراحی سرویس را برای پشتیبانی از بازگشت تغییر دهید. فرآیندهای برگشتی را به صورت دوره ای آزمایش کنید. APIها برای هر مؤلفه یا میکروسرویس باید نسخه‌بندی شوند، با سازگاری عقب مانده به‌گونه‌ای که نسل‌های قبلی کلاینت‌ها به درستی کار خود را با تکامل API ادامه دهند. این اصل طراحی برای اجازه دادن به گسترش تدریجی تغییرات API با بازگشت سریع در صورت لزوم ضروری است.

پیاده سازی بازگشت مجدد برای برنامه های موبایل می تواند پرهزینه باشد. Firebase Remote Config یک سرویس Google Cloud برای آسان‌تر کردن بازگشت ویژگی است.

شما نمی توانید به راحتی تغییرات طرحواره پایگاه داده را برگردانید، بنابراین آنها را در چند مرحله اجرا کنید. هر مرحله را طوری طراحی کنید که امکان خواندن و به‌روزرسانی درخواست‌های طرحواره ایمن توسط آخرین نسخه برنامه شما و نسخه قبلی را فراهم کند. این رویکرد طراحی به شما امکان می دهد در صورت بروز مشکل در آخرین نسخه، با خیال راحت به عقب برگردید.

توصیه ها

برای اعمال راهنمایی در چارچوب معماری در محیط خود، این توصیه ها را دنبال کنید:

1. پیاده‌سازی عقب‌نشینی نمایی با تصادفی‌سازی در منطق تکرار خطای برنامه‌های مشتری.
2. یک معماری چند منطقه ای با failover خودکار برای دسترسی بالا پیاده سازی کنید.
3. از توازن بار برای توزیع درخواست های کاربر در قسمت ها و مناطق استفاده کنید.
4. برنامه را به گونه ای طراحی کنید که تحت بار اضافه به خوبی کاهش یابد. به جای شکست کامل، پاسخ های جزئی را ارائه دهید یا عملکرد محدودی ارائه دهید.
5. یک فرآیند مبتنی بر داده برای برنامه ریزی ظرفیت ایجاد کنید و از آزمایش های بار و پیش بینی ترافیک برای تعیین زمان تهیه منابع استفاده کنید.
6. روش های بازیابی بلایا را ایجاد کنید و آنها را به صورت دوره ای آزمایش کنید.