يتضمن نمط Geode توزيع مجموعة من خدمات الواجهة الخلفية في مجموعة من العقد الجغرافية، يمكن لكل منها خدمة أي طلب لأي عميل في أي منطقة. يسمح هذا النمط بتقديم الطلبات بأسلوب نشط-نشط، ما يحسن زمن الانتقال ويزيد من التوفر من خلال توزيع معالجة الطلبات في جميع أنحاء العالم.
السياق والمشكلة
تواجه العديد من الخدمات واسعة النطاق تحديات محددة حول التوفر الجغرافي والحجم. غالباً ما تجلب التصميمات الكلاسيكية البيانات إلى الحساب عن طريق تخزين البيانات في خادم SQL عن بعد يعمل كطبقة حساب لتلك البيانات، اعتمادًا على التوسع للنمو.
قد يقدم النهج الكلاسيكي عدداً من التحديات:
- مشكلات زمن انتقال الشبكة للمستخدمين القادمين من الجانب الآخر من العالم للاتصال بنقطة نهاية الاستضافة
- إدارة نسبة استخدام الشبكة لاندفاعات الطلب التي يمكن أن تطغى على الخدمات في منطقة واحدة
- تعقيد التكلفة الباهظة لتوزيع نسخ من البنية الأساسية للتطبيق في مناطق متعددة لخدمة على مدار الساعة طوال أيام الأسبوع
تطورت البنية الأساسية السحابية الحديثة لتمكين موازنة التحميل الجغرافي لخدمات الواجهة الأمامية، مع السماح بالنسخ المتماثل الجغرافي لخدمات الواجهة الخلفية. من أجل التوفر والأداء، يعد الاقتراب من البيانات من المستخدم جيداً. عندما يتم توزيع البيانات جغرافياً عبر قاعدة مستخدم بعيدة، يجب أيضاً تخصيص مخازن البيانات الموزعة جغرافياً مع موارد الحوسبة التي تعالج البيانات. يجلب نمط geode الحساب إلى البيانات.
حل
قم بتوزيع الخدمة في عدد من عمليات نشر الأقمار الصناعية المنتشرة في جميع أنحاء العالم، كل منها يسمى geode. يسخر نمط geode الميزات الرئيسية لـ Azure لتوجيه نسبة استخدام الشبكة عبر أقصر مسار إلى geode قريب، ما يحسن زمن الانتقال والأداء. كل geode خلف موازن تحميل عمومي، ويستخدم خدمة قراءة وكتابة منسوخة جغرافياً مثل Azure Cosmos DB لاستضافة مستوى البيانات، ما يضمن تناسق البيانات عبر geode. تضمن خدمات النسخ المتماثل للبيانات تطابق مخازن البيانات عبر المواقع الجغرافية، بحيث يمكن تقديم جميع الطلبات من جميع المواقع الجغرافية.
الفرق الرئيسي بين الخوادم المخصصة للتوزيع والموقع الجغرافي هو أن المواقع الجغرافية لا توجد أبدا في عزلة. يجب أن يكون هناك دائماً أكثر من موقع جغرافي واحد في نظام الإنتاج الأساسي.
تتميز المواقع الجغرافية بالخصائص التالية:
- تتكون من مجموعة من الأنواع المختلفة من الموارد، وغالباً ما يتم تعريفها في قالب.
- ليس لديك أي تبعيات خارج أثر الموقع الجغرافي وتكون قائمة بذاتها. لا يعتمد أي Geode على آخر للعمل، وإذا توقف أحدهم عن العمل، تستمر المواقع الأخرى في العمل.
- تقترن بشكل فضفاض عبر شبكة طرفية ولوحة معززة للنسخ المتماثل. على سبيل المثال، يمكنك استخدام Azure Traffic Manager أو Azure Front Door لواجهة المواقع الجغرافية، بينما يمكن أن يعمل Azure Cosmos DB كخلفية النسخ المتماثل. المواقع الجغرافية ليست هي نفسها المجموعات لأنها تشترك في قاعدة بيانات النسخ المتماثل، لذلك يعتني النظام الأساسي بمشكلات الحصة.
يحدث نمط Geode في بنيات البيانات الضخمة التي تستخدم أجهزة السلع لمعالجة البيانات المجمعة على نفس الجهاز، وMapReduce لدمج النتائج عبر الأجهزة. هناك استخدام آخر يتمثل في الحساب القريب من الحافة، ما يجعل الحساب أقرب إلى الحافة الذكية للشبكة لتقليل وقت الاستجابة.
يمكن للخدمات استخدام هذا النمط أكثر من عشرات أو مئات من أنماط Geode. علاوة على ذلك، تزداد مرونة الحل بأكمله مع كل Geode إضافي، حيث يمكن لأي مناطق جغرافية أن تتولى الأمر إذا كان الانقطاع الإقليمي يأخذ واحداً أو أكثر من المناطق الجغرافية دون اتصال بالإنترنت.
من الممكن أيضاً زيادة تقنيات التوفر المحلي، مثل مناطق التوفر أو المناطق المقترنة، مع نمط geode للتوفر العالمي. وهذا يزيد من التعقيد، ولكنه مفيد إذا كانت بنيتك مدعومة بمحرك تخزين، مثل تخزين كائن ثنائي كبير الحجم يمكن نسخه إلى منطقة مقترنة فقط. يمكنك توزيع مواقع Geode في بصمة داخل المنطقة أو منطقة إقليمية، مع مراعاة القيود التنظيمية أو قيود زمن الانتقال على الموقع.
المسائل والاعتبارات
استخدم التقنيات والأساليب التالية لتنفيذ هذا النمط:
- ممارسات وأدوات DevOps الحديثة لإنتاج وتوزيع مواقع جغرافية Geode متطابقة بسرعة عبر عدد كبير من المناطق أو المثيلات.
- التحجيم التلقائي لتوسيع نطاق مثيلات معدل نقل الحساب وقاعدة البيانات داخل geode. يتم توسيع نطاق كل geode بشكل فردي، ضمن قيود لوحة إلكترونية معززة مشتركة.
- خدمة الواجهة الأمامية مثل Azure Front Door التي تقوم بتسارع المحتوى الديناميكي، وتقسيم TCP، وتوجيه Anycast.
- مخزن بيانات مكرر، مثل Azure Cosmos DB للتحكم في تناسق البيانات.
- التقنيات بلا خادم حيثما أمكن ذلك، لتقليل تكلفة التوزيع دائما، خاصة عندما يتم إعادة توازن التحميل بشكل متكرر في جميع أنحاء العالم. تسمح هذه الاستراتيجية بتوزيع العديد من مواقع geodes بأقل قدر من الاستثمار الإضافي. تقلل تقنيات الفوترة بلا خادم والمستندة إلى الاستهلاك من النفايات والتكلفة الناتجة عن عمليات التوزيع الموزعة جغرافيًا المكررة.
- إدارة واجهة برمجة التطبيقات غير مطلوبة لتنفيذ نمط التصميم، ولكن يمكن إضافتها إلى كل geode التي تقدم تطبيق Azure Function في المنطقة لتوفير طبقة API أكثر قوة، ما يتيح تنفيذ وظائف إضافية مثل تحديد المعدل، على سبيل المثال.
راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:
- اختر ما إذا كنت تريد معالجة البيانات محلياً في كل منطقة، أو توزيع التجميعات في geode واحد ونسخ النتيجة نسخاً متماثلاً في جميع أنحاء العالم. يوفر معالج موجز تغيير Azure Cosmos DB عنصر التحكم متعدد المستويات هذا باستخدام مفهوم حاوية التأجير الخاص به، وprefix leasecollection في ربط Azure Functions المقابل. يتمتع كل نهج بمزاياه وعيوبه الخاصة.
- يمكن أن تعمل مواقع Geode جنباً إلى جنب، باستخدام موجز تغيير Azure Cosmos DB والنظام الأساسي للاتصال في الوقت الحقيقي مثل SignalR. يمكن لمواقع Geode التواصل مع المستخدمين عن بعد عبر مواقع جغرافية أخرى في نمط شبكة، دون معرفة مكان المستخدم البعيد أو الاهتمام به.
- يقوم نمط التصميم هذا بفصل كل شيء ضمنياً، ما يؤدي إلى بنية موزعة للغاية ومفصلة. ضع في اعتبارك كيفية تتبع المكونات المختلفة لنفس الطلب حيث قد يتم تنفيذها بشكل غير متزامن على مثيلات مختلفة. إن وضع استراتيجية رصد سليمة يشكل أمراً بالغ الأهمية. يمكن دمج كل من Azure Front Door وAzure Cosmos DB بسهولة مع Log Analytics ويجب نشر Azure Functions جنبا إلى جنب مع Application Insights لتوفير نظام مراقبة قوي في كل مكون في البنية.
- تحتوي عمليات النشر الموزعة على عدد أكبر من البيانات السرية ونقاط الدخول التي تتطلب تدابير أمان الخصائص. يوفر Key Vault طبقة آمنة للإدارة السرية ويجب تأمين كل طبقة داخل بنية واجهة برمجة التطبيقات بشكل صحيح بحيث تكون نقطة الدخول الوحيدة لواجهة برمجة التطبيقات هي خدمة الواجهة الأمامية، مثل Azure Front Door. يجب أن يقيد Azure Cosmos DB نسبة استخدام الشبكة إلى Azure Function Apps، وتطبيقات الوظائف إلى Azure Front Door باستخدام معرف Microsoft Entra أو ممارسات مثل تقييد IP.
- يتأثر الأداء بشكل كبير بعدد المواقع الجغرافية التي يتم توزيعها، وخطط خدمة التطبيقات المحددة المطبقة على تقنية واجهة برمجة التطبيقات في كل موقع geode. يأتي توزيع مواقع geode الإضافية أو الحركة نحو المستويات المتميزة مع زيادة التكاليف للذاكرة والحوسبة الإضافية، ولكن لا تفعل ذلك على أساس كل عملية. ضع في اعتبارك اختبار التحميل لبنية واجهة برمجة التطبيقات بمجرد توزيعها وتباينها في زيادة أعداد المواقع الجغرافية مع زيادة مستوى الأسعار بحيث يتم استخدام النموذج الأكثر كفاءة من حيث التكلفة لاحتياجاتك.
- تحديد متطلبات التوفر لبياناتك. يحتوي Azure Cosmos DB على علامات اختيارية لتمكين الكتابة متعددة المناطق ومناطق التوفر والمزيد. تزيد هذه التوفر لمثيل Azure Cosmos DB وتنشئ طبقة بيانات أكثر مرونة، ولكنها تأتي مع تكاليف إضافية.
- يقدم Azure مجموعة متنوعة من موازنات التحميل التي توفر وظائف مختلفة لتوزيع نسبة استخدام الشبكة. استخدم شجرة القرارات للمساعدة في تحديد الخيار الصحيح للواجهة الأمامية لواجهة برمجة التطبيقات.
موعد استخدام النمط
استخدم هذا النمط:
- لتنفيذ نظام أساسي واسع النطاق يحتوي على مستخدمين موزعين على مساحة واسعة.
- لأي خدمة تتطلب توفراً شديداً وخصائص مرونة، لأن الخدمات المستندة إلى نمط geode يمكن أن تنجو من فقدان مناطق خدمة متعددة في نفس الوقت.
قد لا يكون هذا النمط مناسبًا لـ
- البنى التي لها قيود بحيث لا يمكن أن تكون جميع المواقع الجغرافية مساوية لتخزين البيانات. على سبيل المثال، قد تكون هناك متطلبات موقع بيانات، أو تطبيق يحتاج إلى الحفاظ على حالة مؤقتة لجلسة معينة، أو ترجيح كبير للطلبات نحو منطقة واحدة. في هذه الحالة، ضع في اعتبارك استخدام خوادم مخصصة للتوزيع مع مستوى توجيه عمومي على علم بمكان وجود بيانات المستخدم، مثل مكون توجيه نسبة استخدام الشبكة الموضح ضمن نمط خوادم التوزيع المخصصة.
- الحالات التي لا يكون فيها التوزيع الجغرافي مطلوباً. بدلاً من ذلك، ضع في اعتبارك مناطق التوفر والمناطق المقترنة لتكوين أنظمة المجموعات.
- الحالات التي يحتاج فيها نظام أساسي قديم إلى إعادة التجهيز. يعمل هذا النمط للتطوير السحابي الأصلي فقط، وقد يكون من الصعب تحديثه.
- البنيات والمتطلبات البسيطة، حيث لا يكون التكرار الجغرافي والتوزيع الجغرافي مطلوباً أو مفيداً.
تصميم حمل العمل
يجب على المهندس المعماري تقييم كيفية استخدام نمط Geode في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:
الركيزة | كيف يدعم هذا النمط أهداف الركيزة |
---|---|
تساعد قرارات تصميم الموثوقية حمل العمل الخاص بك على الصمود في وجه الخلل وضمان استرداده إلى حالة تعمل بشكل كامل بعد حدوث فشل. | يستخدم هذا النمط النسخ المتماثل للبيانات لدعم المثالية التي يمكن لأي عميل الاتصال بأي مثيل جغرافي ومن خلال القيام بذلك يمكن أن يساعد حمل العمل الخاص بك على تحمل انقطاع إقليمي واحد أو أكثر. - RE:05 تصميم متعدد المناطق عالي التوفر - مناطق RE:05 ومناطق التوفر |
تساعد كفاءة الأداء حمل العمل الخاص بك على تلبية الطلبات بكفاءة من خلال التحسينات في التحجيم والبيانات والرمز. | يمكنك استخدام هذا النمط لخدمة التطبيق الخاص بك من منطقة الأقرب إلى قاعدة المستخدمين الموزعة. يؤدي القيام بذلك إلى تقليل زمن الانتقال عن طريق القضاء على حركة المرور لمسافات طويلة ولأنك تشارك البنية الأساسية فقط بين المستخدمين الذين يستخدمون حاليا نفس geode. - PE:03 تحديد الخدمات |
كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.
الأمثلة
- ينفذ Windows Active Directory متغيرًا مبكراً لهذا النمط. يعني النسخ المتعدد الأساسي أنه يمكن تقديم جميع التحديثات والطلبات نظريًا من جميع العقد القابلة للخدمة، لكن أدوار التشغيل الرئيسي الفردي المرن (FSMO) تعني أن جميع مواقع geode ليست متساوية.
- يعرض مسرع نمط geode على GitHub نمط التصميم هذا في الممارسة العملية، وهو مصمم لمساعدة المطورين على تنفيذه باستخدام واجهات برمجة التطبيقات في العالم الحقيقي.