موثوقية العالم لخادم الدبابات

موضوع اليوم - موثوقية World of Tanks Server - زلق إلى حد ما. إن موثوقية اللعبة هي مقايضة ، لذلك يجب القيام بكل شيء بسرعة وبسرعة في تطوير اللعبة. الحمل على الخوادم كبير ، ويميل المستخدمون إلى كسر شيء فقط من الفائدة. قال Levon Avakyan في RIT ++ ما تقوم به Wargaming لضمان الموثوقية.

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

حول المتحدث: يعمل Levon Avakyan في Wargaming كرئيس لخدمات ألعاب WoT وموثوقيتها ويتعامل مع مشاكل موثوقية خادم الخزان.

اليوم سأتحدث عن كيفية القيام بذلك ، بما في ذلك ما يدور حوله خادم World Of Tanks ، وما يتكون منه ، وما بني عليه ، حتى تفهم موضوع المحادثة. علاوة على ذلك ، سننظر في ما يمكن أن يحدث خطأ داخل الخادم نفسه وحوله ، لأن اللعبة بالفعل أكثر من الخادم. وسنتحدث أيضًا قليلاً عن العمليات ، لأن الكثير ينسى أن عملية راسخة في الإنتاج هي جزء من النجاح ليس فقط من حيث توفير الموارد (تأتي العديد من الممارسات من الإنتاج الحقيقي) ، ولكنها تؤثر على جودة وموثوقية الحل.


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

تكنولوجيا BigWorld

هذا هو محرك الواجهة الخلفية ، فضلا عن مجموعة أدوات لإنشاء MMOs.

محرك BigWorld Server القديم إلى حد ما (نشأ في أواخر التسعينات وأوائل العقد الأول من القرن الحادي والعشرين) عبارة عن مجموعة من العمليات المختلفة التي تدعم اللعبة. يتم إطلاق العمليات على كتلة ، مترابطة في شبكة من الآلات. التفاعل مع بعضها البعض ، تظهر العمليات للمستخدم نوعًا من آليات اللعبة.

يسمى المحرك BigWorld ، لأنه من الجيد جدًا إنشاء ألعاب عليه ، حيث يوجد حقل كبير (مساحة) ، تتم فيه العمليات العسكرية (المعارك). بالنسبة للدبابات ، هذا يناسب تمامًا.

من حيث الموثوقية ، تم استثمار الميزات الرئيسية التالية في BigWorld:

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

العمليات الموجودة في نظامنا ووظائفها

• CellApp هي العملية المسؤولة عن معالجة مساحة اللعبة أو جزء منها.
  

كما قلت ، يعمل BigWorld مع مساحات معينة نقوم بتقسيمها إلى خلايا. يتم حساب كل خلية محددة من مساحة لعبتنا من خلال تطبيق معين.

• CellAppMgr - العملية التي تنسق عمل CellApp ، موازنة التحميل.
  

يمكن أن يكون CellApp كثيرًا ، وبالتالي ، يجب أن تكون هناك عملية تتحكم فيها.

• تدير BaseApp الكيانات ، وتعزل العملاء عن العمل مع CellApp.

أحد الأشياء الأساسية في BigWorld هو مفهوم الكيان - على سبيل المثال ، حساب اللاعب. كل ما نقوم به في ساحة المعركة ، نقوم به مع هذا الكيان. تحسب CellApps الفيزياء وآليات اللعبة ، مثل التصوير. يعمل BaseApp مع الكيانات. يخدم الحساب ، الخزان ، إلخ.

• ServiceApp هو تطبيق Base Base متخصص يقوم بتنفيذ نوع من الخدمة.

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

• يدير BaseAppMgr BaseApp و ServiceApp ، لأن هناك الكثير منها أيضًا.
• يقوم LoginApp بإنشاء اتصالات جديدة من العملاء ، وكذلك يقوم بإنشاء وكلاء للمستخدمين على BaseApp.
• تطبق DBApp واجهة وصول إلى التخزين (قواعد البيانات). نحن نعمل مع بيركونا ، ولكن قد تكون قاعدة بيانات أخرى.
• DBAppMgr ينسق عمل DBApp.
• تدير InterClusterMgr الاتصالات بين المجموعات.
• المراجع هو مفتش عملية يمكنه إعادة تشغيل العمليات.
• Bwmachined   - برنامج يعمل على كل آلة في المجموعة لتنسيق عملها. يسمح لجميع مديري BaseApp بالتواصل مع بعضهم البعض.

هكذا تبدو الدبابات من الداخل ، ولو لفترة وجيزة:

• عملاء الاتصال عبر الإنترنت ، والحصول على LoginApp.
• يقوم LoginApp بتفويضهم باستخدام DBApp ويصدر عنوانًا من BaseApp.
• المزيد من العملاء يلعبون عليها.

كل هذا مبعثر عبر العديد من الأجهزة ، كل منها يحتوي على BWMachineD ، والذي يمكنه إدارة كل هذا ، أو التنسيق ، إلخ.

النظام البيئي العالمي من الدبابات

ماذا يوجد في الجوار؟ يبدو أن هناك خادم لعبة واللاعبين - اختاروا دبابة ، ذهبوا للعب. ولكن ، لسوء الحظ (أو بفرح) ، تتطور اللعبة ، ولم تعد آليات لعبة "مجرد إطلاق النار" كافية. وبناءً على ذلك ، بدأ خادم الألعاب يتضخم مع خدمات متنوعة ، كان من المستحيل القيام ببعضها بشكل عام داخل الخادم ، بينما بدأنا في إخراج الآخرين خصيصًا لزيادة سرعة تسليم المحتوى إلى اللاعب. أي أنه من الأسرع كتابة خدمة صغيرة في Python تقوم بميكانيكا الألعاب من فعلها داخل الخادم على جميع BaseAPPs ، مجموعات الدعم ، إلخ.

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

كل شيء سار بشكل سريع وفوضوي ، مما أدى إلى بعض تقنيات حديقة الحيوان التي يتم استخدامها في نظامنا البيئي للدبابات.

التقنيات والبروتوكولات الرئيسية:

1. بيثون 2.7 ، 3.5 ؛

2 - إرلانغ ؛

3 - سكالا ؛

4. جافا سكريبت.

الأطر

5 - جانغو ؛

6. فالكون.

7. غير متزامن ؛

التخزين:

8. Postgres.

9. بيركونا.

10. Memcached و Redis للتخزين المؤقت.

معًا بالنسبة للاعب هذا هو خادم الخزان:

• نقطة تفويض واحدة ؛
• الدردشة
• عشائر
• نظام الدفع ؛
• نظام البطولة
• ألعاب ميتا (خريطة عالمية ، مناطق محصنة) ؛
• بوابة الخزان ، بوابة العشيرة ؛
• إدارة المحتوى وما إلى ذلك.

ولكن إذا نظرت ، فهذه أشياء مختلفة قليلاً مكتوبة على تقنيات مختلفة. هذا يسبب بعض مشاكل الموثوقية.



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

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

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

بالإضافة إلى ذلك ، دفعنا إطار Chromium Embedded Framework (CEF) داخل عميل الخزان. لدينا الآن نفس المتصفح. لا يميزه اللاعب عن نافذة اللعبة. هذا يسمح لك بالعمل مع البنية التحتية بأكملها ، متجاوزًا العمل مع خادم اللعبة.

لدينا العديد من المجموعات - حدث ذلك - سأخبرك لماذا. هذا ما تبدو عليه منطقة رابطة الدول المستقلة.



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

هذا ما يبدو عليه النظام البيئي لعالم الدبابات.

ما الخطأ في كل هذا الاقتصاد؟ أي شيء تريده! ويذهب J. ولكن دعونا تفكيكها.

نقاط الفشل الرئيسية داخل الكتلة

فشل آلة أو عملية واحدة

إن أبسط خيار يمكننا التنبؤ به هو فشل جهاز أو عملية واحدة داخل الكتلة. لدينا مجموعات من 10 إلى 100 سيارة - شيء يمكن أن يطير. كما قلت ، يوفر BigWorld نفسه آليات خارج الصندوق تسمح لنا بأن نكون أكثر موثوقية.



المخطط القياسي: هناك BaseApps المنتشرة عبر أجهزة مختلفة. على BaseApp هناك كيانات تحتوي على كيانات الدولة. كل BaseApp يدعم نفسه مع Round Robin على الآخرين.

لنفترض أن لدينا ملفًا وتوفى بعض تطبيقات BaseApp ، أو مات الجهاز بأكمله - فلا بأس! تركت تطبيقات BaseApps المتبقية هذه الكيانات ، وستتم استعادتها ، ولن تعاني طريقة اللعب للاعب.



يفعل CellAPPs الشيء نفسه تمامًا ، والشيء الوحيد هو أنهم يخزنون حالاتهم على BaseApps أيضًا ، وليس على CellAPPs أخرى.

يبدو أنها آلية موثوقة ، ولكن ...

عليك أن تدفع ثمن كل شيء

بمرور الوقت ، بدأنا في ملاحظة ما يلي.

• يبدأ إنشاء نسخ احتياطية من الكيانات في استيعاب المزيد والمزيد من موارد النظام وحركة مرور الشبكة.

في الواقع ، تبدأ عملية النسخ الاحتياطي نفسها في التأثير على استقرار النظام عندما تكون معظم الشبكة مشغولة في إرسال النسخ إلى Round Robins داخل المجموعة.

• يزداد حجم الكيانات بمرور الوقت ، مع إضافة سمات جديدة وميكانيكا اللعبة.

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

• انخفاض استقرار النظام بشكل عام

نظرًا لحقيقة أننا نحاول الهروب من سقوط آلة أو عملية واحدة ، فإننا نسقط استقرار النظام بأكمله.

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

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

فشل مركز البيانات. كتلة متعددة

إذا لم تسقط فجأة 1-2 سيارات ، وبدأنا نفقد مركز البيانات بالكامل ، أي المجموعة بالكامل ، ما الخصائص التي يجب أن يمتلكها النظام حتى لا تقع اللعبة في مثل هذه الحالة؟

• يجب أن تكون كل مجموعة مستقلة ، أي:
  
  1. يجب أن يكون لها قاعدة بيانات خاصة بها ؛
  2. تقوم المجموعة بمعالجة مساحاتها فقط (ساحات المعارك).
  وهكذا ، إذا ضربت بعض الساحات ، لا يزال البعض الآخر يعمل.
• يجب أن تتواصل المجموعات مع بعضها البعض بحيث يمكن للمرء أن يقول للثانية: "لقد سقطت!" عندما ترتفع ، سيتم استعادة البيانات من النسخ المحفوظة.
• من المرغوب أيضًا أن تقوم بنقل المستخدم من مجموعة إلى أخرى.

في الوقت الحالي ، يبدو مخطط مجموعتنا المتعددة هكذا.



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

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

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

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

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

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

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

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

أذكرك أنه بالإضافة إلى مجموعة الألعاب مع BaseApps و CellApps وغيرها ، لدينا نظام بيئي.



نحاول التأكد من أن أداء النظام البيئي لا يؤثر على طريقة اللعب. في أسوأ الحالات ، على سبيل المثال ، لا يعمل نظام البطولة ، ولكن يمكنك اللعب بشكل عشوائي - على أي حال ، يلعب معظم الناس بشكل عشوائي. نعم ، لقد خفضنا الجودة ، ولكن بشكل عام ، يمكنك البقاء على قيد الحياة لعدة ساعات بدون بطولات.

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

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

نقاط فشل النظام البيئي لعالم الدبابات

المشكلة رقم 1. زيادة الحمل

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

يعد تفاعل الواجهة والتفاعل المصدر الرئيسي لزيادة حمل النظام البيئي.

سأعطي مثالين من خدمة العشيرة:

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

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

نصيحتي الشخصية حول كيفية التعامل مع هذا: أفضل طريقة لجعل النظام أكثر موثوقية تحت التحميل هو تقليل الحمل بشكل عام بطريقة منطقية.

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

إذا كنت تفكر بعناية ، يمكن تجنبها ببساطة.

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

— Web-sockets (nginx-pushstream) . , Web-sockets. , Chromium Embedded Framework — , , Web-sockets Nginx. pushstream, Web-sockets .

№ 2.

, , , — . , , — . , , .

? : - , - , , . - , , . .

.



, 120 Game Play . . , , . , . .



3 , :

1. HTTP API;
2. RabbitMQ — ;
3. Apache Kafka .

, , , , , . , - — , . , .



1. HTTP

— HTTP. , , -, . :

• ( , ).
  

, , . , , , Django, 100 200 , API, . , , - 30-40 , , . , — .

• .
  

, , HTTP, — . . — — . , , , , .

• .
  

. . - , - API — API, .

— , . , , . , 10 , - 100 500. , HTTP . nginx' , — .

, HTTP , .

2. RabbitMQ

RabbitMQ BigWord .

• .
  

— - , , , .

• «», , .
  

: . , API: « N — ». , , , , — . , .

«», «», — .

• .
  

RabbitMQ , , , , , , , .

— RabbitMQ .

3. Kafka

, , — Kafka. , RabbitMQ - .

• .
  

, , , . , , . . Kafka. , — , .

• .
  

, . , , - — .

Kafka , , , - , . .

— .



:

• . , - , ..
• — , , , .
• — , . , , .

. , , , entity. . , , .

DLC

, DLC (Development Lifecycle) — , , .



, , . DLC , , . , . , , , .

DLC, . , , , .

DLC, , :

• ( ).

, , «- , », . , , , , .

• : SRE.

, solution-, technical-owner, reability- — , - , game- . , , , . - , , , , . , .

• SRE .

— - . , . , SRE -. SRE , : « , , , — !» , .

QA , , - , , — .

BigWorld Technology «» . , . . « », .

« » , , . — «» (, ) — . , . , - .

: ++. , 40 , . , .

RootConf — DevOpsConf Russia . DevOps 1 2 , . , . , — !