// テクノロジーは日を追うごとに変化しています。答えはしばらく更新されないと古くなってしまいます。
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 なのか。これは、両方のオープンソース コミュニティが非常に活発であり、両方とも Linux 環境での実行に適しており、運用と保守において統一的に管理できるという事実と大きく関係しています。
.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 テクノロジーは十分に成熟しています。 Web サービス/ヘシアン/RESTful API はいずれも、開発者が異種プラットフォーム間の違いや通信の詳細をあまり考慮することなく、機能開発に集中できるようにします。これは、大企業で 2 つの言語を同時に使用するソリューションでも、それほど複雑さや作業負荷がかからないことを意味します。もちろん、このためドキュメントの量の下限は大幅に引き上げられましたが、実際、ほとんどのチームはこれを実際に喜んでいます。ドキュメントは重要だが毎日時間がないなどとは言わないでください。あなたが書かなくても同僚は協力しますか?
一般的に たとえば、ユーザーのフロントエンドに近いところでは、PHP を使用すると、フロントエンドの頻繁で些細な更新をより速く完了でき、さまざまなニーズの変化に自由に対応できます。ページ構造の調整、ユーザー入力コンテンツの基本的な検証、ユーザー操作のみに関連する単純なロジックなどはすべて、PHP を使用した開発に適しています。ページの変更は、Smarty などのテンプレート テクノロジーを通じてフロントエンド チームに移行することもできます。基本的なビジネス ロジックとデータ更新は Java を使用して開発されているため、再利用性が効果的に向上し、パフォーマンスとスループットが向上し、セキュリティの問題が回避されます。開発効率が多少低下しても保守性は向上しますし、基本的なビジネスロジックの調整は全体的に修正することが多く、レイヤーごとのテストと確認を経てリリースできることが多いため、リリース速度が遅くても問題ありません。
そのため、大規模な Web サイトでは、フロントエンドに PHP、バックエンドに Java が使用されます。これは、採用と保守が容易で、システムが安定し、パフォーマンスが高く、セキュリティが大幅に向上します。コードの再利用とドキュメントの完全性も向上しました。上記の利点をすぐに利用できる場合、建築家としてより幅広い知識を必要とすることはまったく問題ありません。
さて、後ろのクラスメートが良い質問を追加しました。なぜ PHP だけを使用しないのか、それとも Java だけを使用しないのですか? 最初にこれについて少し触れましたが、質問がなぜ PHP+Java なのかということであったため、公開する前に削除しました。実際、多くの企業、特に中小企業は、チーム組織が過度に複雑にならないようにするために、単一の言語を使用することを好みます。
実際には、単一のソリューションで適切な分離を実現でき、PHP はサービスも提供できます。実際、パフォーマンスの問題は、言語の違いではなく、アルゴリズムとアーキテクチャによって引き起こされることがよくあります。 Velocity や JSTL なども優れた分離ソリューションです。
しかし、現実はしばしば理想よりも貧弱であることは誰もが知っています。これらの解決策は、高圧下では多くの問題を明らかにし、バイリンガリズムの利点を反映しています。これらは、変更が難しいいくつかの点を詳しく説明しています。 PHP の動的スクリプト言語の特性により、動作環境を確立する前に、クラス、関数、および定数を繰り返し実行する必要があります。ただし、FastCGI が適用されるだけです。他の言語とは異なり、プロセスを再利用してリクエストを処理すると、フォークのコストが削減されます。初期化後、FastCGI インターフェイスを介してデータが取得され、対応するインターフェイスでデータが返されます。いくつかの理由から、パフォーマンスの低下を回復することは基本的に不可能です。 Java は現在 JIT スポーツカーを運転しています。 さらに、システムレベルの共有データはサポートされていないため、コアデータは一度初期化して、拡張機能やミドルウェアを使用して再利用する必要があります。
2. PHP では間違いが起こりやすく、見つけるのが難しいという事実は、たとえ公式の Zend Studio を使用したとしても変わりません。プログラムの品質を確保し、重大なエラーがないことを確認する必要があります。十分な経験、十分な厳格さ、そして責任あるQAを持っています。 Taobao の Huang Shang 氏はかつて IDE について冗談を言いました。 「ミドルウェアの不足」というジョークの背後にある理由は、主に多くのミドルウェアのサポートがより広範囲になり、PHP に利益をもたらしたため、近年大幅に改善されましたが、その開発の根幹は依然として C および Java コミュニティにあります。 。パフォーマンスとエラーの発生しやすさは言語の特性に起因する技術的な問題であり、柔軟性と速度の代償として根本的な改善を期待することは困難です。
3. Java の世界には JSTL、Velocity、Freemaker もありますが、PHP の柔軟で強力な動的機能、豊富な関数とクラス ライブラリ、簡単な学習コスト、そしてとんでもないドキュメントに比べれば、それは単なるクズです、それはクズです! JSTLを変更した後にVelocityを再起動することは可能でしょうか？ キャッシュをオフにしないとVelocityのパフォーマンスが低下する可能性がありますか？これらを考慮して、特定のデータ調整を調整してください。アクションを変更してテスト ルールを再起動する必要がありますか?
さて、暴言は終わりました。
実際の作業におけるパフォーマンスの問題は、優れたアーキテクチャによって解決できます。間違いを犯しやすい問題は、フレームワークと仕様、および包括的なテストによって解決できます。ミドルウェアのオプションは少なくなりますが、実際には、あるべきものはすべて揃っています。 Java の柔軟性もあります。OSGi などはもちろんのこと、非常にイライラした場合でも、ノードを削除して再起動し、完了後にノードを再インストールするという戦略が考えられます。まだ動作します。
このように、単一言語の技術チームがたくさんあることがわかります。この問題の実際の考慮事項は、チーム自体の特性や蓄積などです。バイリンガリズムを使用する人は、バイリンガリズムを使用する理由も知っており、バイリンガリズムを使用しない人も、自分の道を歩む方法を知っています。最後に一言: 二重言語ソリューションを使用する理由がわからない場合は、基本的に検討する必要はありません。
子豚さん、プログラムを書くのは楽しいです
バックエンド Java の最大の利点は、解決したいあらゆる問題に対して既製のソリューションが用意されていることです。平均すると、運用効率と運用保守コストの点で最高です（ここでは運用保守要員の能力については議論しませんが、当社の運用保守は一般的な平均レベルにすぎないと仮定します）。フロントエンドに何を使用するとしても、バックエンドは当然 Java の方が好きです。
フロントエンドに関しては、Java、jsp タグ ライブラリ、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 サイトを構築することはほとんどありません。それには重大な理由があります。 . フロントエンドデザイナーに対して非常に不親切です。 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 自体の本来の目的は、Lift の Java 移植バージョンを提供することです。全体として、フロントエンドのリフトの 2 つの最も重要な機能は、ほとんど変更されることなく asta4d に移植されています:
1、最初に表示
2、テンプレート エンジンを駆動する CSS セレクター
フロントエンドの純粋な HTML テンプレートは、バックエンドの動的コードを埋め込む場合、フロントエンドのエンジニアは HTML を扱うだけで済みます。 通常のワークフローは次のとおりです。
1. ミッションステートメントまたはバグチケットをダウンロードし、フロントエンドでブランチを開き、ページの作業または変更を開始します
2. ページ上のバグ対応の場合、通常はこのステップで終了します。新しい機能であるか、バグによりバックエンドの連携が必要な場合、チケットはバックエンドに転送されます3. バックエンドはチケットを取得し、動作を開始し、終了し、プッシュします。
4. リリース
フロントエンドとバックエンドは通信する必要がないため、このプロセスではほとんど通信しないことに注意してください。バックエンドが担当するのは 1 つのことだけです。フロントエンドはデータを入力する必要があります。はい、データを入力しているだけなので、バックエンドがフロントエンド データをどこに入力すべきかを理解できない場合にのみ実行されます。 、またはどのようなデータを入力する必要があるかについては、限られたコミュニケーションが必要になります。
私たちの実際の経験の 1 つは、フロントエンド部門が UI を完全に再構築するのに 2 人月かかったということです。フロントエンドの作業が完了した後、バックエンド部門はすべての変更を完了するのにわずか 30 分しかかかりませんでした。はい、フロントエンドの作業が完了してから 30 分後に、リファクタリング ブランチがトランクにマージされ、リリースの準備が整います。
========補足==============
この回答にさらに詳しい説明があります
Alyoda、xxxの経験を持つインターネット包囲者、先生!
Pengtitus、百聞は一見にしかず
フロントエンドのプレゼンテーション層は頻繁に変更する必要があり、php はより安全であるため、php は高速です。動的スクリプト言語であるため、フロントエンドに適していますが、PHP は大規模で複雑なプロジェクトの開発には適していないため、コアとして Java を使用することをお勧めします
Wang Hai、プログラマー
同様の問題は、PHP が MYSQL と優れたパートナーであるため、サーバー側として PHP が使用されるため、JAVA と比較して開発コストとバグ管理コストが高くなります。
13 歳、プログラマー
元のリンク: https://www.zhihu.com/question/20314377
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
