الرجوع إلى دراسات الحالة
البنية المرجعية

منصة MuleSoft الهجينة: تقنية RTF على OpenShift

تصف هذه البنية المرجعية وقت تشغيل MuleSoft الهجين الحقيقي المنشور عبر CloudHub 2.0 و Runtime Fabric (RTF) على OpenShift المستضاف في مركز بيانات العميل، مع توفير F5 للتوجيه المركزي والتحكم في الدخول وتوجيه حركة المرور بين مستويات وقت التشغيل. تم تصميم المنصة مع تكافؤ البيئات عبر المستويات غير الإنتاجية (DEV/TST/STG) ومرونة الإنتاج (PRD/DR).

graph TD Client[External Clients / Mobile / Web] --> F5[F5 Big-IP Load Balancer] subgraph ControlPlane[MuleSoft Anypoint Platform] API_Manager[API Manager] Runtime_Manager[Runtime Manager] end subgraph AWS[AWS Region - CloudHub 2.0] CH2_Ingress[CloudHub 2.0 Ingress] Exp_API[Experience APIs] Sys_API_CH[External System APIs] CH2_Ingress --> Exp_API Exp_API --> Sys_API_CH end subgraph OnPrem[On-Premise Data Center] OpenShift[Red Hat OpenShift Cluster] subgraph RTF[Runtime Fabric] RTF_Ingress[RTF Ingress Controller] Process_API[Process / Orchestration APIs] Sys_API_OP[Internal System APIs] RTF_Ingress --> Process_API Process_API --> Sys_API_OP end Backends[(Legacy DB / ERP / Mainframe)] Sys_API_OP --> Backends end F5 -->|External Traffic| CH2_Ingress F5 -->|Internal/Secure Traffic| RTF_Ingress Sys_API_CH -.->|VPN/Direct Connect| RTF_Ingress ControlPlane -.->|Management| Exp_API ControlPlane -.->|Management| Process_API ControlPlane -.->|Management| Sys_API_CH ControlPlane -.->|Management| Sys_API_OP classDef aws fill:#fff7ed,stroke:#f97316,stroke-width:2px,color:#c2410c; classDef onprem fill:#fef2f2,stroke:#ef4444,stroke-width:2px,color:#b91c1c; classDef control fill:#eff6ff,stroke:#3b82f6,stroke-width:2px,color:#1d4ed8; classDef lb fill:#f0fdf4,stroke:#22c55e,stroke-width:2px,color:#15803d; class AWS aws; class OnPrem onprem; class ControlPlane control; class F5 lb;
1

المبادئ المعمارية

  • هجين حسب التصميم (وضع وقت التشغيل): يتم وضع أحمال العمل على **CloudHub 2.0** أو **RTF** المحلي بناءً على الاتصال والامتثال وزمن الانتقال والقيود التشغيلية - دون المساس بالاتساق في الحوكمة والأمن وقابلية المراقبة.
  • التحكم المركزي في حركة المرور: يتم حوكمة جميع عمليات التوجيه الواردة من خلال طبقة دخول المؤسسة (**F5**) لفرض أنماط متسقة للتعرض ووضعية **TLS** وتوجيه حركة المرور عبر مستويات وقت التشغيل.
  • تكافؤ البيئات: تعكس بيئة ما قبل الإنتاج طوبولوجيا الإنتاج، بما في ذلك مسارات التوجيه وانقسامات وقت التشغيل، لمنع حالات الفشل التي تحدث في الإنتاج فقط والناتجة عن السلوك الهجين غير المختبر.
  • الجاهزية التشغيلية: يتم التعامل مع قابلية المراقبة والاستجابة للحوادث وأدلة إجراءات التعافي من الكوارث (**DR runbooks**) كمتطلبات تسليم أساسية ويتم تنفيذها جنبًا إلى جنب مع بناء المنصة.
2

نموذج الشبكات

2.1 تقسيم الشبكة والمناطق

تتماشى البنية المعمارية مع نموذج قائم على المناطق معتمد بشكل شائع في بيئات المؤسسات:

  • منطقة الدخول (Ingress Zone): نقاط الدخول الخارجية والداخلية التي يتم التحكم فيها من خلال **F5** (**VIPs**، توجيه **L7**، فرض السياسات).
  • مناطق وقت التشغيل:
    • مستوى وقت تشغيل **CloudHub 2.0** لأحمال عمل الـ **API** والتكامل المناسبة.
    • مستوى وقت تشغيل **RTF** المحلي الذي يعمل في مركز بيانات العميل على **OpenShift** لأحمال العمل التي تتطلب التواجد في مركز البيانات أو ضوابط أكثر صرامة.
  • منطقة الأنظمة الخلفية (Backend/System Zone): تطبيقات المؤسسة وقواعد البيانات والخدمات التي يتم الوصول إليها من خلال مسارات محكومة وقوائم السماح.

يتيح هذا الهيكل اتصالاً محكوماً شرقاً وغرباً وشمالاً وجنوباً مع الحفاظ على العزل بين البيئات (**DEV/TST/STG** مقابل **PRD/DR**).

2.2 توجيه حركة المرور (CloudHub 2.0 مقابل RTF المحلي)

يتم توجيه حركة المرور إلى مستوى وقت التشغيل المناسب بناءً على ملكية التطبيق ونموذج التعرض:

  • يوجه **F5** حركة مرور الـ **API** إلى **CloudHub 2.0** أو **RTF** المحلي بناءً على قواعد اسم المضيف / المسار (أو سياسات التوجيه المكافئة).
  • يكون اختيار مستوى وقت التشغيل صريحاً ومحكوماً؛ لا يتم نقل الخدمات بين المستويات دون مراقبة التغيير.

2.3 الاتصال بالأنظمة الخلفية للمؤسسة

تتبع عمليات التكامل التي تتطلب اتصالاً محلياً أنماطاً محكومة:

  • يصل **RTF** المحلي إلى أنظمة مركز البيانات مباشرة ضمن الحدود الأمنية المسموح بها.
  • يصل **CloudHub 2.0** إلى أنظمة المؤسسة من خلال أنماط اتصال معتمدة وضوابط شبكة المؤسسة، مما يضمن بقاء جميع مسارات الوصول قابلة للتدقيق ومحكومة.

2.4 المرونة ونطاقات الفشل

تم تصميم المنصة لعزل حالات الفشل:

  • لا تؤدي حوادث وقت تشغيل **CloudHub 2.0** مباشرة إلى إضعاف خدمات **RTF** المحلية والعكس صحيح.
  • يوفر **F5** سلوك توجيه محكوم ويسمح بأنماط الصيانة المخطط لها وأنماط التبديل عند الفشل المتماشية مع ممارسات المؤسسة.
3

استراتيجية DNS ونقاط النهاية

3.1 اصطلاح تسمية نقاط النهاية

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

  • api-dev.<domain> / api-tst.<domain> / api-stg.<domain>
  • api.<domain> (PRD)
  • api-dr.<domain> (DR)

يدعم هذا النمط فصلاً واضحاً للمخاوف وعزل البيئات والأتمتة السهلة.

3.2 ملكية DNS ومراقبة التغيير

يتم التعامل مع **DNS** كأصل محكوم للمؤسسة:

  • تتم إدارة مدخلات **DNS** عبر عمليات تغيير محددة مع تتبع التدقيق.
  • يتم تنفيذ تسمية نقاط النهاية والتبديلات وفقاً لحوكمة الإصدار وإجراءات التعافي من الكوارث.

3.3 استقلال التوجيه عن DNS (عند الاقتضاء)

بينما يوفر **DNS** هوية البيئة، تظل قرارات التوجيه محكومة عند طبقة الدخول:

  • يحل الـ **DNS** إلى نقاط دخول محكومة، ويطبق **F5** توجيهاً قائماً على السياسة إلى أهداف وقت التشغيل الصحيحة بناءً على قواعد التوجيه المعتمدة.
4

الشهادات وإنهاء TLS

4.1 استراتيجية TLS

يتم تنفيذ **TLS** لتلبية الوضع الأمني ومتطلبات الامتثال والبساطة التشغيلية:

  • يُفرض **TLS** لجميع نقاط النهاية الخارجية.
  • يمكن تطبيق **Mutual TLS (mTLS)** بعمليات التكامل الداخلية الحساسة عند الاقتضاء من السياسة.

4.2 خيارات الإنهاء والنمط القياسي

يتم الحفاظ على وضعية **TLS** متسقة عبر مستويات وقت التشغيل:

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

4.3 إدارة دورة حياة الشهادات

يتم توحيد حوكمة إصدار الشهادات وتدويرها وانتهاء صلاحيتها:

  • تتبع الشهادات معايير المؤسسة لقوة المفتاح والصلاحية ووتيرة التجديد.
  • يتم توثيق إجراءات التدوير واختبارها لتجنب انقطاع الخدمة.

4.4 الضوابط الأمنية عند الحافة

عند الدخول، تدعم البنية المعمارية التطبيق المتسق لـ:

  • فرض سياسة **TLS**
  • تصفية الطلبات وضوابط التوجيه
  • رؤوس الصفحات القياسية وأنماط تعزيز الأمن
  • حماية اختيارية متماشية مع أدوات ووضعية أمن المؤسسة
5

نموذج النشر

5.1 البيئات والطوبولوجيا

يتم نشر المنصة مع فصل واضح للبيئات:

ما قبل الإنتاج
DEV, TST, STG
كل منها مع طوبولوجيا وقت تشغيل هجين (**CloudHub 2.0** + **RTF** محلي) وتوجيه **F5**.
الإنتاج والتعافي من الكوارث
PRD و DR
طوبولوجيا هجينة منعكسة مصممة للمرونة التشغيلية والقابلية للاسترداد.

5.2 استراتيجية وضع التطبيقات

يتم وضع التطبيقات في أحد مستويات وقت التشغيل بناءً على:

  • موقع التبعيات (أنظمة مركز البيانات مقابل الأنظمة الجاهزة للسحاب)
  • متطلبات الأمن / الامتثال
  • حساسية الأداء وزمن الانتقال
  • القيود التشغيلية وملكية وقت التشغيل

5.3 CI/CD وحوكمة الإصدار

يتم تنفيذ عملية **CI/CD** موحدة لضمان القابلية للتكرار عبر أهداف وقت التشغيل:

مصدر وحيد للحقيقة للبناء والتعبئة
بوابات جودة مؤتمتة (اختبارات، تحقق)
نموذج ترقية البيئة (DEV → PRD)
قوالب نشر خاصة بوقت التشغيل

5.4 إدارة الإعدادات والأسرار

تكون الإعدادات خاصة بالبيئة ومنفصلة عن الكود:

  • إعدادات خارجية ومعالجة آمنة للأسرار متوافقة مع معايير المؤسسة
  • فصل واضح لإعدادات وقت التشغيل لـ **CloudHub 2.0** مقابل **RTF** المحلي
  • مراقبة التغيير والقابلية للتدقيق لتحديثات الإعدادات

5.5 الجاهزية للتعافي من الكوارث ونهج التبديل

يتم تنفيذ التعافي من الكوارث (**DR**) كقدرة تشغيلية، وليس فقط بنية تحتية:

  • إجراءات **DR** موثقة للتفعيل والتحقق
  • افتراضات **RTO/RPO** محددة (متماشية مع سياسة المؤسسة)
  • تمارين دورية للتحقق من الجاهزية وتقليل عدم اليقين في الاسترداد
6

نموذج قابلية المراقبة

6.1 أهداف قابلية المراقبة

تم تصميم استراتيجية قابلية المراقبة لدعم:

الاكتشاف السريع والفرز ربط طبقة الـ API إدارة القدرة الاستباقية تيليميتري جاهز للتدقيق

6.2 المقاييس والتسجيل

تغطي عملية جمع المقاييس والتسجيل صحة المنصة وسلوك التطبيق:

  • المقاييس: مؤشرات الأداء الرئيسية للـ **API** (زمن الانتقال، معدلات الخطأ)، حدود موارد وقت التشغيل، ومقاييس التبعية. يتم توحيد مقاييس **CloudHub 2.0** و **RTF** المحلي.
  • التسجيل: سجلات منظمة مع مخطط متسق، معرفات الارتباط (**Correlation IDs**) المنتشرة بشكل طبيعي من البداية إلى النهاية، والتوجيه إلى منصات مركزية (مثل **Splunk/ELK**).

6.3 التنبيه والاستجابة للحوادث

يتم تدوين العمليات التشغيلية من أجل الموثوقية:

  • عتبات تنبيه قائمة على **SLO** لزمن الانتقال / ارتفاع معدل الخطأ ومخاطر التشبع.
  • قالب **RCA** (تحليل الأسباب الجذرية) موحد، وقاعدة معرفة للقضايا المعروفة، وتدفقات فرز الحوادث مع تتبع تحسينات ما بعد الحادث عالمياً.
7

الحوكمة والأمن (موضوعات شاملة)

  • حوكمة الـ API: يتم فرض قواعد دورة الحياة والإصدار وأساسيات السياسة باستمرار عبر أوقات التشغيل.
  • الضوابط الأمنية: يتم توحيد معايير **OAuth2/TLS** و **RBAC** والفرض المدفوع بالسياسة لضمان وضعية متسقة عبر البيئات.
  • الضوابط التشغيلية: يتم دمج حوكمة الإصدار ومراقبة التغيير والقابلية للتدقيق في خطوط أنابيب المنصة وإجراءاتها.

هل تريد المزيد من التفاصيل العميقة؟

قم بتحميل وثائق الهندسة المعمارية الكاملة والمواصفات التقنية.

مواصفات المنصة (PDF) طلب تعمق تقني