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