يوجه هذا الدليل إرشادات التصميم المنظم لتطبيقات السحابة الإلكترونية القابلة للتطوير والمرونة والتي يسهل الوصول إليها. وهي مصممة لمساعدتك على اتخاذ قرارات بشأن هندستك ، بغض النظر عن النظام الأساسي السحابي الذي تستخدمه.
يتم تنظيم الدليل على شكل سلسلة من الخطوات - اختيار بنية → اختيار تقنيات لحساب وتخزين البيانات → تصميم تطبيق Azure → اختيار قوالب → فحص الهندسة المعمارية. لكل منهم ، هناك توصيات ستساعدك في تطوير بنية التطبيق.
ننشر اليوم جزءًا من الفصل الأول من هذا الكتاب. يمكنك تنزيل النسخة الكاملة مجانًا
هنا .
جدول المحتويات
- اختيار العمارة - 1 ؛
- اختيار تقنيات حوسبة وتخزين البيانات - 35 ؛
- تصميم تطبيق Azure: مبادئ التصميم - 60 ؛
- تصميم تطبيق Azure: مؤشرات الجودة - 95 ؛
- تصميم تطبيق Azure: أنماط التصميم - 103 ؛
- دليل القالب - 110 ؛
- قوائم التحقق من صحة العمارة - 263 ؛
- الخلاصة - 291 ؛
- هندسة Azure Reference - 292 ؛
اختيار العمارة
أول قرار يتعين عليك اتخاذه عند تصميم تطبيق سحابي هو اختيار بنية. يعتمد اختيار العمارة على مدى تعقيد التطبيق والنطاق ونوعه (IaaS أو PaaS) والمهام التي يقصد منها. من المهم أيضًا مراعاة مهارات فريق التطوير ومديري المشاريع ، بالإضافة إلى توفر بنية جاهزة للتطبيق.
يفرض اختيار العمارة قيودًا معينة على هيكل التطبيق ، مما يحد من اختيار التقنيات والعناصر الأخرى للتطبيق. ترتبط هذه القيود بكل من مزايا وعيوب البنية المختارة.
ستساعدك المعلومات الواردة في هذا القسم على إيجاد توازن بينهما عند تنفيذ بنية معينة. يسرد هذا القسم عشرة مبادئ تصميم يجب وضعها في الاعتبار. سيساعدك اتباع هذه المبادئ على إنشاء تطبيق أكثر مرونة وقابلية للإدارة.
لقد حددنا مجموعة من خيارات العمارة شائعة الاستخدام في التطبيقات السحابية. القسم المخصص لكل منهم يحتوي على:
- وصف ومنطق العمارة ؛
- توصيات بشأن نطاق هذه البنية ؛
- مزايا وعيوب وتوصيات للاستخدام ؛
- خيار النشر الموصى به باستخدام خدمات Azure المناسبة.
نظرة عامة على العمارة
يقدم هذا القسم نظرة عامة موجزة عن خيارات الهندسة التي حددناها ، بالإضافة إلى توصيات عامة لاستخدامها. يمكنك العثور على معلومات أكثر تفصيلاً في الأقسام ذات الصلة المتاحة عبر الروابط.
المستوى N
يتم استخدام بنية N-tier بشكل شائع في تطبيقات المؤسسة. لإدارة التبعيات ، ينقسم التطبيق إلى طبقات ، كل منها مسؤول عن وظيفة منطقية معينة ، على سبيل المثال ، لعرض البيانات أو منطق الأعمال أو الوصول إلى البيانات. يمكن للطبقة استدعاء طبقات أخرى أدناه. ومع ذلك ، يمكن أن يسبب هذا التقسيم إلى طبقات أفقية صعوبات إضافية. على سبيل المثال ، قد يكون من الصعب إجراء تغييرات على جزء واحد من التطبيق دون التأثير على عناصره الأخرى. لذلك ، ليس من السهل تحديث مثل هذا التطبيق ، وسيتعين على المطورين إضافة ميزات جديدة أقل.
تعد بنية N-tier خيارًا طبيعيًا عند نقل التطبيقات المستخدمة بالفعل والمبنية على أساس بنية الطبقة. لذلك ، يتم استخدام هذه البنية في أغلب الأحيان في حلول IaaS (البنية التحتية كخدمة) أو في التطبيقات التي تجمع بين IaaS مع الخدمات المدارة.
واجهة الويب - قائمة الانتظار - دور العامل
بالنسبة لحلول PaaS ، تعد بنية واجهة الويب وقائمة انتظار ودور العمل مناسبة. باستخدام هذه البنية ، يحتوي التطبيق على واجهة ويب تعالج طلبات HTTP ، ودور عمل الخادم المسؤول عن العمليات التي تستغرق وقتًا طويلاً أو تتطلب موارد الحوسبة. يتم استخدام قائمة انتظار رسائل غير متزامنة للتواصل بين الواجهة ودور عمل الخادم.
تعتبر بنية "واجهة الويب - قائمة الانتظار - دور العمل" مناسبة للمهام البسيطة نسبيًا التي تتطلب موارد حوسبة. مثل العمارة N-tier ، هذا النموذج سهل الفهم. يؤدي استخدام الخدمات المُدارة إلى تبسيط النشر والتشغيل. ولكن عند إنشاء تطبيقات لمجالات موضوعية معقدة ، قد يكون من الصعب التحكم في التبعيات. يمكن بسهولة توسيع واجهة الويب ودور العمل ليشمل المكونات المتجانسة الكبيرة التي يصعب صيانتها وتحديثها. كما هو الحال مع بنية N-tier ، يتميز هذا النموذج بمعدل تحديث أقل وفرص تحسين محدودة.
الخدمات الدقيقة
إذا تم تصميم التطبيق لحل مشاكل أكثر تعقيدًا ، فحاول تنفيذه على أساس بنية الخدمات الدقيقة. يتكون هذا التطبيق من العديد من الخدمات المستقلة الصغيرة. كل خدمة مسؤولة عن وظيفة تجارية منفصلة. تقترن الخدمات بشكل فضفاض وتستخدم عقود API للتفاعل.
يمكن لفريق صغير من المطورين العمل على إنشاء خدمة منفصلة. يمكن نشر الخدمات دون تنسيق معقد بين المطورين ، مما يسهل تحديثها بانتظام. إن بنية الخدمات المصغرة أكثر صعوبة في التنفيذ والإدارة من النهجين السابقين. يتطلب ثقافة إدارة التنمية ناضجة. ولكن إذا تم تنظيم كل شيء بشكل صحيح ، فإن هذا النهج يساعد على زيادة وتيرة إصدار الإصدارات الجديدة ، وتسريع تنفيذ الابتكارات وجعل البنية أكثر تحملاً للخطأ.
صقر
تسمح لك بنية CQRS (فصل مسؤولية القيادة والاستعلام وتوزيع المسؤولية بين الفرق والاستعلامات) بفصل عمليات القراءة والكتابة بين النماذج الفردية. ونتيجة لذلك ، يتم عزل أجزاء النظام المسؤولة عن تغيير البيانات عن أجزاء النظام المسؤولة عن قراءة البيانات. علاوة على ذلك ، يمكن إجراء عمليات القراءة في عرض مادي منفصل فعليًا عن قاعدة البيانات التي تتم الكتابة إليها. هذا يسمح لك بتوسيع عمليات القراءة والكتابة بشكل مستقل وتحسين العرض التقديمي المادي لتنفيذ الاستعلام.
يُفضل استخدام نموذج CQRS لنظام فرعي ذي بنية أكبر. بشكل عام ، لا ينبغي تطبيقه على التطبيق بأكمله ، لأن هذا يعقد بنيته بشكل غير ضروري. يعمل بشكل جيد في أنظمة التعاون ، حيث يعمل عدد كبير من المستخدمين في نفس الوقت مع نفس البيانات.
العمارة القائمة على الأحداث
تستخدم الهندسة القائمة على الأحداث نموذجًا للاشتراك والنشر ينشر فيه الموردون الأحداث ويشترك المستهلكون فيها. الموردون مستقلون عن المستهلكين والمستهلكين مستقلين عن بعضهم البعض.
تعتبر البنية المستندة إلى الأحداث مناسبة تمامًا للتطبيقات التي تحتاج إلى استقبال ومعالجة كميات كبيرة من البيانات بسرعة مع الكمون المنخفض ، مثل إنترنت الأشياء. بالإضافة إلى ذلك ، تعمل هذه البنية بشكل جيد في الحالات التي يجب فيها على الأنظمة الفرعية المختلفة معالجة نفس بيانات الحدث بشكل مختلف.
البيانات الضخمة والحوسبة الكبيرة
البيانات الكبيرة والحوسبة الكبيرة هي خيارات معمارية خاصة تستخدم لحل مشاكل خاصة. عند استخدام بنية البيانات الضخمة ، يتم تقسيم مجموعات البيانات الكبيرة إلى أجزاء ، ثم تتم معالجتها بالتوازي لأغراض التحليل وإعداد التقارير. تسمى الحوسبة الكبيرة أيضًا الحوسبة عالية الأداء (HPC). تتيح لك هذه التقنية توزيع الحوسبة بين عدة آلاف من نوى المعالج. يمكن استخدام هذه البنى للمحاكاة والعرض ثلاثي الأبعاد ومهام أخرى مماثلة.
خيارات العمارة كقيود
تعمل الهندسة المعمارية كقيود في تصميم الحل ، على وجه الخصوص ، فهي تحدد العناصر التي يمكن استخدامها والروابط الممكنة بينها. تحدد القيود "شكل" العمارة وتسمح لك بالاختيار من مجموعة أضيق من الخيارات. إذا تم استيفاء قيود البنية المحددة ، فسيكون للحل خصائص مميزة لهذه البنية.
على سبيل المثال ، تتميز الخدمات الدقيقة بالقيود التالية:
- كل خدمة مسؤولة عن وظيفة منفصلة ؛
- الخدمات مستقلة عن بعضها البعض ؛
- البيانات متاحة فقط للخدمة المسؤولة عنها. لا تتبادل الخدمات البيانات.
يؤدي اتباع هذه القيود إلى إنشاء نظام يمكن فيه نشر الخدمات بشكل مستقل عن بعضها البعض ، ويتم عزل الأخطاء ، ويمكن إجراء تحديثات متكررة ، وإضافة التقنيات الجديدة بسهولة إلى التطبيق.
قبل اختيار بنية ، تأكد من أنك تفهم المبادئ الأساسية والقيود ذات الصلة جيدًا. بخلاف ذلك ، يمكنك الحصول على حل يتطابق خارجيًا مع طراز الهندسة المعمارية المحدد ، ولكنه لا يكشف تمامًا عن إمكانات هذا النموذج. الحس السليم مهم أيضا. في بعض الأحيان يكون من الحكمة التخلي عن تقييد واحد أو آخر بدلاً من السعي من أجل بنية نظيفة.
يوضح الجدول التالي كيفية تنفيذ إدارة التبعية في كل من بنيتها ، والمهام التي تناسبها هذه البنية أو تلك.
تحليل مزايا وعيوب
تخلق القيود صعوبات إضافية ، لذلك من المهم فهم ما يجب عليك التضحية به عند اختيار خيار معماري واحد أو آخر ، وأن تكون قادرًا على الإجابة على السؤال عما إذا كانت مزايا الخيار المحدد تفوق عيوبه لمهمة معينة في سياق معين.
فيما يلي بعض العيوب التي يجب مراعاتها عند اختيار بنية:
- التعقيد هل استخدام العمارة المعقدة له ما يبرره لمهمتك؟ والعكس بالعكس ، هل الهندسة المعمارية بسيطة للغاية تم اختيارها لمهمة معقدة؟ في هذه الحالة ، أنت تخاطر بالحصول على نظام بدون هيكل واضح ، لأن البنية المستخدمة لا تسمح لك بإدارة التبعيات بشكل صحيح.
- الرسائل غير المتزامنة والاتساق في نهاية المطاف. تساعد المراسلة غير المتزامنة على فصل الخدمات وتحسين الموثوقية (بفضل القدرة على إعادة إرسال الرسائل) وإمكانية التوسع. ومع ذلك ، فإنه يخلق بعض الصعوبات ، مثل دلالات انتقال واحد فقط ومشكلة التماسك على المدى الطويل.
- التفاعل بين الخدمات. إذا قسمت التطبيق إلى خدمات منفصلة ، فهناك خطر أن يستغرق تبادل البيانات بين الخدمات الكثير من الوقت أو يؤدي إلى ازدحام الشبكة (على سبيل المثال ، عند استخدام الخدمات الصغيرة).
- الإدارة. ما مدى صعوبة إدارة التطبيق ومراقبة عمله ونشر التحديثات وأداء المهام الأخرى؟
العمارة N-tier
في بنية N-tier ، ينقسم التطبيق إلى طبقات منطقية وطبقات مادية.
الطبقات هي آلية لتقاسم المسؤولية وإدارة التبعيات. كل طبقة لها مجال مسؤوليتها. تستخدم الطبقات ذات المستوى الأعلى خدمات الطبقات ذات المستوى الأدنى ، ولكن ليس العكس.
المستويات مفصولة ماديًا وتعمل على أجهزة كمبيوتر مختلفة. يمكن لمستوى واحد الوصول إلى المستوى الآخر مباشرة أو باستخدام الرسائل غير المتزامنة (قوائم انتظار الرسائل). على الرغم من أنه يجب وضع كل طبقة على المستوى الخاص بها ، إلا أن هذا ليس ضروريًا. يمكنك وضع عدة طبقات على مستوى واحد. إن الفصل المادي للمستويات لا يجعل الحل أكثر قابلية للتوسع وخطأ أيضًا ، ولكنه أبطأ أيضًا ، نظرًا لأن الشبكة غالبًا ما تستخدم للتفاعل. يتكون التطبيق التقليدي من ثلاثة مستويات من مستوى العرض التقديمي ، والمستوى المتوسط ، ومستوى قاعدة البيانات. المستوى المتوسط اختياري. يمكن أن تتكون التطبيقات الأكثر تعقيدًا من أكثر من ثلاثة مستويات. يوضح الرسم البياني أعلاه تطبيقًا بمستويين متوسطين مسؤولين عن المجالات الوظيفية المختلفة.
قد يحتوي تطبيق N-tier على بنية طبقة مغلقة أو بنية طبقة مفتوحة.
- في الهندسة المعمارية المغلقة ، يمكن للطبقة التعسفية الوصول فقط إلى أقرب طبقة سفلية.
- في العمارة المفتوحة ، يمكن أن تشير الطبقة العشوائية إلى أي طبقات سفلية.
تحدد بنية الطبقة المغلقة التبعيات بين الطبقات. ومع ذلك ، يمكن أن يؤدي استخدامه إلى زيادة حركة مرور الشبكة بشكل مفرط إذا قامت طبقة معينة بإعادة توجيه الطلبات إلى الطبقة التالية.
تطبيقات العمارة
يتم استخدام بنية N-tier عادةً في تطبيقات IaaS ، حيث يعمل كل مستوى على مجموعة منفصلة من الأجهزة الافتراضية. ومع ذلك ، لا يجب أن يكون تطبيق N-tier تطبيق IaaS خالص. غالبًا ما يكون من الملائم استخدام الخدمات المُدارة لبعض مكونات الحل ، خاصةً في التخزين المؤقت والرسائل وتخزين البيانات.
يوصى باستخدام بنية N-tier في الحالات التالية:
- تطبيقات ويب بسيطة ؛
- نقل تطبيق محلي إلى Azure بأقل قدر من إعادة الهيكلة
- نشر متسق للتطبيقات الداخلية والتطبيقات السحابية.
تعد بنية N-tier شائعة بين التطبيقات الداخلية العادية ، لذلك فهي مناسبة تمامًا لنقل التطبيقات الموجودة إلى Azure.
الفوائد
- القدرة على نقل التطبيقات بين النشر المحلي والسحابة ، وكذلك بين المنصات السحابية.
- تدريب أقل لمعظم المطورين.
- امتداد طبيعي لنموذج التطبيق التقليدي.
- دعم البيئات غير المتجانسة (Windows / Linux).
المساوئ
- من السهل الحصول على تطبيق يقوم فيه الطبقة الوسطى بإجراء عمليات CRUD فقط في قاعدة البيانات ، مما يزيد من وقت معالجة الطلبات ولا يحقق أي فائدة.
- لن تسمح العمارة المتجانسة بتطوير المكونات الفردية من قبل فرق التطوير المستقلة.
- تستغرق إدارة تطبيق IaaS وقتًا أطول من تطبيق الخدمة المدارة فقط.
- قد يكون من الصعب إدارة أمان الشبكة في الأنظمة الكبيرة.
التوصيات
- استخدم التحجيم التلقائي عند الحمل المتغير. انظر أفضل الممارسات للتحجيم التلقائي.
- استخدم المراسلة غير المتزامنة لفصل المستويات عن بعضها البعض.
- تخزين البيانات شبه الثابتة. انظر اعتبارات التخزين المؤقت.
- تأكد من توافر عالٍ على مستوى قاعدة البيانات باستخدام حل مثل مجموعات Always On Availability في SQL Server.
- قم بتثبيت جدار حماية تطبيق ويب (WAF) بين الواجهة والإنترنت.
- ضع كل مستوى في الشبكة الفرعية الخاصة بك ؛ استخدام الشبكات الفرعية كحدود أمنية.
- قم بالحد من الوصول إلى مستوى البيانات عن طريق السماح فقط بالاستعلامات من المستويات المتوسطة.
N- الطبقة بنية الجهاز الظاهري
يقدم هذا القسم إرشادات لبناء بنية N-tier باستخدام أجهزة افتراضية.
يقدم هذا القسم إرشادات لبناء بنية N-tier باستخدام أجهزة افتراضية. يتكون كل مستوى من جهازي ظاهريين أو أكثر مستضافين في مجموعة توفر أو في مجموعة قابلة للتطوير من الأجهزة الظاهرية. يوفر استخدام العديد من الأجهزة الافتراضية التسامح مع الخطأ في حالة فشل أحدها. لتوزيع الطلبات بين الأجهزة الافتراضية من نفس المستوى ، يتم استخدام الأنظمة الفرعية لموازنة التحميل. يمكن تحجيم المستوى أفقيًا ، مع إضافة أجهزة افتراضية جديدة إلى التجمع.
يتم وضع كل مستوى أيضًا داخل شبكته الفرعية الخاصة. هذا يعني أن عناوين IP الداخلية الخاصة بهم تقع في نفس النطاق. وهذا يجعل من السهل تطبيق قواعد Network Security Group (NSG) وجداول التوجيه على الطبقات الفردية.
لا يتم مراقبة حالة طبقة الويب ومستوى الأعمال. يمكن لأي جهاز افتراضي معالجة أي طلبات لهذه المستويات. يجب أن تتكون طبقة البيانات من قاعدة بيانات منسوخة. بالنسبة لنظام التشغيل Windows ، نوصي باستخدام SQL Server مع مجموعات Always On Availability للتوفر العالي. بالنسبة لنظام التشغيل Linux ، يجب عليك اختيار قاعدة بيانات تدعم النسخ المتماثل ، مثل Apache Cassandra.
الوصول إلى كل مستوى مقيد بمجموعات أمان الشبكة (NSGs). على سبيل المثال ، يُسمح بالوصول إلى طبقة قاعدة البيانات فقط لطبقة العمل
ميزات إضافية
- لا يجب أن تتكون بنية N-tier من ثلاثة مستويات. تميل التطبيقات الأكثر تعقيدًا إلى استخدام المزيد من المستويات. في هذه الحالة ، استخدم التوجيه عبر الطبقة 7 لإعادة توجيه الطلبات إلى مستوى معين.
- تحد المستويات من القرار المتعلق بقابلية التوسع والموثوقية والأمان. يوصى باستخدام مستويات مختلفة للخدمات ذات المتطلبات المختلفة لهذه الخصائص.
- استخدم التحجيم التلقائي باستخدام مجموعات قابلة للتحجيم من الأجهزة الافتراضية.
- ابحث عن العناصر في بنيتك التي يمكنك تنفيذها مع الخدمات المدارة دون إعادة هيكلة رئيسية. على وجه الخصوص ، انتبه إلى التخزين المؤقت والرسائل والتخزين وقواعد البيانات.
- لزيادة الأمان ، ضع التطبيق خلف شبكة المحيط. تتضمن شبكة المحيط مكونات شبكة افتراضية توفر الأمان ، مثل جدران الحماية ومفتشي الحزم. لمزيد من المعلومات ، راجع هندسة الشبكة المرجعية للمحيط.
- للتوافر العالي ، ضع مكونين أو أكثر من مكونات الشبكة الافتراضية في مجموعة التوافر وأضف موازن تحميل لتوزيع طلبات الإنترنت بينهما. لمزيد من المعلومات ، راجع نشر مكونات الشبكة الافتراضية للحصول على توفر عالٍ.
- لا تسمح بالوصول المباشر إلى الأجهزة الافتراضية التي تشغل رمز التطبيق عبر بروتوكولي RDP و SSH. بدلاً من ذلك ، يجب على المشغلين دخول عقدة الحصن. هذا جهاز ظاهري في موقع الشبكة يستخدمه المسؤولون للاتصال بأجهزة افتراضية أخرى. في مضيف المعقل ، يتم تكوين قواعد NSG للسماح بالوصول عبر RDP و SSH فقط من عناوين IP العامة المعتمدة.
- يمكنك توسيع شبكة Azure الظاهرية إلى شبكة محلية باستخدام شبكة افتراضية (VPN) من نوع شبكة إلى شبكة أو Azure ExpressRoute. لمزيد من المعلومات ، راجع الهيكل المرجعي الهجين للشبكة.
- إذا كانت مؤسستك تستخدم Active Directory لإدارة الهوية ، فيمكنك توسيع بيئة Active Directory الخاصة بك إلى شبكة Azure الظاهرية. لمزيد من المعلومات ، راجع هندسة مرجع إدارة الهوية.
- إذا كنت تحتاج إلى مستوى أعلى من التوافر عما هو مطلوب في اتفاقية مستوى خدمة Azure Virtual Machine ، فقم بتكرار التطبيق بين المنطقتين وقم بتكوين Azure Traffic Manager لتجاوز الفشل. لمزيد من المعلومات ، راجع بدء تشغيل أجهزة Windows الظاهرية في عدة مناطق وبدء تشغيل أجهزة Linux الظاهرية في عدة مناطق.
يمكنك تنزيل النسخة الكاملة من الكتاب مجانًا ودراستها على الرابط أدناه.
→
تنزيل