大規模な Web サイトがフロントエンドに PHP を使用し、バックエンド ロジックに Java を使用するのはなぜですか?

返信内容:

// テクノロジーは日々変化しています。答えがしばらく更新されないと、古くなってしまいます。
2 週間前に ThinkInLamp の PHP アーキテクト カンファレンスに参加した後、午前中ずっとニアオ兄弟の話を聞いて、とても感動しました。PHP 業界は方向性が不明確で、2 ～ 3 年を無駄にしましたが、ようやく再び立ち上がってきました。 。
実際、Java の再起動の問題を含め、現在では多くの解決策がありますが、何はともあれ、デュアルプロセスのロード バランスの切り替えは簡単に実行できます (ただし、コールド スタートの問題が発生する可能性があります)。

PHP のパフォーマンスの問題に関しては、PHPNG に対する @Laruence の努力により、JIT が導入され、ZVAL も最適化されており、特に最も問題となる配列定数の参照と配列構造のサイズが最適化されています。データ分析の分野ではすべてが解決されており、将来的にはさらに広い領域が存在することは間違いありません。 現在では @Hantianfeng の Swoole のようなソリューションがあり、fastcgi.com によって提案されている標準 FastCGI ソリューションを真に実装しており、起動するたびにコンテキストを再構築してデータを初期化するコストを排除し、バックエンド/Web サーバー/Works を複数で使用することもできます。 TCP サーバーや UDP サーバーなどの方法。
しかし、これらによって異種言語環境が消滅したわけではなく、業界ではますます一般的になってきています。 最も重要な点は、オープンソース業界の台頭により、より多くのより良い選択肢が与えられ、アーキテクチャの開発がますます容易になり、非同期対話やその他の方法を通じて分離する必要性がますます高まっているということです。 非コア モジュールやミドルウェアに異種言語を使用するオープン ソース プロジェクトでは、パフォーマンスの限界を超えたり、開発や改善を伴う特別なビジネス要件が発生したりすることがよくあります。
モジュールを階層化して分割した後、独自のビジネス シナリオやニーズに応じて、さまざまなモジュールをさまざまな言語で実装することがますます一般的になりました。もちろん、その理由の 1 つは会社の構成です。技術チーム。 PHP と Java は Web 開発において最も高い市場シェアを持っているため、これらが組み合わせて使用​​されることが多いのも不思議ではありません。 現在、Python/NodeJS/Go などの多くのオープンソース プロジェクトが異種システムの軍隊に加わっています。

// 元の答えはおそらく 2012 年頃に書かれたと思われます。
まず第一に、なぜ他ではなく PHP と Java なのか。これは、両方のオープンソース コミュニティが非常に活発であり、両方とも Web 開発に適しており、運用と保守において統一的に管理できるという事実と大きく関係しています。
.Net の市場シェアは低くはありませんが、Windows や SQL Server のライセンス料金、オープンソース コミュニティの活動の低さなどのさまざまな問題により、相対的に考慮されていません。 Web 開発に適した TIOBE のトップ 10 言語には、Python、Perl、Ruby も含まれており、その中で、Perl は主にサーバー スクリプトの分野で多くのアプリケーションが存在する可能性があります。ウェブ上で再び昨日になります。 Python は最近増加傾向にありますが、ドキュメントが不足していて採用が比較的難しいため、当面は大規模 Web サイトの主流の選択肢にはならないでしょう。ルビーは言うまでもありません。

2 つの言語の違いをもう一度見てください。 PHP は柔軟性があり、すぐに開始でき、変更も簡単で、公開も簡単です。欠点としては、間違いが起こりやすいこと (スペルミス、SQL インジェクション、アップロードの実行など)、実行効率が低いことです。グローバルキャッシュが不足している。 Java の利点は、安定性と信頼性が高く、操作効率が高く (特に JIT の出現後、その差はさらに大きくなりました)、間違いを犯しにくい (強い型付け、プリコンパイル、例外をインターセプトする必要がある) ことです。など）、開発とリリースの効率が比較的低いことが欠点です。優秀なエンジニアは上記の問題をある程度変えることができますが、一般的に、犬と同じくらい多くの専門家を擁するドリームチームがどこにでも存在できるのでしょうか?

次に、MVC 階層の観点から見ると、一般的な Web サイト プロジェクトの開発サイクルにおいて、要件の変更と調整が最も頻繁に行われるのはビュー、次にコントローラー、最後にモデルです。これは非常に簡単に理解できます。何もすることがないのに、誰が毎日データ構造を変更するでしょうか。多かれ少なかれ、バージョンがアップグレードされるたびに制御構造を変更する必要があります。 Viewさんの場合、BU、PM、UEDが2日間変わらないのは、まとめて年休を取っているからではないでしょうか？

現時点では、RPC テクノロジーは十分に成熟しているため、開発者は何も考えずに機能開発に集中できます。アーキテクチャ上のプラットフォームや通信の詳細の違いについてはあまりにも重要です。これは、大企業で 2 つの言語を同時に使用するソリューションでも、それほど複雑さや作業負荷がかからないことを意味します。もちろん、このためドキュメントの量の下限は大幅に引き上げられましたが、実際、ほとんどのチームはこのことを実際に喜んでいます。「ドキュメントは重要だが、毎日時間がない」などとは言わないでください。他の同僚はどうすればよいでしょうか。書かなかったら協力しますか？

一般に、ユーザーのフロントエンドに近いところでは、PHP を使用すると、フロントエンドの頻繁かつ些細な更新をより速く完了でき、さまざまなニーズの変化に自由に対応できます。ページ構造の調整、ユーザー入力コンテンツの基本的な検証、ユーザー操作のみに関連する単純なロジックなどはすべて、PHP を使用した開発に適しています。ページの変更は、Smarty などのテンプレート テクノロジーを通じてフロントエンド チームに移行することもできます。基本的なビジネス ロジックとデータ更新は Java を使用して開発されており、再利用性、パフォーマンス、スループットを効果的に向上させ、セキュリティの問題を回避できます。開発効率の多少の低下は保守性の向上につながり、基本的なビジネスロジックの調整は全体的に修正することが多く、レイヤーごとのテストと確認を経てリリースできるため、リリース速度が遅いことは問題になりません。 。
したがって、大規模な Web サイトでは、フロントエンドに PHP、バックエンドに Java が使用されます。Java は、採用と保守が容易で、システムが安定し、パフォーマンスが高く、セキュリティが大幅に向上します。コードの再利用とドキュメントの完全性も向上しました。上記の利点をすぐに利用できる場合、建築家としてより幅広い知識を必要とすることはまったく問題ありません。

わかりました。後ろの学生が良い質問を追加しました。なぜ PHP だけを使用しないのか、それとも Java だけを使用しないのですか?最初にこれについて少し触れましたが、なぜ PHP+Java なのかという疑問があったため、公開する前に削除しました。実際、多くの企業、特に中小企業は、チーム組織が過度に複雑にならないようにするために、単一の言語を使用することを好みます。
実際には、単一のソリューションで適切な分離を実現でき、PHP はサービスも提供できます。実際、パフォーマンスの問題は、言語の違いではなく、アルゴリズムとアーキテクチャによって引き起こされることがよくあります。 Velocity や JSTL なども優れた分離ソリューションです。
しかし、現実は多くの場合、理想よりもはるかに貧弱であることは誰もが知っています。これらの解決策は、高圧下では多くの問題を明らかにし、バイリンガリズムの利点を反映しています。これらは実際に上で述べたものであり、変えるのが難しいことの一部を詳述しています。ポイント:
1. PHP の動的スクリプト言語の特性により、解析速度を確保するために、動作環境を確立する前にクラス、関数、および定数を繰り返し実行する必要があります。 ; アプリケーション FastCGI が使用されますが、他の言語とは異なり、プロセスを再利用してリクエストを処理するだけです。初期化後は、FastCGI インターフェイスを通じてデータが取得され、対応するインターフェイスでデータが返されます。性能面で本来の性能を取り戻すことは基本的に不可能である。さらにひどいのは、現在JITブランドのスポーツカーに乗っているJavaである。 さらに、システムレベルの共有データはサポートされていないため、コアデータは一度初期化して、拡張機能やミドルウェアを使用して再利用する必要があります。
2. PHP では間違いが非常に起こりやすく、見つけるのが難しいという事実は、公式の Zend Studio を使用したとしても変わりません。プログラムの品質が高く、重大なエラーがないことを確認する必要があります。十分な経験、十分な厳格さ、責任ある QA が必要です。 Taobao の Huang Shang 氏はかつて IDE について冗談を言いました。 「ミドルウェアの不足」というジョークの背後にある理由は、主に多くのミドルウェアのサポートがより広範囲になり、PHP に恩恵をもたらしたため、近年大幅に改善されましたが、その開発の根幹は依然として C および Java コミュニティにあります。 。パフォーマンスとエラーの発生しやすさは言語の特性に起因する技術的な問題であり、柔軟性と速度の代償として根本的な改善を期待することは困難です。
3. Java の世界にも JSTL、Velocity、Freemaker などがありますが、PHP の柔軟で強力な動的機能、豊富な関数とクラス ライブラリ、簡単な学習コスト、とんでもないドキュメントに比べれば、それは単なるクズです。 、クズだよ！ JSTLを変更した後、コンテキストを再起動する必要がありますか?キャッシュが無効になっている場合でも、Velocity を再起動する必要がありますか?キャッシュがオンになっていると Velocity のパフォーマンスが低下する可能性はありますか?これらを気にしないとしても、特定のデータ検証ルールを調整した場合、アクションを再起動する必要がありますか?

さて、暴言は終わりました。
実際の作業におけるパフォーマンスの問題は、優れたアーキテクチャによって解決できます。間違いやすい問題は、フレームワークと仕様、および包括的なテストによって解決できます。ミドルウェアのオプションは少なくなりますが、実際には、あるべきものはすべて揃っています。 Java の柔軟性はそのままです。OSGi などはもちろん、非常にイライラした場合でも、ノードを削除して再起動し、完了後にノードを再インストールするという戦略が考えられます。まだ動作します。
したがって、多くの単一言語の技術チームが存在することがわかります。この問題の実際の考慮事項は、チーム自体の特性や蓄積などです。バイリンガリズムを使用する人は、バイリンガリズムを使用する理由も知っており、バイリンガリズムを使用しない人も、自分の道を歩む方法を知っています。最後に一言: 二重言語ソリューションを使用する理由がわからない場合は、基本的に検討する必要はありません。 バックエンド Java の最大の利点は、解決したいあらゆる問題に対して既製のソリューションが用意されているという点です。さらに、JVM ベースのソリューションは、平均的な操作効率と運用保守コストを実現します。最高 (ここでは運用保守担当者の能力については説明しませんが、運用保守が一般的な平均レベルにすぎないと仮定します) したがって、フロントエンドが何であれ、バックエンドは自然に Java に傾きます。 -最終用途。

フロントエンドに関して言えば、Java、jsp tag lib、freemaker、velocity に基づく従来の開発ソリューションでは、Web サイトの UI が頻繁に変更されることが最大の問題です。 。 。 。フロントエンドをどのように変更してデバッグしたいですか?特別な勉強をせずにどうやってそれを理解できるのでしょうか？また、Java の開発モデルは常に MVC であり、バックエンドとフロントエンドが密接に統合されているため、基本的にフロントエンドが UI 層で自由に動作することが困難です。一方、PHP に基づくフロントエンド ソリューションは、少なくともフロントエンド担当者によって理解され、デバッグできるため、バックエンド Java を REST サービスにすると、生産性が大幅に解放されます。フロントエンドの動的コードは転送可能です。フロントエンド エンジニアにとって、最も快適な動的 Web ページ ソリューションは当然のことながら PHP であり、どれだけ調べてもそれを変更することはできません。私も含めて PHP についてはあまり好きではありませんが、それでもフロントエンド エンジニアにとって最も快適で快適な動的 Web ページ ソリューションはやはり PHP であるということをもう一度強調したいと思います。上で多くの人が答えているように、PHP は速いですが、その速さはどこにあるのでしょうか? PM が何を変更するかを指示し、フロントエンドは開始から 10 分以内に変更され、30 分後にリリースされました。バックエンドエンジニアにタスクを送信しますか?それから、待ってください。 。 。

=========================================== == ==================

いくつか質問をして、自分自身を宣伝しましょう。

上で述べたように、従来の Java フロントエンド ソリューションは MVC、テンプレート エンジン、および多数のもので構成されています。これらはエンタープライズ アプリケーションには非常に適していますが、Web サイトにはどうでしょうか。確かに、あまり聞かないような気がします。なぜ？他の場所からテキストをコピーしました (著作権を考慮する必要はありません。これは私が自分で書いたものです)

過去 10 年間で、Java ベースの MVC フレームワークが雨後の筍のように出現しました。問題は、フロントエンド設計者にとって非常に不親切であり、インターネット企業が Java (特に MVC) に基づいて独自の Web サイトを構築することはほとんどありません。重大な理由は次のとおりです:

1. フロントエンド デザイナーに対して非常に不親切です。 MVC モデルでは、プログラマブル テンプレート言語は非常に重要な役割を果たします。ビジュアル作成が主な仕事であるフロントエンド デザイナーは、HTML や CSS に精通しており、テンプレート ファイルに埋め込まれたさまざまな動的コードを理解することはできません。もちろん、これは非常にわかりにくい内容であるため、少なくとも人々にとって理解しやすい従来の PHP が最適になるはずです。

2. 開発効率が低い。インターネット企業の開発は通常、反復的であり、明確な需要がありません。従来の PHP 開発モデルが好まれる理由は、変更が容易であり、開発スピードが速いためです。この点で、MVC モデルの開発は基本的に失敗します。したがって、Java に基づいて独自のフロントエンド ページを構築するインターネット企業はほとんどありません。たとえ構築するとしても、通常は JSP に基づく独自のフレームワークに基づいています。

さらに、過去 10 年近くの MVC の歴史の中で、実際に次の問題に悩まされてきました。

1. フロントエンドのデザイナーやエンジニアは、ページへの埋め込みについて不満を抱いてきました。一方、バックエンド開発者は、動的コードにより、ページの大規模な再構築を実行することが困難になります。ページ。

2. 開発者は、テンプレート言語の機能の貧弱さに悩まされることがよくあります。一部の特殊で複雑なレンダリング ロジックでは、経験豊富な開発者が高度なスキルを備えたコードを作成して実装する必要がある場合があります。そして、そのようなコードは通常、誰も理解できない魔法のコードになります。

3. 開発者は、MVC の開発効率の低さに非常に不満を抱いています。私たちは、より効率的な開発モデルを望んでいます。

さて、本題に戻りますが、フロントエンドとして Java を使用する必要がある場合、上記の MVC やテンプレートなどより良い方法はありますか?答えは「はい」です。つまり、ビューファーストです。 Lift によって最初に提案され提唱されたビューファーストの概念 (Lift を知らない人は、Lift (Web フレームワーク) を参照してください) は、Web サイトの開発モデルを美しくまとめたものと見なされるべきです。実際、PHP フロントエンド ソリューション自体は、ビュー ファーストの概念と一致します。ビューファーストの概念により、煩雑な MVC アーキテクチャが回避されると同時に、Lift は純粋な HTML テンプレート エンジンを提供し、フロントエンド エンジニアがバックエンドの実装をまったく考慮せずに独立して作業できるようになり、共同作業が向上します。フロントエンドとバックエンドの効率化は画期的な意義と言えます。

ああ、自分の宣伝を忘れるところでした。リフト手法は優れていますが、Scala ベースのソリューションは多くの人を諦めさせるのに十分です。ここで Java ベースのビュー ファースト ソリューションを厳粛に提供します: astamuse/asta4d · GitHub

asta4 自体の本来の目的は、リフトの Java 移植版を提供することです。その後の開発では、段階的に異なる点がいくつかありますが、全体として、フロントエンドのリフトの 2 つの最も重要な機能は、ほとんど変更されずに asta4d に移植されています。

1. CSS セレクターの駆動。テンプレート エンジン

フロントエンドの純粋な HTML テンプレートには、バックエンドの動的コードは埋め込まれません。フロントエンド エンジニアは、通常の 2 つの部門で処理する必要があります。 work プロセスは次のとおりです:

1. タスク ブックまたはバグ チケットを取得し、フロント エンドでブランチを開き、ページの作業または変更を開始します。
2.新しい機能やバグには通常、このステップで終了します。その後、チケットがバックエンドに転送されます
3. バックエンドはチケットを取得し、作業を開始し、終了し、プッシュします。
4. リリース

このプロセス中、フロントエンドとバックエンドは通信する必要がないため、ほとんど通信しないことに注意してください。フロントエンドは html、css、js を通じてアイデアを表現します。バックエンドは、フロントエンドが必要とするデータを入力するだけです。バックエンドはフロントエンドのデータを理解できません。どこに入力する必要があるか、またはどのデータを入力する必要があるかについては、限られた通信のみが必要です。

私たちの実際の経験の 1 つは、フロントエンド部門が UI を完全に再構築するのに 2 人月かかったということです。フロントエンドの作業が完了した後、バックエンド部門はわずか 30 分で完了しました。必要な変更をすべて配置します。フロントエンドの作業が完了してから 30 分後に、リファクタリング ブランチがトランクにマージされ、リリースの準備が整います。


========補足==============

この回答にはさらに詳しい説明があります

フロントエンド開発とバックエンド開発はどのように連携しますか? - ピギーの答え 私は PHP+JAVA アーキテクチャをサポートしています。特に、電子商取引 Web サイトなど、複雑なユーザー インタラクション、高い同時実行性、および複雑なバックエンド ビジネスを伴う Web サイトでは、再起動せずに迅速な開発と展開を実現できます。同時に、nginx + fastcgi + php の組み合わせは、高い同時実行性のテストにも耐えることができます。 Java は、複雑なバックエンド業務処理 (注文処理、ショッピング カート、在庫関連など) に非常に適しています。信じられないなら、試してみてください！ PHP もバックエンドとして非常に人気がありますが、これは、NOSQL、SHELL などの他のものの開発が非常に一般的であることを意味します。 PHP の単一プロセスおよびスレッドレス モードは本質的にその欠点を決定するため、特定のビジネス設計を行う場合には、これらの地雷原に注意深く注意を払う必要があります。
同様の問題は、PHP が MYSQL の優れたパートナーであるため、サーバー側として PHP が使用されるため、JAVA と比較して開発コストとバグ管理コストが高くなります。 フロントエンドのプレゼンテーション層を頻繁に変更する必要があるため、Java の方が安全であり、PHP の方が高速です。ただし、PHP は大規模な開発には適していません。複雑なプロジェクトの場合は、Java をコアとして使用することをお勧めします。 フロントエンドは PHP を使用します。これは、PHP が低コストで、すぐに変更およびリリースできるためです。バックエンドでは、PHP は同時実行性が高い場合には Java ほど使いにくいため、Java を使用します。もちろん、Facebook のように PHP をカスタマイズしたい人は例外です... インタプリタさえも自分で書いているのはまだ PHP ではないと思います... 単なる PHP の構文です... データ層とアプリケーション層: 変更はほとんどなく、高いセキュリティと堅牢性の要件があります。
Web 層: 大量の開発、頻繁な変更、中断のないサービスが必要。
これはまさに天国のような試合です。
Java と同じくらい堅牢であれば、開発ははるかに高速になるでしょう。私の Java Web サイトは、不当な PHP リクエストを頻繁に受け取ります。 実際、それは歴史が残した問題である可能性が高く、説明の必要はありません。 それならphp、c、c++を使った方が良いでしょう。 。 この初心者は、私の目には、PHP と Java は両方ともバックエンド言語であると考えています。サーバー側はフロントエンドとバックエンドに分かれている可能性がありますか?
これはあなたが議論している異種モデルですか? たとえば、ショッピング モール、商品リスト、商品詳細、その他の純粋に表示されるページは PHP で処理され、ショッピング カートの追加、注文、支払いは Java で処理されますか?
一般的な中小規模のシステムでは、このような異種混合モデルを使用する必要はないのでしょうか?