البرمجة وتطوير البرمجيات

كيف يعيد مكوّن OpenTelemetry في JetBrains رسم خريطة الخدمات المصغّرة لحظياً

تشرح JetBrains آلية بناء Service Map داخل بيئاتها التطويرية اعتماداً على آثار OpenTelemetry القادمة من النظام أثناء تشغيله، بدلاً من الاعتماد على مخططات ثابتة أو تحليل ساكن للكود. وتعالج الميزة البيانات المتأخرة وغير المرتبة لتحديث العلاقات بين الخدمات وقواعد البيانات ومواضع تكامل الرسائل تدريجياً.

16 سبتمبر 2026
4 دقائق قراءة
5 قراءة
فريق تحرير certi.news
كيف يعيد مكوّن OpenTelemetry في JetBrains رسم خريطة الخدمات المصغّرة لحظياً

نشرت JetBrains في 15 سبتمبر 2026 شرحاً تقنياً لكيفية عمل ميزة Service Map في إضافة OpenTelemetry، وهي ميزة ترسم العلاقات الفعلية بين الخدمات المصغّرة أثناء تشغيل التطبيق داخل بيئة التطوير. أعدّ الشرح Nikita Dukin وEgor Klimov، ضمن تعاون بين فريق Rider Execution وفريق Software Engineering Research.

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

الآثار هي مصدر الخريطة

تعتمد الإضافة على بيانات OpenTelemetry التي تجمع السجلات والمقاييس والآثار. وبينما توضح السجلات ما حدث وتبين المقاييس حجم الظاهرة، تكشف الآثار مسار الطلب عبر النظام. وتتكون كل عملية تتبع من وحدات عمل تسمى spans، وتوفر OpenTelemetry لها اصطلاحات دلالية موحدة، مثل آثار HTTP Client وHTTP Server.

تستخدم الإضافة هذه الآثار لفهم البنية التشغيلية من دون ربط الخوارزمية بإطار عمل أو لغة بعينها. فإذا كانت التطبيقات والمكتبات ترسل الآثار وفق توقعات OpenTelemetry، يمكن للميزة تصور الاتصالات بغض النظر عن التقنية المستخدمة. وتذكر JetBrains أن المنطق نفسه يمكن أن يعمل مع تطبيقات JVM و.NET وPython وGo وغيرها، كما يمكن استخدامه في IntelliJ IDEA وGoLand وPyCharm وWebStorm وRider.

كيف تُبنى الخريطة داخل بيئة التطوير؟

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

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

التحدي ليس الرسم بل تفسير البيانات

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

لذلك صنفت JetBrains إعادة بناء البنية باعتبارها خوارزمية لمعالجة تدفق البيانات. لا تنتظر الإضافة اكتمال التتبع، بل تفحص كل أثر فور وصوله. وتستخدم سمات مثل http.request.method وhttp.response.status_code لتحديد ما إذا كانت العملية اتصال HTTP، بينما تشير سمات أخرى إلى استعلام قاعدة بيانات أو تفاعل مع نظام رسائل.

بعد تصنيف الأثر، تحدد الخوارزمية الخدمة التي أصدرته. وإذا كانت الخدمة جديدة تُضاف إلى الخريطة، وإذا كانت موجودة تُدمج البيانات الجديدة معها وتُحدَّث إحصاءاتها. وفي اتصالات HTTP، تبحث الإضافة عن العلاقة بين أثر CLIENT الصادر من الخدمة المستدعية وأثر SERVER الناتج في الخدمة المستقبلة. وينتقل سياق التتبع مع الطلب، ما يجعل أثر SERVER ابناً لأثر CLIENT. فإذا كان الطرف الآخر موجوداً تُرسم العلاقة فوراً، وإذا لم يكن موجوداً يُحتفظ بالأثر في الذاكرة إلى أن تصل البيانات المقابلة.

تستخدم الاعتمادات الأخرى قواعد مختلفة. فعادة ما تمثل مكالمة قاعدة البيانات بأثر CLIENT واحد، ومنه تستنتج الإضافة عقدة قاعدة البيانات اعتماداً على السمات الدلالية. أما أنظمة الرسائل فتحتاج إلى مرونة أكبر، لأن علاقة المنتج بالمستهلك قد تظهر من خلال علاقة الأب والابن أو عبر روابط الآثار، بحسب نظام الرسائل وطريقة instrumention المستخدمة.

لماذا يهم هذا عملياً؟

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

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

مصدر الخبر
كيف أعددنا هذا الخبر؟

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

ف
كاتب المقال

فريق تحرير certi.news

فريق التحرير

فريق تحرير certi.news يتابع المصادر التقنية ويعيد بناء الأخبار بالعربية مع مراجعة الحقائق والسياق قبل النشر.

من نفس التصنيف

مقالات قد تهمك

عرض جميع المقالات