المحاكاة الافتراضية للخدمات: مفهومها وأبرز الأدوات

يعتمد الكود الخاص بك على خدمة لا تتحكم بها. بوابة دفع، واجهة برمجة تطبيقات شريكة (API)، نظام مركزي قديم، خدمة مصغرة (microservice) لفريق آخر. قد تكون هذه التبعية معطلة للصيانة، أو تحد من عدد مرات تشغيل اختباراتك، أو تفرض رسومًا على كل مكالمة، أو تُرجع بيانات غير مستقرة. لذا يتوقف تطويرك وتصبح مسار تكاملك المستمر (CI pipeline) باللون الأحمر لأسباب لا علاقة لها بكودك.

تحل المحاكاة الافتراضية للخدمات (Service virtualization) هذه المشكلة. فتقوم باستبدال التبعية الحقيقية ببديل يتصرف مثلها، بحيث يمكنك البناء والاختبار مقابل شيء تتحكم به بالكامل. يشرح هذا الدليل ماهية المحاكاة الافتراضية للخدمات، وكيف تختلف عن المحاكاة الصورية (mocking) والتهيئة (stubbing)، ولماذا تلجأ إليها الفرق، وما هي الأدوات التي تقوم بالمهمة، مع أوامر حقيقية لـ WireMock وHoverfly وMountebank وخيارات الشركات الكبرى، وخادم Apidog الوهمي للمحاكاة الافتراضية لعقود واجهات برمجة التطبيقات (API-contract virtualization).

ما هي المحاكاة الافتراضية للخدمات

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

كلمة "سلوك" تحمل هنا أهمية. لا تُرجع الخدمة الافتراضية الجيدة حمولة ثابتة فحسب. بل تتطابق مع تفاصيل الطلب، وتُرجع استجابات مختلفة لمدخلات مختلفة، وتحتفظ بالحالة عبر المكالمات، وتُدخل زمن تأخير (latency) وأخطاء، وتتحدث نفس البروتوكول مثل النظام الحقيقي. الهدف هو بديل واقعي بما يكفي لدرجة أن كودك لا يستطيع تمييز الفرق أثناء التطوير والاختبار.

يشير مصطلح "المحاكاة الافتراضية لواجهة برمجة التطبيقات" (API virtualization) إلى نفس الشيء عندما تكون التبعية عبارة عن واجهة برمجة تطبيقات HTTP، و"محاكي واجهة برمجة التطبيقات" (API simulator) هو الأداة التي تنتج نقطة النهاية الافتراضية. اعتبر كلاهما مرادفين للجزء الذي يركز على واجهة برمجة التطبيقات من المحاكاة الافتراضية للخدمات.

المحاكاة الافتراضية للخدمات مقابل المحاكاة الصورية (Mocking) مقابل التهيئة (Stubbing)

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

يعيد **الـ Stub (التهيئة)** استجابة ثابتة (hardcoded). يتجاهل الطلب ويجيب دائمًا بنفس الطريقة. إذا كان اختبارك يستدعي GET /user/42 وتم إعداد الـ stub لإرجاع كائن مستخدم ثابت، فإنه يعيد نفس الكائن بغض النظر عن المعرف (ID) الذي ترسله. الـ stubs هي أبسط أشكال وتعيش داخل كود الاختبار الخاص بك.

الـ **Mock (المحاكاة الصورية)** هي stub تتحقق أيضًا من التفاعلات. تسجل كيفية استدعائها (أي الطرق، وأي الوسائط، وكم مرة) حتى يتمكن اختبارك من التأكد من أن كودك استخدم التبعية بشكل صحيح. الـ mocks هي أداة لاختبار الوحدات. تعمل عادةً ضمن العملية (in-process)، بنفس لغة كودك. يشرح مقالنا API stubbing vs API mocking هذا التقسيم بعمق أكبر.

تعمل **المحاكاة الافتراضية للخدمات (Service virtualization)** عبر الشبكة، وليس داخل كودك. تنشئ خدمة تعمل على منفذ شبكة حقيقي تتحدث بروتوكولاً حقيقيًا. يتصل تطبيقك بها بنفس الطريقة التي سيتصل بها بالإنتاج، عن طريق تغيير عنوان URL أساسي أو إعداد وكيل. يمكن أن تكون الخدمة الافتراضية ذات حالة (stateful)، ويمكنها مطابقة شروط الطلبات المعقدة، ويمكنها محاكاة سلوك على مستوى البروتوكول مثل أكواد حالة HTTP، والعناوين، والتدفق، وأعطال الاتصال.

الخط الفاصل بين "mock" و "service virtualization" غامض في الحديث اليومي. تسمي العديد من الفرق خادم HTTP وهمي يعمل "mock" حتى عندما يقوم بمحاكاة افتراضية كاملة. وهذا جيد. التمييز المهم هو: هل تستبدل كائنًا داخل عمليتك (mocking/stubbing)، أم تنشئ خدمة شبكية يتصل بها تطبيقك (virtualization)؟ راجع API mocking: كل ما تحتاج لمعرفته للجانب المتعلق بالـ mock.

لماذا تستخدم الفرق المحاكاة الافتراضية للخدمات

ثلاث مشاكل تدفع معظم التبني.

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

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

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

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

كيف تعمل المحاكاة الافتراضية للخدمات

تتبع معظم الأدوات أحد نمطين.

التسجيل والإعادة (Record and replay). توجه الأداة إلى الخدمة الحقيقية كوكيل، وتمرر حركة مرور حقيقية من خلالها مرة واحدة، وتقوم بالتقاط أزواج الطلب/الاستجابة. لاحقًا تعيد تشغيل تلك التسجيلات بدلاً من استدعاء الخدمة الحقيقية. هذه الطريقة سريعة لأنك لا تكتب الاستجابات يدويًا. يعمل وضع الالتقاط في Hoverfly ووضع التسجيل في WireMock بهذه الطريقة.

مدفوعة بالمواصفات (Specification-driven). تقوم بتعريف الخدمة الافتراضية من عقد واجهة برمجة التطبيقات أو يدويًا: تحدد الطلبات التي تتطابق مع الاستجابات، وتضيف قيمًا ديناميكية، وتُعد سلوكًا ذا حالة (stateful). يتطلب الأمر مزيدًا من العمل مقدمًا ولكنه يمنحك تحكمًا كاملاً ويعمل حتى عندما لا تكون الخدمة الحقيقية موجودة بعد.

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

الأدوات

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

WireMock

WireMock هو أداة مفتوحة المصدر للمحاكاة الصورية لواجهة برمجة التطبيقات (API mocking) والمحاكاة الافتراضية للخدمات (service virtualization) لبروتوكول HTTP. يعمل كعملية مستقلة، أو مدمجًا في اختبارات JVM، أو في حاوية. تقوم بتعريف تعيينات الـ stub كـ JSON، ويقوم WireMock بمطابقة الطلبات الواردة مقابلها. يدعم التسجيل والإعادة (record-and-playback) مقابل خدمة حقيقية، وقوالب الاستجابة، والسيناريوهات ذات الحالة، وحقن الأخطاء، والتأخيرات المحاكاة.

شغل ملف JAR المستقل:

java -jar wiremock-standalone-3.13.2.jar --port 8080

ثم قم بتسجيل stub عبر واجهة برمجة تطبيقات الإدارة الخاصة به:

curl -X POST http://localhost:8080/__admin/mappings \
  -H "Content-Type: application/json" \
  -d '{
    "request": {
      "method": "GET",
      "url": "/user/42"
    },
    "response": {
      "status": 200,
      "headers": { "Content-Type": "application/json" },
      "jsonBody": { "id": 42, "name": "Ada Lovelace" }
    }
  }'

يكون WireMock أقوى عندما تكون تبعياتك HTTP وترغب في تحكم دقيق في إعدادات JVM أو الحاويات. يوجد إصدار تجاري مستضاف (WireMock Cloud) إذا كنت تريد خيارًا مُدارًا.

Hoverfly

Hoverfly هي أداة خفيفة الوزن ومفتوحة المصدر للمحاكاة الافتراضية للخدمات مكتوبة بلغة Go. تعمل كوكيل: تقوم بتوجيه حركة مرور تطبيقك الصادرة عبر Hoverfly، وتقوم إما بتسجيل الاستجابات الحقيقية أو إعادة تشغيل الاستجابات المحاكاة. تعمل في عدة أوضاع، بما في ذلك الالتقاط (capture)، المحاكاة (simulate)، التجسس (spy)، التعديل (modify)، التوليف (synthesize)، والمقارنة (diff).

تدفق أساسي للالتقاط ثم الإعادة باستخدام أمر hoverctl:

hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate

تعمل واجهة برمجة تطبيقات الإدارة الخاصة بـ Hoverfly على المنفذ 8888 ويعمل وكيلها على المنفذ 8500 بشكل افتراضي. يجعل نموذج وكيل التسجيل والإعادة مناسبًا جيدًا عندما ترغب في محاكاة حركة المرور الموجودة بسرعة بدلاً من كتابة كل استجابة يدويًا. يوجد أيضًا Hoverfly Cloud مستضاف.

Mountebank

Mountebank هي أداة مفتوحة المصدر مبنية حول "المتخفين" (imposters). المتخفي هو خدمة افتراضية واحدة تستمع على منفذ واحد وتتحدث بروتوكولاً واحدًا. بالإضافة إلى HTTP و HTTPS، يتعامل Mountebank أيضًا مع TCP و SMTP، وهو أمر مفيد عندما لا تكون تبعيتك مجرد واجهة برمجة تطبيقات REST عادية. يمكنك التحكم فيها بالكامل عبر مستوى تحكم REST على المنفذ 2525.

قم بتثبيته وتشغيله:

npm install -g mountebank
mb

ثم أنشئ متخفيًا (imposter) عن طريق إرسال JSON بطريقة POST إلى منفذ التحكم:

curl -X POST http://localhost:2525/imposters \
  -H "Content-Type: application/json" \
  -d '{
    "port": 4545,
    "protocol": "http",
    "stubs": [{
      "predicates": [{ "equals": { "method": "GET", "path": "/user/42" } }],
      "responses": [{ "is": { "statusCode": 200, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }]
    }]
  }'

تحدد المحمولات (Predicates) أي طلب يتطابق؛ وتحدد الاستجابات ما يُعاد. إن وصول Mountebank متعدد البروتوكولات هو ما يميزه بين الخيارات مفتوحة المصدر.

Parasoft Virtualize و Broadcom Service Virtualization

بالنسبة للشركات الكبيرة، اللاعبون الرئيسيون هم Parasoft Virtualize و Broadcom Service Virtualization (جزء من حزمة DevTest). هذه منصات تجارية مصممة للفرق التي تحتاج إلى محاكاة العديد من البروتوكولات وتنسيقات الرسائل بخلاف HTTP، وربط الخدمات الافتراضية بمصادر بيانات حقيقية، وإدارة المحاكاة الافتراضية عبر العديد من البيئات مركزيًا.

تعلن Parasoft Virtualize عن دعمها لمجموعة واسعة من البروتوكولات وتنسيقات الرسائل القياسية الصناعية، بالإضافة إلى خدمات افتراضية مدفوعة بالبيانات تُغذى من مصادر بيانات خارجية. يستهدف عرض Broadcom سيناريوهات مؤسسية مماثلة ببيئات افتراضية للتطوير والاختبار المتوازيين. كلاهما يتضمن ترخيصًا مؤسسيًا وتكاليف إعداد، لذا فهما مناسبان عندما تقوم بمحاكاة بروتوكولات قديمة (mainframe، MQ، رسائل ذات طول ثابت) على نطاق واسع بدلاً من عدد قليل من نقاط نهاية REST. إذا كانت تبعياتك هي واجهات برمجة تطبيقات HTTP عادية، فإن الأدوات مفتوحة المصدر المذكورة أعلاه أو منصة واجهة برمجة تطبيقات تغطي احتياجاتك بجزء بسيط من التكلفة. تأكد من قوائم البروتوكولات والأسعار الحالية مع كل بائع.

Apidog: محاكاة افتراضية خفيفة للخدمات لعقود واجهات برمجة التطبيقات

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

ما يجعل هذا أقرب إلى المحاكاة الافتراضية من مجرد stub عادي هو أن mock Apidog يدرك المخططات وديناميكي. يقرأ Smart Mock الخاص به مخطط JSON الخاص بك ويولد استجابات تحترم كل قيد (الأنواع، التنسيقات، التعدادات، الحقول المطلوبة). كما أنه يطابق أسماء الحقول مقابل القواعد المضمنة، بحيث يُرجع حقل يسمى email بريدًا إلكترونيًا صالحًا وحقل يسمى city اسم مدينة، بدلاً من بيانات عشوائية. للتحكم الدقيق، تولد القيم الديناميكية المستندة إلى Faker.js بيانات واقعية في كل استدعاء، ويمكنك تثبيت قيم ثابتة حيث تحتاج إلى الحتمية.

يمكنك أيضًا كتابة قواعد mock مخصصة تُرجع استجابات مختلفة بناءً على معلمات الطلب، وهو سلوك مطابقة الطلبات الذي يفصل المحاكاة الافتراضية عن الـ stub الثابت. يعمل خادم mock في واجهة المستخدم الرسومية (GUI) أو بدون واجهة (headless)، لذا فهو مناسب لكل من التطوير المحلي والتكامل المستمر (CI). راجع كيفية محاكاة واجهة برمجة تطبيقات في دقيقة واحدة للحصول على شرح تفصيلي.

أين يتناسب Apidog: المحاكاة الافتراضية للخدمات القائمة على عقود واجهة برمجة التطبيقات لـ HTTP/REST وما شابهها. أين لا يتناسب: ليس أداة تسجيل وإعادة تشغيل قائمة على الوكيل للبروتوكولات القديمة التعسفية، وليس مولد تحميل. لهذه الأغراض، الأدوات المذكورة أعلاه هي الخيار الصحيح. لمقارنة أوسع بين الأدوات، راجع مقارنة أدوات محاكاة واجهات برمجة التطبيقات عبر الإنترنت و أفضل 10 أدوات لمحاكاة واجهات برمجة التطبيقات.

كيف تبدأ

طابق الأداة مع التبعية، وليس العكس.

1. حدد البروتوكول. HTTP/REST عادي؟ أي شيء هنا تقريبًا يعمل، ومنصة واجهة برمجة التطبيقات هي الأقل احتكاكًا. هل تحتاج إلى TCP أو SMTP؟ Mountebank. بروتوكولات المؤسسات القديمة على نطاق واسع؟ Parasoft أو Broadcom.
2. قرر بين التسجيل أو التحديد. إذا كانت الخدمة الحقيقية موجودة ويمكنك توجيه حركة المرور عبرها، فإن التسجيل والإعادة (Hoverfly، وضع التسجيل في WireMock) هو الأسرع. إذا لم تكن موجودة بعد، فقم بتشغيل الخدمة الافتراضية من عقد واجهة برمجة التطبيقات (Apidog، stubs WireMock، imposters Mountebank).
3. وجه تطبيقك إليها. قم بتغيير عنوان URL الأساسي أو إعداد الوكيل في بيئة الاختبار أو التطوير الخاصة بك، واحتفظ بذلك خلف الإعدادات بحيث يكون التبديل بين الافتراضي والحقيقي متغيرًا واحدًا.
4. أضف حالات الفشل. الفائدة تكمن في اختبار مسارات الأخطاء، لذا أضف استجابات لـ 4xx و 5xx، والمهل الزمنية، والأجسام خاطئة التكوين. هذا هو الجزء الذي لن تسمح لك التبعيات الحقيقية بالتدرب عليه.
5. شغلها في CI. الخدمة الافتراضية التي تعمل فقط على جهاز الكمبيوتر المحمول الخاص بك تساعدك ولكنها لا تساعد عملية البناء. ضعها في مسار التكامل المستمر (pipeline) بحيث يعني اللون الأخضر أن كل شيء على ما يرام. إذا كنت بحاجة إلى mock يعمل بدون واجهة رسومية (headless) في CI، راجع أدوات mock API بدون واجهة رسومية.

بالنسبة للموازنة بين التبعيات الافتراضية والحقيقية بشكل عام، يشرح مقال خادم mock مقابل الخادم الحقيقي متى تستخدم كل منهما.

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

هل المحاكاة الافتراضية للخدمات هي نفسها المحاكاة الصورية (mocking)؟ ليس تمامًا. تستبدل المحاكاة الصورية عادةً كائنًا داخل عمليتك لاختبارات الوحدات وتتحقق من كيفية استدعائه. أما المحاكاة الافتراضية للخدمات فتنشيء خدمة عاملة على منفذ شبكة يتصل بها تطبيقك عبر بروتوكول حقيقي. يطلق الناس على الخدمات الافتراضية لـ HTTP اسم "mocks" في الاستخدام العادي، وهذا مقبول، لكن التمييز الفني هو بين كائن داخل العملية والخدمة الشبكية.

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

هل يمكن أن تكون الخدمة الافتراضية ذات حالة (stateful)؟ نعم. تدعم أدوات مثل WireMock و Mountebank السيناريوهات ذات الحالة حيث تتغير الاستجابة بناءً على الطلبات السابقة، على سبيل المثال إرجاع سلة فارغة، ثم سلة بها عناصر بعد طلب POST. هذا مهم عندما تقوم بمحاكاة سير العمل (workflows) بدلاً من استدعاءات فردية.

هل أحتاج إلى أداة مؤسسية مدفوعة؟ فقط إذا كنت تقوم بمحاكاة العديد من البروتوكولات غير HTTP أو تدير المحاكاة الافتراضية عبر مؤسسة كبيرة. بالنسبة لواجهات برمجة تطبيقات HTTP العادية، فإن الأدوات مفتوحة المصدر (WireMock، Hoverfly، Mountebank) أو خادم mock لمنصة واجهة برمجة تطبيقات يؤدي المهمة دون الحاجة إلى ترخيص مؤسسي.

ما هي أسرع طريقة لمحاكاة واجهة برمجة تطبيقات HTTP افتراضيًا من مواصفاتها؟ قم باستيراد تعريف واجهة برمجة التطبيقات إلى أداة تُنشئ mock من المخطط. يقوم Apidog بذلك تلقائيًا: استورد مواصفات OpenAPI الخاصة بك وستحصل على خادم mock مدرك للمخطط مع بيانات ديناميكية واقعية، دون الحاجة لكتابة استجابات. من هناك يمكنك إضافة قواعد مخصصة لشروط الطلب/الاستجابة المحددة التي تحتاجها اختباراتك.