أنماط البنية
نمط البنية عبارة عن مجموعة من البنى التي تشترك في خصائص معينة. على سبيل المثال، N-tier هو نمط معماري شائع. في الآونة الأخيرة، بدأت بنيات الخدمات المصغرة في اكتساب شهرة. لا تتطلب أنماط الهندسة المعمارية استخدام تقنيات معينة، ولكن بعض التقنيات مناسبة تمامًا لبنى معينة. على سبيل المثال، تعتبر الحاويات مناسبة بشكل طبيعي للخدمات المصغرة.
لقد حددنا مجموعة من أنماط البنية التي توجد بشكل شائع في التطبيقات السحابية. تتضمن المقالة الخاصة بكل نمط ما يلي:
- وصف ورسم تخطيطي منطقي للأسلوب.
- توصيات لوقت اختيار هذا النمط.
- الفوائد والتحديات وأفضل الممارسات.
- توزيع موصى به باستخدام خدمات Azure ذات الصلة.
جولة سريعة في الأنماط
يقدم هذا القسم جولة سريعة حول أنماط البنية التي حددناها، إلى جانب بعض الاعتبارات عالية المستوى لاستخدامها. يرجى ملاحظة أن القائمة ليست شاملة. اقرأ المزيد من التفاصيل في المواضع المرتبطة.
N-tier
N-tier عبارة عن بنية تقليدية لتطبيقات المؤسسات. تتم إدارة التبعيات عن طريق تقسيم التطبيق إلى طبقات تؤدي وظائف منطقية، مثل العرض التقديمي ومنطق الأعمال والوصول إلى البيانات. يمكن للطبقة فقط أن تستدعي الطبقات الموجودة تحتها. ومع ذلك، يمكن أن تكون هذه الطبقات الأفقية مسؤولية. قد يكون من الصعب إجراء تغييرات في جزء واحد من التطبيق دون لمس باقي أجزاء التطبيق. وهذا يجعل التحديثات المتكررة تحديًا، مما يحد من سرعة إضافة الميزات الجديدة.
تعد N-tier مناسبة طبيعية لترحيل التطبيقات الحالية التي تستخدم بالفعل بنية ذات طبقات. لهذا السبب، غالبًا ما يُنظر إلى N-tier في البنية التحتية كحلول خدمة (IaaS)، أو تطبيق يستخدم مزيجًا من IaaS والخدمات المدارة.
Web-Queue-Worker
للحصول على حل PaaS فقط، ضع في اعتبارك بنية Web-Queue-Worker. في هذا النمط، يحتوي التطبيق على واجهة ويب أمامية تتعامل مع طلبات HTTP وعامل خلفية يقوم بمهام كثيفة لوحدة المعالجة المركزية أو عمليات تشغيل طويلة. تتصل الواجهة الأمامية للعامل من خلال قائمة انتظار رسائل غير متزامنة.
يعد Web-Queue-Worker مناسبًا للمجالات البسيطة نسبيًا مع بعض المهام كثيفة الاستخدام للموارد. مثل N-tier، من السهل فهم البنية. يبسط استخدام الخدمات المدارة التوزيع والعمليات. ولكن مع المجالات المعقدة، قد يكون من الصعب إدارة التبعيات. يمكن بسهولة أن تصبح الواجهة الأمامية والعامل مكونات كبيرة ومتجانسة يصعب صيانتها وتحديثها. كما هو الحال مع N-tier، يمكن أن يقلل ذلك من تكرار التحديثات ويحد من الابتكار.
الخدمات المُصغرة
إذا كان التطبيق الخاص بك يحتوي على نطاق أكثر تعقيدًا، فجرّب الانتقال إلى بنية Microservices. يتكون تطبيق الخدمات المصغرة من العديد من الخدمات الصغيرة المستقلة. كل خدمة تنفذ قدرة عمل واحدة. تقترن الخدمات بشكل فضفاض، وتتواصل من خلال عقود واجهة برمجة التطبيقات.
يمكن بناء كل خدمة بواسطة فريق تطوير صغير ومركّز. يمكن توزيع الخدمات الفردية دون الكثير من التنسيق بين الفرق، مما يشجع على التحديثات المتكررة. تعد بنية الخدمات المصغرة أكثر تعقيدًا في الإنشاء والإدارة من N-tier أو Web-queue-worker. يتطلب تطويرا ناضجا وثقافة DevOps. ولكن إذا تم إجراؤه بشكل صحيح، يمكن أن يؤدي هذا النمط إلى سرعة إصدار أعلى وابتكار أسرع وبنية أكثر مرونة.
بنية تستند إلى الحدث
تستخدم البنى المعتمدة علي الحدث نموذج اشتراك للتوزيع (pub-sub)، حيث ينشر المنتجون الأحداث ويشترك المستهلكون فيها. المنتجون مستقلون عن المستهلكين والمستهلكون مستقلون عن بعضهم البعض.
ضع في اعتبارك بنية تعتمد على الأحداث للتطبيقات التي تستوعب وتعالج حجمًا كبيرًا من البيانات بزمن انتقال منخفض جدًا، مثل حلول إنترنت الأشياء. يكون النمط مفيدًا أيضًا عندما يتعين على الأنظمة الفرعية المختلفة إجراء أنواع مختلفة من المعالجة على بيانات الحدث نفسها.
البيانات الضخمة، الحوسبة الكبيرة
البيانات الضخمة والحوسبة الكبيرة هما نمطان معماريان متخصصان لأحمال العمل التي تتناسب مع ملفات تعريف معينة. تقسم البيانات الضخمة مجموعة بيانات كبيرة جدًا إلى أجزاء، مما يؤدي إلى إجراء معالجة متوازية عبر المجموعة بأكملها، من أجل التحليل وإعداد التقارير. تقوم الحوسبة الكبيرة، والتي تسمى أيضًا الحوسبة عالية الأداء (HPC)، بإجراء عمليات حسابية متوازية عبر عدد كبير (بالآلاف) من النوى. تشمل المجالات عمليات المحاكاة والنمذجة والعرض ثلاثي الأبعاد.
أنماط البنية كقيود
يضع نمط العمارة قيودًا على التصميم، بما في ذلك مجموعة العناصر التي يمكن أن تظهر والعلاقات المسموح بها بين هذه العناصر. ترشد القيود "شكل" العمارة عن طريق تقييد عالم الخيارات. عندما تتوافق العمارة مع قيود أسلوب معين، تظهر بعض الخصائص المرغوبة.
على سبيل المثال، تشمل القيود في الخدمات المصغرة ما يلي:
- تمثل الخدمة مسؤولية واحدة.
- كل خدمة مستقلة عن الآخرين.
- البيانات خاصة بالخدمة التي تمتلكها. الخدمات لا تشارك البيانات.
من خلال الالتزام بهذه القيود، فإن ما ينشأ هو نظام يمكن فيه نشر الخدمات بشكل مستقل، وعزل الأعطال، والتحديثات المتكررة ممكنة، ومن السهل إدخال تقنيات جديدة في التطبيق.
كل نمط بنية له مفاضلاته الخاصة. لذلك، قبل اختيار أي نمط معماري، تأكد من فهم المبادئ والقيود الأساسية لهذا النمط. خلافًا لذلك، يمكن أن ينتهي بك الأمر بتصميم يتوافق مع الأسلوب على مستوى سطحي، لكنه لا يحقق الإمكانات الكاملة لهذا النمط. تحتاج إلى الانتباه أكثر إلى سبب اختيار نمط معماري معين بدلا من كيفية تنفيذه. من المهم أيضًا أن تكون عمليًا. في بعض الأحيان يكون من الأفضل تخفيف القيود بدلاً من الإصرار على النقاء المعماري.
يجب أن يتم اختيار نمط معماري مناسب بشكل مثالي مع توافقات آراء أصحاب المصلحة في حمل العمل المستنيرين. يجب على فريق حمل العمل أولا تحديد طبيعة المشكلة التي يحاولون حلها. ثم يجب عليهم تحديد محركات الأعمال وخصائص البنية المقابلة (المعروفة أيضا باسم المتطلبات غير الوظيفية) ثم تحديد أولوياتها. على سبيل المثال، إذا كانوا بحاجة إلى وقت أقصر للتسويق، فقد يعطون الأولوية لقابلية الصيانة وقابلية الاختبار والموثوقية من خلال قدرات النشر السريع. أو إذا كان فريق حمل العمل لديه ميزانية مقيدة، فقد يعطي الأولوية للجدوى والبساطة. اختيار نمط معماري وصيانته ليس نشاطا لمرة واحدة ولكنه نهج مستمر: يجب قياس البنية باستمرار والتحقق من صحتها وضبطها بمرور الوقت. عادة ما تكون هناك تكلفة كبيرة تشارك في تبديل النمط المعماري، لذلك يمكن تبرير المزيد من الجهد مقدما لكفاءة الفريق على المدى الطويل وتخفيف المخاطر.
يلخص الجدول التالي كيف يدير كل نمط التبعيات وأنواع المجال الأنسب لكل نمط.
| نمط البنية | إدارة التبعية | نوع المجال |
|---|---|---|
| N-tier | الطبقات الأفقية مقسومة على الشبكة الفرعية | مجال الأعمال التقليدية. تواتر التحديثات منخفض. |
| عامل قائمة انتظار ويب | وظائف الواجهة الأمامية والخلفية، مفصولة عن طريق الرسائل غير المتزامنة. | مجال بسيط نسبيًا مع بعض المهام كثيفة الموارد. |
| الخدمات المصغرة | الخدمات المتحللة رأسيًا (وظيفيًا) التي تستدعي بعضها البعض من خلال واجهات برمجة التطبيقات. | مجال معقد. التحديثات المتكررة. |
| البنية المستندة إلى الحدث | المنتج/المستهلك. عرض مستقل لكل نظام فرعي. | أنظمة إنترنت الأشياء والأنظمة في الوقت الحقيقي. |
| البيانات الضخمة | قسّم مجموعة بيانات ضخمة إلى أجزاء صغيرة. المعالجة المتوازية على مجموعات البيانات المحلية. | تحليل البيانات دفعة واحدة والوقت الحقيقي. التحليل التنبؤي باستخدام التعلم الآلي. |
| حساب كبير | تخصيص البيانات لآلاف الذاكرات الأساسية. | حساب المجالات المكثفة مثل المحاكاة. |
النظر في التحديات والمزايا
تخلق القيود أيضًا تحديات، لذلك من المهم فهم المقايضات عند تبني أي من هذه الأساليب. هل تفوق مزايا أسلوب الهندسة المعمارية التحديات، لهذا النطاق الفرعي والسياق المحدود.
فيما يلي بعض أنواع التحديات التي يجب مراعاتها عند اختيار نمط العمارة:
التعقيد. هل تعقيد البنية مبرر لنطاقك؟ على العكس من ذلك، هل النمط مفرط في التبسيط بالنسبة لنطاقك؟ في هذه الحالة، فإنك تخاطر بأن ينتهي بك الأمر بـ "كرة كبيرة من الطين"، لأن الهندسة المعمارية لا تساعدك على إدارة التبعيات بشكل نظيف.
الرسائل غير المتزامنة والاتساق النهائي. يمكن استخدام الرسائل غير المتزامنة لفصل الخدمات، وزيادة الموثوقية (لأنه يمكن إعادة محاولة الرسائل) وقابلية التوسع. ومع ذلك، فإن هذا يخلق أيضًا تحديات في التعامل مع الاتساق النهائي، فضلاً عن إمكانية تكرار الرسائل.
الاتصال بين الخدمات. أثناء تفكيك تطبيق ما إلى خدمات منفصلة، هناك خطر يتمثل في أن الاتصال بين الخدمات سيؤدي إلى زمن انتقال غير مقبول أو يؤدي إلى ازدحام الشبكة (على سبيل المثال، في بنية الخدمات المصغرة).
قابلية الإدارة. ما مدى صعوبة إدارة التطبيق والمراقبة ونشر التحديثات وما إلى ذلك؟