Aspen: خادم Git مفتوح المصدر للوكلاء يتحمل 567 عملية دفع في الثانية

إذا سبق لك تشغيل عدة وكلاء برمجيين على مستودع واحد، فأنت تعرف هذه المعاناة: إنهم يدفعون التغييرات كثيرا، وبالتوازي، ومن دون أي انضباط. صمم خادم Git التقليدي للبشر الذين ينفذون بضع عمليات commit في الساعة. أما الوكلاء، فيستطيع كل منهم تنفيذ عشرات منها في الدقيقة، فيتحول الخادم إلى عنق زجاجة. وتقترح شركة Reason Machines الناشئة ‏(YC F26) حلا: Aspen، وهو خادم Git مفتوح المصدر بني خصيصا لهذا النوع من الأحمال.

ما الذي يعلن عنه المشروع

يورد المطورون رقما رئيسيا واحدا: يستطيع جهاز واحد بثماني نوى تحمل 567 عملية دفع في الثانية إلى المستودع نفسه. والجزء الثاني من الادعاء مهم أيضا: تحفظ كل عملية دفع قبل أن يطبع git كلمة «ok». أي إن السرعة لم تتحقق على حساب الموثوقية؛ فإذا تلقى العميل تأكيدا، تكون البيانات قد كتبت بالفعل.

أما النقطة الثالثة، وربما الأكثر عملية، فهي أن العميل يظل git قياسيا. لا حاجة إلى تثبيت أي شيء، سواء إضافات خاصة أو SDK منفصلة أو بروتوكول مخصص. يواصل الوكيل تنفيذ git push كالمعتاد، ولكن إلى عنوان آخر فحسب.

لماذا يهم ذلك الوكلاء تحديدا

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

لا يتوافر لدينا حتى الآن سوى الادعاء الوارد في منشور، لكن الاتجاه واضح: استخدام Git كذاكرة عمل للوكلاء يتطلب بنية خادم مختلفة عن البنية اللازمة لاستخدام Git أداة للتطوير الجماعي.

القيود والتحفظات

ما لدينا في جوهره حتى الآن هو منشور واحد على X ومقياس واحد. ولا نعرف كيف أجري الاختبار بالضبط: ما حجم عمليات الدفع، وما أنواع الأقراص المستخدمة، وكم عدد العملاء المتزامنين، وهل توجد تعارضات على الفروع نفسها. فالوصول إلى 567 عملية دفع في الثانية باستخدام عمليات commit فارغة أو متناهية الصغر يختلف كثيرا عن تحقيق الرقم نفسه مع تغييرات حقيقية داخل مستودع أحادي ضخم. كذلك ليس واضحا كيف يتعامل Aspen مع hooks وصلاحيات الوصول ومراجعة الشفرة وعمليات التكامل التي اعتادها مستخدمو GitHub وGitLab. المشروع لا يزال في بدايته، ومن المبكر انتظار نضج منتجي منه.

ما الذي ينبغي فعله عمليا

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