استخدام التكرار الجغرافي لتصميم التطبيقات المتوفرة بشكل كبير

2025-05-09

توفر البنية الأساسية المستندة إلى السحابة مثل Azure Storage نظاما أساسيا متاحا للغاية ودائما لاستضافة البيانات والتطبيقات. يجب على مطوري التطبيقات المستندة إلى السحابة التفكير بعناية في كيفية الاستفادة من هذا النظام الأساسي لتحقيق أقصى قدر من هذه المزايا لمستخدميهم. يوفر Azure Storage خيارات التكرار الجغرافي لضمان توفر عال حتى أثناء الانقطاع الإقليمي. يتم نسخ حسابات التخزين التي تم تكوينها للنسخ المتماثل المتكرر جغرافيًّا بشكل متزامن في المنطقة الأساسية، ويتم نسخها بشكل غير متزامن إلى منطقة ثانوية تبعد مئات الأميال.

توفر مساحة تخزين Azure خيارين للنسخ المتكرر الجغرافي: التخزين المتكرر الجغرافي (GRS) و التخزين المتكرر للمنطقة الجغرافية (GZRS). للاستفادة من خيارات التكرار الجغرافي ل Azure Storage، تأكد من تكوين حساب التخزين الخاص بك للتخزين المتكرر جغرافيا للوصول للقراءة (RA-GRS) أو التخزين المتكرر للمنطقة الجغرافية للوصول للقراءة (RA-GZRS). إذا لم يكن كذلك، يمكنك معرفة المزيد حول كيفية تغيير نوع النسخ المتماثل لحساب التخزين الخاص بك.

توضح هذه المقالة كيفية تصميم تطبيق سيستمر في العمل، وإن كان بسعة محدودة، حتى عندما يكون هناك انقطاع كبير في المنطقة الأساسية. إذا أصبحت المنطقة الأساسية غير متوفرة، يمكن للتطبيق الخاص بك التبديل بسلاسة لتنفيذ عمليات القراءة مقابل المنطقة الثانوية حتى تستجيب المنطقة الأساسية مرة أخرى.

اعتبارات تصميم التطبيق

يمكنك تصميم التطبيق الخاص بك لمعالجة الأخطاء العابرة أو الانقطاعات الكبيرة عن طريق القراءة من المنطقة الثانوية عندما تكون هناك مشكلة تتداخل مع القراءة من المنطقة الأساسية. عندما تتوفر المنطقة الأساسية مرة أخرى، يمكن للتطبيق الخاص بك العودة إلى القراءة من المنطقة الأساسية.

ضع في اعتبارك هذه الاعتبارات الرئيسية عند تصميم تطبيقك للتوفر والمرونة باستخدام RA-GRS أو RA-GZRS:

يتم نسخ نسخة للقراءة فقط من البيانات التي تخزنها في المنطقة الأساسية بشكل غير متزامن في منطقة ثانوية. يعني هذا النسخ المتماثل غير المتزامن أن النسخة للقراءة فقط في المنطقة الثانوية متسقة في النهاية مع البيانات الموجودة في المنطقة الأساسية. تحدد خدمة التخزين موقع المنطقة الثانوية.
يمكنك استخدام مكتبات عميل Azure Storage لتنفيذ طلبات القراءة والتحديث مقابل نقطة نهاية المنطقة الأساسية. إذا كانت المنطقة الأساسية غير متوفرة، يمكنك إعادة توجيه طلبات القراءة تلقائيا إلى المنطقة الثانوية. يمكنك أيضا تكوين تطبيقك لإرسال طلبات القراءة مباشرة إلى المنطقة الثانوية، إذا رغبت في ذلك، حتى عندما تكون المنطقة الأساسية متوفرة.
إذا أصبحت المنطقة الأساسية غير متوفرة، يمكنك بدء تجاوز فشل الحساب. عند تجاوز الفشل إلى المنطقة الثانوية، يتم تغيير إدخالات DNS التي تشير إلى المنطقة الأساسية للإشارة إلى المنطقة الثانوية. بعد اكتمال تجاوز الفشل، تتم استعادة الوصول للكتابة لحسابات GRS وحسابات RA-GRS. لمزيد من المعلومات، راجع حساب الإصلاح بعد كارثة والتخزين.

العمل مع بيانات متسقة في نهاية المطاف

يفترض الحل المقترح أنه من المقبول إرجاع البيانات التي يحتمل أن تكون قديمة إلى تطبيق الاستدعاء. نظرا لأن البيانات في المنطقة الثانوية متسقة في نهاية المطاف، فمن المحتمل أن تصبح المنطقة الأساسية غير قابلة للوصول قبل انتهاء التحديث إلى المنطقة الثانوية من النسخ المتماثل.

على سبيل المثال، افترض أن العميل يرسل تحديثا بنجاح، ولكن تفشل المنطقة الأساسية قبل نشر التحديث إلى المنطقة الثانوية. عندما يطلب العميل قراءة البيانات مرة أخرى، يتلقى البيانات القديمة من المنطقة الثانوية بدلا من البيانات المحدثة. عند تصميم التطبيق الخاص بك، يجب أن تقرر ما إذا كان هذا السلوك مقبولا أم لا. إذا كان الأمر كذلك، فستحتاج أيضا إلى التفكير في كيفية إعلام المستخدم.

لاحقا في هذه المقالة، ستتعرف على المزيد حول معالجة البيانات المتناسقة في النهاية وكيفية التحقق من خاصية آخر وقت مزامنة لتقييم أي تناقضات بين البيانات في المناطق الأساسية والثانوية.

التعامل مع الخدمات بشكل منفصل أو كلي معا

على الرغم من أنه من غير المحتمل أن تصبح إحدى الخدمات (الكائنات الثنائية كبيرة الحجم أو قوائم الانتظار أو الجداول أو الملفات) غير متوفرة بينما لا تزال الخدمات الأخرى تعمل بكامل طاقتها. يمكنك التعامل مع عمليات إعادة المحاولة لكل خدمة بشكل منفصل، أو يمكنك التعامل مع عمليات إعادة المحاولة بشكل عام لجميع خدمات التخزين معا.

على سبيل المثال، إذا كنت تستخدم قوائم الانتظار والكائنات الثنائية كبيرة الحجم في التطبيق الخاص بك، فقد تقرر وضع تعليمة برمجية منفصلة لمعالجة الأخطاء القابلة لإعادة المحاولة لكل خدمة. بهذه الطريقة، سيؤثر خطأ خدمة blob فقط على جزء التطبيق الخاص بك الذي يتعامل مع الكائنات الثنائية كبيرة الحجم، مما يترك قوائم الانتظار لمتابعة العمل كالمعتاد. ومع ذلك، إذا قررت معالجة جميع عمليات إعادة محاولة خدمة التخزين معا، فستتأثر طلبات كل من خدمات الكائنات الثنائية كبيرة الحجم وقائمة الانتظار إذا قامت أي من الخدمة بإرجاع خطأ قابل لإعادة المحاولة.

في نهاية المطاف، يعتمد هذا القرار على تعقيد التطبيق الخاص بك. قد تفضل معالجة حالات الفشل حسب الخدمة للحد من تأثير عمليات إعادة المحاولة. أو قد تقرر إعادة توجيه طلبات القراءة لجميع خدمات التخزين إلى المنطقة الثانوية عند اكتشاف مشكلة في أي خدمة تخزين في المنطقة الأساسية.

تشغيل التطبيق الخاص بك في وضع القراءة فقط

للتحضير بشكل فعال للانقطاع في المنطقة الأساسية، يجب أن يكون التطبيق الخاص بك قادرا على معالجة طلبات القراءة الفاشلة وطلبات التحديث الفاشلة. إذا فشلت المنطقة الأساسية، يمكن إعادة توجيه طلبات القراءة إلى المنطقة الثانوية. ومع ذلك، لا يمكن إعادة توجيه طلبات التحديث لأن البيانات المنسوخة نسخا متماثلا في المنطقة الثانوية للقراءة فقط. لهذا السبب، تحتاج إلى تصميم التطبيق الخاص بك لتكون قادرة على التشغيل في وضع القراءة فقط.

على سبيل المثال، يمكنك تعيين علامة تم التحقق منها قبل إرسال أي طلبات تحديث إلى Azure Storage. عندما يأتي طلب تحديث، يمكنك تخطي الطلب وإرجاع استجابة مناسبة للمستخدم. يمكنك حتى اختيار تعطيل ميزات معينة تماما حتى يتم حل المشكلة، وإعلام المستخدمين بأن الميزات غير متوفرة مؤقتا.

إذا قررت معالجة الأخطاء لكل خدمة بشكل منفصل، فستحتاج أيضا إلى التعامل مع القدرة على تشغيل تطبيقك في وضع القراءة فقط حسب الخدمة. على سبيل المثال، يمكنك إعداد علامات للقراءة فقط لكل خدمة. ثم يمكنك تمكين أو تعطيل العلامات في التعليمات البرمجية، حسب الحاجة.

القدرة على تشغيل التطبيق الخاص بك في وضع القراءة فقط يمنحك أيضا القدرة على ضمان وظائف محدودة أثناء ترقية تطبيق رئيسي. يمكنك تشغيل التطبيق الخاص بك لتشغيله في وضع القراءة فقط والإشارة إلى مركز البيانات الثانوي، مما يضمن عدم وصول أي شخص إلى البيانات في المنطقة الأساسية أثناء إجراء الترقيات.

معالجة التحديثات عند التشغيل في وضع القراءة فقط

هناك العديد من الطرق لمعالجة طلبات التحديث عند التشغيل في وضع القراءة فقط. يركز هذا القسم على بعض الأنماط العامة التي يجب مراعاتها.

يمكنك الرد على المستخدم وإعلامه بأن طلبات التحديث لا تتم معالجتها حاليا. على سبيل المثال، يمكن لنظام إدارة جهات الاتصال تمكين المستخدمين من الوصول إلى معلومات جهة الاتصال ولكن دون إجراء تحديثات.
يمكنك إدراج التحديثات في منطقة أخرى. في هذه الحالة، يمكنك كتابة طلبات التحديث المعلقة إلى قائمة انتظار في منطقة مختلفة، ثم معالجة هذه الطلبات بعد أن يأتي مركز البيانات الأساسي عبر الإنترنت مرة أخرى. في هذا السيناريو، يجب إعلام المستخدم بأن طلب التحديث في قائمة الانتظار للمعالجة اللاحقة.
يمكنك كتابة التحديثات إلى حساب تخزين في منطقة أخرى. عندما تعود المنطقة الأساسية إلى الاتصال بالإنترنت، يمكنك دمج هذه التحديثات في البيانات الأساسية، اعتمادا على بنية البيانات. على سبيل المثال، إذا كنت تقوم بإنشاء ملفات منفصلة ذات طابع تاريخ/وقت في الاسم، يمكنك نسخ هذه الملفات مرة أخرى إلى المنطقة الأساسية. يمكن تطبيق هذا الحل على أحمال العمل مثل تسجيل الدخول وبيانات IoT.

معالجة عمليات إعادة المحاولة

يجب أن تكون التطبيقات التي تتصل بالخدمات التي تعمل في السحابة حساسة للأحداث والأخطاء غير المخطط لها التي يمكن أن تحدث. يمكن أن تكون هذه الأخطاء عابرة أو مستمرة، بدءا من فقدان الاتصال لحظيا إلى انقطاع كبير بسبب كارثة طبيعية. من المهم تصميم التطبيقات السحابية مع معالجة إعادة المحاولة المناسبة لتحقيق أقصى قدر من التوفر وتحسين استقرار التطبيق الكلي.

قراءة الطلبات

إذا أصبحت المنطقة الأساسية غير متوفرة، يمكن إعادة توجيه طلبات القراءة إلى التخزين الثانوي. كما ذكرنا سابقا، يجب أن يكون من المقبول أن يقرأ التطبيق الخاص بك بيانات قديمة. توفر مكتبة عميل Azure Storage خيارات لمعالجة عمليات إعادة المحاولة وإعادة توجيه طلبات القراءة إلى منطقة ثانوية.

في هذا المثال، يتم تكوين معالجة إعادة المحاولة لتخزين Blob في BlobClientOptions الفئة وسيتم تطبيقها على الكائن الذي BlobServiceClient نقوم بإنشائه باستخدام خيارات التكوين هذه. هذا التكوين هو نهج أساسي ثم ثانوي ، حيث تتم إعادة توجيه طلبات القراءة من المنطقة الأساسية إلى المنطقة الثانوية. وهذا النهج هو الأفضل عندما يتوقع أن تكون حالات الفشل في المنطقة الأساسية مؤقتة.

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob storage
BlobClientOptions blobClientOptions = new BlobClientOptions()
{
    Retry = {
        // The delay between retry attempts for a fixed approach or the delay
        // on which to base calculations for a backoff-based approach
        Delay = TimeSpan.FromSeconds(2),

        // The maximum number of retry attempts before giving up
        MaxRetries = 5,

        // The approach to use for calculating retry delays
        Mode = RetryMode.Exponential,

        // The maximum permissible delay between retry attempts
        MaxDelay = TimeSpan.FromSeconds(10)
    },

    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for 
    // GET or HEAD requests during retries.
    // If the status of the response from the secondary Uri is a 404, then subsequent retries
    // for the request will not use the secondary Uri again, as this indicates that the resource 
    // may not have propagated there yet.
    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
    GeoRedundantSecondaryUri = secondaryAccountUri
};

// Create a BlobServiceClient object using the configuration options above
BlobServiceClient blobServiceClient = new BlobServiceClient(primaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

إذا حددت أن المنطقة الأساسية من المحتمل أن تكون غير متوفرة لفترة طويلة من الوقت، يمكنك تكوين جميع طلبات القراءة للإشارة إلى المنطقة الثانوية. هذا التكوين هو نهج ثانوي فقط . كما تمت مناقشته سابقا، ستحتاج إلى استراتيجية للتعامل مع طلبات التحديث خلال هذا الوقت، وطريقة لإعلام المستخدمين بأنه تتم معالجة طلبات القراءة فقط. في هذا المثال، نقوم بإنشاء مثيل BlobServiceClient جديد يستخدم نقطة نهاية المنطقة الثانوية.

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Create a BlobServiceClient object pointed at the secondary Uri
// Use blobServiceClientSecondary only when issuing read requests, as secondary storage is read-only
BlobServiceClient blobServiceClientSecondary = new BlobServiceClient(secondaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

تعد معرفة متى يتم التبديل إلى وضع القراءة فقط والطلبات الثانوية فقط جزءا من نمط تصميم معماري يسمى نمط قاطع الدائرة، والذي ستتم مناقشته في قسم لاحق.

طلبات التحديث

لا يمكن إعادة توجيه طلبات التحديث إلى التخزين الثانوي، وهو للقراءة فقط. كما هو موضح سابقا، يجب أن يكون التطبيق الخاص بك قادرا على معالجة طلبات التحديث عندما تكون المنطقة الأساسية غير متوفرة.

يمكن أيضا تطبيق نمط قاطع الدائرة لتحديث الطلبات. لمعالجة أخطاء طلب التحديث، يمكنك تعيين حد في التعليمات البرمجية، مثل 10 حالات فشل متتالية، وتتبع عدد حالات الفشل للطلبات إلى المنطقة الأساسية. بمجرد استيفاء الحد، يمكنك تبديل التطبيق إلى وضع القراءة فقط بحيث لا يتم إصدار طلبات التحديث إلى المنطقة الأساسية.

كيفية تنفيذ نمط قاطع الدائرة

تعد معالجة حالات الفشل التي قد تستغرق وقتا متغيرا للتعافي منها جزءا من نمط تصميم معماري يسمى نمط قاطع الدائرة. يمكن أن يمنع التنفيذ السليم لهذا النمط التطبيق من محاولة تنفيذ عملية من المحتمل أن تفشل بشكل متكرر، وبالتالي تحسين استقرار التطبيق ومرونته.

أحد جوانب نمط قاطع الدائرة هو تحديد متى تكون هناك مشكلة مستمرة في نقطة النهاية الأساسية. لإجراء هذا التحديد، يمكنك مراقبة مدى تكرار مواجهة العميل لأخطاء قابلة لإعادة المحاولة. نظرا لأن كل سيناريو مختلف، تحتاج إلى تحديد حد مناسب لاستخدامه لقرار التبديل إلى نقطة النهاية الثانوية وتشغيل التطبيق في وضع القراءة فقط.

على سبيل المثال، يمكنك أن تقرر إجراء التبديل إذا كان هناك 10 حالات فشل متتالية في المنطقة الأساسية. يمكنك تعقب هذا عن طريق الاحتفاظ بعدد حالات الفشل في التعليمات البرمجية. إذا كان هناك نجاح قبل الوصول إلى الحد، فقم بتعيين العد مرة أخرى إلى الصفر. إذا وصل العدد إلى الحد، فبدل التطبيق لاستخدام المنطقة الثانوية لطلبات القراءة.

كنهج بديل، يمكنك أن تقرر تنفيذ مكون مراقبة مخصص في التطبيق الخاص بك. يمكن لهذا المكون الاتصال باستمرار بنقطة نهاية التخزين الأساسية الخاصة بك مع طلبات القراءة البسيطة (مثل قراءة كائن ثنائي كبير الحجم صغير) لتحديد صحته. ومن شأن هذا النهج أن يأخذ بعض الموارد، ولكن ليس قدرا كبيرا. عند اكتشاف مشكلة تصل إلى الحد الخاص بك، يمكنك التبديل إلى طلبات القراءة الثانوية فقط ووضع القراءة فقط. بالنسبة لهذا السيناريو، عند اختبار اتصال نقطة نهاية التخزين الأساسية بنجاح مرة أخرى، يمكنك التبديل مرة أخرى إلى المنطقة الأساسية ومتابعة السماح بالتحديثات.

قد يختلف حد الخطأ المستخدم لتحديد متى يتم إجراء التبديل من خدمة إلى أخرى داخل التطبيق الخاص بك، لذلك يجب أن تفكر في جعلها معلمات قابلة للتكوين.

هناك اعتبار آخر وهو كيفية التعامل مع مثيلات متعددة من التطبيق، وما يجب فعله عند اكتشاف أخطاء قابلة لإعادة المحاولة في كل مثيل. على سبيل المثال، قد يكون لديك 20 جهازا ظاهريا قيد التشغيل بنفس التطبيق المحمل. هل تتعامل مع كل مثيل بشكل منفصل؟ إذا بدأ مثيل واحد في مواجهة مشكلات، هل تريد تقييد الاستجابة إلى هذا المثيل الواحد فقط؟ أم تريد أن تستجيب جميع المثيلات بنفس الطريقة عندما يكون لدى مثيل واحد مشكلة؟ تعد معالجة المثيلات بشكل منفصل أبسط بكثير من محاولة تنسيق الاستجابة عبرها، ولكن سيعتمد نهجك على بنية التطبيق الخاص بك.

معالجة البيانات المتناسقة في النهاية

يعمل التخزين المتكرر جغرافيا عن طريق النسخ المتماثل للمعاملات من المنطقة الأساسية إلى المنطقة الثانوية. تضمن عملية النسخ المتماثل اتساق البيانات في المنطقة الثانوية في النهاية. وهذا يعني أن جميع المعاملات في المنطقة الأساسية ستظهر في النهاية في المنطقة الثانوية، ولكن قد يكون هناك تأخير قبل ظهورها. لا يوجد أيضا ما يضمن وصول المعاملات إلى المنطقة الثانوية بنفس الترتيب الذي تم تطبيقه في الأصل في المنطقة الأساسية. إذا وصلت معاملاتك إلى المنطقة الثانوية خارج الترتيب، فقد تعتبر بياناتك في المنطقة الثانوية في حالة غير متناسقة حتى اللحاق بالخدمة.

يوضح المثال التالي لتخزين Azure Table ما قد يحدث عند تحديث تفاصيل موظف لجعله عضوا في دور المسؤول. من أجل هذا المثال، يتطلب هذا تحديث كيان الموظف وتحديث كيان دور المسؤول بعدد إجمالي المسؤولين. لاحظ كيفية تطبيق التحديثات خارج الترتيب في المنطقة الثانوية.

الوقت	الحركة	نسخ متماثل	وقت المزامنة الأخير	النتيجة
T0	المعاملة أ: إدراج موظف الكيان في الأساسي			المعاملة أ المدرجة في الأساسي، لم يتم نسخها نسخا متماثلا بعد.
تي 1		المعاملة أ تم نسخه نسخا متماثلا إلى ثانوي	تي 1	المعاملة A المنسوخة نسخا متماثلا إلى ثانوية. تم تحديث وقت المزامنة الأخير.
T2	المعاملة ب: تحديث كيان الموظف في الأساسي		تي 1	المعاملة B المكتوبة إلى الأساسي، لم يتم نسخها نسخا متماثلا بعد.
T3	المعاملة ج: تحديث مدير كيان الدور في ابتدائي		تي 1	المعاملة C المكتوبة إلى الأساسي، لم يتم نسخها نسخا متماثلا بعد.
T4		المعاملة ج تم نسخه نسخا متماثلا إلى ثانوي	تي 1	المعاملة C المنسوخة نسخا متماثلا إلى ثانوية. لم يتم تحديث LastSyncTime بسبب لم يتم نسخ المعاملة B نسخا متماثلا بعد.
T5	قراءة الكيانات من الثانوي		تي 1	تحصل على القيمة القديمة للموظف الكيان لأن المعاملة B لم تقم النسخ المتماثل حتى الآن. تحصل على القيمة الجديدة ل كيان دور المسؤول لأن C لديه تكرارها. آخر وقت مزامنة لم يزل غير موجود تم تحديث لأن المعاملة B لم يتم نسخها نسخا متماثلا. يمكنك معرفة كيان دور المسؤول غير متناسق لأن تاريخ/وقت الكيان بعد وقت المزامنة الأخير.
T6		المعاملة ب تم نسخه نسخا متماثلا إلى ثانوي	T6	T6 – تحتوي جميع المعاملات من خلال C على تم نسخه نسخا متماثلا، وقت المزامنة الأخير تم تحديثه.

في هذا المثال، افترض أن العميل يتحول إلى القراءة من المنطقة الثانوية في T5. يمكنه قراءة كيان دور المسؤول بنجاح في هذا الوقت، ولكن يحتوي الكيان على قيمة لعدد المسؤولين غير المتناسقة مع عدد كيانات الموظفين التي تم وضع علامة عليها كمسؤولين في المنطقة الثانوية في هذا الوقت. يمكن لعميلك عرض هذه القيمة، مع خطر عدم تناسق المعلومات. بدلا من ذلك، يمكن للعميل محاولة تحديد أن دور المسؤول في حالة غير متناسقة محتملة لأن التحديثات قد حدثت خارج الترتيب، ثم إبلاغ المستخدم بهذه الحقيقة.

لتحديد ما إذا كان حساب التخزين يحتوي على بيانات غير متناسقة، يمكن للعميل التحقق من قيمة الخاصية Last Sync Time . يخبرك وقت المزامنة الأخير بوقت آخر تناسق للبيانات في المنطقة الثانوية ومتى كانت الخدمة قد طبقت جميع المعاملات قبل تلك النقطة الزمنية. في المثال الموضح أعلاه، بعد إدراج الخدمة كيان الموظف في المنطقة الثانوية، يتم تعيين وقت المزامنة الأخير إلى T1. يبقى في T1 حتى تقوم الخدمة بتحديث كيان الموظف في المنطقة الثانوية عند تعيينه إلى T6. إذا قام العميل باسترداد وقت المزامنة الأخير عند قراءة الكيان في T5، فيمكنه مقارنتها بالطوابع الزمنية على الكيان. إذا كان الطابع الزمني على الكيان أحدث من وقت المزامنة الأخير، فإن الكيان في حالة غير متناسقة محتملة، ويمكنك اتخاذ الإجراء المناسب. يتطلب استخدام هذا الحقل معرفة وقت اكتمال التحديث الأخير إلى الأساسي.

لمعرفة كيفية التحقق من وقت المزامنة الأخير، راجع التحقق من خاصية آخر وقت مزامنة لحساب تخزين.

الاختبار

من المهم اختبار أن التطبيق الخاص بك يتصرف كما هو متوقع عندما يواجه أخطاء قابلة لإعادة المحاولة. على سبيل المثال، تحتاج إلى اختبار أن التطبيق يتحول إلى المنطقة الثانوية عند اكتشاف مشكلة، ثم التبديل مرة أخرى عندما تصبح المنطقة الأساسية متاحة مرة أخرى. لاختبار هذا السلوك بشكل صحيح، تحتاج إلى طريقة لمحاكاة الأخطاء القابلة لإعادة المحاولة والتحكم في عدد مرات حدوثها.

أحد الخيارات هو استخدام Fiddler لاعتراض استجابات HTTP وتعديلها في برنامج نصي. يمكن لهذا البرنامج النصي تحديد الاستجابات التي تأتي من نقطة النهاية الأساسية وتغيير رمز حالة HTTP إلى استجابة تتعرف عليها مكتبة عميل التخزين كخطأ قابل لإعادة المحاولة. تعرض قصاصة التعليمات البرمجية هذه مثالا بسيطا لبرنامج نصي Fiddler يعترض الاستجابات لقراءة الطلبات مقابل جدول بيانات الموظف لإرجاع حالة 502:

static function OnBeforeResponse(oSession: Session) {
    ...
    if ((oSession.hostname == "\[YOURSTORAGEACCOUNTNAME\].table.core.windows.net")
      && (oSession.PathAndQuery.StartsWith("/employeedata?$filter"))) {
        oSession.responseCode = 502;
    }
}

يمكنك توسيع هذا المثال لاعتراض نطاق أوسع من الطلبات وتغيير responseCode فقط على بعضها لمحاكاة سيناريو العالم الحقيقي بشكل أفضل. لمزيد من المعلومات حول تخصيص البرامج النصية Fiddler، راجع تعديل طلب أو استجابة في وثائق Fiddler.

إذا قمت بإعداد حدود قابلة للتكوين لتبديل التطبيق الخاص بك إلى للقراءة فقط، فسيكون من الأسهل اختبار السلوك مع وحدات تخزين المعاملات غير الإنتاجية.

الخطوات التالية

للحصول على عينة كاملة توضح كيفية إجراء التبديل ذهابا وإيابا بين نقاط النهاية الأساسية والثانوية، راجع نماذج Azure - استخدام نمط قاطع الدائرة مع تخزين RA-GRS.