yivgame
YIVGAMEは、Go-Kitに基づいてGO言語で書かれたマイクロサービスアーキテクチャサーバーソリューションです。ゲームサーバー（長い接続）に加えて、フロントエンドおよびバックエンド操作のAPIインターフェイスサーバーも含まれます。 サーバー自体に加えて、Docker展開の詳細な構成も関与します。
特性
- マイクロサービスアーキテクチャ
- クライアントとゲームサーバーは、GRPCの双方向ストリーミングを介して伝達性を認識しています
- クライアントサーバーサイドWebSocket通信
- HTTPエンドポイントとWebSocketエンドポイントの重みとログを実装します
デザインの練習
マイクロサービスアーキテクチャ
- マイクロサービスアーキテクチャを通じて、従来のゲームサーバーは異なるマイクロサービスに分割されます
- さまざまなマイクロサーバーがGRPCを介して同期してカフカを介して非同期に通信できます
ドメイン駆動型モデル
- さまざまなレベルのソフトウェアのデカップリングを実現するために、各サービスはドメイン駆動型モデルに従って設計されています。
- マイクロサービスのソフトウェア構造を内側から外側、ゲームビジネスレイヤー、ユースケースレイヤー、インターフェイスレイヤー、施設の依存レイヤーに分割します
- さまざまなレベルの間で、外側から内側への一方向の依存を厳密に順守する
ビジネスレイヤーは主にゲームまたはサーバーのコアロジックを実装し、外部の実装を気にせず、ファイルシステム、データベースなどに依存します。ビジネスレイヤーはインターフェイスを使用してインターフェイスを定義し、依存関係レイヤーによるインターフェイスメソッドを実装し、パス依存関係の注入を通じて主に。したがって、いくつかの基本的な標準ライブラリを引用することを除いて、ビジネスレイヤーはサードパーティのパッケージをほとんど指しません。
Kafkaを使用したイベント駆動型モデル
- マイクロサービスシステム全体のコア通信方法は、KAFKAをストリーミングプラットフォームとして使用したGRPC同期コールと非同期イベント通信です。
- マイクロサービスに従っているすべてのアクティビティは、さまざまな懸念を持つイベントの形で発行されます
イベント駆動型モデルとデータ分析
- 過去には、ゲームデータ分析を行うとき、それらはジョイントテーブルを通して検索されました。
- イベント駆動型モデルを使用した後、私たちが注意を払うすべてのプレーヤーの動作は、イベントとして記録し、異なるイベントのさまざまな属性を設計し、非常にスケーラブルなデータ分析を実現することができます
プロジェクトディレクトリ構造
- Go-Kitによって実装されたマイクロサービスアーキテクチャは、ディレクトリ構造のGo-Kitの公式の例と可能な限り一致するようにしてください。
- ドメイン駆動型モデルはレイヤードであるため、プロジェクトディレクトリ構造を設計する際には、内側のパッケージディレクトリを外側のレイヤーに含めることが自然です代わりに、ドメインレベルでのディレクトリ構造は、同じレベルのディレクトリの下に配置されます。これは、より直感的でシンプルです。
グローバル変数はありません
- コードロジックでソフトウェアをより明確にするために、グローバル変数を厳密に回避する
データキャッシュ、データストレージ、Kafka
- したがって、プレーヤーデータはサービスメモリに直接保存され、直接データ処理が容易になります
- プレーヤーデータの変更はWALを介してKafkaに書き込まれ、その後、ストレージサービスはデータベースに非同期に書き込まれます。
- WALメソッドが使用されるため、プレーヤーデータのやり直しと元に戻すことは簡単です
NewsQL Cockroachdb
- データの永続性は、分散トランザクションをサポートするリレーショナルデータベースであるCockroachDBを使用します
- CockroachdBを使用すると、水平スケーリング、フォールトトレランス、自動回復、負荷分散を簡単に実現できます
V1.0からV1.0からV1.0.6からCockroachdBを使用し始めました。CockroachDBは、特定の状況と圧力の下で常にクラッシュの問題を抱えていましたが、クラッシュの問題は再び現れませんでした。改善していません。 YIVGAMEのほとんどすべてのデータはメモリにあり、保存時にDBのみを記述する必要があるため、YIVGAMEシステム全体でDBパフォーマンスボトルネックはありません。
モデル
通信図
- 通信方法
- HTTP：HTTPは、主にバックグラウンド操作システムでの通信に使用される短い接続です。
- WebSockent：クライアントはCOCOS Creatorを使用して開発され、WebSocketは主にゲームでのリアルタイムと強力なインタラクションとの困難な通信に使用されます。
- GRPC：HTTP/2プロトコルGRPCに基づいて、GOマイクロサービスエコシステムでは比較的一般的な通信方法であることがわかります。
- データ形式
- JSON：JSON形式の自己解釈により、主にゲーム内の短い接続とバックエンド操作システムインターフェイス間のデータ交換に使用されます。
- Protobuf：主にクライアントとサーバーのWebsocketとマイクロサービス間のデータ交換に使用されます
サービスコンポーネント図
- エージェント：主にデータパケットを直接送信し、バックエンドマイクロサービスに転送します。水平に簡単に拡張できます
- ユーザーセンターはユーザーセンターで管理されており、ユーザーセンターは、Apigate、ゲームサーバー、および使用する他のマイクロサービスのGRPCインターフェイスを読み取り、削除、変更、およびチェックする責任があります。 。
- ゲームサーバー：主にゲームビジネスロジックの処理を担当します
ID認証と認証
- JWTを使用して、サービス間を認証します
- APIゲートウェイを介したシングルサインイン
- グローバルに認証を行い、すべてのマイクロサービスで承認を行います
施設の依存
- Docker：すべての依存関係機能とゲームインスタンスは、Dockerコミュニティバージョンを通じて展開されます
- Rockcoach：永続的なデータベースとして
- Kafka：メッセージキューとストリームプラットフォームとして
- など：サービスの発見のため
- GOGS：バージョン管理にはGOGSを使用します
- BIND9：ドメイン名サーバー、ドメイン名解像度の切り替えによる開発およびテストネットワークのシームレスな切り替え
ゴーキットジェネレーター
- YIV/GK：Go-Kitコードジェネレーターは、現在、Go-Kitが発見した唯一の動揺です。サービスインターフェースを書くには、すべての人がエンドポイント、セット、およびコードのパターンを記述する必要があります。あなたは繰り返しの仕事をしていると感じています。何度か検索した後、私はGo-Kitの公式の例を完全に一致させませんでしたまだ完璧ではなく、完全に適用できなかったので、私はそれをフォークダウンして自分で変更し、自動的にコードを生成しましたエラーの確率。
システム環境
参照してください
- Gonet/2：Yivgameは、透明な伝送にストリームを使用する、Kafkaの導入など、Gonetから多くのデザインを吸収しました。
- Go-Kit：YivgameはGo-Kitに基づいて開発されています
- GODDD：GOで書かれたドメインモデルに基づくサンプルアプリ
- GOの実用的な持続性：データベースアクセスの整理
- きれいなアーキテクチャ
- クリーンアーキテクチャを適用してアプリケーションに移動します
- 階層構造を理解するための投稿
デザインに関するいくつかの考え
- システムの複雑さは、簡単なシンプルさの背後には消えません。 Go-Kitの利点は、それほど単純に見えず、Go-Kitの設計目標を直接反映しています。
- Go-Kitは、使いやすく、フラットで高速な目標を追求するのに適していません。論理的なデカップリングに役立ちます。
- Go-Kitはサービスインターフェイスから始まり、ビジネスエリアに焦点を当てることから始まり、HTTPまたはGRPCは外の世界に公開する方法にすぎず、最終的に配置されます。
- 執筆の自由を追求しないでください結果を定義しているため、無料ではありません。コードは絵画のように書かれているので、コンパイルして実行することができますが、エンジニアリングには適していません。
- 導入されたマイクロサービスコールのコーデックと通信は約2ミリ秒で、通常、国内の相互ping遅延は40msです。
- それがフレームワークであろうと、彼らは単なるツールですツールが最高の場合、それらがうまく使用されない場合、それらは彼らのデザインの本質を学び、マスターすることです。
