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

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










المقدمة



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



تحدثنا في المرة الماضية عن الأنواع المختلفة للوحدات المتراصة وكيفية استخدام المكونات لبناءها ، سواء مكونات التجميع أو مكونات النشر. لقد تعاملنا مع العمارة الموجهة نحو الخدمة.



الآن سنقوم أخيرًا بتحديد الخصائص الرئيسية لبنية الخدمات المصغرة.



علاقة البنى



يجب أن يكون مفهوماً ، بناءً على البيانات الواردة في مقالات التعريفات السابقة ، أن أي خدمة تعتبر مكونًا ، ولكن ليست كل خدمة عبارة عن خدمة مصغرة.



خصائص بنية الخدمات المصغرة



الخصائص الرئيسية لبنية الخدمات المصغرة هي:



  • منظم حول قدرات الأعمال
  • المنتجات وليس المشاريع
  • نقاط نهاية ذكية وأنابيب خاملة
  • الحكم اللامركزي
  • إدارة البيانات اللامركزية
  • أتمتة البنية التحتية
  • تصميم للفشل
  • التصميم التطوري


تأتي النقطة الأولى من الهندسة المعمارية الموجهة للخدمة لأن الخدمات المصغرة هي حالة خاصة من الخدمات. النقاط الأخرى تستحق دراسة منفصلة.



منظم حول قدرات الأعمال



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



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



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



المنتجات وليس المشاريع



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



نقاط نهاية ذكية وأنابيب خاملة



أولت بنية SOA الكثير من الاهتمام لقنوات الاتصال ، ولا سيما Enterprise Service Bus (ناقل خدمة المؤسسات). وهو ما يؤدي غالبًا إلى وجود صندوق السباغيتي الخاطئ ، أي أن تعقيد الكتلة المتراصة يتحول إلى تعقيد الاتصالات بين الخدمات. تستخدم بنية الأجهزة الصغيرة فقط طرق اتصال بسيطة.



الحكم اللامركزي



يجب أن يتخذ الأشخاص الذين يطورون الخدمات المصغرة القرارات الأساسية للخدمات المصغرة. هنا ، تعني القرارات الرئيسية اختيار

لغات البرمجة ومنهجية النشر وعقود الواجهة العامة وما إلى ذلك.



إدارة البيانات اللامركزية



لا يمكن للنهج القياسي ، الذي يعتمد فيه التطبيق على قاعدة بيانات واحدة ، أن يأخذ بعين الاعتبار خصوصيات كل خدمة محددة. يفترض MSA إدارة البيانات اللامركزية ، حتى استخدام التقنيات المختلفة.



أتمتة البنية التحتية



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



تصميم للفشل



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



التصميم التطوري



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

كملاذ أخير.



خاتمة



بعد كل ما سبق ، يمكننا صياغة ماهية الخدمات المصغرة. بنية الخدمات المصغرة هي نهج لتطوير تطبيق فردي كمجموعة من الخدمات الصغيرة ، كل منها يعمل في عمليته الخاصة ويتفاعل من خلال آليات خفيفة الوزن ، غالبًا واجهة برمجة تطبيقات لموارد HTTP. هذه الخدمات مبنية على قدرات العمل ويمكن نشرها بشكل مستقل باستخدام

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










All Articles