نشر الخدمات المصغّرة: من أفضل الممارسات والاستراتيجيات إلى المراقبة والأمان

في الستينيات والسبعينيات من القرن الماضي، البنية المتكاملة (Monolithic Architecture) كانت الخيار السائد لتطوير التطبيقات بسبب محدودية موارد الحوسبة، التي فرضت دمج جميع الوظائف في وحدة واحدة متماسكة.

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

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

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

ما هي الخدمات المصغرة؟ وكيف تعمل؟

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

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

منذ ذلك الحين، أصبحت الخدمات المصغرة خيارًا معماريًا سائدًا، مدعومًا بالتطورات في تقنيات الحاويات مثل Docker، وأدوات التنسيق مثل Kubernetes، ومنصات الحوسبة بدون خادم. لكن كيف تعمل الخدمات المصغّرة؟

كيف تعمل الخدمات المصغّرة؟

في جوهرها، تقوم بنية الخدمات المصغّرة على تقسيم التطبيق الكبير إلى خدمات أصغر ومستقلة، كلٌّ منها مسؤولة عن وظيفة تجارية محددة. تتواصل هذه الخدمات فيما بينها عبر الشبكة، غالبًا من خلال REST APIs أو gRPC أو وسطاء الرسائل مثل RabbitMQ أو Apache Kafka.

وفقًا لتعريف Martin Fowler وJames Lewis، تتسم الخدمات المصغّرة بأربع خصائص رئيسية هي:

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

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

المراحل الرئيسية لنشر الخدمات المصغّرة

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

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

التخطيط والتحضير لنشر الخدمات المصغّرة

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

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

وثمة فئة فرعية من هذا المبدأ تُعرف بـ مبدأ الاقتران الخفيف. يعني ذلك أن كل خدمة قادرة على العمل باستقلالية في تواصلها مع الخدمات الأخرى، وأن اعتمادها عليها يبقى في حده الأدنى. وبذلك، لا تؤثر التغييرات أو التحديثات في خدمة ما على الخدمات الأخرى، مما يتيح توسيع نطاق كل خدمة بشكل مستقل.

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

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

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

العنصر الأخير في المعادلة هو إعداد خطوط أنابيب التكامل المستمر والتسليم المستمر (CI/CD) للخدمات المصغّرة. تُمكّن هذه الخطوط الفرق من نشر الميزات الجديدة أو الإصلاحات عبر أدوات CI/CD مثل Jenkins وGitLab، مما يُتيح للمؤسسات الحفاظ على استقرار النظام مع الإصدار المتكرر للميزات الجديدة.

بعد أن اطّلعت على الجانب التخطيطي والتحضيري للخدمات المصغّرة، لنتحدث عن استراتيجيات نشرها.

استراتيجيات نشر الخدمات المصغّرة

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

• نسخة خدمة لكل حاوية: في هذا الأسلوب، تعمل كل خدمة مصغّرة في حاوية مستقلة، مما يوفر عزلاً أفضل مقارنةً بنموذج تشغيل نسخ متعددة على مضيف واحد. تُيسّر الحاويات عملية التوسع وتُحسّن توزيع الموارد.
• نسخة خدمة لكل آلة افتراضية: تعمل كل خدمة في آلة افتراضية (VM) منفصلة، مما يوفر عزلاً أعلى مستوىً من الحاويات. يُحسّن هذا الأسلوب الأمان والاستقرار، غير أنه ينطوي عادةً على استهلاك أعلى للموارد.
• الإصدارات التدريجية المرحلية: يُطلق في البداية على مجموعة صغيرة من المستخدمين لاختبار الاستقرار قبل الطرح الكامل. يُقلّل هذا الأسلوب من تأثير أي مشكلات تظهر، ويُتيح التراجع السريع للحفاظ على سلامة النظام.
• النشر الأزرق-الأخضر (Blue-Green Deployment): يعتمد هذا الأسلوب على بيئتي إنتاج متطابقتين؛ إحداهما تخدم الحركة المرورية الحية، والأخرى مخصصة لاختبار الإصدار القادم. يُتيح النشر الأزرق-الأخضر التراجع بسهولة وإجراء التحديثات دون أي توقف، إذ يمكن تحويل الحركة المرورية بين البيئتين في أي وقت.
• الإصدارات المتدرجة: تقوم هذه الاستراتيجية على طرح التحديثات تدريجياً عبر شرائح مستخدمين أو بيئات مختلفة. تبدأ عادةً بالبيئات الداخلية قبل الوصول إلى الإنتاج، مما يُحدّ من نطاق تأثير أي مشكلات محتملة ويُتيح للفرق معالجتها على مراحل.
• النشر بدون خوادم (Serverless Deployment): يعتمد هذا الأسلوب على منصات serverless مثل AWS Fargate وGoogle Cloud Run، التي تتولى إدارة البنية التحتية تلقائياً بما في ذلك التوسع وتوزيع الموارد. مع النشر بدون خوادم، لا حاجة لإدارة الخوادم الأساسية، مما يُتيح لك التركيز الكامل على الخدمات المصغّرة نفسها.

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

تنسيق الخدمات المصغّرة

بعد اختيار إحدى استراتيجيات نشر الخدمات المصغّرة، ستحتاج إلى أداة تنسيق تضطلع بدور المحرّك الرئيسي. أدوات تنسيق الخدمات المصغّرة، مثل Kubernetes، تُؤتمت عمليات نشر الخدمات المصغّرة وتوسّعها ومراقبتها وإدارة الحاويات الخاصة بها.

تستخدم Airbnb، على سبيل المثال، Kubernetes، مما يتيح لمهندسيها نشر مئات التعديلات على الخدمات المصغّرة دون الحاجة إلى إشراف يدوي. ومن أبرز مزايا أدوات تنسيق الخدمات المصغّرة مثل Kubernetes وجود موازنة التحميل المدمجة.

تُسهم ميزة موازنة التحميل في توزيع حركة المرور الواردة على نسخ متعددة من الخدمة المصغّرة، مما يمنع أي نسخة منفردة من أن تصبح نقطة اختناق، ويُعزز قدرة النظام على استيعاب ارتفاعات الطلب.

يؤدي Kubernetes دوراً محورياً في إدارة الخدمات المصغّرة من خلال قدرات الإصلاح الذاتي، إذ تُستبدل الحاويات المعطّلة تلقائياً وتُعاد تشغيلها. تعتمد صحيفة The New York Times على هذه الميزة للحفاظ على خدماتها المصغّرة دون التأثير على تجربة المستخدم أو التعرض لأي توقف.

علاوة على ذلك، يُحسّن Kubernetes أمان الخدمات المصغّرة من خلال إدارة الإعدادات والبيانات الحساسة، كبيانات اعتماد قواعد البيانات ومفاتيح API، باستخدام ConfigMaps و Secrets. وهذا أمر بالغ الأهمية للشركات والخدمات التي تتعامل مع معلومات حساسة للعملاء، كشركة Uber.

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

بعد إعداد أداة تنسيق الخدمات المصغّرة، ستحتاج إلى بناء وأتمتة خطوط الأنابيب CI/CD لنشر الخدمات المصغّرة.

CI/CD Pipelines لنشر الخدمات المصغّرة

كما أشرنا سابقاً، تُمثّل قنوات التكامل المستمر والتسليم المستمر (CI/CD) للخدمات المصغّرة ركيزةً أساسية في عملية النشر. إذ تتولى قنوات CD نشر تعديلات الكود تلقائياً إلى بيئة الإنتاج فور اجتيازها مراحل الاختبار والتكامل ضمن الـ CI/CD pipeline.

بعد ذلك، يتدخل جزء CD من الـ CI/CD pipelines بحيث يُنشر الكود تلقائياً إلى أداة تنسيق الخدمات المصغّرة، كـ Kubernetes cluster، في كل مرة تجتاز فيها التعديلات مراحل الاختبار والتكامل.

فضلاً عن ذلك، تُنفَّذ مراحل الاختبار والتكامل بالكامل بصورة تلقائية عبر الـ CI/CD pipelines، إذ تشمل اختبارات الوحدة واختبارات التكامل والاختبارات الشاملة من طرف إلى طرف.

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

أخيراً، يُساعد تطبيق CI/CD pipelines للخدمات المصغّرة وفق أفضل الممارسات المتبعة، المؤسساتِ على تسريع دورة التطوير وتقليل الأخطاء اليدوية والحفاظ على معايير جودة عالية.

تعتمد شركات عديدة كـ Spotify وExpedia وiRobot وLufthansa وPandora وغيرها على CI/CD pipelines للخدمات المصغّرة عبر أدوات مثل CircleCI وAWS CodePipeline وGitLab، وذلك لأتمتة عمليات النشر وضمان جودة الكود وطرح الميزات الجديدة بسرعة مع الحفاظ على استقرار النظام.

أنماط التواصل بين الخدمات المصغّرة

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

في أنماط التواصل التزامني، تتفاعل الخدمات في الوقت الفعلي، أي أن الخدمة ترسل طلباً وتنتظر الاستجابة قبل المتابعة. وأكثر هذه الأنماط شيوعاً هي: REST (نقل الحالة التمثيلي) APIs, gRPC (استدعاء الإجراء البعيد من Google)، و GraphQL.

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

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

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

يُفصل هذا النمط من التواصل بين الخدمات المصغرة بالسماح لها بإرسال الرسائل واستقبالها عبر وسيط مثل Kafka أو RabbitMQ. إذ ترسل الخدمات رسائلها إلى طابور انتظار يعمل كمنطقة تخزين مؤقت، مما يُتيح لها التواصل باستقلالية دون الحاجة إلى انتظار استجابة كما هو الحال في أنماط التواصل المتزامن. يُمكّن هذا الطابور الخدماتِ الأخرى من معالجة الرسائل وفق سرعتها الخاصة، بينما يُكمل المُرسل عمله دون انتظار المستقبل.

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

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

علاوة على ذلك، في نمط التواصل غير المتزامن القائم على النشر والاشتراك (Pub/Sub) بين الخدمات المصغرة، ترسل الخدمات (الناشرون) الرسائل إلى موضوع معين، وتستمع إليه خدمات أخرى (المشتركون) لاستقبال التحديثات. يدعم هذا النموذج عدداً من المشتركين في آنٍ واحد، مما يُتيح بث الرسائل إلى خدمات متعددة في الوقت ذاته.

أخيراً، وعلى غرار أنماط الأحداث، تعتمد أنماط التواصل غير المتزامن القائمة على ملحمة قائمة على التوافق الكوريوغرافي (choreography-based saga) بين الخدمات المصغرة أيضاً على الأحداث للتواصل فيما بينها؛ غير أن هذا النمط يُرتّب تسلسلاً محدداً للأحداث، بحيث يُشغّل كل حدث الخطوة التالية والخدمة المعنية بتنفيذها.

الفارق هنا أن أنماط الأحداث لا تفرض تسلسلاً أو سير عمل محدداً، وتستطيع خدمات متعددة الاستجابة لحدث واحد، خلافاً لنهج choreography-based saga الذي يعتمد على ترتيب معين وعملية محددة.

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

تُستخدم وسطاء الرسائل المدفوعة بالأحداث، كـ Apache Kafka وAWS EventBridge، عادةً لمعالجة تدفقات الأحداث واسعة النطاق في الوقت الفعلي، وتوجيه الأحداث بين الخدمات المصغرة في مجالات كالخدمات المالية وبيئات AWS.

أما وسطاء رسائل النشر والاشتراك (Pub/Sub) كـ Google Cloud Pub/Sub وRedis Streams، فتُستخدم في الغالب لتبادل الرسائل عبر الأنظمة الموزعة لدعم التحليلات الفورية واستيعاب الأحداث، وكذلك للإشعارات الفورية وتطبيقات الدردشة.

وأخيراً، تُستخدم وسطاء رسائل choreography-based saga أساساً في معالجة طلبات التجارة الإلكترونية، وأنظمة حجز السفر، وحالات الاستخدام التي تتطلب تنسيق معاملات معقدة متعددة الخطوات عبر خدمات متعددة دون الحاجة إلى تحكم مركزي.

اكتشاف الخدمة في الخدمات المصغرة

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

يتحقق ذلك من خلال اكتشاف الخدمة المدمج الذي يوفره Kubernetes DNS، والذي يُحدّث عناوين IP وسجلات DNS ديناميكياً مع توسع الخدمات أو تغيير مواقعها داخل المجموعة.

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

في المقابل، يتوفر أيضاً أسلوب الاكتشاف من جانب العميل، حيث يستعلم العميل أو بوابة API من سجل الخدمات كـ Consul أو Eureka للعثور على النسخ المتاحة.

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

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

على سبيل المثال، يعتمد نشر الخدمات المصغرة في Netflix على الاكتشاف من جانب العميل باستخدام Eureka وRibbon لموازنة الأحمال، مما يُمكّن العميل من اختيار النسخة الأنسب بناءً على معايير كزمن الوصول وحمل الخادم.

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

تُساعد حلول اكتشاف خدمات الميكروسيرفيس من جانب الخادم، كـ Kubernetes وـ AWS Elastic Load Balancing وبوابات API (مثل Kong وـ NGINX وغيرها)، على توجيه حركة المرور بكفاءة والحفاظ على توفر عالٍ للخدمة، وتعتمدها شركات كـ Airbnb وـ Pinterest وـ Expedia وـ Lyft وغيرها.

أمان الميكروسيرفيس

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

بما أن كل خدمة تحتاج إلى تأمين مستقل، فإن سطح الهجوم في الميكروسيرفيس أوسع بكثير، مما يستلزم ضمانات إضافية. لهذا الغرض، تُستخدم معايير مثل OAuth2 وـ JSON Web Tokens (JWT) على نطاق واسع للمصادقة والتفويض، كما يمكنك أن تتوقع.

علاوة على ذلك، كثيرًا ما تُوظَّف بوابة API لإدارة الأمان عبر الميكروسيرفيس، إذ تفرض المصادقة والتفويض عند نقطة الدخول. كما يمكن لبوابات API تطبيق تحديد معدل الطلبات والتسجيل والمراقبة، مما يضيف طبقات حماية إضافية لأمان الميكروسيرفيس.

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

هنا يبرز دور شبكات الخدمات (service meshes)، إذ تضيف طبقة من أمان الشبكة وتشفّر حركة المرور بين الخدمات وتفرض سياسات مثل المصادقة المتبادلة TLS. وتُنشئ هذه الشبكات في جوهرها تشفيرًا شاملًا من طرف إلى طرف يُعزز أمان الميكروسيرفيس بشكل ملحوظ.

توسعة الميكروسيرفيس

من أبرز مزايا MSA، بل السبب الجوهري الذي دفع إلى تطويرها لتحل محل البنية المتجانسة، هو قدرتها العالية على التوسع. وعادةً ما تتم توسعة الميكروسيرفيس بأحد أسلوبين: رأسي وأفقي.

باختصار، تعني التوسعة الرأسية للميكروسيرفيس (التوسع للأعلى) إضافة موارد أكثر، كـ CPU أو الذاكرة، إلى نسخة قائمة. أما التوسعة الأفقية (التوسع للخارج) فتوزّع الحمل وتزيد السعة.

من حيث التطبيق، تُعدّ التوسعة الرأسية للميكروسيرفيس أيسر الأسلوبين، إذ يكفي تعديل نسخة واحدة بالترقية إلى خادم أكبر، أو زيادة الذاكرة وقدرة المعالجة في نسخة سحابية، أو إضافة مساحة تخزين أكبر.

يُستخدم هذا النوع من التوسعة عادةً حين يُسهم رفع قدرة RAM أو CPU في تحسين أداء الاستعلامات ومعالجة البيانات، كما هو الحال في الخدمات المسؤولة عن التخزين المؤقت في الذاكرة.

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

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

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

على خلاف التوسعة الرأسية، لا تُوجد حدود للتوسعة الأفقية للميكروسيرفيس، إذ يمكنك إضافة أي عدد من النسخ للتعامل مع أحمال العمل المتزايدة وارتفاعات حركة المرور، مما يمنحك قابلية توسع أعلى.

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

غير أن التوسعة الأفقية وإضافة المزيد من النسخ يستلزمان موازنات أحمال إضافية وآليات اكتشاف خدمات وأدوات تنسيق، مما يزيد من تعقيد بنية الميكروسيرفيس بشكل ملحوظ.

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

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

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

مراقبة الميكروسيرفيس

في هذه المرحلة، تكون قد أتممت نشر الميكروسيرفيس تقريبًا، ولم يتبق سوى التحقق من عمله بشكل متسق وموثوق. هنا يأتي دور أدوات مراقبة الميكروسيرفيس مثل Prometheus وـ Grafana ابدأ الآن.

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

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

الخاتمة

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

الأسئلة الشائعة

ما استراتيجيات النشر الشائعة للخدمات المصغرة؟

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

ما دور Kubernetes في تنسيق الخدمات المصغرة؟

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

كيف أضمن الأمان في بيئة الخدمات المصغرة؟

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