مشاركة عبر

توصيات للتصميم من أجل البساطة والكفاءة

  • مقالة

ينطبق على توصية قائمة التحقق من موثوقية Azure Well-Architected Framework هذه:

RE:01 تصميم حمل العمل الخاص بك لتتماشى مع أهداف العمل وتجنب التعقيد أو النفقات العامة غير الضرورية. استخدم نهجا عمليا ومتوازنا لاتخاذ قرارات التصميم التي تحقق النتائج المرجوة. تحتوي على تصميمك على الضروريات لتقليل أوجه القصور والمشاكل المحتملة.

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

التعريفات

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

استراتيجيات التصميم الرئيسية

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

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

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

تمارين التصميم التعاوني

العمل مع المساهمين من أجل:

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

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

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

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

  • حدد أهداف التوفر والاسترداد لتدفقاتك لإعلام بنية حمل العمل الخاص بك. تتضمن مقاييس الأعمال أهداف مستوى الخدمة (SLOs) واتفاقيات مستوى الخدمة (SLAs) ومتوسط وقت الاسترداد (MTTR) و متوسط الوقت بين الفشل (MTBF) وأهداف وقت الاسترداد (RTOs) وأهداف نقطة الاسترداد (RPOs). حدد القيم المستهدفة لهذه المقاييس. قد يتطلب هذا التمرين حلا وسطا وفهما متبادلا بين فرق التكنولوجيا والأعمال لضمان أن تحقق أهداف كل فريق أهداف العمل وواقعية. لمزيد من المعلومات، راجع توصيات تحديد أهداف الموثوقية.

توصيات تصميم إضافية

يمكنك تنفيذ التوصيات التالية دون مشاركة المساهمين:

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

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

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

  • استخدم المراسلة غير المتزامنة لفصل منتج الرسالة عن المستهلك.

  • البنية الأساسية المجردة بعيداً عن منطق المجال. تأكد من أن منطق المجال لا يتداخل مع الوظائف المتعلقة بالبنية الأساسية، مثل المراسلة أو الاستمرار.

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

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

تطوير تعليمة برمجية كافية فقط

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

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

  • استخدام المكتبات وأطر العمل.

  • تقديم البرمجة المزدوجة أو جلسات مراجعة التعليمات البرمجية المخصصة كممارسة تطوير.

  • تنفيذ نهج لتحديد التعليمات البرمجية غير المستخدمة. كن متشككا في التعليمات البرمجية التي لا تغطيها اختباراتك التلقائية.

استخدم أفضل مخزن بيانات لبياناتك

في الماضي، قامت العديد من المنظمات بتخزين جميع بياناتها في قواعد بيانات SQL الارتباطية الكبيرة. توفر قواعد البيانات الارتباطية ضمانات ذرية ومتسقة ومعزولة ودائمة (ACID) لمعاملات البيانات الارتباطية. ولكن قواعد البيانات هذه تأتي مع عيوب:

  • قد تتطلب الاستفسارات ارتباطات باهظة الثمن.

  • تحتاج إلى تطبيع البيانات وإعادة هيكلتها للمخطط المكتوب.

  • يمكن أن يؤثر القفل على الأداء.

بدائل قواعد البيانات الارتباطية

في حل كبير، من المحتمل ألا تلبي تقنية مخزن بيانات واحدة جميع احتياجاتك. تشمل بدائل قواعد البيانات الارتباطية ما يلي:

  • مخازن قيم المفتاح

  • قواعد بيانات الوثائق

  • قواعد بيانات محرك البحث

  • قواعد بيانات السلاسل الزمنية

  • قواعد بيانات فئة الأعمدة

  • قواعد بيانات الرسم البياني

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

على سبيل المثال، يمكنك تخزين كتالوج المنتجات في قاعدة بيانات المستندات، مثل Azure Cosmos DB، الذي يدعم مخططًا مرنًا. كل وصف منتج هو مستند قائم بذاته. للاستعلام عن الكتالوج بأكمله، يمكنك فهرسة الكتالوج وتخزين الفهرس في Azure Cognitive Search. قد ينتقل مخزون المنتج إلى قاعدة بيانات SQL لأن هذه البيانات تتطلب ضمانات ACID.

التوصيات

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

  • تذكر أن البيانات تتضمن أكثر من مجرد بيانات التطبيق الثابتة. كما يتضمن سجلات التطبيقات والأحداث والرسائل والمخابئ.

  • تبني استمرارية متعددة اللغات أو حلول تستخدم مزيجا من تقنيات مخزن البيانات.

  • ضع في اعتبارك نوع البيانات التي لديك. على سبيل المثال، قم بتخزين:

    • بيانات المعاملات في قاعدة بيانات SQL.

    • مستندات JSON في قاعدة بيانات المستندات.

    • بيانات تتبع الاستخدام في قاعدة بيانات سلسلة زمنية.

    • سجلات التطبيق في Azure Cognitive Search.

    • الكائنات الثنائية كبيرة الحجم في Azure Blob Storage.

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

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

    • تحسين الاستعلامات.

    • ضبط للأداء.

    • العمل مع أنماط الاستخدام المناسبة.

ضع في اعتبارك هذه العوامل عند اختيار تقنية تخزين:

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

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

تسهيل Azure

يقدم Azure الخدمات التالية:

  • Azure Functions هي خدمة حساب بلا خادم يمكنك استخدامها لإنشاء تزامن بأقل قدر من التعليمات البرمجية.

  • Azure Logic Apps هو نظام أساسي لتكامل سير العمل بلا خادم يمكنك استخدامه لإنشاء تنسيق باستخدام واجهة المستخدم الرسومية أو عن طريق تحرير ملف تكوين.

  • Azure Event Grid هي خدمة توزيع رسائل نشر-اشتراك قابلة للتطوير بدرجة كبيرة ومدارة بالكامل توفر أنماطا مرنة لاستهلاك الرسائل تستخدم بروتوكولات MQTT وHTTP. باستخدام Event Grid، يمكنك إنشاء مسارات بيانات مع بيانات الجهاز، وإنشاء بنيات بلا خادم تستند إلى الأحداث، ودمج التطبيقات.

لمزيد من المعلومات، راجع:

مثال

للحصول على مثال لحمل العمل الذي يحدد المكونات وميزاتها استنادا إلى المتطلبات، راجع نمط Reliable Web App.

قائمة التحقق من الموثوقية

راجع المجموعة الكاملة من التوصيات.

قائمة التحقق من الموثوقية