المقدمة
يعد اختيار النمط المعماري أحد الحلول التقنية الأساسية في بناء نظام المعلومات. في هذه السلسلة من المقالات ، أقترح تحليل الأساليب المعمارية الأكثر شيوعًا لبناء التطبيقات والإجابة على سؤال متى يكون النمط المعماري الأكثر تفضيلاً. في هذه العملية ، سأحاول رسم سلسلة منطقية تشرح تطور الأساليب المعمارية من متراصة إلى خدمات مصغرة.
القليل من التاريخ
إذا حاولت طرح سؤال على المطورين: "لماذا نحتاج إلى خدمات مصغرة؟" ، عندها ستحصل على مجموعة متنوعة من الإجابات. ستسمع أن الخدمات المصغرة تعمل على تحسين القياس ، وتسهيل فهم الكود الخاص بك ، وتحسين التسامح مع الخطأ ، وأحيانًا ستسمع أنها تسمح لك "بتنظيف الشفرة". دعنا نعود إلى التاريخ لنفهم الغرض من ظهور الخدمات المصغرة.
باختصار ، ظهرت الخدمات المصغرة في فهمنا الحالي على النحو التالي: في عام 2011 ، قام جيمس لويس بتحليل عمل العديد من الشركات ، ولفت الانتباه إلى ظهور نمط جديد "تطبيق صغير" يعمل على تحسين SOA من حيث تسريع نشر الخدمة. بعد ذلك بقليل ، في عام 2012 ، في قمة الهندسة المعمارية ، تمت إعادة تسمية النمط إلى خدمة مصغرة. وبالتالي ، كان الهدف الأولي لإدخال الخدمات المصغرة هو تحسين وقت التسويق السيئ السمعة .
كانت الخدمات المصغرة في "موجة الضجيج" في عام 2015. وفقًا لبعض الدراسات ، لم يكتمل أي مؤتمر دون الحديث عن موضوع الخدمات المصغرة. علاوة على ذلك ، تم تخصيص بعض المؤتمرات حصريًا للخدمات المصغرة. في الوقت الحاضر ، تبدأ العديد من المشاريع في استخدام هذا النمط المعماري ، وإذا كان المشروع يحتوي على الكثير من الرموز القديمة ، فمن المرجح أنها تنتقل بنشاط إلى الخدمات المصغرة.
بالرغم من كل ما سبق ، لا يزال هناك عدد غير قليل من المطورين الذين يمكنهم تحديد مفهوم "الخدمات المصغرة". لكننا سنتحدث عن هذا بعد قليل ...
مونوليث
الأسلوب المعماري مقابل الخدمة المصغرة هو monolith (أو الكل في واحد). ربما لا يكون من المنطقي معرفة ماهية الكتلة المتراصة ، لذلك سأدرج على الفور أوجه القصور في هذا الأسلوب المعماري الذي بدأ في تطوير المزيد من الأساليب المعمارية: الحجم والتماسك والنشر وقابلية التوسع والموثوقية والقصور الذاتي. أدناه أقترح التعرف على كل من العيوب بشكل منفصل.
الحجم
متراصة كبيرة جدا. وعادة ما يتواصل مع قاعدة بيانات كبيرة جدًا. أصبح التطبيق أكبر من أن يفهمه مطور واحد على الإطلاق. فقط أولئك الذين أمضوا الكثير من الوقت وراء هذا الكود يمكنهم العمل بشكل جيد مع متراصة ، بينما سيقضي المبتدئون الكثير من الوقت في محاولة اكتشاف المتراصة وليس حقيقة أنهم سيكتشفونها. عادة ، عند العمل مع متراصة ، هناك دائمًا كبير "مشروط" معين يعرف المتراصة جيدًا إلى حد ما ويصفع مطورين جدد آخرين لمدة عام أو نصف. وبطبيعة الحال ، فإن مثل هذا المسن المشروط هو نقطة فشل واحدة ، ويمكن أن يؤدي رحيله إلى موت المتراصة.
الترابط
الكتلة المتراصة هي "كرة كبيرة من الطين" ، يمكن أن تؤدي التغييرات فيها إلى عواقب لا يمكن التنبؤ بها. من خلال إجراء تغييرات في مكان واحد ، يمكنك إتلاف الكتلة المتراصة في مكان آخر (نفس "خدش أذني ، * @ سقط"). هذا يرجع إلى حقيقة أن المكونات الموجودة في الكتلة الواحدة لها علاقات معقدة للغاية ، والأهم من ذلك ، علاقات غير واضحة.
تعيين
يعد نشر كتلة متراصة ، بسبب العلاقات المعقدة بين مكوناتها ، عملية طويلة لها طقوسها الخاصة. عادة ما تكون هذه الطقوس غير موحدة تمامًا ويتم تمريرها شفهيًا.
قابلية التوسع
يمكن أن تحتوي وحدات Monolith على متطلبات موارد متضاربة ، مما يستلزم حل وسط من حيث الأجهزة. تخيل أن المونليث الخاص بك يتكون من خدمتين A و B. تتطلب الخدمة A حجم القرص الثابت ، وأن الخدمة B تتطلب الكثير على ذاكرة الوصول العشوائي. في هذه الحالة ، يجب أن يدعم الجهاز الذي تم تثبيت الوحدة المتراصة عليه متطلبات كلتا الخدمتين ، أو سيتعين عليك تعطيل إحدى الخدمتين يدويًا.
مثال آخر (أكثر كلاسيكية): الخدمة A أكثر شيوعًا من الخدمة B ، لذلك تريد أن تكون الخدمات A هي 100 ، والخدمات B هي 10. مرة أخرى ، هناك خياران: إما أن ننشر 100 وحدة متجانسة كاملة ، أو في بعض ثم سيتعين تعطيل الخدمات B يدويًا.
الموثوقية
نظرًا لأن جميع الخدمات معًا ، إذا سقطت الوحدة المتراصة ، فإن جميع الخدمات تسقط مرة واحدة. في الواقع ، ربما لا يكون هذا سيئًا للغاية ، على الأقل لن يكون هناك فشل جزئي في نظام موزع ، ولكن من ناحية أخرى ، نظرًا لخطأ في الوظيفة يستخدمه 0.001٪ من المستخدمين ، فقد تفقد جميع مستخدمي نظامك.
التعطيل
نظرًا لحجم الكتلة المتراصة ، من الصعب التبديل إلى التقنيات الجديدة. نتيجة لذلك ، فإن الاحتفاظ بهذا الأقدم المشروط مهمة منفصلة. يمكن أن تصبح المجموعة التكنولوجية المختارة في بداية المشروع كتلة تعيق تطوير المنتج.
خاتمة
في المرة القادمة ، سنتحدث عن كيفية محاولة الأشخاص حل هذه المشكلات بالانتقال إلى المكونات و SOA.
اقرأ أكثر: