ホームページ  >  記事  >  Java  >  なぜJSPは排除されたのですか?

なぜJSPは排除されたのですか?

(*-*)浩
(*-*)浩オリジナル
2019-05-11 11:05:018267ブラウズ

以前のプロジェクトのほとんどは、父親と母親の両方である Java プログラマーであり、フロントエンド (ajax/jquery/js/html/css など) とバックエンド (java/mysql/Oracle など) に取り組んでいました。 )。

時代の発展に伴い、多くの大企業、中堅企業、中小企業ではフロントエンドとバックエンドの境界が徐々に明確になり、フロントエンドエンジニアはフロントエンドのことのみを担当するようになりました。 、バックエンドエンジニアはバックエンドのことだけを担当する、専門化という言葉があるように、何でも知っている人は結局何もできません。

推奨コース: Java チュートリアル

なぜJSPは排除されたのですか?

大企業や中堅企業にはプロフェッショナルが必要で、中小企業にはゼネラリストが必要ですが、個人のキャリア開発を考えると、これらを分けておくことをお勧めします。一生Javaだけで食っていくつもりならCSSやJSなどは勉強しないほうがいいです。

Java、JVM 原則、Spring 原則、mysql ロック、トランザクション、マルチスレッド、大規模同時実行性、分散アーキテクチャ、マイクロサービス、関連するプロジェクト管理などにエネルギーを集中してください。これにより、コアの競争力が向上します。ことわざにあるように、人生に投資したものは、人生があなたに返してくれるでしょう。

(ポジティブなエネルギーに満ちています:

あなたが業界のエリートになれば、時が来れば、車、家、女性、お金、そしてチャンスがすべてあなたのもとにやってくるでしょう。心配しないでください。

Java プログラマーになるのはとても簡単です。知識が増えれば増えるほど、より多くのお金を稼ぐことができます。もちろん、ある程度の感情的な感情も必要です。インテリジェンス...

あなたの能力が高ければ高いほど、他の人よりも多くの価値を生み出すことができます。あなたが会社に価値を生み出し、会社はあなたにさまざまな利益を与えてくれる、Win-Win の状況です!)

かつて、私たちの Java Web プロジェクトはすべて、springmvc/struts、spring spring jdbc/hibernate/mybatis などの複数のバックエンド フレームワークを使用していました。

ほとんどのプロジェクトは、Java バックエンド、コントロール層の 3 つの層に分割されています。 (コントローラー/アクション)、ビジネス層 (サービス/管理)、永続化層 (dao)。

コントロール層は、パラメータの受信、関連するビジネス層の呼び出し、データのカプセル化、JSP ページへのルーティングを担当します。次に、JSP ページ上でさまざまなタグ (jstl/el) または手書き Java (<%=%>) を使用して、背景データを表示します。 ######右?

まずこの状況を見てみましょう。要件が決定され、コードが記述され、テストが完了しました。次に何をするでしょうか?もうすぐ発売されるのかな?

Maven や Eclipse、その他のツールを使用してコードを war パッケージにパッケージ化し、この war パッケージを実稼働環境の Web コンテナ (tomcat/jboss/weblogic/websphere/jetty/) に公開する必要があります。樹脂)ですよね?

公開後、Web コンテナを起動してサービスの提供を開始する必要がありますが、この時点でドメイン名や DNS などを設定することで Web サイトにアクセスできるようになります (Web サイトであると仮定します)。

そうですね、フロントエンドとバックエンドのコードはすべてその war パッケージに含まれていますか? js、css、画像、さまざまなサードパーティのライブラリが含まれますよね?

それでは、Web サイトのドメイン名 (www.xxx.com) をブラウザに入力してみましょう。その後はどうなりますか? (この質問は多くの企業の面接質問でもあります)

先ほど取り上げましたが、土台の悪い子供用の靴を探してください。

ブラウザは IP 経由でサービスにルーティングします。TCP 3 ウェイ ハンドシェイクの後、ブラウザは TCP プロトコル経由で Web サーバーへのアクセスを開始します。Web サーバーがリクエストを取得した後、サービスの提供を開始し、リクエストを受け取り、レスポンスを渡すと、レスポンスがブラウザに返されます。

それでは、見てみましょう。まず、ホームページに 100 枚の写真と 1 つのテーブル クエリがあると仮定します。このとき、ユーザーの一見 1 つの HTTP リクエストは、実際には 1 つではありません。ユーザーファースト 初回訪問時, ブラウザーにキャッシュはありません。100 枚の写真に対して、ブラウザーは 100 回の http リクエストを連続して要求します (長い http リンクと短い http リンクの問題については誰かが教えてくれるでしょうが、ここでは説明しません)。 Web サーバーはこれらのリクエストを受信すると、TCP 送信用のソケットを作成するためにメモリを消費する必要があります。

ここが重要な点です。この場合、ページ内のすべてのリクエストはサーバーにのみリクエストされるため、Web サーバーへの負荷は非常に高くなります。ユーザーが 1 人だけであれば、問題ありません。同時に 10,000 人がいる場合 アクセスに関しては (Web サーバー クラスターについては話さず、単一インスタンスの Web サーバーについて話しましょう)、サーバーはいくつの TCP リンクを処理できますか?サーバーにはどれくらいのメモリが搭載されていますか?何回の IO に耐えることができますか? Web サーバーに割り当てたメモリの量はどれくらいですか?下がってしまうのでしょうか?

これが、Web アプリケーションが大規模および中規模になればなるほど、より分離する必要がある理由です。

理論的には、データベース、アプリケーション サービス、メッセージ キュー、キャッシュ、ユーザーがアップロードしたファイル、ログなどを 1 つのホストに配置できますが、これはすべての卵を 1 つのかごに入れるようなもので、隠されたものが存在します。非常に大きな危険です。

通常の分散アーキテクチャ、アプリケーション サーバー クラスター (フロント、バック) ファイル サーバー クラスター、データベース サーバー クラスター、メッセージ キュー クラスター、キャッシュ クラスターなどを分解する必要があります。

本題に入りますが、まず第一に、アプリケーション アーキテクチャを強化するために、今後の Java Web プロジェクトでは jsp の使用を避け、フロントエンドとバックエンドを分離し、分散アーキテクチャを試す必要があります。

jsp 使用の問題点:

1. 動的リソースと静的リソースはすべて結合されており、真の動的リソースと静的リソースの分離は実現できません。サーバーは、CSS http リクエスト、JS、画像、動的コードなどのさまざまな http リクエストを受信するため、大きな負荷がかかります。サーバーに問題が発生すると、フロントエンドとバックエンドが一緒にプレイされることになり、ユーザー エクスペリエンスが非常に低下します。

2. フロントエンド エンジニアが HTML を完成させた後、Java エンジニアは HTML を JSP ページに変更する必要がありますが、エラー率が高くなります (ページ内に大量の JS コードが頻繁に表示されるため)。問題を修正するときは、両者が協力する必要があります。開発、非効率。

3.jsp は Java をサポートする Web サーバー (Tomcat など) で実行する必要があり、nginx は使用できません (nginx は単一インスタンスの http 同時実行数が最大 50,000 と言われており、この利点があります)を使用する必要があります)、パフォーマンスを向上させることはできません。

4. 初めて JSP をリクエストするときは、Web サーバーでサーブレットにコンパイルする必要があります。最初の実行は遅くなります。

5. jsp をリクエストするたびに、サーブレットにアクセスし、出力ストリームを使用して html ページを出力しますが、これは html を直接使用する場合ほど効率的ではありません。

6.jsp には多くのタグと式が含まれているため、フロントエンド エンジニアはページを変更するときに負担がかかり、多くの問題点に遭遇することになります。

7. jsp に大量のコンテンツがある場合、同期的に読み込まれるため、ページの応答が非常に遅くなります。

上記の問題点のいくつかに基づいて、フロントエンドとバックエンドの真の分離を達成するために、プロジェクト全体の開発の重みを前方に移動する必要があります。

以前の方法は次のとおりです:

1. クライアント リクエスト
2. サーバー側のサーブレットまたはコントローラーがリクエストを受信します (ルーティング ルールはバックエンドによって定式化され、その重みのほとんどはプロジェクト全体の開発 バックエンドで)
3. サービスを呼び出し、ビジネス ロジックを完成させるための dao コード
4. jsp に戻る
5.jsp はいくつかの動的コードを表示します

新しい方法

1. ブラウザはリクエストを送信します
2. HTML ページに直接到達します (ルーティング ルールはフロントエンドによって策定され、プロジェクト開発全体の重みが前倒しされます)
3. HTML ページは、サーバー インターフェイスを呼び出してデータを生成します (Ajax などを介して)
4. 動的な効果を表示するには、HTML を入力します。

(興味のある子供たちは、Alibaba などの大規模な Web サイトにアクセスし、F12 キーを押して、ページを更新したときに http がどのように機能するかを監視できます。ほとんどの子供たちは、バックグラウンド データを個別に要求します。大規模で包括的なデータの代わりに、json を使用してデータを送信します。動きを含むページ全体を返す http リクエスト)

これの利点:

1. 真のフロントエンドとバックエンドの分離を実現でき、フロントエンド サーバーは nginx を使用します。 。

フロントエンド サーバーは、CSS、JS、画像などの一連の静的リソースを配置します (CSS、JS、画像、その他のリソースを、Alibaba Cloud のような特定のファイル サーバーに配置することもできます) oss、cdn アクセラレーションを使用)、フロントエンド サーバーはページ参照、ジャンプ、およびバックエンド インターフェイスの呼び出しを制御します。バックエンド サーバーは tomcat を使用します。

(nodejs、react、router、react、redux、webpack などのフロントエンド エンジニアリング フレームワークを使用する必要があります)

2. バグを見つけた場合は、すぐにバグを見つけることができます。いいえ、ボールを蹴り合う現象が発生します。

ページのロジック、ジャンプ エラー、ブラウザの互換性の問題、スクリプト エラー、ページ スタイル、その他の問題はすべてフロントエンド エンジニアの責任です。

インターフェイス データ エラー、データが正常に送信されない、応答タイムアウトなどの問題はすべてバックエンド エンジニアによって解決されます。

両者はお互いに干渉せず、フロントエンドとバックエンドはお互いを愛する家族です。

3. 同時実行性が高い場合は、フロントエンド サーバーとバックエンド サーバーを同時に水平方向に拡張できます。たとえば、淘宝網のホームページでは、2,000 台のフロントエンド サーバーをクラスタ化する必要があります。 1 日あたり平均数十億の PV に耐えます。

(私は Alibaba のテクノロジー サミットに行き、すべての Web コンテナーが自分たちで書かれていると言っているのを聞きました。たとえ 1 つのインスタンスが 100,000 http 同時実行に耐えられるとしても、2,000 ユニットは 2 億 http 同時実行に耐えることができます。も使用してください。ピークが来て無限に拡大することを予測するのは恐ろしいです。たった 1 つのホームページです...)

4. バックエンド サーバーの同時実行負荷を軽減し、インターフェイスを除くすべての http リクエストをバックエンド サーバーに転送します。フロントエンドのnginx。

5. バックエンド サービスが一時的にタイムアウトまたはダウンした場合でも、フロントエンド ページには正常にアクセスできますが、データは更新されません。

6. インターフェイスを共有できるように、WeChat に関連する軽いアプリケーションも必要になる場合があります。アプリ関連のサービスもある場合は、コードを通じて多数のインターフェイスを再利用することもできます。効率を高めるために再構築します。

7. ページにどれだけ多くのものが表示されていても、非同期で読み込まれるため心配する必要はありません。

注:

1. 要件会議を開催する場合は、フロントエンドエンジニアとバックエンドエンジニア全員が参加し、インターフェース文書を策定する必要があり、バックエンドエンジニアはテストケースを作成する必要があります。フロントエンド エンジニアをチームのフルタイム テスターとして機能させるには、

chrome プラグイン postman を使用することをお勧めします。また、サービス層のテスト ケースは junit で作成されます。

2. 上記のインターフェイスは Java のインターフェイスではありません。端的に言えば、インターフェイスを呼び出すということは、コントローラー内のメソッドを呼び出すことを意味します。

3. フロントエンド チームの作業負荷を増加させ、バックエンド チームの作業負荷を軽減し、パフォーマンスとスケーラビリティを向上させます。

4. ページのネスト、ページング、ページ ジャンプ制御などの機能を解決するには、いくつかのフロントエンド フレームワークが必要です。 (上記のフロントエンド フレームワーク)。

5. プロジェクトが非常に小さい場合、または単純なイントラネット プロジェクトの場合は、アーキテクチャは必要ないので安心してくださいが、プロジェクトが外部ネットワーク プロジェクトの場合は、ははは。

6. 以前は、Velocity/freemarker などのテンプレート フレームワークを使用して静的ページを生成する人もいましたが、現在ではこの方法は廃止されました。

この記事の主な目的は、大規模な外部 Java Web プロジェクトで jsp が排除されたことを言うことですが、jsp を完全に無視できるとは言いません。関連する Java Web の基本をしっかりと理解する必要がありますが、それ以外の場合、springmvc フレームワークは何に基づいていると思いますか?

以上がなぜJSPは排除されたのですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。