yivgame
Yivgame هو حل خادم Architecture Microservice المكتوب في لغة GO استنادًا إلى GO-KIT. بالإضافة إلى خادم اللعبة (اتصال طويل) ، فإنه يتضمن أيضًا خادم واجهة API للعمليات الأمامية والخلفية. بالإضافة إلى الخادم نفسه ، سيتم أيضًا تورط التكوين التفصيلي لنشر Docker.
خاصية
- الهندسة المعمارية للخدمة الدقيقة
- يدرك العميل وخادم اللعبة نقل القابلية من خلال تدفق ثنائي الاتجاه GRPC
- اتصالات WebSocket من جانب الخادم
- قم بتنفيذ نقاط نهاية HTTP ونقاط WebSocket الأوزان والسجلات
ممارسة التصميم
الهندسة المعمارية للخدمة الدقيقة
- من خلال بنية الخدمات الصغيرة ، يتم تقسيم خوادم اللعبة التقليدية إلى خدمات microservices مختلفة
- يمكن أن تتواصل الخوادم الصغيرة المختلفة بشكل متزامن من خلال GRPC وعدم التزامن من خلال كافكا
نموذج يحركه المجال
- من أجل تحقيق فصل مستويات البرامج المختلفة ، تم تصميم كل خدمة وفقًا للنموذج الذي يحركه المجال.
- قسّم بنية برنامج الخدمات المجهرية من الداخل إلى الخارج إلى طبقة أعمال اللعبة ، واستخدم طبقة الحالة وطبقة الواجهة وطبقة تبعية المنشأة
- يلتزم بدقة بالاعتماد في اتجاه واحد من الخارج إلى الداخل بين المستويات المختلفة
تنفذ طبقة العمل بشكل أساسي المنطق الأساسي للعبة أو الخادم ، ولا تهتم بالتطبيقات الخارجية ، وتعتمد على أنظمة الملفات وقواعد البيانات ، إلخ لهم في الحقن التبعية. لذلك ، باستثناء الإشارة إلى بعض المكتبات القياسية الأساسية ، فإن طبقة العمل بالكاد تشير إلى حزم الطرف الثالث.
نموذج يحركه الحدث مع كافكا
- طريقة الاتصال الأساسية بين نظام الخدمات الدقيقة بأكملها هي مكالمة GRPC المتزامنة والاتصال غير المتزامن باستخدام Kafka كمنصة دفق.
- سيتم نشر جميع الأنشطة التي يتم اتباعها في Microservices في شكل أحداث تم إنشاؤها
نموذج يحركه الحدث وتحليل البيانات
- في الماضي ، عند إجراء تحليل بيانات اللعبة ، تم البحث عنهم من خلال الجداول المشتركة.
- بعد استخدام النموذج القائم على الحدث ، يمكن تسجيل جميع سلوكيات المشغل التي نولي اهتمامًا بها كأحداث ، وتصميم سمات مختلفة لأحداث مختلفة ، وتحقيق تحليل بيانات قابلة للتطوير للغاية
هيكل دليل المشروع
- نظرًا لأن بنية الخدمات الصغيرة التي تنفذها GO-KIT ، فحاول أن تبقيها متسقة مع المثال الرسمي لـ GO-KIT في بنية الدليل قدر الإمكان.
- نظرًا لأن النموذج الذي يحركه المجال ، من الطبيعي تضمين دليل الحزمة الداخلية في الطبقة الخارجية عند تصميم بنية دليل المشروع بنية الدليل على مستوى المجال ، بدلاً من ذلك ، يتم وضع دليل الحزم من مستويات مختلفة تحت الدليل من نفس المستوى.
لا متغيرات عالمية
- من أجل توضيح البرنامج في منطق الكود ، تجنب بدقة المتغيرات العالمية
ذاكرة التخزين المؤقت للبيانات وتخزين البيانات والكافكا
- لذلك ، يتم تخزين بيانات المشغل مباشرة في ذاكرة الخدمة ، مما يسهل معالجة البيانات المباشرة
- تتم كتابة تعديل بيانات اللاعب إلى Kafka من خلال Wal ، ثم يتم كتابة خدمة التخزين بشكل غير متزامن إلى قاعدة البيانات.
- نظرًا لأن طريقة WAL يتم استخدامها ، فإن إعادة تنفيذ بيانات اللاعب والتراجع عنها سهلة التنفيذ
newsql cockroachdb
- يستخدم ثبات البيانات CockroachDB ، وهي قاعدة بيانات علائقية تدعم المعاملات الموزعة
- يمكن أن يؤدي استخدام الصراصير إلى تحقيق التحجيم الأفقي بسهولة ، وتحمل الأعطال ، والاسترداد التلقائي ، وموازنة التحميل
لقد بدأت في استخدام COALCTHDB من V1.0 ، من الإصدار 1.0 لم يكن كبير. نظرًا لأن جميع بيانات YivGame تقريبًا في الذاكرة ، ولا يلزم كتابة DB إلا عند حفظها ، لذلك لنظام Yivgame بأكمله ، لا يوجد عنق زجاجة أداء DB.
نموذج
رسم تخطيطي للاتصال
- طريقة الاتصال
- HTTP: HTTP هو اتصال قصير ، يستخدم بشكل أساسي في نظام تشغيل الخلفية.
- WebSocket: تم تطوير العميل باستخدام COCOS Creator ، ويدعم الاتصالات ذات الاتصال الطويل WebSocket.
- GRPC: استنادًا إلى بروتوكول HTTP/2 GRPC ، يمكن أن يدرك التواصل متعدد البث على اتصال المقبس.
- تنسيق البيانات
- JSON: نظرًا للتفسير الذاتي لتنسيق JSON ، يتم استخدامه بشكل أساسي لتبادل البيانات بين الاتصالات القصيرة وواجهات نظام التشغيل الخلفية في اللعبة.
- Protobuf: يستخدم بشكل رئيسي لتبادل البيانات بين العميل والخادم WebSocket و Serro-Service
مخطط مكون الخدمة
- الوكيل: يتم استخدامه بشكل أساسي للوصول إلى عميل. ويسهل التوسع أفقيًا
- UserCenter: تتم إدارة جميع بيانات المشغل في مركز المستخدم ، ومركز المستخدم مسؤول عن القراءة والكتابة وحذف بيانات اللعبة والتحقق منها. .
- خادم اللعبة: مسؤول بشكل أساسي عن معالجة منطق أعمال الألعاب
مصادقة الهوية والمصادقة
- استخدم JWT للمصادقة بين الخدمات
- تسجيل الدخول من خلال بوابة API
- هل المصادقة على الصعيد العالمي ، والتفويض في كل خدمة microservice
تبعية المرافق
- Docker: يتم نشر جميع مرافق التبعية وحالات اللعبة من خلال نسخة مجتمع Docker
- Rockcoach: كقاعدة بيانات مستمرة
- كافكا: كقائمة انتظار للرسالة ودفق منصة
- إلخ: لاكتشاف الخدمة
- GOGS: استخدم GOGS لإدارة الإصدار
- BIND9: خادم اسم المجال ، التبديل السلس لشبكات التطوير والاختبار من خلال دقة اسم مجال التبديل
GO-KIT مولد
- YIV/GK: GO-KIT Code هو تدريبات كهربائية يدويًا. لكتابة واجهة الخدمة ، يجب أن تكتب مجموعة كاملة من نقطة النهاية. تشعر بأنك تقوم بعمل متكرر وذات أخطاء للغاية. لم يكن مثاليًا بعد ، ولم يكن الأمر قابلاً للتطبيق تمامًا بالنسبة لي ، لذا فإنني أتخلى عن ذلك وأغيرته بنفسي وتجاوزه تلقائيًا ، مما قد يقلل من الكود المكررة بنسبة 60 ٪ عند كتابة واجهات الخدمة. احتمال الأخطاء.
بيئة النظام
الرجوع إلى
- Gonet/2: امتصت Yivgame الكثير من التصميمات من Gonet ، مثل استخدام التيار لإرسال شفاف ، وإدخال Kafka ، إلخ.
- go-kit: تم تطوير yivgame بناءً على go-kit
- Goddd: تطبيق نموذج يعتمد على نموذج المجال المكتوب في Go
- الثبات العملي في GO: تنظيم الوصول إلى قاعدة البيانات
- الهندسة المعمارية النظيفة
- تطبيق الهندسة المعمارية النظيفة للذهاب إلى التطبيقات
- منشور لفهم الهيكل الهرمي
بعض الأفكار حول التصميم
- سيتغير تعقيد النظام فقط. ميزة GO-KIT هي أنها لا تبدو بسيطة ، ويعكس بشكل مباشر أهداف التصميم في الكود.
- GO-KIT غير مناسب لتحقيق أهداف سهلة الاستخدام وسريعة وسريعة. يساعد على فصل المنطق.
- يبدأ GO-KIT بواجهة الخدمة ، ويبدأ بالتركيز على مجالات الأعمال ، HTTP أو GRPC هو مجرد وسيلة لنشرها إلى العالم الخارجي ، ويتم وضعها في النهاية.
- لا تعني حرية الكتابة ، لكن حرية التكيف ليس مجانيًا لأنه يحدد النتيجة هي أن الخدمات المكتوبة باستخدامها تبدو متشابهة. إنه لأمر رائع لدرجة أن الكود مكتوب مثل اللوحة ، ويمكن تجميعه وتشغيله.
- يرتب وتواصل مكالمات الخدمات المجهرية التي تم تقديمها حوالي 2 مللي ثانية ، وعادة ما يكون تأخير Ping المتبادل المحلي 40 مللي ثانية.
- سواء كان ذلك إطارًا أو لغة ، فهي مجرد أدوات إذا كانت الأدوات هي الأفضل ، فستكون سيئة إذا لم يتم استخدامها بشكل جيد.
