ยิว
Yivgame เป็นโซลูชันเซิร์ฟเวอร์เกม Microservice Architecture ที่เขียนขึ้นในภาษา GO ตาม Go-Kit นอกเหนือจาก Game Server (การเชื่อมต่อที่ยาวนาน) ยังมีเซิร์ฟเวอร์อินเตอร์เฟส API สำหรับการดำเนินการด้านหน้าและแบ็คเอนด์ นอกเหนือจากเซิร์ฟเวอร์เองการกำหนดค่าโดยละเอียดของการปรับใช้ Docker จะมีส่วนร่วมเช่นกัน
มีลักษณะเฉพาะ
- สถาปัตยกรรม Microservice
- ไคลเอนต์และเซิร์ฟเวอร์เกมตระหนักถึงการส่งผ่านผ่านการสตรีมสองทิศทาง GRPC
- การสื่อสาร WebSocket ฝั่งไคลเอ็นต์
- ใช้จุดสิ้นสุดของ HTTP และจุดสิ้นสุดของ WebSocket และบันทึก
การออกแบบ
สถาปัตยกรรม Microservice
- ผ่านสถาปัตยกรรม Microservice เซิร์ฟเวอร์เกมแบบดั้งเดิมจะถูกแบ่งออกเป็น microservices ที่แตกต่างกัน
- เซิร์ฟเวอร์ขนาดเล็กที่แตกต่างกันสามารถสื่อสารแบบซิงโครนัสผ่าน GRPC และแบบอะซิงโครนัสผ่าน Kafka
โมเดลโดเมน
- เพื่อให้บรรลุการแยกซอฟต์แวร์ระดับต่าง ๆ ให้บริการแต่ละบริการได้รับการออกแบบตามโมเดลที่ขับเคลื่อนด้วยโดเมน
- หารโครงสร้างซอฟต์แวร์ของไมโครเซิร์ตจากด้านในไปด้านนอกเป็นเลเยอร์ธุรกิจของเกมใช้เลเยอร์เคสเลเยอร์เลเยอร์อินเตอร์เฟสและเลเยอร์การพึ่งพาสิ่งอำนวยความสะดวก
- ปฏิบัติตามอย่างเคร่งครัดโดยการพึ่งพาทางเดียวจากภายนอกไปด้านในระหว่างระดับต่าง ๆ
เลเยอร์ธุรกิจส่วนใหญ่ใช้ตรรกะหลักของเกมหรือเซิร์ฟเวอร์ไม่สนใจเกี่ยวกับการใช้งานภายนอกและขึ้นอยู่กับระบบไฟล์ฐานข้อมูล ฯลฯ เลเยอร์ธุรกิจใช้อินเตอร์เฟสเพื่อกำหนดอินเทอร์เฟซใช้วิธีการอินเทอร์เฟซโดยเลเยอร์การพึ่งพาและผ่าน พวกเขาอยู่ในการฉีดพึ่งพาอาศัยกัน ดังนั้นยกเว้นการอ้างถึงไลบรารีมาตรฐานขั้นพื้นฐานบางชั้นธุรกิจแทบจะไม่อ้างถึงแพ็คเกจบุคคลที่สาม
โมเดลที่ขับเคลื่อนด้วยเหตุการณ์กับ Kafka
- วิธีการสื่อสารหลักระหว่างระบบ microservice ทั้งหมดคือการโทรแบบซิงโครนัส GRPC และการสื่อสารเหตุการณ์แบบอะซิงโครนัสโดยใช้ Kafka เป็นแพลตฟอร์มสตรีมมิ่ง
- กิจกรรมทั้งหมดที่ถูกติดตามใน Microservices จะถูกเผยแพร่ไปยัง Kafka ในรูปแบบของเหตุการณ์ที่เกิดขึ้น
รูปแบบที่ขับเคลื่อนด้วยเหตุการณ์และการวิเคราะห์ข้อมูล
- ในอดีตเมื่อทำการวิเคราะห์ข้อมูลเกมพวกเขาจะถูกค้นหาผ่านโต๊ะร่วม
- หลังจากใช้โมเดลที่ขับเคลื่อนด้วยเหตุการณ์พฤติกรรมของผู้เล่นทั้งหมดที่เราให้ความสนใจสามารถบันทึกได้เป็นเหตุการณ์การออกแบบคุณลักษณะที่แตกต่างกันสำหรับเหตุการณ์ที่แตกต่างกันและบรรลุการวิเคราะห์ข้อมูลที่ปรับขนาดได้อย่างมาก
โครงสร้างไดเรกทอรีโครงการ
- เนื่องจากสถาปัตยกรรม Microservice ที่ดำเนินการโดย Go-Kit พยายามทำให้สอดคล้องกับตัวอย่างอย่างเป็นทางการของ Go-Kit ในโครงสร้างไดเรกทอรีให้มากที่สุด
- เนื่องจากแบบจำลองที่ขับเคลื่อนด้วยโดเมนเป็นเรื่องธรรมดาที่จะรวมไดเรกทอรีแพคเกจชั้นในในชั้นนอกเมื่อออกแบบโครงสร้างของโครงการโครงการ โครงสร้างไดเรกทอรีในระดับโดเมนแทนไดเรกทอรีของแพ็คเกจที่แตกต่างกันอยู่ภายใต้ไดเรกทอรีของระดับเดียวกัน
ไม่มีตัวแปรทั่วโลก
- เพื่อที่จะทำให้ซอฟต์แวร์ชัดเจนขึ้นใน Code Logic หลีกเลี่ยงตัวแปรทั่วโลกอย่างเคร่งครัด
แคชข้อมูลการจัดเก็บข้อมูลและ kafka
- ดังนั้นข้อมูลผู้เล่นจะถูกเก็บไว้โดยตรงในหน่วยความจำบริการซึ่งอำนวยความสะดวกในการประมวลผลข้อมูลโดยตรง
- การปรับเปลี่ยนข้อมูลผู้เล่นถูกเขียนไปยัง Kafka ผ่าน Wal จากนั้นบริการจัดเก็บข้อมูลจะถูกเขียนขึ้นไปยังฐานข้อมูลแบบอะซิงโครนัส
- เนื่องจากใช้วิธี WAL การทำซ้ำและการยกเลิกข้อมูลผู้เล่นจึงใช้งานง่าย
newsql cockroachdb
- การคงอยู่ของข้อมูลใช้ cockroachdb ฐานข้อมูลเชิงสัมพันธ์ที่รองรับธุรกรรมแบบกระจาย
- การใช้ CockroachDB สามารถบรรลุการปรับขนาดแนวนอนได้อย่างง่ายดายการทนต่อความผิดพลาดการกู้คืนอัตโนมัติและการปรับสมดุลโหลด
ฉันเริ่มใช้ CockroachDB จาก v1.0 จาก v1.0 ถึง v1.0.6, Cockroachdb มีปัญหาการชนภายใต้สถานการณ์และแรงกดดันเฉพาะ ไม่ได้มีขนาดใหญ่ เนื่องจากข้อมูลเกือบทั้งหมดของ yivgame อยู่ในหน่วยความจำและต้องเขียนเฉพาะ DB เมื่อบันทึกดังนั้นสำหรับระบบ yivgame ทั้งหมดจึงไม่มีคอขวดประสิทธิภาพ DB
แบบอย่าง
แผนภาพการสื่อสาร
- วิธีการสื่อสาร
- HTTP: HTTP เป็นการเชื่อมต่อสั้น ๆ ส่วนใหญ่ใช้สำหรับการสื่อสารในระบบการทำงานพื้นหลัง
- WebSocket: ลูกค้าได้รับการพัฒนาโดยใช้ Cocos Creator และการสื่อสารที่เชื่อมต่อกันเป็นเวลานานรองรับ WebSocket
- GRPC: ตามโปรโตคอล HTTP/2 GRPC มันสามารถตระหนักถึงการสื่อสารหลายสตรีมบนการเชื่อมต่อซ็อกเก็ต
- รูปแบบข้อมูล
- JSON: เนื่องจากการตีความตัวเองของรูปแบบ JSON ส่วนใหญ่จะใช้สำหรับการแลกเปลี่ยนข้อมูลระหว่างการเชื่อมต่อสั้น ๆ และอินเทอร์เฟซระบบการทำงานแบ็กเอนด์ในเกม
- Protobuf: ส่วนใหญ่ใช้สำหรับการแลกเปลี่ยนข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์ WebSocket และ Micro-Service
ไดอะแกรมส่วนประกอบบริการ
- ตัวแทน: ส่วนใหญ่ใช้สำหรับการเข้าถึงลูกค้า และง่ายต่อการขยายในแนวนอน
- USERCENTER: ข้อมูลผู้เล่นทั้งหมดได้รับการจัดการในศูนย์ผู้ใช้และศูนย์ผู้ใช้มีหน้าที่รับผิดชอบในการอ่านการเขียนการลบการแก้ไขและตรวจสอบข้อมูลเกม .
- Game Server: ส่วนใหญ่รับผิดชอบในการประมวลผลตรรกะทางธุรกิจของเกม
การรับรองความถูกต้องและการรับรองความถูกต้อง
- ใช้ JWT เพื่อตรวจสอบความถูกต้องระหว่างบริการ
- การลงชื่อเข้าใช้ครั้งเดียวผ่าน API Gateway
- ทำการรับรองความถูกต้องทั่วโลกและการอนุญาตในทุก microservice
การพึ่งพาสิ่งอำนวยความสะดวก
- Docker: สิ่งอำนวยความสะดวกการพึ่งพาและอินสแตนซ์เกมทั้งหมดถูกปรับใช้ผ่านเวอร์ชันชุมชน Docker
- RockCoach: เป็นฐานข้อมูลถาวร
- Kafka: เป็นคิวข้อความและแพลตฟอร์มสตรีม
- ETCD: สำหรับการค้นพบบริการ
- GOGS: ใช้ GOGS สำหรับการจัดการเวอร์ชัน
- bind9: เซิร์ฟเวอร์ชื่อโดเมนการสลับการพัฒนาและการทดสอบเครือข่ายผ่านการสลับการสลับชื่อโดเมน
เครื่องกำเนิดไฟฟ้า go-kit
- Yiv/GK: Go-Kit Code Generator เป็นสว่านไฟฟ้ามือ ในการเขียนอินเทอร์เฟซบริการแต่ละคนต้องเขียนชุดปลายทางและการขนส่งที่สมบูรณ์ คุณรู้สึกว่าคุณกำลังทำงานซ้ำ ๆ และมีแนวโน้มที่จะเกิดข้อผิดพลาดมาก ยังไม่สมบูรณ์แบบและมันก็ไม่สามารถใช้ได้กับฉันอย่างสมบูรณ์ดังนั้นฉันจึงแยกมันลงและเปลี่ยนมันเองและส่งผ่านรหัสโดยอัตโนมัติซึ่งสามารถลดรหัสที่ซ้ำกันได้ 60% เมื่อเขียนอินเทอร์เฟซบริการที่สำคัญกว่านั้น ความน่าจะเป็นของข้อผิดพลาด
สภาพแวดล้อมระบบ
อ้างถึง
- Gonet/2: Yivgame ได้ดูดซับการออกแบบจำนวนมากจาก Gonet เช่นการใช้สตรีมสำหรับการส่งผ่านโปร่งใสแนะนำ Kafka ฯลฯ
- go-kit: yivgame ได้รับการพัฒนาตาม go-kit
- Goddd: แอพตัวอย่างที่ใช้โมเดลโดเมนที่เขียนใน GO
- การคงอยู่ในทางปฏิบัติใน GO: การจัดระเบียบการเข้าถึงฐานข้อมูล
- สถาปัตยกรรมที่สะอาด
- การใช้สถาปัตยกรรมที่สะอาดเพื่อไปแอปพลิเคชัน
- โพสต์เพื่อทำความเข้าใจโครงสร้างลำดับชั้น
ความคิดบางอย่างเกี่ยวกับการออกแบบ
- ความซับซ้อนของระบบจะเปลี่ยนไปและจะไม่หายไป . ข้อได้เปรียบของ Go-Kit คือมันไม่ได้ดูง่ายและสะท้อนให้เห็นถึงเป้าหมายการออกแบบโดยตรงในรหัส
- Go-Kit ไม่เหมาะสำหรับการใช้งานที่ง่ายต่อการใช้งานสั้นแบนและรวดเร็ว ช่วย decoupling เชิงตรรกะ
- Go-Kit เริ่มต้นด้วยอินเทอร์เฟซบริการเริ่มต้นด้วยการมุ่งเน้นไปที่พื้นที่ธุรกิจ HTTP หรือ GRPC เป็นเพียงวิธีการเผยแพร่ไปยังโลกภายนอกและมันถูกวางไว้ในที่สุด
- อย่าใช้เสรีภาพในการเขียน แต่การปรับตัวให้เข้ากับซอฟต์แวร์เสรีภาพ ไม่ฟรีเพราะมันกำหนดผลลัพธ์คือบริการที่เขียนโดยใช้มันดูคล้ายกัน มันยอดเยี่ยมมากที่รหัสถูกเขียนเหมือนภาพวาดและสามารถรวบรวมและเรียกใช้ได้
- ตัวแปลงสัญญาณและการสื่อสารของการโทร microservice ที่แนะนำคือประมาณ 2 มิลลิวินาทีและการหน่วงเวลาร่วมกันในประเทศมักจะ 40ms
- ไม่ว่าจะเป็นเฟรมเวิร์กหรือภาษาพวกเขาเป็นเพียงเครื่องมือ หากเครื่องมือดีที่สุดพวกเขาจะไม่ดีหากพวกเขาไม่ได้ใช้งานได้ดี
