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

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

مقدمة

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

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

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

علاقة العمارة

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

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

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

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

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

نظمت حول القدرات التجارية

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

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

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

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

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

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

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

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

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

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

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

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

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

تصميم للفشل

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

العمارة مع التطور التطوري (التصميم التطوري)

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

اختتام

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

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

قراءة الجزء 2

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

إضافة تعليق