تطوير التطبيقات باستخدام Kubernetes

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
يُعتبر Kubernetes على نطاق واسع المنصة المثالية للفرق في المؤسسات الكبيرة والمتوسطة التي تتطلب توفرًا عاليًا وقابلية للتوسع التلقائي. ومع ذلك، فقد أضاف أيضًا تعقيدًا إلى سير عمل المطورين الحالي. يمكن فهم هذا التغيير كجزء من توجه أوسع نحو تبني نموذج الخدمات المصغرة (micro-service) والتعقيد المتزايد في كيفية تشغيل البرمجيات. في هذه المقالة، سنبحث كيف تطورت مشكلة تطوير البرمجيات مع هذا التحول النموذجي.
حلقة التطوير
لنبدأ بمفهوم حلقة التطوير ودورها في سير عمل التطوير. تتكون حلقة التطوير لأي مشروع برمجي من حلقتين منفصلتين تتقاطعان عبر Git.

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

لننفترض إعدادًا بسيطًا حيث يقوم الـ الواجهة الأمامية باستدعاء الـ واجهة برمجة التطبيقات (API)، والتي بدورها تتواصل مع خدمتين أخريين تُسميان الهوية و db. في هذا السيناريو، يعمل مطورنا على api ، والتي تحتوي على تبعيات هابطة (الواجهة الأمامية) وصاعدة (الهوية، db). دعنا نستكشف كيف تتغير عملية التطوير لخدمة api في حلقتي التطوير المختلفتين -
دورة التطوير الداخلية
- الوصول إلى التبعيات الصاعدة -
apiتحتاج الخدمة إلى التواصل مع خدمتي الهوية وdb لتعمل بنجاح. - الوصول إلى التبعيات الهابطة - لاختبار ما إذا كانت التغييرات التي يتم إجراؤها على خدمة
apiمتوافقة مع تبعياتها الهابطة، من المهم أيضًا إعادة توجيه الطلبات الهابطة إلى هذه الخدمة.
دورة التطوير الخارجية
- التبعيات الصاعدة - لكي يتم تشغيل اختبار شامل لخدمة
api، يجب أن يكون هناك وصول إلى نسخة عاملة منidentityوdbخدمات - التبعيات النهائية - هناك أيضًا حاجة إلى طريقة للسماح لـ
الواجهة الأماميةبالوصول إلى هذه الخدمة لأغراض الاختبار. - نقطة نهاية مستضافة - بالإضافة إلى المتطلبات المذكورة أعلاه، نحتاج أيضًا إلى استضافة هذه النسخة من
واجهة برمجة التطبيقات (API)الخدمة بحيث يمكن اختبارها مباشرة
مشكلة حلقة التطوير الداخلية هي شيء Telepresence من Ambassador Labs قد حلته. لقد حاولنا حل مشكلة حلقة التطوير الخارجية على منصة TrueFoundry من خلال Intercepts.
تقديم TrueFoundry Intercepts

يعمل مفهوم TrueFoundry Intercepts على حل مشاكل حلقة التطوير الخارجية الثلاث الموضحة في الأقسام السابقة. نتبع الاستراتيجية التالية لمعالجة ذلك -
- عناوين URL للمعاينة - باستخدام المنصة نفسها، من السهل نشر نسخة من خدمة موجودة عند SHA التزام محدد. يتيح لك ذلك إنشاء عناوين URL للمعاينة مخصصة لالتزام معين أو طلب سحب.
- اعتراضات قائمة على الرأس - تتيح الاعتراضات للخدمة الاستمرار في استخدام نفس عنوان URL مع إضافة رأس إضافي يعيد التوجيه إلى النسخة التجريبية. على سبيل المثال، يمكننا ربط اعتراض بـ
APIخدمة تعيد التوجيه إلى نسخة تجريبية بناءً على رأس يتم تمريره إليها. هذا يعنيالواجهة الأماميةيمكنها الاستمرار في العمل بنفس عنوان URL بمجرد تمرير رأس إضافي أثناء الاختبار.
💡
لقراءة المزيد حول اعتراضات TrueFoundry، يرجى الرجوع إلى وثائقنا - https://docs.truefoundry.com/docs/intercepts
خاتمة
لقد ناقشنا التغييرات في سير العمل التطويري التي أحدثها ظهور الخدمات المصغرة (microservices) وكيف نحاول معالجتها. لا يزال هذا سؤالاً مفتوحاً، ويمكننا أن نتوقع المزيد من الحلول المبتكرة في هذا المجال مستقبلاً.
تحدث معنا
إذا كنت تتطلع إلى زيادة العوائد من مشاريع نماذج اللغة الكبيرة (LLM) الخاصة بك وتمكين عملك من الاستفادة من الذكاء الاصطناعي بالطريقة الصحيحة، يسعدنا التحدث وتبادل الأفكار.
تناول قهوة ☕️ معنا
تعرف على كيف يساعدك TrueFoundry في نشر نماذج اللغة الكبيرة (LLMs) في 5 دقائق:
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI





















.png)
.webp)










.webp)






