في منشور سابق ، تحدثنا عن كيف أصبحت الخدمات السحابية معيارًا غير مكتوب لتقديم خدمات تكنولوجيا المعلومات. من السهل تخمين أنه يتعين على الشركات التي لا تزال ترغب في جني الأموال من تطبيقات المستخدم أن تتكيف وأن تنشئ منتجات جديدة مع مراعاة نهج Cloud-Native. لكن بالنسبة للمطورين ، هذه أخبار إيجابية بالتأكيد ، حيث أن استخدام التقنيات السحابية يفتح فرصًا جديدة هائلة لهم. الشيء الرئيسي هو أن تكون قادرة على التخلص منها بشكل صحيح.
عندما يطلب تطبيق بيئة
إذا كنت قد قرأت بالفعل
دليل التكنولوجيا السحابية ، فربما تتذكر أن تقنية المحاكاة الافتراضية هي واحدة من "المصادر السحرية" للسحب. بفضل هذا ، لا يحتاج المطور عملياً للتفكير في معلمات الخوادم التي سيعمل عليها تطبيقه. لماذا قضاء بعض الوقت في هذا إذا كان برنامج hypervisor أو الحاوية التي تم تهيئتها بشكل صحيح يمكن أن يقوم بتكوين جهاز مع أي الخصائص التي يحتاجها أي تطبيق تقريبًا؟
تطوير هذه الفكرة هو نهج البنية التحتية كرمز (IAC). جوهرها هو تمكين المطورين أو خدمات التشغيل من استخدام نفس الأساليب المستخدمة خلال مرحلة التطوير للحفاظ على البنية التحتية. يتيح لك إعداد وحدات التحكم في البرامج الشائعة مقدمًا ودمج هذه المكونات بسهولة في المشاريع الجديدة.
إن قدرات مراكز البيانات الحديثة تسمح لنا بالفعل بالانتقال إلى اللغة التصريحية لإدارة البنية التحتية. من الناحية المثالية ، يجب أن يدير التطبيق تجمع الموارد الذي يشغله في مركز البيانات. سيسمح ذلك للمطور بعدم قفل القيود المرتبطة بعملية العمل مع البنية التحتية ، عندما يكون من الضروري الطلب والتصميم مسبقًا أو في حالة تكرار نفس مكونات البنية التحتية في مشاريع مختلفة.
في الواقع ، يقوم المطور أو المهندس بإجراء "طلب السحب" ، الذي يحتوي على تكوين الجهاز الظاهري (kernel ، الذاكرة ، الشبكة ، القالب ، إلخ) ، ثم يقوم مدير البيئة الافتراضية بإنشاء الجهاز بشكل مستقل أو إنشاء مثيل لقاعدة بيانات جديدة أو بدء تشغيل الخدمة المثبتة مسبقًا ، وفقًا للإعدادات في ملف. هذا النهج هو الخلاص الحقيقي عند العمل مع البيانات الكبيرة والشبكات العصبية. تتطلب التطبيقات المرتبطة بهذه التقنيات ، في بعض الحالات ، تغيير كميات الذاكرة وقوة المعالج ديناميكيًا.
على سبيل المثال ، لتدريب شبكة ، من الضروري "دفع" مئات غيغا بايت من المعلومات عبرها ، وتتيح السحب الحصول على السعة المطلوبة لذلك عند الطلب. بعد اكتمال التدريب ، يتم إرجاع الموارد إلى تجمع الموفر ، ولا يحتاج المطور إلى التفكير في كيفية أخذها أو كيفية تكوين التطبيق بطريقة مختلفة بحيث يستمر في العمل بكمية أقل.
متراصة مقابل أمر الفوضى
نظرًا لحقيقة أن السحب يمكن أن تتكيف بمرونة مع احتياجات المطور ، فإن هذا ، نظريًا ، يبسط مهمة أخرى - مشكلة توسيع نطاق التطبيقات. لماذا نظريا؟
لسوء الحظ ، فإن مهمة تحجيم التطبيقات ليست خطية. لكي يتعامل التطبيق مع الأحمال الضخمة أثناء فترات ذروة الحضور (أو الحوسبة) ، لا يكفي فقط منحه ذاكرة إضافية وطاقة المعالج. على الإطلاق ، لكل تطبيق تقليدي عتبة ، وبعد ذلك لم يعد قادرًا على "هضم" موارد جديدة وإظهار زيادة في الأداء. المشكلة في هذه الحالة ليست في الموارد ، ولكن في بنية معظم البرامج.
هذه المشكلة حادة بشكل خاص للتطبيقات ذات بنية متجانسة ، والتي ، في الواقع ، هي ملفات ثنائية واحدة. مزايا هذا النهج واضحة: التطبيقات المتجانسة بسيطة للغاية وخطية. يمكن توقع جميع سيناريوهات سلوك المستخدم وتعقبها وتصحيحها إذا لزم الأمر.
ومع ذلك ، فإن هذه البساطة لها ثمن. أولاً ، هذه هي مشاكل التحجيم المذكورة أعلاه. في مرحلة ما ، حتى التطبيق المترابط الأكثر تفكيرًا يتوقف عن العمل بكفاءة أكبر من الترقية إلى تكوين الخادم الذي يعمل عليه.
ثانياً ، ليس من السهل نقل تطبيق متآلف إلى خوادم جديدة وقد يتطلب ذلك إعادة تجميع كاملة للبرنامج.
ثالثًا ، من الصعب الحفاظ على مثل هذا التطبيق وتطويره. يتطلب أي منعطف التحديث التجميع الكامل للبرنامج بأكمله ، ويمكن أن يؤدي خطأ في واحدة من كتل التعليمات البرمجية في سقوط النظام بأكمله.
بحثًا عن أفكار حول كيفية حل هذه المشكلات ، تم تطوير مفهوم آخر - الهندسة المعمارية الموجهة نحو الخدمة (SOA). يعني ذلك أن التطبيق مقسم إلى عدة وحدات ، كل منها يوفر للآخرين نوعًا من الوظائف. تتفاعل الوحدات مع بعضها البعض من خلال مجموعة من خدمات الويب ، ويمكنها الوصول بشكل مستقل إلى قاعدة بيانات أو قواعد البيانات الخاصة بها.
هذا النهج يبسط بالفعل دعم البرنامج ولا يحول تحديثه "إلى عمل sapper" ، حيث لا يوجد مجال للخطأ ؛ ولكن لديه أيضا عيوبه. المفتاح هو مشاكل التوسع في تطوير مثل هذه التطبيقات. مع نمو البرنامج ، يصبح من الصعب أكثر فأكثر "دفع" الميزات الجديدة إلى الحزم 5-10 المعتمدة أصلاً من قبل المهندس المعماري. عددهم ينمو ، والذي يتحول إلى مشاكل مع الدعم.
Microservice كعنصر من تطور التطبيق
إن نتيجة تطور الخدمية هي فكرة هندسة الخدمات الميكروية ، والتي تُستخدم في تصميم التطبيقات السحابية. من الناحية النظرية ، تتشابه أفكار كلتا الطريقتين إلى حد كبير ، ولا يفرد بعض المهندسين المعماريين حتى بنية الخدمات الدقيقة كنموذج منفصل ، معتبرين أنها حالة خاصة من الخدمية.
تتضمن بنية Microservice أن التطبيق لا يتكون من عدد صغير من الوحدات الكبيرة ، ولكن من العديد من الأجزاء المستقلة. على عكس المتراصة ، في تطبيق microservice ، يمكنك استخدام طرق مختلفة لتفاعل المكونات مع بعضها البعض. لا يحتوي النظام على حالة واحدة محددة مسبقًا. بدلاً من ذلك ، يعمل كل مكون "وفقًا للحالة": بمجرد تلقي حدث ما ، يبدأ العمل. وهذا يسمح بهندسة مرنة للغاية ومستقلة.
في الوقت نفسه ، يتغير باستمرار عدد الخدمات في تطبيق خدمات microservice - تتم إضافة بعضها ، بينما يتم حذف بعضها. في النهج الجديد ، يمكن استبدال أي خدمة microservice وبدلاً من ذلك ، يتم تضمين سلسلة من خدمات microservices. الخدمات الأخرى تستمر في العمل بثبات ، لأنها ليست مرتبطة مباشرة. هذا هو التطور الطبيعي للبرنامج. بفضل هذا ، يتمتع المطورون والمهندسون المعماريون بفرصة لتغيير شيء بسرعة من أجل الاستجابة للتغيرات في متطلبات الأعمال وتفوق المنافسين.
بالإضافة إلى زيادة سرعة تحديث التحديثات ، فإن استخدام بنية الخدمات المجهرية يسمح بالإدارة اللامركزية. يحق للفريق المسؤول عن تطوير الخدمة تحديد بنيتها الداخلية وميزاتها. هذا النهج ، بالمناسبة ، يتم تنفيذه الآن من قبل مجلس سبيربنك المعماري في كتلة التكنولوجيا.
في الوقت نفسه ، أثناء الجلوس لتطوير تطبيق السحاب الخاص بك ، يجب ألا تتسرع في سحقه سريعًا إلى العناصر المكونة له. المعارض الرئيسي لمثل هذا النهج الطائش هو مارتن فاولر ؛ هو أحد مؤلفي فكرة العمارة المجهرية. من الأسهل في البداية استخدام نهج مترابط ، ثم تحفيز تطور التطبيق "بطريقة طبيعية" ، مع التركيز على انهيار الاختناقات وإضافة وظائف إضافية.
نتيجةً لذلك ، يمكننا صياغة القاعدة التالية: مهمة المبرمج عند العمل باستخدام بنية microservice لا تقتصر فقط على تقسيم التطبيق إلى أقصى عدد ممكن من المكونات ، ولكن للتمييز المتعمد بين مسؤوليتهم عن تلقي البيانات ومعالجتها.
أربعة تفاصيل
بالإضافة إلى العديد من المزايا الواضحة ، تتميز بنية الخدمات الميكروية بخصائصها الخاصة ، والتي يجب مراعاتها عند تطوير تطبيق السحاب. على وجه الخصوص ، لدعم تشغيل مثل هذا التطبيق ، من الضروري الحفاظ باستمرار على المتطلبات المتزايدة لجودة إدارة واجهات برمجة التطبيقات الداخلية.
عندما يغير أحد المكونات واجهته ، يجب أن يدعم التوافق مع الإصدارات السابقة لدعم الإصدار السابق من واجهة برمجة التطبيقات الخاصة به. في حالة ملاحظة هذه القاعدة ، يمكنك التبديل ديناميكيًا من الإصدار القديم إلى الإصدار الجديد دون إخفاقات. إذا لم ينجح دعم الإصدار السابق من واجهة برمجة التطبيقات ، فإن هذا يهدد ، في أحسن الأحوال ، بفقدان جزء من وظائف التطبيق ، وفي أسوأ الأحوال ، حدوث أعطال دائمة في تشغيله.
الميزة المهمة الثانية لتطبيقات microservice هي صعوبة العثور على الأخطاء فيها. إذا تعطل تطبيق مكتوب في منطق متآلف أو الخدمية ، فلن يكون من الصعب العثور على مصدر المشكلة. في تطبيق يتكون من العديد من الخدمات ، قد يستغرق البحث عن سبب الخطأ وقتًا طويلاً نظرًا لأن البيانات الواردة من المستخدم غالبًا ما تمر عبر العديد من الخدمات المصغرة ، ومن الصعب تحديد أي منها يتعطل. في الوقت نفسه ، يجب تنفيذ عملية البحث عن الأخطاء بعناية فائقة: أي إعادة بيع غير ناجحة يمكن أن تؤدي إلى انهيار وحدة العمل ، بالإضافة إلى المشكلة الأولية ، سيتلقى المطور مشكلة ثانية.
التفاصيل الهامة الثالثة التي يجب مراعاتها عند تطوير تطبيق السحاب هي الطريقة التي تتفاعل بها مكوناتها مع بعضها البعض. كما هو الحال في الخدمية ، تستخدم الخدمات خدمات الويب لتبادل البيانات ، لكن أنماط التفاعل ، مثل التدفق ، CQRS ، تحديد مصادر الأحداث ، ظهرت في بنية الخدمة المجهرية. عادةً ما يتوقع المطورون أن يكون زمن الاستجابة بين الطلب والاستجابة في التطبيق صغير جدًا. في النظام الموزع ، لا يمكن للمرء حتى الاعتماد على حقيقة أن الجواب سيأتي على الإطلاق.
أيضًا ، في بنية التطبيقات السحابية ، تستخدم الخدمات المصغرة قواعد بيانات متعددة مناسبة تمامًا لحل مشاكلها المحددة. على سبيل المثال ، يمكن للشبكات القراءة بسرعة ، ولكن بالكاد تستطيع التعامل مع عدد كبير من عمليات تغيير البيانات. هذه القاعدة مناسبة تمامًا للحفاظ على حسابات الودائع - نادراً ما تتغير. هناك نوع آخر من العمليات قيد المعالجة ؛ يمكن أن يكون هناك عشرات التغييرات على كل خريطة فيها كل يوم ، وعلى العكس ، هناك قراءات قليلة من البيانات.
أخيرًا ، الحقيقة الرابعة التي تحتاج إلى تذكرها عند تطوير تطبيق سحابي هي أن بنية الخدمات الميكروية تركز أساسًا على استخدام خدمات عديمي الجنسية. في هذه الحالة ، لا تذهب إلى التطرف. بعض الخدمات ، إذا لزم الأمر ، لا يزال بإمكانها تقديم الدعم الحكومي إذا كان منطق العمل يتطلب ذلك ، ويجب تصميمها بعناية خاصة.
على سبيل المثال: إذا قدم المستخدم طلبًا للحصول على قرض ، فيجب على النظام الذي تلقى التطبيق حفظ هذه الحالة من أجل تحويلها إلى خدمات أخرى. لكن الخدمة المسؤولة عن العثور على المعلومات في الملف الداخلي لتاريخ الائتمان قد لا تحفظ حالتها وتنسى البيانات التي اسم المستخدم الذي بحثت عنه منذ بضع دقائق - على أي حال ، بعد لحظة سيأتي طلب جديد (على الرغم من أنه في هذه العملية قد يكون سلوك خدمة مختلفة).
جميع الأمثلة والممارسات المذكورة أعلاه تستخدم بالفعل بنشاط من قبل قادة صناعة تكنولوجيا المعلومات العالمية. على سبيل المثال ، تعد Netflix رائدة في تطوير بنية الخدمات المصغرة. أصدرت الشركة العديد من التطبيقات المفتوحة المصدر والمكتبات وإطار عمل لرصد وتوازن وتسجيل تطبيقات الخدمات التي تعمل بالمجهر.