ما هي الخدمات المصغرة (Microservices)؟

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

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

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

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

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

كيف تُقسّم النظام إلى خدمات؟

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

ويُستعان بمفهوم النطاق المحدد (Bounded Context) من التصميم الموجّه بالنطاق: لكل نطاق لغة ومصطلحات وقواعد مستقلة. وحدود اللغة تكشف حدود الخدمة غالبًا، فإذا اختلف معنى المصطلح بين فريقين فهما يتحدثان عن نطاقين.

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

كيف تتخاطب الخدمات عبر الواجهات؟

تتخاطب الخدمات عبر واجهات برمجة التطبيقات (API)، وقد تكون متزامنة أو غير متزامنة. فالطلب المتزامن، عبر REST API أو gRPC، ينتظر ردًا فوريًا، ويناسب الاستعلامات التي يحتاجها المستخدم الآن. والرسائل غير المتزامنة، عبر قناة أو حدث، تفصل المرسل عن المستقبل، وتناسب المهام التي تحتمل تأخرًا.

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

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

كيف تُنشر كل خدمة على حدة؟

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

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

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

ما عبء النظام الموزع؟

العبء الأول أن الشبكة لم تعد موثوقة تمامًا. فالاستدعاء قد يتأخر أو يفشل أو يصل مرتين، والخدمة قد تعمل بينما قاعدة بياناتها متعثرة. ويصبح الفشل الجزئي (Partial Failure) حالة عادية تُصمم لها الخدمات، لا استثناءً نادرًا.

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

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

متى تختار الخدمات المصغرة ومتى تتجنبها؟

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

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

متى تقلق على نظامك المصغّر؟

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

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

أسئلة شائعة

مقالات ذات صلة

• ما هو التكامل المستمر والتسليم المستمر (CI/CD)؟
• ما هي المحاكاة الافتراضية (Virtualization)؟
• ما هو Docker؟
• ما هو DevOps؟

المصادر

• IBM Think, What are microservices? — تحديث 24 يونيو 2026
• AWS, What are Microservices? — 2026
• Martin Fowler & James Lewis, Microservices — 25 مارس 2014
• NIST, Security Strategies for Microservices-based Application Systems (SP 800-204) — أغسطس 2019

صورة الغلاف: Archer4523 / Wikimedia Commons، بموجب رخصة CC BY-SA.