اختيار الطراز المعماري (الجزء الثاني)

أهلا هبر. أواصل اليوم سلسلة من المنشورات التي كتبتها خصيصًا لبدء تيار جديد من الدورة. "مهندس برمجيات".

مقدمة

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

В آخر مرة لقد تعاملنا مع المونوليث وتوصلنا إلى استنتاج مفاده أن المونوليث به عدد من المشكلات: الحجم والاتصال والنشر وقابلية التوسع والموثوقية والصلابة.

أقترح هذه المرة الحديث عن إمكانيات تنظيم النظام كمجموعة من الوحدات/المكتبات (هندسة موجهة للمكونات) أو خدمات (بنية موجهة نحو الخدمة).

الهندسة المعمارية الموجهة للمكونات

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

مع الاستخدام السليم للمكونات، يتم حل مشكلة "كرة الأوساخ الكبيرة" (الحجم الكبير + الاقتران العالي)، ويمكن أن تكون المكونات نفسها وحدات تجميع (وحدات، مكتبات) ووحدات نشر (خدمات). لا يتم دائمًا تعيين وحدات النشر للعملية الجارية: على سبيل المثال، يتم نشر تطبيق ويب وقاعدة بيانات معًا.

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

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

المتراصة "المثالية" هي مجموعة من الوحدات المنفصلة منطقيا، كل منها تنظر في قاعدة البيانات الخاصة بها.

الخدمات الهندسية الموجهة

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

تعمل البنية الموجهة نحو الخدمة (SOA = البنية الموجهة نحو الخدمة) على حل جميع المشكلات المحددة للوحدة المتراصة: تتأثر خدمة واحدة فقط عند حدوث تغيير، وتدعم واجهة برمجة التطبيقات المحددة جيدًا التغليف الجيد للمكونات.

ولكن ليس كل شيء على ما يرام: فخدمية SOA تخلق مشاكل جديدة. تعد المكالمات عن بعد أكثر تكلفة من المكالمات المحلية، كما أن إعادة توزيع المسؤوليات بين المكونات أصبحت أكثر تكلفة بشكل ملحوظ.

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

تحظى الهندسة المعمارية الموجهة نحو الخدمة بدعم جيد من قبل المجتمع المعماري والبائعين. وهذا يعني وجود العديد من الدورات والشهادات والأنماط المتطورة. يتضمن الأخير، على سبيل المثال، ناقل خدمة المؤسسة المعروف (ESB = ناقل خدمة المؤسسة). وفي الوقت نفسه، يعد ESB بمثابة أمتعة من البائعين، وليس من الضروري استخدامه في SOA.

بلغت شعبية الهندسة المعمارية الموجهة نحو الخدمة ذروتها في عام 2008 تقريبًا، وبعد ذلك بدأت في الانخفاض، والتي أصبحت أكثر دراماتيكية بشكل ملحوظ بعد ظهور الخدمات المصغرة (~ 2015).

اختتام

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

المصدر: www.habr.com