في نوفمبر ، أطلقت OTUS برنامجًا تعليميًا جديدًا "Software Architect" ، فيما يتعلق بهذا ، قمنا بإعداد سلسلة من المنشورات لطلاب المستقبل من الدورة التدريبية وقراء مدونتنا.
يعد إنشاء منتج جديد محفوفًا بالمخاطر دائمًا. يعد اختيار البنية المناسبة خطوة مهمة على طريق النجاح. إذا اخترت بين بنية متجانسة ، وموجهة نحو الخدمة ، و microservice وهندسة الخادم ، فإن هذا المنشور سوف يساعدك في اتخاذ القرار الصحيح.
العمارة متجانسة
متراصة هي كلمة قديمة تدل على كتلة حجرية ضخمة. على الرغم من أن المصطلح يستخدم على نطاق واسع اليوم ، إلا أن النظرة تظل كما هي في جميع المجالات. في هندسة البرمجيات ، يشير النموذج المترابط إلى وحدة واحدة غير قابلة للتجزئة. يتمثل مفهوم البرنامج المتجانس في دمج المكونات المختلفة للتطبيق في برنامج واحد على نفس النظام الأساسي. عادةً ما يتكون التطبيق المترابط من قاعدة بيانات وواجهة مستخدم عميل وتطبيق خادم. جميع أجزاء البرنامج موحدة ، وتتم إدارة جميع وظائفها في مكان واحد. دعونا نلقي نظرة على هيكل البرمجيات متجانسة بالتفصيل.
تعد البنية المتجانسة ملائمة للمجموعات الصغيرة ، لذا تختار العديد من الشركات الناشئة هذا النهج عند إنشاء تطبيق ما. مكونات البرنامج المترابط مترابطة ومترابطة ، مما يساعد البرنامج على تحقيق الاكتفاء الذاتي. تعتبر هذه البنية حلاً تقليديًا لإنشاء التطبيقات ، لكن بعض المطورين يجدونها قديمة. ومع ذلك ، فإننا نعتقد أن الهندسة المتجانسة هي الحل الأمثل في بعض الحالات.
على الرغم من أننا نتمتع بتجربة إيجابية في استخدام خدمات microservices في Google ، إلا أننا [في Scaylr] سلكنا طريقًا مترابطًا ، لأن وجود خادم مترابط واحد ينطوي على عمل أقل لنا كمهندسين.
ستيفن شيروينسكي ، رئيس قسم التصميم في سكايلر
لمعرفة ما إذا كان هذا الحل مناسبًا لعملك ، دعنا ننظر إلى إيجابيات وسلبيات.
مزايا العمارة متجانسة
التطوير المبسط والنشر
هناك العديد من الأدوات التي يمكنك دمجها لتسهيل التطوير. بالإضافة إلى ذلك ، يتم تنفيذ جميع الإجراءات مع دليل واحد ، مما يبسط عملية النشر. بفضل النواة المتجانسة ، لا يحتاج المطورون إلى نشر التغييرات أو التحديثات بشكل منفصل ، حيث يمكنهم القيام بذلك على الفور وتوفير الكثير من الوقت.
أقل القضايا الشاملة
تعتمد معظم التطبيقات على العديد من المهام المشتركة للمكونات ، مثل مسارات التدقيق ، وقطع الأشجار ، والحد من السرعة ، وما إلى ذلك. من السهل أن تأخذ التطبيقات المتجانسة هذه المشكلات في الاعتبار بسبب قاعدة الكود الشائعة الخاصة بها. من الأسهل توصيل المكونات بهذه المهام عندما يعمل كل شيء في تطبيق واحد.
أفضل أداء
عند التجميع بشكل صحيح ، تكون التطبيقات المتجانسة عادةً أكثر إنتاجية من التطبيقات المستندة إلى الخدمات المصغرة. على سبيل المثال ، قد يحتاج أي تطبيق بهندسة الخدمات الميكروية إلى إجراء 40 من مكالمات واجهة برمجة التطبيقات لـ 40 خدمة ميكروية مختلفة لتحميل كل شاشة ، مما يؤدي بوضوح إلى ضعف الأداء. توفر التطبيقات المتجانسة ، بدورها ، اتصالاً أسرع بين مكونات البرنامج بسبب الكود الشائع والذاكرة.
سلبيات العمارة متجانسة
قاعدة الكود تصبح مرهقة بمرور الوقت
مع مرور الوقت ، يستمر تطوير وتوسيع معظم المنتجات ، ويصبح هيكلها غير واضح. تبدأ قاعدة الكود في أن تبدو ضخمة جدًا وتصبح صعبة الفهم والتغيير ، خاصة للمطورين الجدد. كما أصبح من الصعب على نحو متزايد العثور على آثار جانبية وإدمان. مع نمو قاعدة الشفرة ، تتدهور الجودة ويتم تحميل IDE بشكل زائد.
من الصعب إدخال تقنيات جديدة
إذا كنت بحاجة إلى إضافة بعض التقنيات الجديدة إلى التطبيق الخاص بك ، فقد يواجه المطورون عقبات أمام التنفيذ. تعني إضافة تقنية جديدة إعادة كتابة التطبيق بالكامل ، وهو مكلف ويستغرق وقتًا طويلاً.
مرونة محدودة
في التطبيقات المتجانسة ، يتطلب كل تحديث بسيط إعادة نشر كاملة. وبالتالي ، يجب على جميع المطورين الانتظار حتى يتم ذلك. عندما تعمل عدة فرق في نفس المشروع ، يمكن تقليل المرونة بشكل كبير.
في النهاية
النموذج المتجانس ليس قديمًا ، وفي بعض الحالات لا يزال يعمل بشكل رائع. لا تزال بعض الشركات العملاقة ، مثل Etsy ، متجانسة ، على الرغم من شعبية الخدمات الدقيقة اليوم. يمكن أن تكون بنية البرنامج أحادي الليث مفيدة إذا كان فريقك في المرحلة الأولية ، وقمت بإنشاء منتج لم يتم التحقق منه ولم يكن لديك خبرة في الخدمات المصغرة. تعد وحدة الإنتاج المتجانسة مثالية للشركات الناشئة التي تحتاج إلى تشغيل المنتج في أسرع وقت ممكن. ومع ذلك ، فإن بعض المشكلات المذكورة أعلاه تسير جنبًا إلى جنب مع العمارة المتجانسة.
SOA
العمارة الموجهة نحو الخدمة (SOA) هي نمط من بنية البرنامج الذي يتضمن تطبيقًا معياريًا يتكون من وكلاء برمجيات منفصلين ومرتبطين بشكل فضفاض يؤدي وظائف محددة. يقسم الخدمية المكونات إلى دورين رئيسيين: مزود الخدمة والمستهلك. كل من هذه الأدوار يمكن أن تقوم به وكلاء البرمجيات. مفهوم الخدمية هو هذا: يمكن تصميم تطبيق ما وبهذه الطريقة بحيث يتم دمج وحداتها بسهولة ويمكن إعادة استخدامها بسهولة.
إيجابيات الخدمية
إعادة استخدام الخدمات
نظرًا لطبيعة المكونات الوظيفية المستقلة وغير المرتبطة بشكل فضفاض في التطبيقات الموجهة نحو الخدمة ، يمكن إعادة استخدام هذه المكونات في تطبيقات متعددة دون التأثير على الخدمات الأخرى.
خفة مصحوبة
نظرًا لأن كل خدمة برنامج وحدة مستقلة ، فمن السهل التحديث والصيانة دون التأثير على الخدمات الأخرى. على سبيل المثال ، يكون من السهل إدارة تطبيقات المؤسسات الكبيرة عند تقسيمها إلى خدمات.
موثوقية أعلى
الخدمات أسهل في التصحيح والاختبار من قطع كبيرة من التعليمات البرمجية ، كما هو الحال في متراصة. وهذا بدوره يجعل المنتجات القائمة على الخدمية أكثر موثوقية.
التنمية الموازية
نظرًا لأن البنية الموجهة للخدمة هي طبقات ، فهي تدعم التزامن في عملية التطوير. يمكن تطوير الخدمات المستقلة بشكل متوازٍ وإكمالها في نفس الوقت.
سلبيات الخدمية
صعوبة في الإدارة
العيب الرئيسي للهندسة المعمارية الموجهة نحو الخدمات هو تعقيدها. يجب أن توفر كل خدمة تسليم الرسائل في الوقت المناسب. يمكن أن يتجاوز عدد هذه الرسائل مليون في وقت واحد ، مما يجعل من الصعب إدارة جميع الخدمات.
ارتفاع تكاليف الاستثمار
يتطلب تطوير الخدمية استثمارًا كبيرًا في الموارد البشرية والتكنولوجيا والتطوير.
حمولة إضافية
في الخدمية ، يتم التحقق من صحة جميع المدخلات قبل أن تتفاعل إحدى الخدمات مع خدمة أخرى. عند استخدام خدمات متعددة ، يزيد هذا من زمن الاستجابة ويقلل من الأداء الكلي.
في النهاية
هو الأنسب الخدمية لأنظمة المؤسسة المعقدة مثل المصرفية. من الصعب للغاية تقسيم النظام المصرفي إلى خدمات ميكروية. لكن النهج المترابط غير مناسب أيضًا للنظام المصرفي ، حيث يمكن أن يتسبب جزء منه في تلف التطبيق بالكامل. أفضل حل هو استخدام نهج الخدمية وتنظيم التطبيقات المعقدة في خدمات معزولة ومستقلة.
بهذا نختتم الجزء الأول من الترجمة ، وسنتحدث عن الخدمات المصغرة والبنية بدون خادم في
الجزء الثاني من المادة.