معايير متعدد اللغات: اختيار الأداة المناسبة للوظيفة المناسبة

رفيق قصير وسهل القراءة. للاطلاع على التعمق الكامل في البنية - تخطيط الحزام، ومصفوفة القرار، والأنماط المضادة، وكيفية تفرع المعايير - اقرأ مقالةالطويلة.

اختارت مؤسستك مكدسًا واحدًا في عام 2019. لكن أعباء العمل الخاصة بك لم تفعل ذلك.

لا تزال معظم الفرق تعمل على توحيد لغة واحدة لكل خدمة جديدة: كل شيء في Node، وكل شيء في Python، وكل شيء في Java، أو رهان بطولي على Rust من أجل الحقول الخضراء فقط. هذه العادة مفهومة - يصبح التوظيف وقوالب CI ومراجعة الأمان أسهل عندما تكون الحزمة موحدة. المشكلة هي أن أعباء العمل ليست موحدة. تعمل بوابة API، ووظيفة ETL الليلية، وتحويل حافة NGINX، وملكية الخدمات الصغيرة لـ JVM، والواجهة الخلفية للدردشة ذات الاتصالات طويلة الأمد على التركيز على أجزاء مختلفة من وقت التشغيل. إن اختيار فائز واحد من مناظرة في المدخل أو اختيار معيار صغير واحد هو كيف ينتهي بك الأمر إلى استخدام الأداة الخاطئة التي تحمل العبء الخطأ.

مقاييس متعدد اللغاتهو الترياق: أداة قابلة للتكرار ولوحة معلومات حية تقارنثمانية أوقات تشغيلعلى أعباء عملنفسهاHTTP، بحيث يمكن للمهندسين المعماريين مطابقة الأدلة مع السياقات المحدودة بدلاً من تحيز المكدس الافتراضي.

ما يقيسه

لوحة المعلومات العامة تقارنNGINX njs,OpenResty Lua,Python (FastAPI),Go (net/http),Rust (Actix)وBunوJava (Javalin / Jetty)وKotlin (Ktor / Netty)عبر سبعة اختبارات تركيبية تعكس API الحقيقي وأنماط الحواف: الخط الأساسي للنص العادي، وتسلسل JSON، وفيبوناتشي المرتبطة بـ CPU، والسلسلة المعالجة، فحص الطلب، الطلب الفرعي الداخلي + التحويل، ومنطق التوجيه. يُبلغ كل اختبار عن الطلبات في الثانية، والمتوسط ​​ووقت الاستجابة (بما في ذلك P99)، والوقت حتى البايت الأول من التجعيد، وأعداد الأخطاء - يتم بثها مباشرة عند اكتمالbench.sh.

Java وKotlin موجودان جنبًا إلى جنب مع أوقات التشغيل المترجمة والبرمجة النصية حتى تتمكن متاجر JVM من رؤية كيف تتداول Javalin وKtor ضد Go وRust وBun وFastAPI على مسارات متطابقة - وليس ضد سرد متموج يدويًا "المؤسسة مقابل الحقل الأخضر". يعيش الحزام في أمثلة / معايير سير عمل: خدمات الإنشاء Docker، وملف تعريفwrkمشترك (10 ثوانٍ، 4 خيوط، 100 اتصال)، ونتائج JSON التي تستهلكها لوحة المعلومات. يمكنك تفرعها للمرشحين والمسارات الساخنة الخاصة بك.

لماذا يعتبر هذا إطار عمل للقرار، وليس لوحة صدارة

لا تتوج معايير

Polyglot Benchmarks لغة واحدة إلى الأبد. يتغير الفائزون حسب صف الاختبار - وهو بالضبط ما تريده عند تصميم الخدمات الصغيرة. يقوم قسم الحكم في لوحة المعلومات بتعيين النتائج لحالات الاستخدام (توجيه الحافة في Lua/njs، والتزامن الأساسي في Rust/Go، وخدمات JVM في Java/Kotlin، والسرعة في Python). هذه هي الأطروحة:متعدد اللغات حسب التصميم، مع بيانات لوحات مراجعة الهندسة المعمارية بدلاً من الرأي.

ست فوائد للمنصة والقيادة الهندسية

• الأدلة فوق الرأي— إرفاق المخططات والتكوينات بـ ADRs؛ تسوية مناقشات المكدس من خلال جولات محسوبة.
• الفائزون في أحمال العمل- المسارات الحساسة لزمن الوصول مقابل تحويلات الدفعة مقابل الحافة مقابل عقارات JVM تحصل على قادة مختلفين.
• إجمالي تكلفة الملكية— RPS الخام ليس كافيًا؛ وزن وقت البناء وحجم الصورة وملاءمة مهارات الفريق وعبء العمليات.
• سير العمل القابل للتكرار- نفس الريبو، نفس ملف الإنشاء، نفس البرنامج النصي للعمل؛ يمكن إعادة تشغيله في CI.
• خدمات مشروعة متعددة اللغات- لغات مختلفة لكل حدود الخدمة دون خجل أو مفاجأة.
• تقليل المخاطر— النموذج الأولي في المركز الثاني قبل التفويض على مستوى المؤسسة.

بداية سريعة

1. افتح لوحة القيادة المباشرةأثناء التشغيل (أو ابدأ تشغيلًا محليًا).
2. Cloneworkflow-examplesوcd benchmarksوdocker compose up— ثماني خدمات لغات بالإضافة إلى لوحة القيادة ومجرى المقعد.
3. اقرأresults.jsonعلى حجم لوحة المعلومات وقم بتعيين الفائزين إلىفي صفوف حمل العمل.
4. اكتب ADR - يتضمن المدة والخيوط والاتصالات وفئة الأجهزة.

اقرأ النسخة الطويلة

تغطي مقالةالطويلةتخطيط الريبو الكامل، وجدول المعايير، ومخطط مصفوفة القرار، وأنماط الحالة لكل مجموعة اختبار (بما في ذلك Java وKotlin)، والأنماط المضادة، والقيود، ومقتطفات جاهزة لتحسين محركات البحث للمشاركة مع ARB الخاص بك. تم النشر بواسطةWorkstation; موقع قياس الأداء مستضاف علىpolyglot-benchmarks.fictionally.org.

#Rust #GoLang #Bunjs #Java #Kotlin #Lua #Python #njs #FastAPI #Javalin #Ktor #OpenResty #polyglot #benchmarks