jsp는 왜 없어졌나요?

이전 프로젝트의 대부분은 프론트엔드(ajax/jquery/js/html/css 등)와 백엔드(java/mysql/Oracle 등) 작업을 하는 아버지이자 어머니인 자바 프로그래머들이었습니다.

시대가 발전하면서 많은 대기업, 중소기업, 중소기업이 점차 프론트엔드와 백엔드의 경계를 점점 더 명확하게 구분하기 시작했고, 프론트엔드 엔지니어는 프론트엔드 업무만 담당하게 되었습니다. 백엔드 엔지니어는 백엔드만 담당한다는 말이 있듯이, 그 분야에 전문성이 있는 사람은 뭐든지 다 안다면 결국 아무것도 잘 못하는 사람이다.

추천 과정: Java 튜토리얼.

대기업과 중기업에는 전문가가 필요하고, 중소기업에는 제너럴리스트가 필요하지만 개인의 경력 개발을 위해서는 분리하는 것이 좋습니다. 평생 자바만 먹을 생각이라면 CSS, JS 등은 공부하지 마세요.

Java, JVM 원칙, Spring 원칙, MySQL 잠금, 트랜잭션, 멀티스레딩, 대규모 동시성, 분산 아키텍처, 마이크로서비스 및 관련 프로젝트 관리 등에 에너지를 집중하여 핵심 경쟁력이 점점 더 높아질 것입니다. 속담처럼, 당신이 인생에 투자한 것은 인생이 당신에게 돌려줄 것입니다.

(긍정에너지 가득 :

업계 엘리트가 되면 차, 집, 여자, 돈, 기회 다 찾아올 거라 믿으세요. 걱정하지 마세요, 정말.

정말 간단합니다. 자바 프로그래머가 되려면 더 많은 돈을 벌 수 있습니다. 물론 어느 정도의 감성 지능도 필요합니다.

다른 사람보다 더 많은 가치를 창출합니다. 회사와 회사가 다양한 혜택을 누리는 상생! )

옛날에 우리 자바 웹 프로젝트에서는 springmvc/struts + spring + spring jdbc/hibernate/mybatis 등 여러 백그라운드 프레임워크를 사용했습니다.

대부분의 프로젝트는 Java 백엔드, 제어 계층(컨트롤러/작업), 비즈니스 계층(서비스/관리) 및 지속성 계층(dao)의 세 가지 계층으로 나뉩니다.

컨트롤 레이어는 매개변수 수신, 관련 비즈니스 레이어 호출, 데이터 캡슐화, JSP 페이지로의 라우팅을 담당합니다. 그런 다음 jsp 페이지에서 다양한 태그(jstl/el) 또는 손으로 작성한 java(<%=%>)를 사용하여 배경 데이터를 표시합니다.

그렇죠?

먼저 요구 사항이 결정되고, 코드가 작성되었으며, 테스트가 완료된 상황을 살펴보겠습니다. 출시 예정인가요?

maven 또는 eclipse 및 기타 도구를 사용하여 코드를 war 패키지로 패키징한 다음 이 war 패키지를 프로덕션 환경의 웹 컨테이너(tomcat/jboss/weblogic/websphere/jetty/resin)에 게시해야 합니다. ?

게시 후 웹 컨테이너를 시작하고 서비스 제공을 시작해야 합니다. 이때 도메인 이름, DNS 등을 구성하여 웹사이트에 액세스할 수 있습니다. (웹사이트라고 가정)

한번 볼까요? 프런트엔드와 백엔드 코드가 모두 해당 war 패키지에 포함되어 있나요? js, css, 사진 및 다양한 타사 라이브러리도 포함됩니다. 그렇죠?

알겠습니다. 웹사이트 도메인 이름(www.xxx.com)을 브라우저에 입력하세요. 그 다음에는 어떻게 되나요? (이 질문은 많은 회사의 면접 질문이기도 합니다)

방금 뽑아서 말씀드리자면, 기초가 좋지 않다면 어린이 신발을 직접 검색해 보세요.

브라우저는 tcp 3-way handshake 이후에 tcp 프로토콜을 통해 웹 서버에 액세스하기 시작하고, 서비스 제공을 시작하고, 요청을 받습니다. 응답을 통해 귀하에게 반환됩니다.

먼저 홈페이지에 100장의 사진이 있고 단일 테이블 쿼리가 있다고 가정해 보겠습니다. 이때 사용자의 겉보기에 하나의 http 요청은 실제로는 하나가 아닙니다. 브라우저에 캐시가 없어야 합니다. 100개의 사진에 대해 브라우저는 100개의 http 요청을 연속적으로 요청합니다(누군가가 길고 짧은 http 링크 문제에 대해 알려줄 것입니다. 이에 대해서는 여기서 논의하지 않습니다). 요청에는 TCP 전송을 위한 소켓을 생성하는 데 메모리가 필요합니다.

여기서 중요한 점은 페이지의 모든 요청이 서버에만 요청되기 때문에 웹 서버에 대한 부담이 매우 높다는 것입니다. 단 한 명이라면 10,000명이 액세스하면 어떨까요? (먼저 웹 서버 클러스터에 대해 이야기하지 않고 여기서는 단일 인스턴스 웹 서버에 대해 이야기하겠습니다.) 서버가 처리할 수 있는 TCP 링크는 몇 개입니까? 서버의 메모리 용량은 얼마나 됩니까? 얼마나 많은 IO를 견딜 수 있습니까? 웹 서버에 얼마나 많은 메모리를 할당했습니까? 다운될까요?

이것이 대형 및 중형 웹 애플리케이션일수록 분리가 필요한 이유입니다.

이론적으로는 데이터베이스 + 애플리케이션 서비스 + 메시지 큐 + 캐시 + 사용자 업로드 파일 + 로그 + 등을 하나의 호스트에 담을 수 있지만 이는 계란을 한 바구니에 담는 것과 같아서 숨겨진 위험이 매우 큽니다.

일반 분산 아키텍처는 애플리케이션 서버 클러스터(전면, 후면) + 파일 서버 클러스터 + 데이터베이스 서버 클러스터 + 메시지 큐 클러스터 + 캐시 클러스터 등을 분해해야 합니다.

우선, 향후 Java 웹 프로젝트에서는 jsp를 사용하지 않도록 노력해야 합니다. 프런트엔드와 백엔드를 분리하고 분산 아키텍처를 사용하여 애플리케이션 아키텍처를 더욱 강력하게 만들어야 합니다.

jsp 사용 시 문제점:

1. 동적 리소스와 정적 리소스는 모두 함께 결합되며 진정한 동적 및 정적 분리는 달성될 수 없습니다. 서버는 CSS http 요청, js 요청, 사진, 동적 코드 등과 같은 다양한 http 요청을 받기 때문에 큰 압력을 받고 있습니다. 서버에 문제가 발생하면 프런트엔드와 백엔드가 함께 플레이되며 사용자 경험이 극도로 저하됩니다.

2. 프론트엔드 엔지니어가 html을 완성한 후, 자바 엔지니어는 html을 jsp 페이지로 수정해야 합니다(종종 js 코드가 많기 때문입니다). 페이지), 문제를 수정해야 하며, 양측의 공동 개발은 비효율적입니다.

3.jsp는 Java(Tomcat 등)를 지원하는 웹서버에서 실행되어야 하며, nginx는 사용할 수 없습니다(nginx는 최대 5w의 단일 인스턴스 http 동시성을 갖는다고 합니다) , 이 장점을 활용해야 함), 성능 개선은 나오지 않습니다.

4. 처음 jsp를 요청하는 경우 웹 서버에서 서블릿으로 컴파일해야 하며 첫 번째 실행 속도가 느려집니다.

5. jsp를 요청할 때마다 서블릿에 액세스한 다음 출력 스트림을 사용하여 html 페이지를 출력하는데 이는 html을 직접 사용하는 것만큼 효율적이지 않습니다.

6.jsp에는 많은 태그와 표현이 포함되어 있어 페이지를 수정할 때 프론트엔드 엔지니어들이 많은 어려움을 겪게 됩니다.

7.jsp에 컨텐츠가 많으면 동기적으로 로드되기 때문에 페이지 응답이 매우 느려집니다.

위의 문제점 중 일부를 기반으로 프론트엔드와 백엔드의 진정한 디커플링을 달성하려면 전체 프로젝트의 개발 비중을 앞으로 옮겨야 합니다!

기존 방식은 다음과 같습니다.

1. 클라이언트 요청
2 서버 측 서블릿 또는 컨트롤러가 요청을 받습니다(라우팅 규칙은 백엔드에 의해 공식화됨). 그리고 전체 프로젝트의 대부분의 무게는 백엔드에 있습니다)
3. 서비스 호출, 비즈니스 로직 완성을 위한 dao 코드
4. jsp 반환
5.jsp는 일부 동적 코드를 표시합니다. 🎜🎜##🎜🎜 #새로운 방법은 다음과 같습니다.

1. 브라우저가 요청을 보냅니다.

2. 라우팅 규칙은 프런트 엔드에서 공식화됩니다. 전체 프로젝트 개발의 비중이 앞으로 이동합니다.)

3 .html 페이지는 서버 인터페이스를 호출하여 ajax 등을 통해 데이터를 생성하는 역할을 담당합니다.
4 동적 효과를 표시하려면 html을 입력합니다.

(관심 있는 아이들은 알리바바 같은 대형 웹사이트에 접속한 후 F12를 눌러 페이지 새로 고침 시 http가 어떻게 작동하는지 모니터링할 수 있습니다. 대부분은 별도로 배경 데이터를 요청합니다. , 대신 json을 사용하여 데이터를 전송합니다. 동적 + 정적을 포함하여 전체 페이지를 반환하기 위한 크고 포괄적인 http 요청)

이것의 이점은 다음과 같습니다.

1 실제 프런트엔드 및 백엔드 분리가 가능합니다. 달성할 수 있으며 프런트엔드 서버는 nginx를 사용합니다.

프런트엔드 서버는 CSS, JS, 그림 등과 같은 일련의 정적 리소스를 배치합니다. (CSS, JS, 그림 및 기타 리소스를 다음과 같은 특정 파일 서버에 넣을 수도 있습니다.) Alibaba Cloud의 oss 및 cdn 가속 사용), 프런트 엔드 서버는 페이지 참조, 점프 및 백엔드 인터페이스 호출을 담당합니다. 백엔드 서버는 tomcat을 사용합니다.

(nodejs, React, Router, React, redux, webpack과 같은 일부 프런트엔드 엔지니어링 프레임워크를 사용해야 함)

2. 문제는 서로 공놀이가 없다는 것입니다.

페이지 로직, 점프 오류, 브라우저 호환성 문제, 스크립트 오류, 페이지 스타일 및 기타 문제는 모두 프런트엔드 엔지니어가 처리합니다.

인터페이스 데이터 오류, 데이터가 성공적으로 제출되지 않음, 응답 시간 초과 및 기타 문제는 모두 백엔드 엔지니어가 해결합니다.

두 당사자는 서로 간섭하지 않습니다. 프런트엔드와 백엔드는 서로 사랑하는 가족입니다.

3. 대규모 동시성의 경우 프런트엔드 서버와 백엔드 서버를 동시에 수평으로 확장할 수 있습니다. 예를 들어 Taobao의 홈페이지에는 2,000개의 프런트엔드 서버가 필요합니다. 일 평균 수억 PV를 견딜 수 있도록 클러스터링되었습니다.

(Alibaba의 기술 서밋에 가서 모든 웹 컨테이너를 직접 작성했다고 들었습니다. 단일 인스턴스가 100,000 http 동시성을 견딜 수 있다고 해도 2,000개 유닛은 2억 http 동시성을 지원할 수 있으며, 또한 무섭습니다. 홈페이지 하나만이라도.)

4. 백엔드 서버의 동시성 부담을 줄이고, 인터페이스를 제외한 모든 http 요청을 프론트엔드 nginx.

5. 백엔드 서비스가 일시적으로 중단되거나 다운되어도 프런트엔드 페이지에는 정상적으로 접속은 되지만 데이터를 새로고침할 수는 없습니다.

6. 인터페이스를 공유하려면 WeChat 관련 조명 애플리케이션도 필요할 수 있습니다. 앱 관련 서비스가 있는 경우 일부 코드를 통해 많은 수의 인터페이스를 재사용할 수도 있습니다. 재건, 효율성을 향상시킵니다.

7. 페이지에 아무리 많은 내용이 표시되어도 비동기적으로 로드되기 때문에 걱정이 없습니다.

참고:

1 요구사항 회의를 개최할 때는 프런트엔드 및 백엔드 엔지니어가 모두 참여해야 하며, 인터페이스 문서가 작성되어야 하며, 백엔드 엔지니어는 테스트 케이스를 작성해야 합니다. 프론트엔드 엔지니어가 팀의 전담 테스터 역할을 하도록 하지 마세요.

chrome의 플러그인 우편 배달부를 사용하고 테스트 케이스를 작성하려면 junit을 사용하는 것이 좋습니다. 서비스 계층.

2. 위의 인터페이스는 Java의 인터페이스가 아닙니다. 직설적으로 말하면 인터페이스를 호출한다는 것은 컨트롤러에서 메서드를 호출하는 것을 의미합니다.

3. 프론트엔드 팀의 작업량을 늘리고, 백엔드 팀의 작업량을 줄이며, 성능과 확장성을 향상시킵니다.

4. 페이지 중첩, 페이징, 페이지 점프 제어 등과 같은 기능을 해결하려면 프런트엔드 프레임워크가 필요합니다. (위에서 언급한 프런트엔드 프레임워크)

5. 프로젝트가 작거나 간단한 인트라넷 프로젝트라면 아무런 아키텍처도 필요하지 않으니 안심하셔도 되지만, 프로젝트가 외부 네트워크 프로젝트라면 하하하.

6. 과거에는 일부 사람들이 Velocity/freemarker와 같은 템플릿 프레임워크를 사용하여 정적 페이지를 생성했지만 이제는 이러한 관행도 제거되었습니다.

이 글의 주된 목적은 대규모 외부 자바 웹 프로젝트에서 jsp가 없어졌다는 것을 말하는 것이지만, 일부 학생 친구들에게는 jsp/servlet의 기본과 jsp가 완전히 무시될 수 있다는 뜻은 아닙니다. 다른 관련 Java 웹은 아직 확실히 파악해야 합니다. 그렇지 않으면 springmvc 프레임워크가 무엇을 기반으로 한다고 생각하시나요?

위 내용은 jsp는 왜 없어졌나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!