إذا نظرنا إلى الوراء في الماضي قبل حوالي خمس سنوات ، يمكنك أن ترى كم تغير منذ ذلك الحين الموقف من بنية الخدمات الصغيرة. في البداية كانت شعبية للغاية. بعد نجاح Netflix و Amazon و Gilt.com ، قرر المطورون أن التطوير الفعلي للخدمات الميكروية لا يختلف عن تطوير التطبيقات. لقد أدرك الجميع الآن أن الخدمات المصغرة هي أسلوب معماري جديد فعال لحل بعض المشكلات ، ولديها إيجابيات وسلبيات.
لفهم ماهية الخدمات المجهرية وما هي الحالات التي ينبغي استخدامها ، التفتنا إلى خايمي بويلتا ، مؤلف كتاب التدريب العملي على الإرشادات الدقيقة مع بيثون. تحدث عن مزايا هذه البنية ، كما شارك التوصيات للمطورين الذين يخططون للتبديل إليها من متراصة.
الفوائد والمخاطر
يجمع التطبيق التقليدي المترابط بين جميع إمكانياته في وحدة واحدة متصلة. في حالة الخدمات الصغيرة ، فإن العكس هو الصحيح. ينقسم التطبيق إلى خدمات أصغر مستقلة يمكن نشرها وتحديثها واستبدالها بشكل مستقل. يتم إنشاء كل خدمة microservice لغرض عمل واحد ويمكن أن تتفاعل مع خدمات microservices الأخرى باستخدام آليات بسيطة.
يوضح Buelta: "إن بنية الخدمات المصغرة هي طريقة لتنظيم نظام تتواصل فيه عدة خدمات مستقلة مع بعضها البعض بطريقة معينة (يحدث هذا عادةً مع خدمات RESTful على الويب). الميزة الرئيسية هي أن كل خدمة ميكروية قادرة على التحديث والنشر بشكل مستقل عن الآخرين. "
لا تحدد بنية الخدمات الميكروية فقط كيفية إنشاء التطبيق الخاص بك ، ولكن أيضًا كيفية تنظيم فريقك.
"يمكن لفريق واحد مستقل أن يكون مسؤولاً مسؤولية كاملة عن الخدمة الصغيرة. وهذا يسمح للمؤسسات بالنمو دون دفع المطورين معًا ".
واحدة من المزايا الرئيسية للخدمات الصغيرة هي أنها تتيح لك تقديم الابتكارات دون أي تأثير خاص على النظام ككل. بمساعدة الخدمات الصغيرة ، يمكنك إجراء القياس الأفقي ، ووضع حدود واضحة للوحدات النمطية ، واستخدام مجموعة متنوعة من التقنيات وإجراء تطوير متوازي.
عندما سئل عن المخاطر المرتبطة بالخدمات المصغرة ، أجاب Buelta: "إن الصعوبة الرئيسية في تنفيذ الهيكل (وخاصة عند الانتقال من متراصة) هي إنشاء تصميم تكون فيه الخدمات مستقلة حقًا. إذا تعذر تحقيق ذلك ، فستصبح الاتصالات بين الخدمات أكثر صعوبة ، مما يؤدي إلى تكاليف إضافية. تحتاج Microservices إلى محترفين سيشكلون اتجاه التطور على المدى الطويل. أوصي المؤسسات التي ترغب في الانتقال إلى مثل هذه البنية لتعيين شخص مسؤول عن "الصورة الكبيرة". وقال خايمي "نحن بحاجة إلى النظر في الخدمات المصغرة على نطاق أوسع".
الانتقال من متراصة إلى الخدمات الصغيرة
ينصح مارتن فاولر ، وهو مؤلف ومستشار برمجيات معروف ، بالالتزام بمبدأ "الأول هو متراصة". ويرجع ذلك إلى حقيقة أن استخدام بنية microservice من بداية التطوير أمر محفوف بالمخاطر ، لأنه في معظم الحالات مناسب فقط للأنظمة المعقدة وفرق التطوير الكبيرة.
"المعيار الرئيسي الذي يجب أن يشجعك على التحول إلى بنية جديدة هو حجم فريقك. المجموعات الصغيرة لا ينبغي أن تفعل هذا. في مثل هذه الظروف ، يفهم المطورون بالفعل كل ما يحدث مع التطبيق ، ويمكنهم دائمًا طرح سؤال توضيحي على أحد الزملاء. وقال جايمي "إن المتراصة تعمل بشكل مثالي في هذه المواقف ، وبالتالي يبدأ كل نظام تقريبًا". هذا يؤكد "قاعدة بيتزا اثنين" من أمازون ، والتي بموجبها يمكن أن يتغذى الفريق المسؤول عن خدمة ميكروية واحدة ببيتزا - وإلا فإنه كبير جدًا.
"مع نمو الشركة وزيادة فرق التطوير ، قد تكون هناك حاجة إلى تنسيق أفضل. غالبًا ما يبدأ المبرمجون في التداخل مع بعضهم البعض. أصبح فهم الغرض من جزء معين من التعليمات البرمجية أكثر صعوبة. في مثل هذه الحالات ، يكون الانتقال إلى الخدمات المجهرية أمرًا منطقيًا - حيث سيساعد ذلك على مشاركة المسؤوليات وتوضيح الصورة العامة للنظام. يمكن لكل فريق تحديد أهدافه الخاصة والعمل بشكل مستقل بشكل رئيسي ، مع إعطاء واجهة خارجية واضحة. ومع ذلك ، لكي يكون هذا الانتقال منطقيًا ، يجب أن يكون هناك العديد من المطورين ".
توصيات للترحيل إلى الخدمات الصغيرة
ورداً على سؤال حول التوصيات العملية التي يمكن أن يستخدمها مطورو البرامج عند التبديل إلى الخدمات المصغرة ، قال Buelta: "مفتاح بنية الخدمات المصغرة الناجحة هو أن كل خدمة يجب أن تكون مستقلة قدر الإمكان."
السؤال الذي يطرح نفسه: "كيف يمكنك جعل الخدمات مستقلة؟" أفضل طريقة لاكتشاف ترابط أي نظام هي التفكير في إمكانيات جديدة: "إذا كنت تريد إضافة وظيفة جديدة ، فهل يمكن تنفيذها عن طريق تغيير خدمة واحدة فقط؟ ما هي أنواع الوظائف التي تتطلب تنسيق العديد من الخدمات المصغرة؟ هل سيتم استخدامها كثيرًا أم نادرًا؟ "من المستحيل إنشاء تصميم مثالي ، ولكن على الأقل يمكنك استخدامه لاتخاذ القرارات الصحيحة والمستنيرة" ، تشرح Buelt.
ينصح Jaime بالتبديل إلى البنية بشكل صحيح بحيث لا تضطر إلى إعادة كل شيء لاحقًا. "بمجرد اكتمال الانتقال ، سيكون تغيير حدود الخدمات الصغيرة أكثر صعوبة. من المفيد تخصيص مزيد من الوقت للمرحلة الأولية من المشروع. "
يعد الانتقال من نمط تصميم إلى آخر خطوة خطيرة. سألنا عن المشكلات التي واجهها خايمي وفريقه أثناء الانتقال إلى الخدمات المصغرة ، والتي أجاب عليها:
في الواقع ، ترتبط الصعوبات الرئيسية بالناس. عادةً ما يتم التقليل من شأن هذه المشكلات ، لكن التبديل إلى خدمات microservices يغير بالفعل طريقة عمل المطورين. المهمة ليست سهلة! ويضيف: "لقد واجهت شخصيًا مشكلات مماثلة. على سبيل المثال ، كان علي تدريب وتقديم المشورة للمطورين. من المهم بشكل خاص توضيح سبب ضرورة إجراء بعض التغييرات. هذا يساعد الناس على فهم أسباب تقديم جميع الابتكارات التي قد لا يحبونها.
عند الانتقال من بنية متجانسة ، يمكن أن تنشأ صعوبات كثيرة عند نشر تطبيق تم إصداره مسبقًا كوحدة نمطية واحدة. يتطلب تحليلًا أكثر شمولية لضمان التوافق مع الإصدارات وتقليل المخاطر. في بعض الأحيان يكون التعامل مع هذه المهمة صعباً للغاية ".
أسباب لاختيار Docker و Kubernetes و Python كمكدس للتكنولوجيا الخاصة بك
سألنا Buelt عن التكنولوجيا التي يفضلها لتنفيذ الخدمات المصغرة. فيما يتعلق باختيار اللغة ، كانت الإجابة بسيطة: "بيثون هو الخيار الأفضل بالنسبة لي. هذه هي لغتي البرمجة المفضلة! .. هذه اللغة مناسبة تمامًا للخدمات الميكروية. أنها مريحة للقراءة وسهلة الاستخدام. بالإضافة إلى ذلك ، لدى Python وظائف واسعة لتطوير الويب ونظام ديناميكي ديناميكي للوحدات الخارجية لأية احتياجات. تشمل هذه الاحتياجات الاتصال بالأنظمة الأخرى ، مثل قواعد البيانات ، واجهات برمجة التطبيقات الخارجية ، إلخ. "
غالبًا ما يتم اعتبار Docker كأحد أهم أدوات خدمات microservices. وأوضح Buelta لماذا:
"يتيح لك عامل الإرساء تغليف التطبيق ونسخه في حزم قياسية مناسبة. هذا يقلل من عدم اليقين وتعقد البيئة. كما أنه يبسط إلى حد كبير الانتقال من التطوير إلى إنتاج التطبيق. علاوة على ذلك ، يتم تقليل الوقت لاستخدام المعدات. يمكنك وضع العديد من الحاويات في بيئات مختلفة (حتى في أنظمة التشغيل المختلفة) في صندوق فعلي واحد أو جهاز ظاهري. "
حول Kubernetes:
"Kubernetes يسمح لك بنشر حاويات Docker متعددة بطريقة منسقة. هذا يجعل المطورين يفكرون بطريقة مجمعة ، ويتذكرون بيئة الإنتاج. كما يسمح لك بتعريف كتلة باستخدام التعليمات البرمجية بحيث يتم تعريف عمليات النشر أو تغييرات التكوين الجديدة في الملفات. كل هذا يجعل الطرق الممكنة مثل GitOps (كتبت عنها في كتابي) ، مع الحفاظ على التكوين الكامل في نظام التحكم في الإصدار. يتم إجراء كل تغيير بطريقة محددة وقابلة للعكس ، نظرًا لأنه دمج منتظم. بفضل هذا ، من السهل جدًا استعادة البنية التحتية أو تكرارها. "
"عليك قضاء بعض الوقت في تعلم دوكر وكوبرنيتيس ، لكن الأمر يستحق ذلك. كلا الأدوات قوية جدا. بالإضافة إلى ذلك ، فإنهم يشجعونك على العمل بطريقة تتجنب المشاكل أثناء الإنتاج "، كما يقول بيلت.
خدمات متعددة اللغات
عند تطوير خدمات micros ، يمكنك استخدام مجموعة متنوعة من التقنيات ، نظرًا لأن الفريق المستقل مسؤول بشكل مثالي عن كل واحدة منها. شارك Buelta رأيه بشأن الخدمات المصغرة متعددة اللغات: "الخدمات المصغرة متعددة اللغات رائعة! هذه هي واحدة من المزايا الرئيسية للهندسة المعمارية. مثال نموذجي لخدمات micros متعددة اللغات هو نقل التعليمات البرمجية القديمة المكتوبة بلغة واحدة إلى لغة جديدة. يمكن أن تحل أي خدمة microservice محل أي واجهة توفر نفس الواجهة الخارجية. ومع ذلك ، فإن رمزها سيكون مختلفا تماما. على سبيل المثال ، قمت بالتبديل من تطبيقات PHP القديمة ، واستبدلت بها نظائرها مكتوبة في بيثون. " وأضاف خايمي: "العمل مع منصتين أو أكثر في نفس الوقت سيساعد على فهمها بشكل أفضل وفهم الحالات التي من الأفضل استخدامها فيها."
في حين أن القدرة على استخدام الخدمات المصغرة متعددة اللغات هي ميزة معمارية رائعة ، إلا أنها يمكن أن تزيد من تكاليف المعاملات. Buelta تنصح: "نحن بحاجة إلى معرفة التدبير. لا معنى لاستخدام أداة جديدة في كل مرة وحرمان الفريق من فرصة تبادل المعرفة مع بعضهم البعض. قد تعتمد أشكال محددة على حجم الشركة ، ولكن كقاعدة عامة ، لا معنى لاستخدام أكثر من لغتين أو ثلاث لغات مختلفة دون سبب وجيه. لست مضطرًا إلى تضخيم رصة التكنولوجيا - فسيتمكن المطورون من مشاركة المعرفة والبدء في استخدام الأدوات المتاحة بشكل أكثر فعالية.
عن المؤلف
خايمي بويلتا هو مبرمج محترف ومطور بيثون ، على مدى سنوات حياته المهنية ، واجه العديد من التقنيات المختلفة. قام بتطوير برامج للعديد من المجالات والصناعات ، بما في ذلك الطيران والشبكات والاتصالات ، بالإضافة إلى أنظمة SCADA الصناعية وخدمات ألعاب الفيديو عبر الإنترنت والخدمات المالية.
كجزء من العديد من الشركات ، تعامل مع المجالات الوظيفية مثل التسويق والإدارة والمبيعات وتصميم اللعبة. Jaime هو مؤيد متعطش للأتمتة ويريد من أجهزة الكمبيوتر القيام بكل العمل الشاق ، مما يتيح للناس التركيز على أشياء أكثر أهمية. يقيم حاليًا في دبلن ويتحدث بانتظام في مؤتمرات PyCon في أيرلندا.