😷 ♨️ 🎯 PHPでのGoogleプロトコルバッファーの操作 🛩️ 👩🏽‍🚀 🍰

私が現在開発中のプロジェクトでは、アプリケーションの各部の間でデータを交換するために使用されるプロトコルを変更する必要がありました。現在、内部サービスレベルでは、シリアル化されたPHP配列をTCPソケット経由で転送することで交換が行われます。 PHPには両側にアプリケーションがあるため、問題はありません。データパケット形式も標準であるため、特別な問題はありません。処理の速度に満足していないことがよくありますが、言語とプラットフォームに強く結びついているという事実もあります。別のシステムとドッキングしたり、何かを書き直したりする必要がある場合は、困難が伴います。結局、母国語のみがシリアル化された形式を理解するため、パーサーを作成したくありません。最初の選択は正当化された以上のものでした-開発とデバッグの速度が優先されましたが、今ではアーキテクチャを高く異なる外観で見る時間と欲求がほとんどありません。

最も単純なデータが送信されると言わなければならない-文字列（さまざまな長さ、実際にはほとんどキロバイトまたは10、通常数百バイトはありません）、整数（Unixタイムスタンプを含む）、定数のセット、true / falseフラグのみある場合には、浮動小数点値が送信されます。基本的に、文字列、整数、浮動小数点数の3種類のデータになります。必要に応じて、列挙されたフォームに起因するコマンドコードフィールドを強調表示することもできます（コマンドの数は制限されていますが、もちろんシステムの成長に伴い増加します）。シリアル化された形式では、このようなパッケージは多くのスペースを占有し、ソケット上のデータはローカルマシン内で送信されますが、これはまだオプションではありません-最初はシステムはクラスターの複数のノードへの動的な拡張を許可する必要があります。

ちなみに、PHP配列の代わりにすぐにJSONを使用するように考えられます。これにより、他の言語のプロトコルを理解する問題が解決されます。しかし、私が理解しているように、文字列文字、特にUTFに変換されて\ u3490として表示されるキリル文字のエンコードには、落とし穴があります。これにより、送信されるデータ量が大幅に増加します。

そこで、私は（もう一度、えー）将来、さまざまなプラットフォーム間でやり取りできるアプリケーションサービス間のやり取りのためのさまざまな形式を探り始め、ネットワーク上で透過的に送信され、可能な限りコンパクトになりました。私はヘッセのプロトコルが本当に好きでした（テストでは、2番目の実装は非常に優れています）が、あまりにも閉じられており、ドキュメントがほとんどありません。だから基本的に私はFacebook / Apache ThriftとGoogle Protocol Bufferを見た。

Thriftは現在開いており、Apache Fundationに転送されていますが、その実装はかなり複雑でわかりにくく、最小限のドキュメントと例（不在は言うまでもありません）とともに、すぐに消えてしまいました。

しかし、Google Protocol Buffer（以降、略してPBと呼びます）は非常に快適で興味深いことがわかりました。しかし、私のタスクは開発者が提供するPythonやJavaではなく、PHPで彼と仕事をすることだったため、困難はすぐに始まりました。このトピックに関する資料はないので、誰かが同じことをしなければならない場合に備えて、自分の手順を説明することにしました。プロトコル自体については説明しません。プロジェクトのWebサイトに良い紹介があります（開発者ガイドなど）。

したがって、最初に喜ばれるのは、PBを使用するために追加のソフトウェアをインストールしたり、PHPの拡張機能をコンパイルしたりする必要がないことです。つまり、ホームマシンと共有ホスティングの両方で実験を行うことができます。これまでのところ、PHPで作業する唯一の手段はpb4phpプロジェクトです。これは開発の初期段階にあります（バージョン番号0.25で判断し、開発は1人で実行され、1年以上前に開始されますが、時々コミットが表示されますが、アクティビティはほとんどありません）。私たちはそれを使用しますが、私はあなたのニーズを真剣に評価することをお勧めします-フォーマットの基本的な機能と作成/読み取り/書き込み/シリアル化の操作があなたにとって十分であれば、すべてがうまくいき、より高度な操作はサポートされません。

たとえば、最も単純なオプションを想像してください。たとえば、ニュースを受信するサービスがあります。たとえば、RSSフィードからニュースを抽出し、購読者にニュースを送信するサーバーがあります。サービスの1つまたは両方がPHP上にある間に、両方のサービス間のデータ交換をプロトコルバッファーを介したデータ交換に減らしたいと考えています。何をどのように行うのですか？

最初に、メッセージ形式に同意する必要があります、それが最も簡単なオプションであるとしましょう：

message News { required int32 id = 1; optional string source = 2; optional string dsign = 3; optional string news_msg = 4; optional int32 n_timestamp = 5; } * This source code was highlighted with Source Code Highlighter .

message News { required int32 id = 1; optional string source = 2; optional string dsign = 3; optional string news_msg = 4; optional int32 n_timestamp = 5; } * This source code was highlighted with Source Code Highlighter .

message News { required int32 id = 1; optional string source = 2; optional string dsign = 3; optional string news_msg = 4; optional int32 n_timestamp = 5; } * This source code was highlighted with Source Code Highlighter .

message News { required int32 id = 1; optional string source = 2; optional string dsign = 3; optional string news_msg = 4; optional int32 n_timestamp = 5; } * This source code was highlighted with Source Code Highlighter .

message News { required int32 id = 1; optional string source = 2; optional string dsign = 3; optional string news_msg = 4; optional int32 n_timestamp = 5; } * This source code was highlighted with Source Code Highlighter .

message News { required int32 id = 1; optional string source = 2; optional string dsign = 3; optional string news_msg = 4; optional int32 n_timestamp = 5; } * This source code was highlighted with Source Code Highlighter .

message News { required int32 id = 1; optional string source = 2; optional string dsign = 3; optional string news_msg = 4; optional int32 n_timestamp = 5; } * This source code was highlighted with Source Code Highlighter .

message News { required int32 id = 1; optional string source = 2; optional string dsign = 3; optional string news_msg = 4; optional int32 n_timestamp = 5; } * This source code was highlighted with Source Code Highlighter .

message News { required int32 id = 1; optional string source = 2; optional string dsign = 3; optional string news_msg = 4; optional int32 n_timestamp = 5; } * This source code was highlighted with Source Code Highlighter .

基本タイプのみを使用して最も単純なメッセージを説明しました（列挙と定数はこれまでのところ使用していません）。各フィールドには、メッセージのエンコードに必要な数値タグが割り当てられています。メッセージが正しく認識されない唯一の必須フィールドは識別子です。残りのフィールドは存在しない場合があります。もちろん、実際の状況では、形式はより複雑であり、フィールドタイプの選択は簡単ではありませんが、ここではこれを省略します。プロトコルに関する資料の1つを読んで、フォーマットを頻繁に変更する場合はすべてのフィールドをオプションとして宣言することをお勧めします。最終バージョンでのみ区別できるため、例では必須フィールドが1つしかないという開発者の言葉に出会いました。パラメータがない場合、メッセージには含まれません。つまり、データパケットのサイズを節約できます。

指定されたファイルは、* .proto形式のプレーンテキストファイルとして保存されます。さらに、コンパイラー（さまざまなプラットフォーム用にここからダウンロードできます）を使用して、メッセージをバイナリー形式、実際には後で使用するためのテンプレートにコンパイルします。

標準コンパイラは、サポートされている言語（Java、C ++、Python）のメッセージ、オブジェクト、ユーティリティメソッドのラッパーをすぐに生成します。しかし、私たちはまだリストに載っていないPHPで作業しています。

pb4phpパッケージ（example / protoc.phpディレクトリにあります）には、PHPに対して（不器用で、正直に）同じことを行うスクリプトがあります-指定されたprotoファイルをロードし、メッセージを処理するためのPHPクラス構造を生成します（はい、 PHPコード）。このコンパイラは、メッセージのテキスト記述、つまり上記で作成した* .protoファイルを処理することに注意してください。

ただし、メッセージのラッパークラスを手動で生成することを好みました。特に、サンプルファイル自体にエラーが見つかりました。コンパイラは、文字列データ型へのポインタを誤って生成します。PBMessage:: WIRED_STRING定数はソースにありません。すべての例に存在しますが、PBMessage :: WIRED_LENGTH_DELIMITEDに置き換える必要があります。

ラッパークラスは、一般的なPBMessageクラスを継承し、メッセージの特定のフィールドの説明を追加して、フィールドのゲッター/セッターを設定します。コードから判断すると、それらは通常の連想配列として格納され、シリアル化中にのみバイナリ形式PBでエンコードされます。

このクラスは非常にシンプルで、pb_news_interface.phpファイルに保存されます。

クラス NewsはPBMessageを拡張します
{
var $ wired_type = PBMessage :: WIRED_LENGTH_DELIMITED;
パブリック関数 __construct（$ reader = null ）
{
親:: __コンストラクト（$リーダー）;
$ this- > fields [ "1" ] = "PBInt" ;
$ this-> values [ "1" ] = 0;
$ this- > fields [ "2" ] = "PBString" ;
$ this-> values [ "2" ] = '' ;
$ this- > fields [ "3" ] = "PBString" ;
$ this-> values [ "3" ] = '' ;
$ this- > fields [ "4" ] = "PBString" ;
$ this-> values [ "4" ] = '' ;
$ this- > fields [ "5" ] = "PBInt" ;
$ this-> values [ "5" ] = 0;
}
関数 ID（）
{
return $ this-> _ get_value（ '1' ）;
}
関数 set_id（$値）
{
return $ this-> _ set_value（ '1' 、$ value）;
}
関数ソース（）
{
return $ this-> _ get_value（ '2' ）;
}
関数 set_source（$値）
{
return $ this-> _ set_value（ '2' 、$ value）;
}
関数 dsign（）
{
return $ this-> _ get_value（ '3' ）;
}
関数 set_dsign（$値）
{
return $ this-> _ set_value（ '3' 、$ value）;
}
関数 news_msg（）
{
return $ this-> _ get_value（ '4' ）;
}
関数 set_news_msg（$値）
{
return $ this-> _ set_value（ '4' 、$ value）;
}
関数 n_timestamp（）
{
return $ this-> _ get_value（ '5' ）;
}
関数 set_n_timestamp（$値）
{
return $ this-> _ set_value（ '5' 、$ value）;
}
}
*このソースコードは、ソースコードハイライターで強調表示されました。

コンストラクターでは、データ型の定義済みの名前を使用してデータ形式を記述します。pb4phpは、それらをメインプロトコルデータ型のクラス-PBInt、PBBool（PBIntから継承）、PBSignedInt、PBEnum（列挙）、PBStringおよびPBBytesにマッピングします。すべてのプロトコルデータ型を組み込み言語データ型に直接マップできるわけではないため、このようなラッパーが必要です。たとえば、C ++のsint32 / int32は同じint32型にマップされます（ただし、一般にデータ型の問題は単純ではなく、マッピングテーブル文書から完全な答えを与えていません）。 pb4phpはいくつかの基本的なタイプのみを実装しているため、フォーマットを記述するために最も一般的なタイプを選択する必要があります。

ところで、ラッパーコード自体は最適とはほど遠いです。魔法の__get / __ setメソッドを使用して、よりシンプルで短いコードに置き換えることができます。明らかに、コードはPHPとOOP機能の古いバージョンとの互換性のために書かれたようです。

では、続けましょう。プログラムでプロトコルを使用するには、2つのユーティリティファイルを接続する必要があります。メッセージを処理するメインクラス（/message/pb_message.php）と、メッセージ用に生成されたラッパークラス（pb_news_interface.php）です。その後、通常のPHPクラスをさらに使用します。

//クラスのインスタンスを作成します：
$ new_news = new News（）;
//フィールドに入力します：
$ new_news-> set_id（1）; //識別子を1に設定します
$ new_news-> set_n_timestamp（time（））; //タイムスタンプを追加します
$ new_news-> set_news_msg（ 'Test News' ）; //メッセージ本文
//残りのフィールドには入力せず、デフォルト値で初期化されます
*このソースコードは、ソースコードハイライターで強調表示されました。

さらに作業を進めるには、たとえばネットワークを介してさらに送信するために、メッセージのシリアル化された値を取得する必要があります。これを行うには、メッセージを文字列（HEX）にエンコードする組み込みSerializeToStringメソッドがあります。

ちなみに、作成者は、オブジェクトをネットワーク経由で送信する組み込みメソッドも処理しました-Sendメソッドを呼び出してURLとメッセージのインスタンスを渡すだけで、cURLを介して、シリアル化されたPBメッセージを含むメッセージパラメーターでPOSTリクエストが行われます。実際には、組み込みのデータ転送メカニズムを使用しませんが、機能をテストするだけです。

興味深い定数MODUSもあります。これは、バイナリまたは文字列のストレージ形式を担当します。バイナリはネットワークを介した伝送により効率的であり、トラフィックを節約します。この文字列は、開発者によるテストおよび読み取りに便利です。

//組み込みメソッドを使用してメッセージを送信します。
$ new_news-> Send（ 'http://domain.com/pb-service/server.php' ）;
//シリアル化された文字列を取得します
$ res = $ new_news-> SerializeToString（）; //奇妙なパラメータがまだ渡されていますが、理由はわかりません
*このソースコードは、ソースコードハイライターで強調表示されました。

調査を行って、アプリケーションで追跡されている典型的なデータセットを取得し、pb4phpバリアントのPHPおよびプロトコルバッファーのネイティブシリアル化とバージョンを比較しようとしました。データサイズの増加は約30％（通常の方法では186バイトに対して127バイト）でしたが、これは真剣な研究のふりをするものではありませんが、実際のデータセットの効率を比較するのは興味深いことでした。

オブジェクトの元のフォームを復元するには、インスタンスを作成してParseFromStringメソッドを呼び出すだけです。

$ tmp = $ new_news-> SerializeToString（）; //シリアル化
$ test = new News（）; //メッセージのインスタンスを作成します
$ test-> ParseFromString（$ test）; //メッセージを復元します
//チェック
echo 'ID：' 。 $ test-> get_id（）; //戻ります：ID：1
*このソースコードは、ソースコードハイライターで強調表示されました。

ところで、ライブラリでサポートされているいくつかの高度なPB機能については、ディレクトリ/ examples / nested_mess /を見てください。通常のタイプのフィールドを除き、内部に含まれるメッセージを使用してRSSをプロトコルバッファーに変換するだけの例があります。ネストされたクラスも。

そして、最終的に。 pb4phpの機能を使用すると、次のことができます。

プロトコルバッファメッセージの元の仕様に従って、PHPクラスラッパーを生成します（最適な構造ではありませんが）。

通常のPHPクラスと同様に、メッセージクラスを使用してPHPスクリプトで作業し、フィールドにデータを入力します。

後続のファイルへの記録またはネットワーク経由の送信（組み込みHTTP-POSTメソッドを含む）のために、メッセージを16進文字列にシリアル化します。通常、最終メッセージは通常のシリアル化された配列またはJSONよりも10〜30％少なくなります（まだJSONでテストしていないかどうかはわかりませんが、そうだと思います）。

直列化されたビューからPHPクラスへのメッセージを復元します。

メッセージにネストされたメッセージだけでなく、基本データ型を使用できます。

もちろん、シリアル化はリソースを消費し、通常のネイティブよりも常に長くなりますが、単純なメッセージ（複数のフィールドがある場合）ではほとんど見えません。主な利点は、データ量の削減（特に、ネットワークおよび大量のメッセージフローで送信する場合に重要）、および実装言語とプラットフォーム機能に依存しないサービスを簡単に構築できることです。喜ばない唯一のことは、プロジェクトのほとんど凍結された開発（プロトコルバッファー自体ではなくpb4phpを意味します）とその一意性です-多くの言語では、いくつかの実装があります。 PHP用のC拡張機能を備えたバリアントを作成することは興味深いでしょう。シリアル化/リカバリ操作を大幅に高速化できます。また、Zend Frameworkなどの主要なフレームワークからのサポートも希望します。

ただし、この形式でもプロジェクトを使用できます。PHPでGoogleプロトコルバッファー形式のメッセージを処理する方法をすばやく学習する必要がある場合は、pb4phpを使用してください。

PHPでのGoogleプロトコルバッファーの操作

More articles: