ステップバイステップのネットワーク プログラミング フレームワーク ioGame 17.1.46 に、圧力テストとシミュレーションのクライアント リクエスト モジュールが追加されました

メジャーアップデート

[ 160 ]軽量ウィジェット - 圧力テストおよびシミュレーション クライアント リクエスト モジュール

ドキュメント: https://www.yuque.com/iohao/game/tc83ud

 

導入

このモジュールはクライアントをシミュレートし、シミュレーションのワークロードを簡素化するために使用されます。対応するリクエストとコールバックを記述するだけで済みます。

このモジュールを使用した後、フロントエンドのクラスメートと共同で特定の関数をデバッグするときに、フロントエンドの仲間に「クリック、クリック、クリック」と指示する必要はありません。この「クリック＆クリック」通信と共同デバッグ方法は過去のものになるでしょう。

単純なリクエストのシミュレーションに加えて、通常は複雑なリクエストのオーケストレーションを実行し、複雑なサービスのプレッシャー テストをサポートできます。模擬テストのプロセスは対話型ですが、テストの自動化もサポートしています。

単体テストとは異なり、このモジュールは実際のネットワーク環境をシミュレートでき、シミュレーション テスト中のサーバーとの対話は持続可能でインタラクティブです。

インタラクティブ モードは、特定の機能のデバッグとテストに使用されます。インタラクション プロセス中に、開発者はコンソールで特定のシミュレーション リクエスト コマンドを実行するように指定したり、コンソールでのいくつかの動的なリクエスト パラメータの入力をサポートしたりできるため、さまざまなビジネス ロジックの傾向を簡単にテストできます。

インタラクティブな部分については、その具体的な意味を知るために後続のドキュメントを読む必要があります。

 

特徴

• 使い方が簡単

• 圧力試験のサポート

• クライアントリクエストをシミュレートできる

• 実際のネットワーク環境をシミュレートできる

• 複雑なビジネスリクエストを調整可能

• 同じシミュレーション テスト ケースは、複数の接続モード (tcp、udp、websocket) での作業をサポートします。

• サーバーとの継続的な対話、シミュレーション テスト プロセスは対話型ですが、テストの自動化もサポートします

 

エントリーレベルのデモ

ドキュメントはたくさんありますが、実際に使用するのは比較的簡単です。

図1

図の左側は提供するアクション、図の右側は作成したシミュレートされたリクエストです。

図Ⅱ

コンソールは対話型部分であり、どのシミュレートされたクライアント要求が提供されているかを確認できます。

コンソールに [cmd-subCmd] と入力して、対応するリクエストをトリガーします。

図 3

リクエストがトリガーされた後、サーバーに応答データがあると、シミュレートされたリクエストに対応するコールバックに入ります。

 

まとめ

たとえば、プライベート チャット システム、チャット チャネル、フレンド システムなどの単純な機能を実行する必要がある場合、このシミュレーション クライアントが役に立ちます。

シミュレートされたクライアント モジュールは ClientUser (プレーヤー) オブジェクトも提供し、シミュレートされたクライアントは ClientUser に対応します。ClientUser はクライアントのユーザー (プレイヤー) オブジェクトであり、開発者は動的属性での通貨、戦闘力、血液バーなどの節約などの動的属性オプションを通じてビジネスを拡大できます。継承によって拡張することもできます。

その他のアップデート

ドキュメント生成が強化され、アクション パラメーターと戻り値のコメント説明が追加されました。

ioGame の使用傾向統計

ioGame に注目するゲームサーバー開発者の数は増加し続けています ( 2022 年 9 月から 2023 年 7 月までの 統計) 。

ここでの統計情報は、ioGame フレームワークに注目している開発者に関する統計情報であり、ioGame が使いやすさや強力な機能などの利点により、多くの開発者の注目を集めていることがわかります。誰かが ioGame を使用しているかどうか知りたい場合は、ここにアクセスして統計、開発者のレビュー、ディスカッションを読むことができます。

https://www.yuque.com/iohao/game/gpxk93#TwVa8

ここには毎月の統計データが表示されます。統計データは Yuque のバックグラウンドから取得されており、これらのデータは現実的で客観的でライブです。

コストの関係で、Mobao Mooduo にはこの種のサービスを提供できる販売業者が存在しないため、このような統計の方が信頼性が高くなります。

統計を通じて、多くの開発者が毎日 ioGame のオンライン ドキュメントにアクセスしていることがわかります。これらの統計は Kouhe から得られたものではなく、主観的に作成されたものでもありません。

したがって、ioGame を使用するかどうかまだ迷っている開発者は、誰かが ioGame を使用しているかどうかではなく、「なぜこれらの開発者が ioGame を使用することを選択するのか」について議論する必要があります。

クリックすると Yuque のバックグラウンドで ioGame のデータが表示されます

メイブンアシスタント

ioGame は中央ウェアハウスにアップロードされました。最新のフレームワーク ソース コードをダウンロードできない場合は、開発者の Maven ウェアハウス プロキシでネイティブまたは Tencent クラウド プロキシを使用することをお勧めします。Alibaba Cloud のプロキシは現在推奨されていません。Tencent Cloudのプロキシ設定については、 こちら を参照してください。

ioGame の最新バージョンは https://www.yuque.com/iohao/game/ab15oeで確認してください。

ioGame は軽量のオンライン ゲーム サーバー フレームワークです。ioGame にはミドルウェアへの強い依存関係がありません。つまり、他のミドルウェア製品をインストールする必要はありません。現時点では、フレームワーク全体を取得するために必要な依存関係は 1 つだけです。すべての機能特性をサポートする時間。

<dependency>
    <groupId>com.iohao.game</groupId>
    <artifactId>run-one-netty</artifactId>
    <version>${ioGame.version}</version>
</dependency>

---

全体フレームプレビューマップ

 

---

ioGame ネットワーク ゲーム サーバー フレームワークの概要

• ロックフリーの非同期、イベント駆動型のアーキテクチャ設計、軽量、クラスタリングをサポートするサードパーティのミドルウェアやデータベースに依存しない、分散型
• ioGame を使用すると、クラスター内に中央ノードを持たず、クラスター自動化、マルチプロセスを備えた段階的なゲーム サーバーを簡単に構築できます。
• 小型パッケージ、高速起動、少ないメモリ使用量、より経済的、構成ファイル不要、エレガントなルーティング アクセス制御を提供
• 開発者は一連のビジネス コードを変更せずに使用でき、WebSocket、TCP、UDP などの複数の接続方法をサポートできます。
• 開発者は一連のビジネス コードを使用して、さまざまな通信プロトコル (Protobuf、JSON) を簡単に切り替え、拡張できます。
• ネイティブに近いパフォーマンス。ビジネス フレームワークは、単一スレッドで 1 秒あたり平均 1,152 万回のビジネス ロジックを実行できます。
• コードは共同デバッグ ドキュメント、JSR380 検証、アサーション + 例外メカニズム = メンテナンス コストの削減
• このフレームワークには同じプロセスとのインテリジェントな親和性があり、開発中にビジネス コードを見つけてジャンプすることができます。
• アーキテクチャ導入の柔軟性と多様性: 独立型と統合型の両方
• 同じ種類の複数のゲームロジックサーバーと同時に通信してデータを取得できます
• ロジック サーバーはプロセスやマシンを越えて相互に通信できます。
• プレイヤーがゲーム ロジック サーバーを動的にバインドできるようにサポートします。
• 他のフレームワークとの互換性
• WebMVC開発者に優しい
• スプリングの強い依存性はありません
• 学習コストゼロ

 

高性能、安定性、使いやすさ、組み込みの負荷分散、クラス爆発の回避設計、プロセス間クロスマシン通信、中央ノードのないクラスター、クラスター自動化、およびステートフルマルチプロセスサーバーについてはどうですか? もしそうなら、ここでは Java 言語で書かれたオンライン ゲーム サーバー フレームワーク ioGame をお勧めします。以下では、このフレームワークをさまざまな側面から簡単に紹介します。

ioGame は、次の機能を備えた Java オンライン ゲーム サーバー フレームワークです。

• ロックフリーの非同期、イベント駆動型のアーキテクチャ設計
• Webソケットとソケットの2つの通信プロトコルをサポート
• protobuf や json などのさまざまな通信プロトコルをサポート
• 中央ノードのないクラスター、クラスター自動化、分散設計
• 非常に軽量で、サードパーティのミドルウェアやデータベースに依存せずにクラスターと分散をサポートできます。
• 複数の通信方法を提供し、論理サーバーはマシンを越えて相互に通信できます。
• Spring や他のフレームワークとの簡単な統合
• 低い学習コストと優れた開発経験
• マルチサーバー単一プロセス、マルチサーバー、およびマルチプロセスの起動および展開方法をサポート
• ゲームドキュメント生成のためのアクセシビリティ機能を提供します
• パッケージサイズが小さく、起動が速く、メモリ使用量が少ない
• エレガントなルーティング アクセス制御を提供する
• 柔軟なスレッド拡張と設定を提供します
• スマートな同一プロセス アフィニティ

ioGame は、オンライン ゲーム サーバー用に特別に設計された軽量のフレームワークで、独自のゲーム サーバーを迅速に構築して実行するのに役立ちます。H5、モバイル ゲーム、PC ゲーム、単純なチャット ルーム、複雑なグローバル サーバー、ターンベース ゲーム、戦略ゲーム、アイドル カジュアル ゲーム、リアル ゲームなど、あらゆるタイプとサイズのオンライン ゲームに適しています。タイムバトルやMMORPGなど、ioGameはあなたのニーズにお応えします。

ioGame は、パッケージング、メモリ使用量、起動速度の点でも優れています。jar パッケージが約 15MBになると、アプリケーションは通常 0.x 秒以内に起動し、メモリ使用量は小さくなります。詳細については、 最初からサーバーをすばやく作成する完全な例を参照してください。

エコロジー統合の観点から、ioGame は Spring (5 行のコード) と簡単に統合できます。Spring に加えて、 solon ... などの他のフレームワークとも統合できます。他のフレームワークの関連する生態学。 

軽量という点では、ioGame は サードパーティのミドルウェアやデータベースに依存せずにクラスタリングと分散をサポートでき、実行には Java 環境のみが必要です。これは使いやすいことを意味し、企業の導入コストや導入面でのメンテナンスの困難も軽減します。ioGame を使用する場合、Nginx、Redis、MQ、Mysql、ZooKeeper、Protobuf プロトコル コンパイル ツールなどの他のサービスをインストールすることなく、フレームワーク全体を取得するには依存関係が 1 つだけ必要です。

通信方式に関しては、ほとんどのフレームワークはプッシュ（ブロードキャスト）通信方式しかサポートできませんが、ioGameでは単一リクエスト処理、プッシュ、単一論理サーバー間の相互通信、複数の論理サーバー間での相互通信の5種類の通信方式を提供しています。同じタイプであり、パルスで通信します。さまざまな通信方式を組み合わせて使用​​することで、これまで難しかった作業を簡単に完了することができ、これらの通信方式はクロスプロセスおよびクロスマシン通信をサポートします。

接続方法に関しては、ioGame を使用すると、開発者は変更を加えずに複数の接続方法をサポートしながら、一連のビジネス コードを使用できます。ioGame はすでに TCP、WebSocket、UDP 接続方法をサポートしており、これらの接続方法間の柔軟な切り替えもサポートしています。接続方法はスケーラブルで、拡張操作も非常に簡単です。つまり、後で KCP がサポートされる場合は、現在のプロジェクトで TCP、WebSocket、または UDP が使用されているかどうかに関係なく、KCP に切り替えることができます。 KCP 接続方法は既存の業務コードを変更する必要がありません。

通信プロトコルに関しては、ioGame を使用すると、開発者は一連のビジネス コードを使用して、Protobuf や JSON などのさまざまな通信プロトコルを簡単に切り替えたり拡張したりできます。ビジネス メソッドを変更せずに、わずか 1 行のコードで Protobuf から JSON に切り替えます。

クラスターに関しては、ioGame のブローカー (ゲーム ゲートウェイ) は中央ノードフリーの自動クラスター設計を採用しており、すべてのノードは同等かつ自律的であり、単一障害点はありません。クラスターは自動的に管理され、柔軟にスケールできます。ノードが参加または終了すると、サービスの可用性に影響を与えることなく、負荷分散とデータの一貫性を自動的に確保できます。

分散に関しては、ioGame のロジック サーバーは分散設計アイデアを採用しており、サーバーをゲーム外部サーバーとゲーム ロジック サーバーなどのさまざまなレベルに分割し、各層には明確な責任とインターフェイスがあります。これにより、コードの可読性と保守性が向上し、水平展開が容易になります。

学習コストの点では、ioGame の学習コストは非常に低く、学習コストはゼロと言えるため、ゲームプログラミングの経験がなくても、簡単に始めることができます。開発者は通常の Java メソッドや WebMVC 関連の知識を習得するだけで、フレームワークを使用してサービスを開発できます。このフレームワークは、開発者がコーディング習慣を変更する必要はありませんが、開発者のニーズに適応します。

同一プロセスとの親和性という点では、同一プロセス内では、異なるNettyインスタンス間の通信はネットワーク伝送を介さずメモリ経由で伝送されるため、データ伝送速度が非常に高速です。同一プロセス アフィニティとは、同じプロセス内のゲーム ロジック サーバーへのアクセスが優先されることを意味し、同じプロセス内にリクエストを処理できるゲーム ロジック サーバーがない場合、他のプロセスまたはマシンにゲーム ロジックを見つけに行きます。リクエストを処理できるサーバー; 簡単に言うと、フレームワークはリクエストの処理において非常にインテリジェントであり、同じプロセス内のロジック サーバーを優先して消費します。

開発経験の面では、ioGame は開発者の開発経験に細心の注意を払っており、フレームワークは JSR380 検証、アサーション + 例外メカニズム、ビジネス コードの位置付けなどの多くの豊富な機能を提供し、開発者のビジネス コードをより明確かつ簡潔にします。

ビジネスの同時実行性の観点から、このフレームワークは開発者にとって単一プレーヤーの同時実行問題を解決するだけでなく、同じ部屋またはビジネス内の複数のプレーヤーの同時実行問題に対する解決策も提供します。このフレームワークは、スレッドのスケーラビリティに対するフレンドリーなサポートを提供します。厳密なスレッド番号設定を提供できます。詳細については 、ioGame スレッド関連を参照してください。

分散開発の経験という観点から見ると、分散アプリケーションを開発するときは通常、複数のプロセスを開始する必要があります。これにより、デバッグとトラブルシューティングが非常に困難になり、開発者の効率が低下し、作業負荷が増加します。これは多くのフレームワークでは解決できない問題ですが、ioGame はそれを解決しました。ioGame はマルチサーバーの単一プロセス起動をサポートしているため、開発者は段階的なシステムの開発とデバッグが容易になります。

フロントエンドとのドッキングと共同デバッグに関して、ioGame はゲーム ファイルを生成するための補助機能を提供するため、コードはドッキング ファイルになります。簡単に言うと、ビジネスコードが記述されると、フレームワークが最新のドキュメントを自動的に生成します。ゲーム ドキュメントの世代が存在しない場合、ドッキング ドキュメントの作成と保守に時間を割く必要があり、チームの数が増えると、ドキュメントは乱雑になり、同期が失われ、最新ではなくなり、ドッキング ドキュメントを作成することを忘れてしまいます。アップデート等。

デプロイメントに関しては、ioGame はマルチサーバー、単一プロセスのデプロイメント、およびマルチサーバー、マルチプロセス、マルチマシンのデプロイメントをサポートしており、コードを変更することなく、デプロイメント方法を自由に切り替えることができます。日常生活では単一の思考に従って開発を行うことができ、本番ではマルチプロセスのデプロイメントを使用することを選択できます。

シミュレートされたクライアント テストに関しては、ioGame はプレッシャー テストとシミュレートされたクライアント リクエストモジュールを提供します。このモジュールはクライアントをシミュレートし、シミュレーションのワークロードを簡素化するために使用されます。対応するリクエストとコールバックを記述するだけで済みます。単純なリクエストのシミュレーションに加えて、通常は複雑なリクエストのオーケストレーションを実行し、複雑なサービスのプレッシャー テストをサポートできます。模擬テストのプロセスは対話型ですが、テストの自動化もサポートしています。単体テストとは異なり、このモジュールは実際のネットワーク環境をシミュレートでき、シミュレーション テスト中のサーバーとの対話は持続可能でインタラクティブです。

アーキテクチャの柔軟性の観点から、ioGame のアーキテクチャは 1. ゲーム外部サーバー、2. ブローカー (ゲーム ゲートウェイ)、3. ゲーム ロジック サーバーの 3 つの部分で構成されており、これら 3 つは相互に独立させることも、相互に統合することもできます。したがって、ioGame を使用すると、ほぼすべての展開方法に対応でき、ニーズに応じてさまざまな種類のゲームに適応でき、これらのタスクを ioGame で簡単に実行できます。

ioGame に基づいて開発者によって作成されたプロジェクト モジュールは、通常、ルーティング用のフレームワークの合理的な設計のおかげでよく整理されており、ルーティング用のエレガントなアクセス制御も提供します。これらのモジュールを整理すると、他の開発者がプロ​​ジェクトを引き継いだり、フォローアップ メンテナンス (モジュールの整理や提案)をする際に役立ちます。この段階ではこの作品のパワーを感じられないかもしれませんが、深く使っていくと、このデザインの多くの利点と利点に気づくでしょう。

ioGame に基づいて開発者によって作成されたプロジェクトは、通常、簡潔な構文、高パフォーマンス、低遅延を備えています。プロジェクトが ZGC によってもたらされる改善と構文の単純さを享受できるように、フレームワークには少なくとも JDK17 が必要です。JDK17 以降、ZGC は、ゲームの速度に影響を与えることなく余分なメモリをクリーンアップできるミリ秒未満の一時停止時間という目標をはるかに下回っています。これにより、プロジェクト内に JVM チューニング マスターを偽装して導入するのと同じような、遅延やクラッシュの問題が発生することはなくなります。詳細については、「 JDK 17 ガベージ コレクション GC パフォーマンスの飛躍的な向上」を参照してください。

要約すると、ioGame はオンライン ゲーム開発に非常に適したフレームワークです。これにより、高性能、低遅延、簡単にスケーラブルなゲーム サーバーを簡単に作成でき、時間とリソースを節約できます。素晴らしいオンライン ゲームをすぐに開発したい場合は、今すぐ ioGame を選択してください。このフレームワークは、多くの複雑で反復的な作業を保護し、プロジェクト内の機能モジュール構造と開発プロセスを明確に整理して定義できるため、その後のプロジェクトの保守コストを削減できます。

このフレームワークは、開発、展開、ストレス テスト、シミュレーション テストなどのすべての段階で優れたサポートを提供します。ioGame についてはすでに予備的な理解ができていると思いますが、まだ紹介しきれていない豊富な機能や機能がたくさんありますが、その後の演習を通じてさらに理解を深めることができます。読んでいただきありがとうございます。ioGame を使用して独自のゲーム サーバーを構築できることを楽しみにしています。

---

ioGameは 「ネットワークコミュニケーションフレームワーク」と「ビジネスフレームワーク」で構成されています。

• ネットワーク通信フレームワーク:サーバー間のネットワーク通信を担当します
• ビジネス フレームワーク:責任とは、ビジネス ロジックがどのように処理され、記述されるかです。

ネットワーク通信フレームワーク 

SOFABolt は、  Ant Financial Services Group によって開発された Netty に基づくネットワーク通信フレームワークのセットです。

• Java プログラマーが、ネットワークの基盤となる NIO の実装にあまり複雑に絡み合ったり、デバッグが難しいネットワークの問題に対処したりするのではなく、ネットワーク通信に基づくビジネス ロジックの実装に集中できるようにするために、Netty が登場しました。 。
• ミドルウェア開発者が通信フレームワークの車輪を繰り返し製造するのではなく、製品の機能と特徴の実現にもっと集中できるようにするために、SOFABolt が誕生しました。

ボルトの名前は、ディズニーのアニメーション「ライトニング ドッグ」から取られており、Netty のベスト プラクティスに基づいた、軽量で使いやすく、高性能で、拡張しやすい通信フレームワークです。

ビジネスフレームワーク

 ソファ ボルトを使用すると、 Java プログラマはネットワーク通信に基づくビジネス ロジックの実装により集中できるよう。ビジネス フレームワークは、ビジネス ロジックをどのように便利に実装するかという問題を解決するものです。ビジネス フレームワークはゲーム フレームワークの一部です。その役割は、プログラマーのビジネス ロジックの実装を簡素化することです。ビジネス フレームワークにより、プログラマーはゲーム ビジネスの作成をすぐに開始できるようになります。

ビジネスフレームワークは、 アクション（つまり業務の処理方法）ごとにasmとSingleton、Flyweight、Commandなどの設計パターンを組み合わせ、配列を通じてアクションを取得するというネイティブに近い方法です。 

ビジネス フレームワークは、単一スレッドで 1 秒あたり平均 1,152 万回のビジネス ロジックを実行できます。

---

アーキテクチャ図

ioGame を通じて、クラスターレスのセントラル ノード、クラスターの自動化、段階的なオンライン ゲーム サーバーを簡単に構築できます。

ロックフリーの非同期およびイベント駆動型のアーキテクチャ設計、中央ノードのないクラスタ、組み込みの負荷分散、分散サポート、マシンの動的な増減、クラスの爆発を回避する設計。

図中の各ゲーム外部サーバー、各ゲームロジックサーバー、各ブローカー（ゲームゲートウェイ）は別プロセスに配置することができ、ロジックサーバー同士はプロセスを越えて通信することができます（ゲーム外部サーバーもロジックサーバーの一種です）。

ゲームゲートウェイクラスター

ブローカー (ゲーム ゲートウェイ) はクラスターのデプロイメントをサポートします。クラスターの使用は簡単です。クラスターにはセントラル ノードがなく、クラスターの自動化、および独自のロード バランシングがありません。ioGame 自体にはサービス登録が含まれており、Eureka や ZooKeeper などの外部サービス登録センターに接続する必要はありません (サーバー コストを隠れて節約します)。

ブローカー (ゲーム ゲートウェイ) の介入により、サービス登録、ヘルス チェック (次のバージョンで利用可能)、サーバーへの接続維持など、以前の非常に複雑な負荷分散設計が ioGame では不要になりました。構造は単純なものが多いです。実際、ゲーム ゲートウェイは転送のみを実行するため、単一のブローカー (ゲーム ゲートウェイ) のパフォーマンスはすでに十分です。

ロジックサーバー

ロジック サーバーは通常、ゲーム外部サーバーとゲーム ロジック サーバーを指します。論理サーバーは多数存在でき、論理サーバー拡張数の理論上の上限は netty の接続上限となります。

 

ゲーム海外サーバー

外部サーバーはユーザー（プレイヤー）との接続を長時間維持します。まず仮説を立ててみましょう。ハードウェアの 1 つがユーザー接続の制限を 5,000 人に設定できる場合、ユーザー数が 7,000 人に達したときに、転用と解凍のために外部サーバーを追加できます。ゲームの外部サーバーの拡張が簡単なため、同時オンライン プレーヤーの数は簡単に数百万、数千万、さらにはそれ以上に達する可能性があります。

ゲームの複数の外部サーバーを起動した場合でも、開発者はこれらのプレイヤーがどのゲーム外部サーバーに接続しているかを気にする必要はありません。フレームワークがすでにこれらのことを行っているため、これらのプレイヤーは常にブロードキャスト (プッシュ) メッセージを受信できます。プレイヤーの観点からは、サーバーは「1 つ」しかありませんが、同様に、開発者の観点からは、ゲーム外部サーバーは「1 つ」しかありません。

構造的な組み合わせ（展開の多様性）に関して

デプロイメントに関しては、マルチサーバーおよび単一プロセスのデプロイメント (単一のアプリケーションと同様であり、段階的な開発ではデバッグがより便利です) をサポートし、また、マルチサーバー、マルチプロセス、およびマルチプロセスもサポートします。マシンの展開。

アーキテクチャは、1. ゲーム外部サーバー、2. ブローカー (ゲーム ゲートウェイ)、3. ゲーム ロジック サーバーの 3 つの部分で構成されます。これら 3 つは、次のように相互に独立させることも、相互に統合することもできます。

• ゲーム サーバー、ブローカー (ゲーム ゲートウェイ)、ゲーム ロジック サーバーの 3 つの部分が 1 つのプロセス内にあります。[単一のアプリケーション;段階的に開発する場合はデバッグがより便利です]
• ゲーム サーバー、ブローカー (ゲーム ゲートウェイ)、ゲーム ロジック サーバーの 3 つの部分は複数のプロセスにあり、[分散]
• ゲーム サーバーとブローカー (ゲーム ゲートウェイ) の 2 つの部分は 1 つのプロセス内にありますが、ゲーム ロジック サーバーは複数のプロセス内にあります。[以前のゲームの従来のアーキテクチャと同様]
• ゲームの外部サーバーを必要とせず、ブローカー (ゲーム ゲートウェイ) とゲーム ロジック サーバーの 2 つの部分のみを他のシステム サービスに使用することも可能です。

ioGame はオブジェクト指向の設計原則 (単一責任の原則、オープニングとクローズの原則、文学置換の原則、依存性逆転の原則、インターフェイス分離の原則、ディミッターの法則) に従っているため、アーキテクチャの責任は明確に定義されており、組み合わせることができます。柔軟に。

ゲーム外部サーバーは、アーキテクチャの 3 つの部分のうちの 1 つであり、デフォルトのゲーム外部サーバーは netty に基づいて実装されます。必要に応じて、将来的には minaやSmart -socketなどの通信フレームワークを使用して、ゲームの外部サーバー の追加実装を提供することも できます。ゲームは外部サーバーに対する単一責任の原則を満たしており、ユーザー (プレイヤー) の長期接続のみを維持するため、既存のゲーム ロジックはビジネス ロジックとして機能します。 

ほとんどすべての開発者がこのような状況に遭遇したことがあります。プロジェクトの初期段階では通常、単一のプロジェクトの形で開発されますが、需要が増加し反復されるにつれて、肥大化したプロジェクトに発展します。分割を実行します。難しくてコストがかかります。完了不可能な場合でも、完全なリファクタリングが行われます。

ioGame は構造的な組み合わせに関してさまざまなデプロイメントを提供しており、組み合わせることにより、プロジェクトの初期段階でこれらの分割問題を回避できます。開発段階では、モノリシックなアプリケーション開発の考え方を使用できるため、開発コストが削減されます。単一アプリケーションの開発方法により、段階的なプロジェクトを開発する際のデバッグがより便利になり、段階的な開発やプロジェクト モジュールの分割を考慮できるだけでなく、チームの開発コストも削減できます。

アーキテクチャの利点

このアーキテクチャは高度に抽象化されているため、設計者は基礎となる実装や通信パラメータなどの問題を考慮する必要がなく、ビジネスに集中できるようになります。

論理サーバーの位置の透過性と同時に、モジュール化と抽象化により、アーキテクチャ全体のサーバー間の結合が非常に低く、登録後すぐに論理サーバーを使用できるため、拡張性と保守性が大幅に向上します。動的拡張を簡単かつ効率的に行うことができます。論理サーバーはブローカー（ゲームゲートウェイ）に登録されているため、動的に論理サーバーの追加、削除、変更が可能であり、論理サーバー間の結合が小さいため、デバッグやテスト作業の制御も可能であり、論理サーバー間の接続も容易である。

より明確な構造は、ゲーム外部サーバーがクライアント アクセス (ユーザーとプレイヤーの接続) の維持を担当し、ゲーム ロジック サーバーがビジネス ロジックを担当し、ブローカー (ゲーム ゲートウェイ) がそれらの間のスケジューリングを担当するということです。分割アーキテクチャのリーズナブルなため、特にk8sを利用してこの3台のサーバーを自由に配置すると、水位の高いサーバーを増設でき、水位が過ぎたら水位を下げることができるので便利です。

---

ioGame を通じてゲームプログラミングを簡単に行うことができます。以下はビジネス例です。

プロトコルファイル定義

まず、ビジネス キャリアの説明として使用されるプロトコル ファイルをカスタマイズします。このプロトコルは、jprotobuf を使用して純粋な Java コードで記述されています。jprotobuf は、同じパフォーマンスを持つ google protobuf の簡略化された使用法です。

これは、DTO、POJO、ビジネス データ キャリアなどとして理解できます。その主な目的はビジネス データの送信です。

/** 请求 */
@ProtobufClass
@FieldDefaults(level = AccessLevel.PUBLIC)
public class HelloReq {
    String name;
}

アクション

ゲームサーバーのプログラミングでは、ゲームサーバーがビジネスデータを受信した後、ビジネスデータを処理します。このビジネス コードは、TCP、WebSocket、UDP を同時にサポートできます。

@ActionController(1)
public class DemoAction {
    @ActionMethod(0)
    public HelloReq here(HelloReq helloReq) {
        HelloReq newHelloReq = new HelloReq();
        newHelloReq.name = helloReq.name + ", I'm here ";
        return newHelloReq;
    }
}

メソッドは、ビジネス フレームワーク内の アクション(ビジネス アクション) を表します。

メソッド名のパラメータは、フロントエンドから渡されたビジネスデータを受け取るために使用され、メソッドが戻ったときに、データをゲームのフロントエンドで受け取ることができます。プログラマーは、ビジネス フレームワークの内部の詳細を気にする必要はありません。

上記の例からわかるように、これは通常の Java クラスと何ら変わりはなく、この設計方法によりクラスの爆発が回避されます。ゲーム ビジネス の作成のみを担当している場合、ビジネス フレームワークの学習はここで終了します。

ゲームプログラミングはとても簡単です!

 

Q :ゲームサーバーのプログラミングを始めてもいいですか?

はい、すでにゲームサーバーのプログラミングを開始できます。

 

アクセス例（コンソール）

 hereメソッド (通常はゲーム フロントエンドによって要求される) にアクセスすると、コンソールは次のように出力します。

┏━━━━━ Debug. [(DemoAction.java: 4 ).here] ━━━ [cmd: 1 - subCmd: 0 - cmdMerge: 65536 ] 
⁄ userId : 888 
_____ Parameters: helloReq : HelloRe q(name=Tower) Tom) 
_____ 応答: HelloRe q(name=Tam, I'm here ) 
_____ 時間: 0ミリ秒 (ビジネス メソッドにかかった合計時間) 
┗━━━━━ デバッグ [DemoAction.java] ━━━ [現在のスレッド: RequestMessage -8-1 ] _ _ _

 

コンソールの印刷手順

Debug. [(DemoAction.java:4).here]：
    表示执行业务的是 DemoAction 类下的 here 方法，4 表示业务方法所在的代码行数。
    在工具中点击控制台的 DemoAction.java:4 这条信息，就可以跳转到对应的代码中（快速导航到对应的代码），这是一个开发良好体验的开始！
userId :  
    当前发起请求的 用户 id。
参数 :  
    通常是游戏前端传入的值。
响应：
    通常是业务方法返回的值 ，业务框架会把这个返回值推送到游戏前端。
时间：
    执行业务方法总耗时，我们可根据业务方法总耗时的时长来优化业务。
路由信息：[cmd - subCmd]
    路由是唯一的访问地址。

上記の情報があれば、ゲーム開発者は問題をすぐに特定できます。視覚的な情報がないと、開発中のフロントエンドとバックエンド間の通信に多くの時間が無駄になってしまいます。質問には次のようなものがあります。

• パラメータを渡すかどうか (ゲームのフロントエンドが言った)
• 質問に応答するかどうか (ゲームのバックエンドは質問が返されたと報告します)
• ビジネス実行時間の問題 (ゲームのフロントエンドは応答を受け取っていないと言いますが、ゲームのバックエンドはずっと前に応答したと言っています)

その中で、コード ナビゲーションを使用すると、開発者はビジネス クラスの対応するコードにすばやくジャンプでき、複数人で協力するプロジェクトでは、どのメソッドがビジネスによって実行されたかをすぐに知ることができるため、迅速に読み取りや変更を行うことができます。 ;

組み込み関数

さまざまなオプションのモジュールが組み込まれており、アプリケーション開発を容易にするためにオンデマンドで選択できます。

• ドメイン イベント (軽量スタンドアロン最速 MQ --  disruptor ;ドメイン イベント モジュールを通じて、同様の Guava-EventBus、Spring イベント駆動モデル ApplicationEvent、ビジネス分離を実装し、同時実行を回避し、システムのメイン スレッドをブロックしないようにすることができます。 .. など、さまざまなウェーブ操作)
• タスクディレイラー （Quartzのようなタスクスケジューリングではなく、将来の特定の時間にタスクを実行、一時停止、キャンセルなどを行うことができます）
• マルチ環境スイッチング (異なる動作環境での構成のサポート)
• light-jprotobuf  (単一の .proto ソース ファイル内で複数のオブジェクトを生成できないという jprotobuf の要件を補い、ソース ファイルに対する jprotobuf のコメントを簡素化するため)
• ステップバイステップのロック (Redisson に基づく単純な実装)

その他の組み込み機能:

• 心拍関連
• ユーザーのオンラインとオフラインに関連するフック メソッド
• UserSessions  (全ユーザーのUserSessionの管理、オンラインユーザーの統計など)
• UserSession  (チャネルと1:1の関係で、対応するuserId、チャネル等の情報が取得可能)
• ログイン関連(繰り返しログイン、トップナンバーなどの関連機能強化を提供)
• ビジネスパラメータの基本タイプの自動ボックス化およびボックス化解除（プロトコルフラグメントの解決）

群衆のために？

1. 長年Web社内システム開発に携わっていて、ゲームについて知りたい
2. ゲーム開発の初心者
3. ゲーム開発に携わったことはないが、興味がある方
4. デザインパターンの実践とソファボルトの適用に興味のある学習者
5. 新しいものを受け入れる
6. 祖先のコードを放棄したい人

1年以上のプログラミング実務経験のある方を推奨

ioGame は、 チームを支援したり、友人を連れて行ったりできるよう、オンラインで高品質のドキュメントを豊富に提供しているため、手を取り合って教える必要はありません。