يحذر دليل جديد من TechForge من أن العديد من مشاريع الخدمات المصغرة (microservices) الناشئة تنتهي كـ "مونوليث موزعة" (distributed monoliths)، مما يتسبب في زمن انتقال (latency) ناتج عن استدعاءات الشبكة دون الحصول على أي فوائد في التوسع (scaling). ويحث المقال الفرق الهندسية على البدء بـ monolith متماسك، وعدم تفكيكه إلا عند ظهور احتياجات واضحة للتوسع أو لتوزيع الملكية.
لماذا تندفع الفرق نحو الخدمات المصغرة (microservices)
إن جاذبية الخدمات المصغرة واضحة: خدمات مستقلة، وعمليات نشر منفصلة، والوعد بتوسيع كل جزء من التطبيق وفقاً لمتطلباته الخاصة. لقد حولت ثقافة الشركات الناشئة وقصص النجاح الأخيرة هذا النمط إلى رمز للهندسة الحديثة. ومع ذلك، فإن تقسيم الـ monolith في وقت مبكر جداً غالباً ما يؤدي إلى إنشاء نوع جديد من الـ monolith — عشرات المكونات المتصلة عبر الشبكة. والتكلفة؟ زمن انتقال أعلى، وصعوبة في تصحيح الأخطاء (debugging)، وأعباء تشغيلية أكبر، بينما تظل الفوائد الأصلية بعيدة المنال.
الخطأ الأول: البدء بـ monolith بالاسم فقط
غالباً ما تطلق الفرق تسمية "قائم على الخدمات المصغرة" على نظام ما، بينما تحتفظ بقاعدة كود واحدة وقاعدة بيانات مشتركة. والنتيجة هي سلسلة من الوحدات (modules) شديدة الترابط التي لا تزال تتواصل مع بعضها البعض عبر HTTP أو RPC. ويطلق الدليل على هذا اسم "مونوليث موزعة". وتتطابق نقاط الألم مع نقاط الألم في الـ monolith التقليدي — الترابط الوثيق وصعوبة تغيير جزء واحد دون التأثير على البقية — بالإضافة إلى زمن الانتقال الإضافي الناتج عن القفزات عبر الشبكة (network hops).
ما يجب فعله بدلاً من ذلك: ابدأ ببناء monolith نظيف أولاً. حدد حدوداً واضحة للوحدات (modules)، وحافظ على توحيد طبقة البيانات، وتأكد من إمكانية اختبار التطبيق ونشره كوحدة واحدة. لا تقم باستخراج وحدة لتصبح خدمة مستقلة إلا عندما تحتاج إلى توسع مستقل أو ملكية منفصلة من قبل فريق آخر.
التقسيم حسب الطبقة التقنية مقابل القدرة الوظيفية للأعمال
خطأ شائع آخر هو تقسيم الخدمات بناءً على الاهتمامات التقنية — مثل واجهة المستخدم (UI)، أو منطق الأعمال (business logic)، أو الوصول إلى البيانات. وهذا يجبر الطلب على المرور عبر سلسلة من الخدمات لإجراء عملية واحدة، مما يؤدي إلى تضخم أوقات الاستجابة وإنشاء مخطط اعتماد (dependency graph) هش.
النهج الأفضل: قم بتنظيم الخدمات حول القدرات الوظيفية للأعمال مثل "الطلبات" أو "المدفوعات" أو "المخزون". اجعل كل قدرة تمتلك بياناتها وواجهة برمجة التطبيقات (API) الخاصة بها، مما يلغي الحاجة إلى انتقال الطلب عبر الطبقات.
ملكية البيانات أمر بالغ الأهمية
عندما تكتب خدمتان في نفس جدول قاعدة البيانات، فإنهما لم تعودا مستقلتين. ويؤكد الدليل على أنه يجب ألا تقوم خدمة أبداً بالاستعلام عن جداول خدمة أخرى مباشرة؛ بل يجب أن يتم ذلك دائماً من خلال واجهة برمجة التطبيقات (API) العامة لتلك الخدمة. إن مشاركة قاعدة البيانات تربط الخدمات ببعضها البعض، وتلغي مبدأ العزل، وتجعل تغييرات المخطط (schema changes) كابوساً من حيث التنسيق.
HTTP المتزامن ليس حلاً شاملاً
الاعتماد على HTTP المتزامن (synchronous HTTP) في كل تفاعل يجعل النظام بأكمله عرضة للتأثر بخدمة واحدة بطيئة. إذا كانت الخدمة A تنتظر رد الخدمة B قبل العودة إلى العميل، فإن أي تباطؤ في B سينتقل إلى A وفي النهاية إلى المستخدم.
أنماط بديلة: استخدم الرسائل غير المتزامنة (asynchronous messaging) للمهام التي لا تتطلب إجابة فورية. تتيح طوابير الرسائل (message queues) أو المهام الخلفية (background jobs) للخدمات تسليم العمل ومواصلة المعالجة، مما يجعل النظام ككل أكثر مرونة.
قبول الاتساق النهائي (eventual consistency)
توفر قواعد البيانات 관계ية التقليدية معاملات ACID — الذرية (Atomicity)، والاتساق (Consistency)، والعزل (Isolation)، والمتانة (Durability). ولكن عبر حدود الخدمات، تختفي هذه الضمانات. إن محاولة فرض عمليات الالتزام ثنائية المراحل (two-phase commits) — وهو بروتوكول يحاول جعل المعاملات الموزعة تتصرف مثل المعاملات المحلية — تؤدي إلى التعقيد وعدم الاستقرار.
يوصي الدليل باستخدام الـ sagas (سلسلة من الإجراءات التعويضية) أو نمط الـ outbox (حيث تكتب الخدمة الأحداث في جدول محلي يتم نشره لاحقاً). تقر هذه الأساليب بأن البيانات قد تكون غير متزامنة مؤقتاً، وتصمم منطق الأعمال للتعامل مع هذه الفجوات.
ابنِ للنظام مع مراعاة احتمالية الفشل منذ اليوم الأول
لا ينبغي لخطأ في خدمة واحدة أن يؤدي إلى تعطل النظام بأكمله. قم بتنفيذ مهلات زمنية (timeouts) لتجنب الانتظار للأبد، وعمليات إعادة المحاولة مع التراجع التدريجي (retries with back-off) للتعامل مع الإخفاقات العابرة، وقواطع الدائرة (circuit breakers) التي توقف الاستدعاءات للخدمة المتعثرة حتى تتعافى. إن إضافة هذه الضمانات بعد حدوث انقطاع في بيئة الإنتاج هو أمر متأخر جداً؛ بل يجب أن تكون جزءاً من التصميم الأولي.
قابلية المراقبة (Observability) أمر لا يقبل التفاوض
إن تصحيح أخطاء نظام موزع مع سجلات (logs) مبعثرة عبر العديد من الحاويات (containers) أمر شبه مستحيل. تتيح السجلات المركزية (centralized logging)، والمقاييس المجمعة (aggregated metrics)، ومعرفات الارتباط (correlation IDs) على مستوى الطلب للمهندسين تتبع طلب مستخدم واحد أثناء انتقاله عبر خدمات متعددة. كما تقوم أدوات التتبع (tracing tools) بتصور مخطط الاستدعاء (call graph)، مما يسهل تحديد اختناقات الأداء والإخفاقات.
حافظ على خفة البنية التحتية في البداية
على الرغم من قوة Kubernetes، إلا أنه يفرض منحنى تعلم حاداً وأعباء تشغيلية إضافية. بالنسبة لعدد قليل من الخدمات، يوفر Docker Compose قدرًا كافيًا من التنسيق (orchestration) لتشغيل المكدس التقني بالكامل محليًا. ولا ينبغي تقديم منصة أكثر تعقيدًا إلا عندما تتطلب أنماط حركة المرور، أو تكرار النشر، أو حجم الفريق ذلك.
مواءمة الخدمات مع ملكية الفرق
لقد ابتُكرت الخدمات المصغرة (Microservices) جزئيًا للسماح للفرق الصغيرة والمستقلة بامتلاك دورة الحياة الكاملة للخدمة. إذا كان فريق واحد مسؤولًا عن عشر خدمات، فإن تكاليف التنسيق ترتفع بشكل كبير، مما يؤدي إلى تآكل الفوائد المرجوة. ويشير الدليل إلى أن الفرق التي يقل عدد أعضائها عن عشرة أشخاص قد تستفيد بشكل أفضل من النظام الأحادي (monolith)، مما يحافظ على البساطة مع السماح بالتطوير المعياري.
الحجة المضادة: متى تتألق الخدمات المصغرة
لا يدعي الدليل أن الخدمات المصغرة سيئة بطبيعتها. ففي البيئات التي تتطلب فيها أجزاء مختلفة من التطبيق متطلبات توسع متفاوتة تمامًا، أو حيث تفرض القيود التنظيمية عزلًا صارمًا للبيانات، يمكن لهذا النمط أن يوفر قيمة حقيقية. وغالبًا ما تجد المؤسسات الكبيرة ذات خطوط الإنتاج المتعددة أن الخدمات المستقلة تقلل من الاحتكاك بين الفرق وتمكن من دورات إصدار أسرع.
المفتاح هو القصد والتعمد. إذا اعتمد فريق ما الخدمات المصغرة لأنهم بحاجة إلى التعامل مع ملايين الطلبات في الثانية لميزة معينة، أو لأن خط إنتاج جديد يجب أن تمتلكه وحدة أعمال منفصلة، فإن التعقيد المضاف يكون مبررًا. تستهدف تحذيرات الدليل الحالات التي يكون فيها القرار مدفوعًا بالزخم الإعلامي (hype) بدلاً من المتطلبات الملموسة.
ما يجب مراقبته لاحقاً
مع اعتماد المزيد من الشركات للمكدسات السحابية الأصلية (cloud-native stacks)، تستمر الأدوات المتعلقة بشبكة الخدمات (service mesh)، والتتبع الموزع (distributed tracing)، وعمليات النشر التجريبي المؤتمتة (automated canary deployments) في النضج. هذه التطورات تخفض الحاجز التشغيلي ولكنها لا تلغي خيارات التصميم الأساسية التي سلط الدليل الضوء عليها. يجب على الفرق مراقبة تطور منصات الملاحظة (observability platforms) وأطر عمل المراسلة غير المتزامنة (async messaging frameworks)، ولكن يجب عليهم أيضًا البدء بمسوغ واضح لكل خدمة يقومون بتشغيلها.
الخلاصة
الخدمات المصغرة هي وسيلة لتحقيق غاية، وليست غاية في حد ذاتها. ابدأ بنظام أحادي (monolith) جيد الهيكلة، وامنح كل خدمة ملكية حقيقية لبياناتها، واستخدم الاتصال غير المتزامن حيثما أمكن، واجعل المرونة والقدرة على الملاحظة (observability) جزءًا من الكود منذ السطر الأول. عندما تكون الجدوى التجارية واضحة، قم بفصل الخدمات بشكل متعمد؛ وإلا، فحافظ على بساطة البنية التحتية بما يتطلبه حل المشكلة.