administration

مدونة المبرمج: ماذا يحدث تحت غطاء gamer.ru

content auto translated from {from}

لمحة تاريخية قصيرة

تعيش موقع gamer.ru بالفعل إعادة كتابة كاملة للرمز للمرة الثالثة (وربما حتى الرابعة). تم إنشاء المشروع في البداية باستخدام Ruby-on-Rails في سنوات الألفين البعيدة. كانت البنية معمارية مدمجة، لذا كانت كل طلبات المستخدم "تجر" خلفها عددًا هائلًا من الطلبات الإضافية إلى قاعدة البيانات وتحميل جميع المكتبات الممكنة. لضمان عمل المورد عند 100 ألف زائر يوميًا، كان من الضروري استخدام خمسة سيرفرات قوية، استخدام memcached وRedis وتكرار قواعد البيانات عبر العديد من السيرفرات. سمح ذلك بالبقاء على قيد الحياة بصعوبة حتى عام 2018، عندما بدأت الشركة تواجه مشاكل مالية وتفكك فريق المطورين.

حوالي عام 2020، سقط شهادة SSL عن الموقع. كان من المستحيل تحديثها، حيث كانت النسخة القديمة من Ruby-on-Rails تعتمد على إصدار قديم من openssl، بينما كانت الشهادات الجديدة تتطلب إصدارًا أكثر حداثة. لم يهتم أحد كثيرًا - استمر الموقع في العمل بشكل غير متقن. في الفترة من 2015 إلى 2025، انخفضت الزيارات تدريجياً من 100 ألف إلى 1000 شخص يومياً. بدأت المدونات المخفية والتعليقات في احتواء عدد هائل من الرسائل غير المرغوب فيها، بما في ذلك محتوى غير محترم. فقد ياندكس تمامًا الاهتمام بنا، وامتلأت صفحة مشرف الويب لدينا بأخطاء حرجة.

ماذا فعلنا لإصلاح كل شيء

كان الموقع بحاجة إلى تحسين كبير، حيث لم تعد البنية القديمة تتناسب مع الواقع. تراكم في قاعدة البيانات حوالي 100 ألف منشور و1.6 مليون تعليق، كان من الضروري نقلها بعناية إلى المحرك الجديد. قررنا الانتقال إلى بنية الميكروسيرفيس على كل من الواجهة الخلفية والواجهة الأمامية، مع الاستفادة من التكنولوجيا الحديثة، بما في ذلك عناصر HTMLElement العصرية.

تمت إعادة كتابة المشروع بالكامل من الصفر باستخدام NodeJS دون استخدام مكتبات طرف ثالث، مما يضمن لنا حياة هادئة لمدة 10 إلى 20 عامًا القادمة. الآن يمكننا ألا نخاف من أن تحديث مكتبة عصرية مثل ExpressJS أو React سيكسر الموقع بأكمله ويتطلب إعادة هندسة ضخمة مرة أخرى. حتى محرر المنشورات البصري كان علينا كتابته بأنفسنا، لأننا لم نجد أي شيء جاهز يتماشى مع طلباتنا المتواضعة. الآن يقوم المحرك بتقديم صفحات HTML للأجهزة القديمة ومحركات البحث، بينما يقدم المحتوى للمستخدمين عبر AJAX.

حتى اليوم، يتحمل الموقع بنجاح متوسط تحميل يقارب 150 طلبًا في الثانية، حيث يشكل الزوار الآليين ونباتات الزحف الجزء الأكبر من حركة المرور. تتصرف روبوتات semrush وopenai بشكل نشط بشكل خاص، وكأنها تحاول تحميل الموقع بالكامل خلال يوم واحد. بينما يقوم ياندكس بفهرستنا ببطء، بسرعة 1-2 طلب في الثانية، يمكن لهذه الكائنات أن تطلب 50 طلبًا.

ومع ذلك، كان المحرك مُحسنًا لدرجة أن كل هذه جيش الروبوتات يمكن لمسه بسهولة باستخدام خادم افتراضي واحد غير مكلف يبلغ حوالي 500 روبل شهريًا.

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

post more button

1081

post actions

تعليقات

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

نعم، شيء من هذا القبيل ) هذه الطريقة تسمح أيضًا باستخدام وحدات بنفس الصادرات على الواجهة الأمامية والخلفية.

بهذه الطريقة:
let { session, ajax, addViewRoute } = typeof window !== 'undefined'
? await import("../../shared/frontend.js")
: await import("../../shared/backend-server.js")

هذا يسمح لك باستخدام نفس الكود في المتصفح والخادم. وهو مفيد بشكل خاص للقوالب وتعريف المسارات العامة.

رائع! يذكرني قليلاً بـ Dapr من .NET، إنه حل مثير جداً وأنيق. هل أفهم بشكل صحيح أن منطق الأعمال لا يعرف أين يوجد الوحدة فعلياً، وأن وسيلة النقل تختار على مستوى التجريد؟ إذا كان الأمر كذلك، يبدو أنه تم تنفيذ تجريد RPC مخصص مع التبديل بين الاستدعاءات المحلية و http؟

بوابة مكتوبة ذاتيًا، مصنوعة بهذه الطريقة بحيث يمكن أن تكون الخدمات الدقيقة جزءًا من مونوليث أو يمكن تشغيلها كمكونات صغيرة مستقلة. أي أن أي طريقة API يمكن أن تبقى داخل المونوليث أو تُستخرج بشكل منفصل مع سطرين من التعليمات البرمجية. يساعد ذلك في توفير الذاكرة (لأنها محدودة، ويتطلب كل عملية حوالي 200-500 ميغا بايت من الذاكرة العشوائية)، ولكنه في الوقت نفسه يتيح توزيع الحمل عبر خوادم إضافية. هناك وظيفة عالمية ajax(طريقة، مسار،...)، التي تستدعي وظائف من الوحدات المجاورة؛ إذا كان الوحدة المجاورة في نفس المجال، يتم استدعاء الوظيفة مباشرة، وإذا كانت في الآخر، يتم عبر طلب شبكة مع تمرير معرف جلسة المستخدم... كل شيء كان رائعًا جدًا، ومن باب الاحتياط، حتى الآن، كل شيء لا يزال متشعبًا في المونوليث.)

شكراً على التحليل التفصيلي. من القيم بشكل خاص أنه تم وصف الحلول، وكذلك القيود الحقيقية التي كان لا بد من مواجهتها. عادة ما تبقى مثل هذه الأمور بعيدة عن الأنظار.

أنا فضولي، إذا لم يكن سراً، ماذا تستخدم حالياً كواجهة برمجة التطبيقات (API Gateway)؟ ما الذي أثبت أنه ملائم للتوجيه، والتوثيق، وتحديد الحد الأقصى في نظام الخدمات المصغرة؟

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

بالطبع لا يمكن أن يُسعد مسار إحياء Gamer ، لكن أين، اسمحوا لي أن أسأل، قد اختفوا المكافآت الصغيرة المتبقية من الأوقات السابقة: الحالة VIP التي كانت تسمح بتحرير المشاركات دون إنفاق الطاقة، والميداليات التي كانت تجلب شعورًا لطيفًا بالحنين، والتراسل مع الأصدقاء، وفي النهاية قائمة الأصدقاء؟ أين هي إداراتي على مدونة "The Witcher 3: Wild Hunt"؟ وأين هي حالتي الشخصية Wiedzminka، التي حصلت عليها ذات مرة عند الوصول إلى المستوى 60؟ أوه، صحيح، وأين هي المستويات نفسها؟ لا أطلب أن تعيدوا لي اللمبة، لكن من المحبط جدًا فقدان عناصر التدوير التي كان يشتهر بها Gamer القديم.

شكراً.