إدارة واجهات البرمجة غير المتزامنة على نطاق واسع: من التوثيق إلى الحوكمة

تتحول المعمارية المعتمدة على الأحداث من نموذج محدود بين عدد قليل من الخدمات إلى شبكة واسعة من المنتجين والمستهلكين وقنوات الرسائل. عند هذه النقطة، لا تعود المشكلة الأساسية هي إرسال الرسالة، بل معرفة ما الذي يُرسل، ومن يملكه، ومن يعتمد عليه، وكيف يمكن تغيير مخططه أو إعادة إنشاء بنيته التحتية دون التسبب في أعطال إنتاجية. هذا هو محور جلسة Ian Cooper حول إدارة واجهات البرمجة غير المتزامنة على نطاق واسع، بالاستناد إلى ممارسات هندسية واقعية في Just Eat Takeaway.

لماذا يتعقد الأمر مع التوسع؟

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

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

ثلاثة محاور لإدارة واجهات الأحداث

يقسم Cooper المشكلة إلى الاكتشاف والحوكمة والتزويد. ويبدأ ذلك بفهم ما يجب وصفه في أي نقطة نهاية عبر ما يسميه «ABCs»: العنوان، والربط، والعقد. العنوان يحدد مكان تدفق الرسائل، والربط يصف البروتوكول والنقل والترميز، أما العقد فيحدد الرؤوس والبيانات التي تحملها الرسالة.

في هذا السياق، توفر AsyncAPI نظيراً لآليات توثيق واجهات HTTP مثل OpenAPI، مع نمذجة الخوادم والقنوات والرسائل والعمليات والروابط الخاصة بالبروتوكول. وتدعم وصف الرسائل باستخدام JSON Schema وAvro وProtobuf، كما تسمح بإعادة استخدام التعريفات بدلاً من تكرارها في ملفات متعددة. لكن Cooper يؤكد أن وضع مئات ملفات AsyncAPI في مستودع واحد لا يحل الاكتشاف وحده؛ إذ يظل البحث النصي محدوداً عندما يكبر مخزون الأحداث.

لذلك قد تحتاج المؤسسات إلى أدوات كتالوج مثل EventCatalog أو Marmot، أو إلى سجل مفتوح مثل xRegistry، بهدف عرض تدفقات الرسائل والعلاقات بينها وربط المخططات بالمنتجين والمستهلكين. وتختلف هذه الأدوات في مستوى التصور والواجهات الجاهزة، لكن وظيفتها المشتركة هي نقل الاكتشاف من سؤال يُطرح في Slack أو يُبحث عنه في مستودعات متفرقة إلى خدمة قابلة للاستعلام.

دور CloudEvents في توحيد البيانات الوصفية

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

وتشرح الجلسة أن نمطي binary وstructured في CloudEvents يرتبطان بقدرة بروتوكول النقل على حمل الرؤوس، لا بكون الرسالة «ثنائية» أو «منظمة» بالمعنى المعتاد. وتبرز أهمية هذا التفصيل في أنظمة مثل SNS، حيث يمكن لعدد محدود من سمات الرسالة أن يُستهلك سريعاً إذا وُضعت كل بيانات CloudEvents في الرؤوس، ما يجعل تغليفها داخل الجسم خياراً عملياً في بعض السيناريوهات.

الحوكمة لا تقتصر على التوثيق

توثيق العقد يعرّف المستهلكين بماهية الرسالة، لكنه لا يمنع المنتج من نشر تغيير يكسر اعتمادهم. لذلك يوصي النهج المعروض باستخدام سجل مخططات يطبق قواعد توافق عند تحديث العقد، ويرفض الرسائل أو التغييرات التي لا تطابق القواعد المعتمدة.

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

ما الذي يتغير عملياً؟

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

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