Pourquoi jsp a-t-il été éliminé ?

La plupart des projets précédents étaient des programmeurs Java qui étaient à la fois père et mère, travaillant sur le front-end (ajax/jquery/js/html/css, etc.) et le back-end (java/mysql/Oracle, etc. ) .

Avec l'évolution des temps, de nombreuses grandes, moyennes et petites entreprises ont progressivement commencé à distinguer de plus en plus clairement les frontières entre le front-end et le back-end. Les ingénieurs front-end ne sont responsables que du front-end. les choses finales, et les ingénieurs back-end ne sont responsables que des choses back-end. Comme le dit le proverbe, il y a des spécialisations, si une personne sait tout, alors elle n'est bonne en rien après tout.

Cours recommandé : Tutoriel Java.

Les grandes et moyennes entreprises ont besoin de professionnels, et les petites entreprises ont besoin de généralistes, mais pour le développement de carrière personnel, je suggère de les séparer. Si vous comptez simplement manger Java pour le reste de votre vie, n’étudiez pas CSS, JS, etc.

Concentrez votre énergie sur Java, les principes JVM, les principes Spring, les verrous MySQL, les transactions, le multi-threading, la grande concurrence, l'architecture distribuée, les microservices et la gestion de projet associée, etc., afin que votre compétitivité de base devienne de plus en plus haut, comme le dit le proverbe, ce que vous investissez dans la vie sera ce que la vie vous rendra.

(Plein d'énergie positive :

Une fois que vous serez devenu une élite dans une industrie, croyez-moi, le moment venu, les voitures, les maisons, les femmes, l'argent et les opportunités viendront tous à vous . , ne vous inquiétez pas, vraiment.

C'est très simple d'être un programmeur Java. Plus vous avez de connaissances, plus vous gagnerez d'argent. Bien sûr, vous devez aussi avoir une certaine dose d'émotion. intelligence.

Plus votre capacité est forte, plus vous créez de valeur que les autres. Vous créez de la valeur pour l'entreprise, et l'entreprise vous offre divers avantages, une situation gagnant-gagnant )

Une fois ! il était une fois, nos projets Web Java utilisaient plusieurs frameworks backend, springmvc/struts + spring + spring jdbc/hibernate/mybatis, etc.

La plupart des projets sont divisés en trois couches dans le backend Java, la couche de contrôle ( contrôleur/action), couche métier (service/gestion), couche persistance (dao).

La couche de contrôle est responsable de la réception des paramètres, de l'appel des couches métier pertinentes, de l'encapsulation des données et du routage vers les pages jsp. Utilisez ensuite diverses balises (jstl/el) ou java manuscrites (<%=%>) sur la page jsp pour afficher les données d'arrière-plan.

N'est-ce pas ?

Regardons d'abord cette situation. Les exigences ont été déterminées, le code a été écrit et les tests ont été terminés. Est-il sur le point de sortir ?

Vous devez utiliser Maven ou Eclipse et d'autres outils pour empaqueter votre code dans un package war, puis publier ce package war dans le conteneur Web de votre environnement de production (tomcat/jboss/weblogic/websphere/jetty/ résine), non ?

Après la publication, vous devez démarrer votre conteneur Web et commencer à fournir des services. À ce stade, vous pouvez accéder à votre site Web en configurant le nom de domaine, le DNS, etc. (en supposant que vous soyez un site Web).

Voyons voir, tous vos codes front-end et back-end sont-ils dans ce package de guerre ? Y compris vos js, css, images et diverses bibliothèques tierces, n'est-ce pas ?

D'accord, entrons le nom de domaine de votre site Web (www.xxx.com) dans le navigateur. Que se passe-t-il après cela ? (Cette question est aussi une question d'entretien dans de nombreuses entreprises)

Je viens de le dire, si vous n'avez pas de bonnes bases, veuillez rechercher vous-même des chaussures pour enfants.

Le navigateur accède à votre service via IP. Après la négociation à trois voies TCP, il commence à accéder à votre serveur Web via le protocole TCP. Une fois que votre serveur Web a reçu la demande, il commence à fournir des services et reçoit la demande. request, puis transmet la réponse, renvoie votre réponse au navigateur.

Alors jetons un coup d'œil. Supposons d'abord que votre page d'accueil contient 100 images et une seule requête de table. À ce stade, la requête http apparemment unique de l'utilisateur n'en est en fait pas une. il n'y aura pas de cache dans le navigateur. Pour vos 100 images, le navigateur demandera successivement 100 requêtes http (quelqu'un me parlera du problème des liens http longs et courts, qui ne sera pas abordé ici). Le serveur reçoit ces requêtes, il doit consommer de la mémoire pour créer un socket pour la transmission TCP.

Voici le point important. Dans ce cas, la pression sur votre serveur web sera très forte, car toutes les requêtes de la page ne sont demandées qu'à votre serveur. S'il n'y a qu'une seule personne, ce sera le cas. très bien s'il y a 10 000 personnes simultanément. Quant à l'accès (ne parlons pas des clusters de serveurs Web, parlons des serveurs Web à instance unique), combien de liens TCP votre serveur peut-il gérer ? De combien de mémoire dispose votre serveur ? À combien d’IO pouvez-vous résister ? Quelle quantité de mémoire avez-vous allouée au serveur Web ? Est-ce que ce sera en baisse ?

C'est pourquoi, plus les applications web sont grandes et moyennes, plus elles doivent être découplées.

En théorie, vous pouvez placer votre base de données + service d'application + file d'attente de messages + cache + fichiers téléchargés par l'utilisateur + journaux + etc. sur un seul hôte, mais c'est comme mettre tous vos œufs dans un panier, les dangers cachés sont. énorme.

L'architecture distribuée normale doit être démontée, votre cluster de serveur d'applications (avant, arrière) + cluster de serveur de fichiers + cluster de serveur de base de données + cluster de file d'attente de messages + cluster de cache, etc.

Passons aux choses sérieuses. Tout d'abord, nous devrions essayer d'éviter d'utiliser jsp dans les futurs projets Web Java. Nous devrions découpler le front et le backend et jouer avec l'architecture distribuée, afin que notre architecture d'application soit plus forte.

Plaisirs liés à l'utilisation de jsp :

1. Les ressources dynamiques et les ressources statiques sont toutes couplées, et une véritable séparation dynamique et statique ne peut pas être réalisée. Le serveur est soumis à une forte pression car il recevra diverses requêtes http, telles que des requêtes http css, js, des images, des codes dynamiques, etc. Une fois qu'il y a un problème avec le serveur, le front-end et le backend seront joués ensemble et l'expérience utilisateur sera extrêmement mauvaise.

2. Une fois que l'ingénieur front-end a terminé le code HTML, l'ingénieur Java doit modifier le code HTML en une page jsp. Le taux d'erreur est élevé (car il y a souvent un grand nombre de codes js dans la page). ), et les deux parties doivent collaborer pour modifier le problème. Développement, inefficacité.

3.jsp doit être exécuté sur un serveur Web prenant en charge Java (comme Tomcat, etc.), et nginx ne peut pas être utilisé (nginx aurait jusqu'à 50 000 accès simultanés http à instance unique, cet avantage doit être utilisé), et les performances ne peuvent pas être améliorées.

4. La première fois que vous demandez jsp, il doit être compilé dans un servlet sur le serveur Web. La première exécution sera plus lente.

5. Chaque fois que vous demandez jsp, vous accédez au servlet puis utilisez le flux de sortie pour afficher la page HTML, ce qui n'est pas aussi efficace que d'utiliser directement le HTML.

Il existe de nombreuses balises et expressions dans 6.jsp. Les ingénieurs front-end seront étirés lors de la modification de la page et rencontreront de nombreux problèmes.

7. S'il y a beaucoup de contenu dans jsp, la réponse de la page sera très lente car elle est chargée de manière synchrone.

Sur la base de certains des points faibles ci-dessus, nous devrions faire avancer le poids du développement de l'ensemble du projet pour parvenir à un véritable découplage du front-end et du back-end !

L'ancienne méthode était la suivante :

1. Demande du client
2. Le servlet ou le contrôleur côté serveur reçoit la demande (les règles de routage sont formulées par le backend, et la majeure partie du poids de celle-ci est générée). tout le développement du projet dans le backend)
3. Appelez le service et le code dao pour compléter la logique métier
4 Retour jsp
5.jsp affiche du code dynamique

La nouvelle méthode est :

1. Le navigateur envoie une requête
2. Atteint directement la page html (les règles de routage sont formulées par le front-end, et le poids de l'ensemble du développement du projet est avancé)
3. La page html est chargée d'appeler l'interface du serveur pour générer des données (via ajax, etc. etc.)
4. Remplissez le html pour afficher les effets dynamiques.

(Les enfants intéressés peuvent visiter de grands sites Web tels que Alibaba, puis appuyer sur F12 pour surveiller le fonctionnement de http lorsque vous actualisez la page. La plupart d'entre eux demandent des données d'arrière-plan séparément. Utilisez JSON pour transmettre des données au lieu d'un fichier volumineux et complet. requête http pour renvoyer la page entière y compris dynamique + statique)

Les avantages de ceci sont :

1 De vrais front-end et back-end peuvent être réalisés Découplés, le serveur front-end. utilise nginx.

Le serveur frontal place une série de ressources statiques telles que CSS, JS, images, etc. (Vous pouvez même placer des CSS, JS, images et autres ressources dans un serveur de fichiers spécifique, tel que celui d'Alibaba Cloud. oss et utilise l'accélération cdn), le serveur frontal est responsable du contrôle des références de page, des sauts et de l'appel des interfaces back-end. Le serveur back-end utilise tomcat.

(Vous devez utiliser certains frameworks d'ingénierie front-end tels que nodejs, React, Router, React, Redux, Webpack)

Si vous trouvez un bug, vous pouvez rapidement localiser le. problème. Non Il y a un phénomène de frappe dans le ballon.

La logique des pages, les erreurs de saut, les problèmes de compatibilité du navigateur, les erreurs de script, les styles de page et d'autres problèmes sont tous traités par les ingénieurs front-end.

Les erreurs de données d'interface, les données non soumises avec succès, le délai de réponse et d'autres problèmes sont tous résolus par les ingénieurs back-end.

Les deux parties n'interfèrent pas l'une avec l'autre. Le front-end et le back-end forment une famille qui s'aime.

3. Dans le cas d'une grande concurrence, je peux étendre horizontalement les serveurs front-end et back-end en même temps. Par exemple, une page d'accueil de Taobao nécessite de regrouper 2 000 serveurs front-end. résister au PV quotidien moyen de centaines de millions+.

(Je suis allé au sommet technologique d'Alibaba et j'ai entendu dire qu'ils avaient écrit eux-mêmes tous leurs conteneurs Web. Même si une seule instance peut supporter 100 000 accès simultanés http, 2 000 unités peuvent gérer 200 millions d'accès simultanés http, et elles peuvent également utiliser It's effrayant de prédire qu'il y aura une expansion illimitée. . )

4. Réduisez la pression de concurrence sur le serveur back-end et transférez toutes les requêtes http sauf l'interface vers le nginx front-end.

5. Même si le service back-end expire temporairement ou est en panne, la page front-end sera toujours accessible normalement, mais les données ne seront pas actualisées.

6. Peut-être avez-vous également besoin d'une application légère liée à WeChat, afin que vos interfaces puissent être partagées. S'il existe également des services liés aux applications, vous pouvez également réutiliser un grand nombre d'interfaces via du code. reconstruction pour améliorer l’efficacité.

7. Peu importe le nombre de choses affichées sur la page, vous n'avez pas peur car elle est chargée de manière asynchrone.

Remarque :

1. Lors de la tenue d'une réunion d'exigences, tous les ingénieurs front-end et back-end doivent participer, et les documents d'interface doivent être formulés. et ne laissez pas les ingénieurs front-end Servir de test à temps plein à votre équipe, il est recommandé d'utiliser

postman du plug-in chrome, et les cas de test de la couche de service sont écrits en junit.

2. L'interface ci-dessus n'est pas l'interface de Java. Pour parler franchement, appeler l'interface signifie appeler la méthode dans votre contrôleur.

3. Augmente la charge de travail de l'équipe front-end, réduit la charge de travail de l'équipe back-end et améliore les performances et l'évolutivité.

4. Nous avons besoin de frameworks front-end pour résoudre des fonctions telles que l'imbrication de pages, la pagination, le contrôle des sauts de page, etc. (Ces frameworks front-end mentionnés ci-dessus).

5. Si votre projet est petit, ou un simple projet intranet, alors vous pouvez être assuré qu'il ne nécessite aucune architecture, mais si votre projet est un projet de réseau externe, hahaha.

6. Dans le passé, certaines personnes utilisaient des frameworks de modèles tels que Velocity/Freemarker pour générer des pages statiques, mais maintenant cette pratique a également été éliminée.

L'objectif principal de cet article est de dire que jsp a été éliminé dans les projets Web Java externes à grande échelle, mais il ne dit pas que jsp peut être complètement ignoré. Pour certains amis étudiants, jsp. /servlet, etc. Les bases du Web Java pertinentes doivent encore être bien maîtrisées. Sinon, sur quoi pensez-vous que le framework springmvc est basé ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!