متجانسة إلى خدمات مصغرة: متى ولماذا وكيف يتم الانتقال

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

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

تستكشف هذه المقالة الاختلافات بين بنيات monolithic و N-tier و microservices. كما يناقش أيضًا متى وكيف يتم الترحيل إلى بنية الخدمات المصغرة.

دعنا نتعمق!

ما هي العمارة المتجانسة؟

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

الايجابيات

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

سلبيات

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

ما هي العمارة متعددة المستويات؟

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

بشكل عام ، تعمل هذه البنية على فصل الاهتمامات واستخدام الطبقات لكل مهمة محددة. على سبيل المثال ، تُظهر الصورة التالية بنية من 3 طبقات لتطبيق MVC نموذجي. تتعامل طبقة النموذج مع مصادر البيانات ، وتعمل طريقة العرض كطبقة العرض التقديمي. تعمل وحدة التحكم كمعالج بين النموذج وطبقات العرض.

الايجابيات

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

سلبيات

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

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

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

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

الايجابيات

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

سلبيات

• زيادة التعقيد : يمكن أن تكون إدارة العديد من الخدمات المستقلة أكثر تعقيدًا.
• متطلبات موارد أعلى : قد يتطلب تشغيل العديد من الخدمات المزيد من الموارد والبنية التحتية.
• زيادة حمل الاتصال : يتطلب الاتصال بين الخدمات واجهات برمجة تطبيقات.
• زيادة تعقيد الاختبار والنشر : قد يكون اختبار العديد من الخدمات ونشرها أمرًا معقدًا.

متجانسة مقابل خدمات متعددة المستويات مقابل الخدمات المصغرة

يلخص الجدول التالي جميع الاختلافات الرئيسية: -

Monolithic to Microservices: ما هو الوقت المناسب لاتخاذ مرحلة انتقالية

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

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

Monolithic to Microservices: الرحلات الناجحة

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

قد تتوقع دراسات حالة عملية لتقييم كيفية اتخاذ الشركات الكبيرة لقرارات الهجرة. دعونا نناقش دراسات الحالة الخاصة بـ Amazon و Netflix لمعرفة كيف حددوا الوقت المناسب للترحيل.

دراسة حالة أمازون

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

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

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

دراسة حالة Netflix

Netflix هي شركة مشهورة ومعروفة للغاية في الوقت الحاضر. إنه متوفر في 190 دولة ولديه أكثر من 223 مليون مستخدم مدفوع اعتبارًا من عام 2022.

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

استغرق Netflix سنوات لترحيل تطبيقاتها الموجهة للعملاء وتطبيقات غير المخصصة لهم. ومع ذلك ، فإن الفوائد هائلة. زادت ساعات المشاهدة الشهرية للشركة بمقدار 1000 مرة بشكل حاد بين عامي 2008 و 2015 ~ مما أدى إلى ارتفاع الإيرادات والأرباح.

كيفية ترحيل تطبيقك من Monolithic إلى Microservices Architecture يدويًا

هناك عدة خطوات يمكنك اتباعها للانتقال (يدويًا) لتطبيقك من بنية متجانسة إلى بنية خدمات مصغرة:

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

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

أدوات يدوية للترحيل من monolithic إلى microservices

هناك العديد من الأدوات التي يمكن أن تساعد في عملية تفكيك التطبيق الأحادي إلى خدمات مصغرة. على سبيل المثال ، تعد Mono2Micro و Decomposition Tool و Decomposer من IBM من أكثر الأدوات شيوعًا التي تساعد في عملية التحلل.

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

التحلل التلقائي لترحيل Monolithic إلى Microservices: اتجاه مستقبلي

أحدث طفرة في الذكاء الاصطناعي والتعلم الآلي ثورة في الأساليب التقليدية لأداء مهامنا. ألن يكون من الرائع أن تقوم الآلات بمهام التحلل المتجانسة المعقدة للخدمات الدقيقة؟

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

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

تتبع عملية التحلل التلقائي ثلاث خطوات بسيطة.

الخطوة 01: الوصول إلى سجلات الوصول إلى URI

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

الخطوة 02: تطبيق خوارزمية ML العنقودية

خوارزمية التجميع هي طريقة تعلم آلي غير خاضعة للإشراف والتي ، في ضوء مجموعة من نقاط البيانات ، تنشئ مجموعات K لها نقاط بيانات ذات طبيعة مماثلة. عند تغذيتها ببيانات سجلات الوصول التاريخية ، تقوم خوارزمية التجميع هذه بإنشاء مجموعات من URIs لها وقت وصول مماثل وحجم مستند الاستجابة.

الخطوة 03: مجموعات نشر الخدمات المصغرة

يمكنك إنشاء خدمة مصغرة لكل مجموعة من عناوين URL. بعد ذلك ، يمكنك نشر هذه الخدمات المصغرة على أي بنية أساسية سحابية.

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

أفضل الممارسات للانتقال من Monolithic إلى Microservices Architecture

فيما يلي بعض أفضل الممارسات التي يجب اتباعها عند الترحيل من بنية متجانسة إلى بنية خدمات مصغرة:

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

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

استنتاج

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

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