Dora-RPC 端午節アップグレード PHP マイクロサービス開発キット

Dora-RPC 端午節アップグレード、マスターもベータ版で多くの機能を追加しました。

いくつかの企業は、1 年以上プロジェクトラインでこれをスムーズに使用してきました。もちろん、彼らはこのプロトタイプに基づいていくつかの修正を加えました。最近のアップグレードでは、独自の機能が削除され、パフォーマンスが 2 倍になったほか、非同期タスクが修正されました。結果を取得するために追加されました。現在、groupclient の機能も 2 つのクライアントの代わりにクライアントに統合される予定です。

これまで詳しく紹介したことはありませんでしたが、現在の機能の一部を簡単に紹介します。

このオープンソースは、PHP のフロントエンドとバックエンドの分離のために Swoole 拡張機能を使用して再カプセル化されています。プロジェクトが巨大になる場合は、それを分離する必要があります。このようにして、複雑なシステムを API サービスを通じてシンプルかつ保守しやすくし、複雑なプロジェクトの評価や呼び出しを容易にしたいと考えています。プロジェクトグループがより明確になります。

フレームワークの考え方:

• 最も基本的なサーバーとクライアントのセットのみを提供しており、簡単な統合を通じてあらゆる開発フレームワークで使用できます。
• 返されるデータ構造は 3 つの層に分かれており、各層にはメッセージとコードが含まれます。第 1 層 (最下層) は現在のクライアントの通信状況を表し、第 2 層はクライアントの実行時に異常や配信状況が存在するかどうかを表します。サーバー上の現在の API と 3 番目の層 この層はコードの実行ステータスを表し、ビジネス コードで例外が発生した場合は、ここに自動的に記録されます。このメソッドは RPC 自体の複雑さのために使用され、このメソッドはシステムの実際のステータスを判断するために特別に提供されています。
• 非同期タスクの後続取得機能をサポートするために、開発パッケージの最下層がアップグレードされました。主な理由は、現在のクライアントの場合、サーバーが非同期タスクを処理した後に処理結果をクライアントに送信するためです。新しいタスクをサーバーに送信し、Recive を実行するときに、クライアントは以前は、返されたコンテンツがこのリクエストであるかどうかを判断できませんでした。同時に、長いリンクの特殊な性質により、最後のリクエストが異常に中断された場合、受信が実行されなかった場合、最後の結果がこのリクエストによって取得されました。上記問題を防ぐために、guid生成機能を特別に実装し、非同期タスクの結果収集と本リクエスト以外の戻りデータの特定をguidの判断で完了させます。
• ビジネス コードの特殊性により、何らかの特別な理由でビジネス コードが失敗しないことを保証することはできません。このため、ビジネス コードはタスク上ではなく実行されます。労働者の上司。このようにして、多くの特別な機能を実行できます。ただし、タスクの欠点は、多くのスウールの非同期機能がサポートされていないことです。
• サービスのグループ化、多くの場合、私たちは同じ世界にいるので、影響を受けます。さらに、異なるサービスが異なるサーバーにデプロイされるのが一般的であるため、サービスのグループ化機能が提供されています。特定のサーバーがどのグループに属しているかを指定し、接続作業のグループを通じて正しいサーバー構成を見つけることができます。

タスク配信モード:

配信されるタスクの数は次のように分類できます:

• 複数タスクの同時配信
• 単一タスク配信

タスクの配信と結果の待機には複数のモードがあります。

• タスクを投稿すると現在のプロセスがブロックされ、処理が完了して戻りデータを取得するのを待ちます
• 非同期タスクはタスクの処理結果を待ちません。配信成功のみを返しますが、戻りはありません。タスクがサーバーによって完了した後、非同期タスクはサーバー上でタスクが処理されるのを待ちません。サービスが完了すると、サーバーはすぐに配信成功を返します。処理結果をクライアントに送信します。クライアントは以前の非同期タスクの結果をすべて一律に取得し、関数を通じて現在のビジネス プロセスに返します。
上記の方法により、インターフェースの応答速度とサーバー使用率を飛躍的に向上させることができます。複雑なマルチスレッドを使用せずに目標を達成できます。

ネットワーク通信:

• クライアントは PHP-FPM および CLI で動作し、長いリンクを維持できます
• 各往復リクエストに必要なネットワーク時間は約 0.002 ～ 0.004 です (イントラネット ネットワークにも依存します)
• リンクは引き続き維持されます要求が処理された後も保持されます。シャットダウンしないことで、クライアントとサーバーのハンドシェイク時間が短縮され、ポートの消費が削減されます。
• データが大きい場合は、パッケージ圧縮 gzip がサポートされています。特別なニーズがある場合は、必要に応じて、シリアル化に使用される PHP の組み込みシリアライズを直接置き換えることができます。接続と結果の受信のデフォルトのタイムアウトは 3 秒で、const ファイルで設定されます。タイムアウトが発生した場合、クライアントは自動的に他の設定を使用して指定された回数だけ再試行し、エラーの原因を説明する json を返します。必要に応じて、再試行ロジック内に再試行監視を追加して、各サーバーの動作ステータスを監視できます。
• このリクエストで IP が一度失敗した場合、すべての設定が試行されたか、再試行回数を超えたことが判明した場合は、失敗が返されます。 cli が一度失敗した後、API が再度配信されると、以前のすべてのシールド設定がキャンセルされ、API が再試行されます。
• RPC シングルスレッド クライアントと仮想マシンでの以前のテスト QPS は 1 秒あたり約 200 ～ 500 の通信でしたが、各タスクは多くの QPS で配信でき、2,000 の単一アプリケーション サーバーに到達することができます
• 現在の通信アーキテクチャには、リバース プロキシ サービス。クライアントがリバース プロキシに接続するまでに一定の時間がかかるためです。また、リバース プロキシ サーバーは高性能ですが、分散サービスの場合は直接接続する方が便利です。
サービスの検出:

サーバーを増減する必要がある場合、通常のプロセスではクライアント構成を更新して新しいサーバーを追加しますが、この方法には依然として多くの欠点があり、特定のサーバーに障害が発生した場合は追加されません。短期的には、構成を手動で変更するか、サービス検出を通じて構成を削除する必要があります。制御ロジックは完璧なので、後でこのプロセスを完全に自動化できます。

このフレームワークは、すべてのサーバーの IP とポート、およびそれらが属するグループを記録するストレージとして Redis を使用して、サービス検出を実装する最も簡単な方法を提供します。

• アプリケーション サーバーを起動し、サービスによって検出された Redis リストを通知すると、サーバーは現在のサービスの IP、ポート、グループを登録のために複数の Redis に自動的に報告し、タイムアウト時間を定期的に更新します。個々のノードがタイムアウト期間後に再度報告しない場合、そのノードは自動的に削除されます。
• クライアントは、複数の Redis から最新の構成を定期的に取得し、ローカル構成ファイルの内容を更新します。
その後のサポート:

次のステップでは、分散ログ、設定の同期などをサポートします。

最後に、Dora-RPC は非常にオープンソースであり、その本来の目的は、Swoole コミュニティ ユーザーに優れたものを作成するためのリファレンスを提供することです。 RPC とマイクロサービス。

同時に、皆様がこのプロジェクトの開発に積極的に参加していただけることを願っております。有効な参加者は wiki に記録されます。

プロジェクトアドレス: https://github.com/xcl3721/Dora-RPC

最近の活動: http://www.huodongxing.com/event/5337738177600 SOA の実践経験を共有し、無料チケット