تعرف على


Microservices


لتطوير المشاريع التقنية

الطريقة التقليدية

بالطريقة التقليدية تنفيذ برمجة المشاريع التقنية (موقع أو تطبيق ولوحة تحكم) لمشروع ما مثل متجر إلكتروني، خدمة حكومية، تطبيق لشركة ناشئة… يتم من خلال تطوير المشروع بلغة برمجة يتقنها الفريق فينطلق المشروع صغيراً ثم يبدأ يتوسع بإضافة المزايا على نفس المشروع المبني والمنشور وقد يتم تطوير لوحة التحكم وتطوير API كذلك على نفس المشروع الذي تم بناءه كمشروع واحد ويتم الاتصال بقاعدة البيانات بشكل مباشر، مثلاً إنشاء مشروع متجر إلكتروني بلغة برمجة محددة ويحتوي على كل مزايا المتجر الإلكتروني عضويات، منتجات، سلة مشتريات، كوبونات، دفع، مبيعات… وكل ميزة يتم تطويرها (في نفس المشروع) كميزة إضافية Module أو Plugin مثلاً إضافة ميزة قائمة الأمنيات، وكل عضو بذلك سيقوم بتطوير أي ميزة على (نفس المشروع المنُفَذ كاملاً)، والأمور تسير بشكل جيد بدون Microservices صحيح؟ المشكلة هي عندما يكبر حجم المشروع تأتي المعوقات وتزداد، ومن يفكر جيداً قد يبني API كنظام واحد كامل لاحتياجات المشروع في الموقع والتطبيق ولوحة التحكم ولكن هذا لا يزال ليس الخيار الأفضل للتطوير ولا يلبي مزايا التطوير باستخدام Microservices …

ماذا يمكننا أن نفعل

عوضاً عن الطريقة التقليدية؟

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

تسمى الطريقة التقليدية بالاسم Monolithic Architecture

حيث Mono تعني Single أي واحد و Lithic تعني Stone أي حجر فالكلمة
(Single Stone) حجر واحد هي أسلوب الهيكلة والتطوير بالطريقة التقليدية


ما هي Microservices باختصار؟

ولا يهمك … باختصار Microservices كتعريف أساسي عبارة عن هيكلة بناء Architecture بنمط محدد Pattern لتطوير فكرة برنامج (خدمة) بدلاً من انشاء مشروع برمجي واحد يتم تقسيمه بإنشاء عدة مشاريع برمجية وكل مشروع عبارة عن جزء (خدمة مصغرة) من كامل فكرة البرنامج، ويتم التواصل من قبل بعضها البعض باستخدام API والتي تكون بطريقة REST عادةً … وبذلك يمكن العمل على كل خدمة مصغرة وبنائها واختبارها وتطويرها ونشرها وتوسيع نطاقها كمشروع مستقل.

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

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


توضيح أكثر من خلال Git: كل خدمة مصغرة من المشروع عبارة عن Repo مستقل في Git ولا يتم اضافة الخدمات المصغرة في مشروع واحد مشترك لكن يتم التواصل بكل خدمة مع الخدمات المرتبطة بها من خلال API.


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


توضيح أكثر بالصورة:

الفرق بين الطريقة التقليدية Monolithic و Microservices

هيكلة بناء الطريقة التقليدية


هيكلة بناء Microservices

لماذا Microservices تعتبر أفضل رغم أنه يتضح بأن الطريقة التقليدية شكلها أسهل كهيكل بناء لأن المضمون يكون في الحاجة والفائدة المستقبلية (للمشروع الواعد) المناسب لاستخدام هذه الهيكلية فيه وللمساهمة في نموه أكثر وسهولة التعامل مع الخدمات المصغرة بشكل مستقل مما يعطي نتائج أفضل وسيتم سرد كامل الفروقات والمزايا بالتفاصيل في بقية المقال …

ما هي مشاكل التطوير
بالطريقة التقليدية
قبل Microservices

  • التطوير والاختبار والنشر للنظام كامل مع كل ميزة مما يتحتم على ذلك:

    1. التطوير بالتعامل مع النظام كامل كل مرة كل عضو بالفريق بتقنية واحدة

    2. اختبار النظام كامل لأن أي مشكلة قد تؤثر على النظام

    3. أي ميزة إضافية تعني رفع ونشر النظام كامل من جديد وما يواجه ذلك

  • تواجد النظام كامل على بيئة واحدة رغم اختلاف استهلاك الموارد لكل خدمة في النظام في أوقات مختلفة فعند عمل scale up سيكون على النظام كامل مما يكون غير منطقي للـ Scalability

  • تصاعد تعقيدات أنظمة المشاريع التقنية كمثال بسيط في السابق المستخدم يسجل مباشرة من خلال الموقع، لكن الأن هناك طرق كثيرة للتسجيل والدخول : (بريد إلكتروني، OAuth عبر جوجل أو تويتر…، SMS OTP) ومن خلال قنوات متعددة بالموقع والتطبيق … للمستخدم والبائع والمندوب … الخ ومع ارتباط ذلك بالنظام كامل ككتلة واحدة تتصاعد التعقيدات.

  • صعوبة التعامل كـ Third Parties طرف ثالث من خلال نظام واحد متكامل.


مزايا Microservices

في الغالب هي عكس عيوب ومشاكل الطريقة التقليدية ونذكرها كالتالي:

  • المرونة Flexibility حيث يمكن لكل Service أن تكون مستقلة بالتنفيذ والتطوير والفريق والنشر بأي لغة برمجة وعلى أي سيرفر… وتتحدث مع باقي الخدمات من خلال Rest API أو غيره.

  • التدريج في المواصفات Scalibility حيث يمكن لكل Service أن تكون مستقلة وعمل Scale لها حسب مما تحتاجه بغض النظر عن باقي الـ Microservices وزيادة الموارد لها في السيرفر.

  • الاعتمادية Reliability كمثال أنه في حالة حدوث خطأ أو مشكلة على خدمة ما أو على الخادم لهذه الخدمة فلا يأثر على باقي الخدمات.

  • تسهيل التعقيد Simplicity فأن فصل النظام كخدمات مستقلة يقلل التعقيدات والحاجة لفهم خدمة بدلاً من النظام كامل بكل الخدمات.


من يستخدم Microservices؟

  • Amazon

  • Netflix

  • Uber

  • Ebay

  • Groupon

  • Twitter

  • Paypal

  • Walmart


تجربة شركة Uber للانتقال إلى Microservices

بدأت شركة Uber بالطريقة التقليدية Monolithic Architecture وذلك عندما كانت الخدمة تغطي سان فرانسيسكو فقط وكانت هذه الطريقة بالنسبة لأوبر هي الأفضل وقتها.

عندما بدأت شركة Uber بالتوسع لمدن أخرى وإضافة خدمات أخرى أصبح تواجد كل المنطق (Logic) في مكان واحد ونظام واحد غير عملي وبدأ بذلك يظهر عيوب استخدام Monolithic Architecture حيث أن كل المزايا والخدمات تأتي coupled أي مرافقة للنظام كامل مما وصل الامر عند إضافة تغيير واحد يحتاج إلى Redeploy كامل للمشروع وما يتخلل ذلك من عدة مشاكل، وبعدها تم الانتقال الى Microservices مما حل تلك المشاكل وأدى إلى تحسين مرونة العمليات لديهم وسلاسة التكامل المستمر وطرح تجربتهم الإيجابية كما فعلت الشركات الأخرى الكبيرة...

يمكن معرفة اذا كان مناسب استخدام Microservices بالإجابة على ٦ أسئلة

  1. هل هناك معدل كبير وسريع من التغييرات؟

  2. هل توجد دورات حياة مستقلة؟

  3. هل هناك حاجة لزيادة المواصفات والموارد بشكل مستقل لبعض الخدمات؟

  4. هل ترغب أن يكون بالنظام فشل معزول لا يأثر على توقف بقية النظام؟

  5. هل النظام كبير ويحتاج إلى تبسيط التطوير بخدمات مفصلة؟

  6. هل تحتاج إلى تقنيات مختلفة تلبي عدة احتياجات للمشروع؟

هل لـ Microservices عيوب؟

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

وبالنسبة لعيوب Microservices والتي يمكن السيطرة عليها حسب ما يمكن لذلك نسميها تحديات أفضل من كلمة عيوب خصوصاً عندما يكون هذا الخيار الأمثل للاستخدام حسب الأسئلة السابقة :

  1. التعامل مع التعقيدات المرتبطة بالنظم الموزعة

  2. تعدد قواعد البيانات والعمليات قد تكون متعبة إذا لم تدار جيداً

  3. الحاجة لتتبع ومعرفة أين وكيف تعمل المشاريع المستقلة كخدمات بشمولية

ملاحظة مهمة

لا تعامل كل Service في الـ Microservices على أنها Monolithic حتى لا تقع في خطأ بالاعتقاد انك تعمل على أكثر من Monolithic وتكرر مشاكلها في كل مرحلة تطوير بدلاً من أن تقللها بالمشروع ومهم التعامل مع Containers لأهميتها في تسهيل الرفع وعمل Scale


لا شك
يتطلب Learning Curve (منحنى تعلم) كافي للتطوير بطريقة Microservices وعدم إتقانها وعدم العمل على الآلية والتقنيات المناسبة لتطبيقها يجعلها صعبة وغير محببة❌ بلا شك

ما هو SOA وما علاقته بـ Microservices

SOA اختصاراً لـ Service-Oriented Architecture وهناك تشابه مع Microservices من ناحية بناء الخدمات (Services) لكن اختلاف من ناحية الفكرة والهدف حيث أن SOA الهدف منها توفير خدمات كأدوات متنوعة لإعادة استخدامها بشكل عام وليست مبنية أساساً بشكل مخصص من أجل نظام أو برنامج، بينما Microservices الهدف منها متعلقة بتطوير خدمات لبناء نظام متكامل لديك معرفة انك تقوم ببناء هذا النظام أو البرنامج من خلال Microservices بمزايا مخصصة لهذا المشروع ويمكن أيضاً إعادة استخدامها لكن ليس متطلب وليست مصممة من أجل ذلك بالتحديد، وهناك الكثير من الفلسفة المتعلقة بالفروقات ولكن نهاية الأمر هذا هو الفرق الأساسي.

خاتمة

أتمنى أن أكون وفقت في إيصال المعلومة بشكل مفيد ومختصر وواضح

محبكم عبدالملك الثاري

ارحب بمتابعتك عبر تويتر althari@