恥知らずのウェブエンジニア -web engineer, shameless

これは一歩を踏み出すことができない者たちのブログ

なぜPHPはgRPCサーバーがサポートされていないのか?

なんかもうアレなので、前回少し触れたのですが、2018/2月現在公式なPHPのgRPCサーバーはサポートされていません。

GoでgRPCサーバー立てて、PHPでリクエストしてみる - 恥知らずのウェブエンジニア -web engineer, shameless

様々な迫害には慣れているPHPerでもそもそもサポートされないというのは辛いものがあります。

なぜPHPのgRPCサーバーがサポートされていなのか下記のMLのdiscussionを英語の勉強も兼ねてまとめてみようと思います。

※素人意訳なので、間違いありましたらごめんなさい。

groups.google.com

gRPC Servers in PHP?

PHPのgRPCクライアントは作れるけど、gRPCサーバーは作れません。それの技術的ブロッカー、将来的な実装のロードマップはあります?

 

PHPのgRPCサーバーにはいくつかの問題があります。そして今の所、解決策はありません。

nginx, Apacheのフロントエンドなしで素のPHPを実行している場合解決策がありません。典型的な設定では、PHPでlong-lived streaming RPCをすることができません。

ページはすぐにtimeoutしてしまいます。unary RPCを提供することはできます。または制限時間を持つstreaming RPCを提供できますが、それはもはやgRPCではありません。

そして現時点ではPHPには適切なHTTP/2サポートはありません。

フロントエンドサーバーからPHPプロセスへリクエストを転送するモデルでは、gRPCリクエストを処理するために必要なHTTP/2 streamへのアクセスができません。

これ以上のことについては、PHPからweb-socketを提供することをおすすめします。おそらくすべての解決策はapacheなどなしの素のPHPを実行することになると思われます。 これはPHPを使いたい典型的な構成ではありません。したがって、PHPのgRPCサーバーは特殊な構成になるため、あまり役に立たないでしょう。

 

下記のようにphp-cliを使ってweb-serverを動かすことができます PHP: Built-in web server - Manual

 

ドキュメントの冒頭に、「これは開発のテスト、デモ用でパブリックネットワーク上で使用しないでください。」と書いてありますけど

 

良い方法を見つけることにも非常に興味があります。他の言語はこれをどのように処理していますか?Pythonに関しても同じ問題を抱えているのでは。 gRPCは素のPythonプロセスだけをサポートしていますか?

 

この例を見てみると grpc/route_guide_server.py at release-0_13 · grpc/grpc · GitHub PHPも同じ種類のソケットリスニング操作を実行することができます。 このようなデーモン化されたPHPプロセスを書くことは一般的です。もちろん、PHPがHTTP / 2の機能をネイティブにサポートするかどうかは別の問題として。。

 

他の言語(Ruby、Node.js、Python、C#、...)にはそのような問題がないのは、それらがすべてコマンドラインから適切に動作しているフレームワークを持っているからです。

gRPC pythonサーバーを動かすためのpythonデーモンを適切に起動することができます。

nodeにはフロントエンドなしで稼働できる組み込みの機能があります。 Rubyは長い間ネイティブでこれもやっています。

PHPのみがデーモンを実行するための適切なサポートを持っていません。オプションとしてあるのは、本番環境に適していないプロトタイプです。

 

ReactPHPのようなもので回避できるかも? Event-driven, non-blocking I/O with PHP - ReactPHP

 

素のPHPプロセスとしてサーバーを実行することはスケーラビリティがなく、PHPコミュニティは推奨していなく、PHP Web Hosting Serviceでほとんどサポートされていません。

 

私はReactPHPを掘り下げ、必要なHTTP / 2をサポートするかどうか見てみる

 

ReactPHPは、gRPCのC coreがすでに行っていること以上のものを提供しません。coreは非同期I / OとHTTP / 2を処理します。

PHPをgRPCサーバーとしてサポートすることは、third partyの依存を必要とすることなく、既に持っているものの周りにコードを書くことを意味します。

しかし、それには素のPHPが必要であり、私たちが見るに公式のPHPサーバのサポートは、LAMPのほかにPHPに対する大きな需要を見たことがないと思っています。 そのモデルをサポートするためのリソースをコミットする必要があります。

 

正しい解決策は、SAPIとして"php-fpm"と同じような "php-grpc server"があればと思う。 それはHTTP / 2ウェブサーバを起動し、$ _SERVER / $ _ POSTの適切な変数を使用してserverへの個々のPHPリクエストを作成します。

これは、CのgRPCサーバーがlong-lived streamingを処理できるようにする一方で、PHPの原理を破ることなく維持します。 しかしこれは複雑になるかもしれません。

現状の回避策は、Go FastCgiクライアントライブラリを使用して、gRPC / HTTP2上でリクエストを受け入れ、それらをphp-fpmベースのバックエンドに送信する単純なGoベースのプロキシを書くことです。

 

我々が想像している2つの主な動機は比較的共通している。 1つは、私たちのPHPベースのREST + JSON APIは、protobufやThriftのように見えるようになっているinternal pseudo-type system(内部擬似型システム)を長年にわたって成長させてきました。

2つ目はObjective-CAndroidPHP、およびJavaScriptAPIクライアントを使用し、これらのクライアントの開発を容易にするためのコード生成です。 我々はgRPC + Protobufがそれらの解決策であると見ています。

ほとんどの人がApacheやnginixでPHPを使用しているので、素のPHPサーバーをサポートすることに抵抗があることを理解しています。 しかし私たちはunary RPC ができることに興奮しています。 おそらく、PHPApache / nginixがHTTP / 2サポートを進化させると、gRPC PHPサーバーのサポートも進化する可能性があります。

 

PHPサーバーの問題と使用例を深く理解し、合理的な解決策を考案したいと考えています。

 

我々はgRPCからFastCGIPHP-FPM)にブリッジする形でPHPサーバのサポートを開発しました。興味があるなら、それをオープンソースにして、関わっているコミュニティのメンバーをさらに増やしたい。

 

素晴らしい! 間違いなくオープンソースにするべきです。 PHPのgRPCサーバーは必須です - マイクロサービスの時代にはすべてのPHPLAMPで実行されているわけではありませんから。

 

PHPサーバソリューションにも非常に興味があります。 PHPのマイクロサービスプラットフォームは、PHPが "嫌われ者の言語"(red headed step child of a language)でなくなるのを助けるだろう。 :-)

 

アップデート - 私たちはオープンソーシングをクリアし、独自のビットを抽出するよう努めています。できるだけ早くgRPCエコシステムへ組み込まれるよう評価するものを得るでしょう。

 

多くのユーザーが興味を持っているので、gRPCエコシステムへの登場を楽しみにしています

 

その後進捗どうですか???

まとめ

なんとなく背景がわかった気がします。

  • そもそもPHPは、素の(nakedな)PHPの状態でデーモン化して実行がすることができない
    • built-in serverがあるけどあくまでテスト用で本番環境では使えない
    • 一般的な設定ではすぐtime outするため、Streaming RPCがまともに使えない
    • フロントエンド(apache, nginx)を置いてしまうとHTTP/2 streamへのアクセスができない。それってもはやgRPCじゃなくない?
  • そのためthird partyなしでのPHPでのgRPCサーバーのサポートはできない
  • php-fpmのようなphp-grpc-serverが追加されるとても幸せ

  • PHPデベロッパーにとってフロントエンド(apache, nginx)があることは一般的になっている

    • 素のPHPだけのサーバーの方が違和感
  • そしてPHPデベロッパーとして有り難いのは、共通のprotoを使うことで開発が簡略化できること。unary RPCだけでもありがたい
  • Apache,nginixのHTTP / 2サポートが進むとまた状況が変わるもしれない
  • gRPCからphp-fpmへブリッジするlibraryの開発もされている(が開発者の返信が2016年末で止まっている…)

gRPCとしては、

  • PHPの言語のみではgRPCの全機能が提供できなく、中途半端なぐらいになるぐらいなら公式サポートはできない

PHP開発者としては、

  • 開発者側としてはコードの自動生成、unary RPCだけでも利点がある(しかしそれがgRPCであるべきなのかと言われるとアレな感じも。。。)

のような状況のようです。 また関連してnginx が gRPC proxy supportの実装を進めているようです(中身よくわかってない) これによって状況がまた変わるかも? Milestone 1.13 – nginx

今後も動きがありそうなので引き続きウォッチ。