일반적인 웹 서비스의 배포 방식
사용자브라우저<--컴퓨터 통신 영역-->물리적컴퓨터(서버)
-
신호들이 서버로 전달될 때 신호들은 ip 주소를 보고 ip 주소에 해당하는 서버로 신호를 전달해준다.
-
IP : 포트 , 번호로 구성되어 있는데 IP 주소로는 신호를 "어떤 물리적 서버" 에 전달해줄 지, 포트 번호로는 해당 서버에서 "어떤 웹서버"로 신호를 최종적으로 전달해줄 지 판단해줄 수 있다.
-
웹 서버 : HTTP 요청을 받아서 그 요청을 전달하거나, 요청에 맞게 파일을 전달하는 역할
-
따라서 브라우저로부터 온 신호들은 최종적으로 웹 서버들에게 전달이 됨 (ex) APACHE, Nginx
-
그런데 웹 서버에서 또 다른 웹 애플리케이션 서버 , 파일 시스템(어떤 정보를 달라 라고 요청)으로 전달이 될 수도 있다 ...
(+ 웹 서버와 웹 애플리케이션 시스템은 서로 다르다! )
웹 서버 VS 웹 애플리케이션 서버
출처 : 블로그 출처1
출처 : 이미지 ,내용 출처2
웹 서버
(EX : Nginx, APACHE)
- 정적자원의 파일을 웹 클라이언트에게 제공할 때 사용
- 동적인 페이지 처리가 필요하다면 웹 애플리케이션 서버에 요청을 넘김
웹 애플리케이션 서버
(EX : 톰캣 - 호랑이얼굴고양이)
- 웹 서버로부터 요청을 받아서 처리, 결과는 웹 서버로 반환
- 주로 동적인 페이지 생성을 위한 데이터베이스 연동의 작업을 진행
- 웹 애플리케이션 서버는 웹 아카이브 파일들, 어플리케이션 파일들을 열기 위한 서버
- 웹 어플리케이션 서버는 스프링 / 스프링 부트에 접근하여 자신에게 요청된 것을 수행하는 것
- 이때 그냥 SPRING 을 사용했다면 WAR 파일의 형태로 있었을 것이고 / Spring 부트라면 그 자체로..
총 정리
- 하드웨어 서버 - 웹 서버 - (스프링 부트와 같은 웹 어플리케이션 시스템으로 넘겨주기 / 혹은 파일로 넘겨주기)
Java와 Jar
- 스프링 부트 프로젝트를 빌드하면 jar 파일이 나오게 된다
- jar : JAVA ARchive
- JAVA로 작성 후 컴파일 된 JAVA Bytecode와 실행을 위해 필요한 다양한 자원을 배포를 위해 모아놓은 파일의 형태
=> 다른 형태의 압축파일과 같다고 볼 수 있음
Jar 파일 생성해보기
- 플젝 세팅 들어가서 Artifact -> add -> jar 선택 ,
- 사용할 모듈 선택하고 ok
- 해당 모듈에 들어가서 빌드 Artifact
- 아래와 같이 잘 빌드 되었다 뜨면 jar 파일 잘 생성된 것
- jar 파일 확인
- 프로젝트 구조
- JAR 파일 구조
=> jar 은 빌드된 결과물
=> jre 가 있는 환경에서 실행할 수 있도록 해주는 것
- MANIFIEST.MF 자세히 살펴보기
-
위의 MAIN 클래스가 JAR 의 원천이라고 할 수 있음
-
만약 우리가 배포를 하게 되면 이 jar 파일을 서버로 가져다가 / 혹은 이미지로 가져다가 작업을 한다
웹 어플리케이션 구조
1) presentation 레이어 : 사용자와 직접적으로 맞닿는 부분
2) logic 레이어 : 요청을 처리하는 결정 짓는 부분
3) data 레이어 : 데이터의 표현을 저장, 불러오는 부분 (ㄹㅇ 실제 데이터는 아니라는 말)
Spring Boot 프로젝트 구조
1) controller - 디스패처 서버로부터 직접적으로 요청 받음 & 해당 요청을 검증
2) service - 컨트롤러가 검증한 데이터 받아서 사용자의 입력에 따른 데이터 조작을 수행
3) 레포지토리 - 데이터를 받아서 데이터를 저장하고, db로부터 데이터 불러와서 돌려주는 역할 수행 (db는 스프링 부트 외부에 존재!)
(+)
아래 기술한 스프링 구조 내용 , 이미지 출처 블로그 주소
- controller가 모든 요청 받는다
- 주소(URL)에 해당하는 모델 찾아서 기능 수행
- 해당하는 데이터를 보여줄 View를 찾는다.
- (Controller 파일 들어가면 다 명시되어있음)
Model
- DB 작업
- 일반적으로 POJO로 구성된다.
- Java Beans
View
- 사용자가 보는 페이지
- Model data의 렌더링(컨텐츠를 가져와서 구성)을 담당하며, HTML ouput을 생성한다.
- JSP
Controller
- View와 Model 사이의 인터페이스(컨트롤) 역할을 담당한다
- 사용자 요청을 수신하여 그에 따라 적절한 결과를 Model에 담아 View에 전달한다.
- 즉, Model Object와 이 Model을 화면에 출력할 View Name을 반환한다.
- Controller —> Service —> Dao —> DB
- Servlet
DispatcherServlet
Spring Framework가 제공하는 Servlet 클래스
사용자의 요청을 받는다.
Dispatcher가 받은 요청은 HandlerMapping으로 넘어간다.
HandlerMapping
사용자의 요청을 처리할 Controller를 찾는다. (Controller URL Mapping)
요청 url에 해당하는 Controller 정보를 저장하는 table을 가진다.
즉, 클래스에 @RequestMapping(“/url”) annotaion을 명시하면 해당 URL에 대한 요청이 들어왔을 때 table에 저장된 정보에 따라 해당 클래스 또는 메서드에 Mapping한다.
ViewResolver
Controller가 반환한 View Name(the logical names)에 prefix, suffix를 적용하여 View Object(the physical view files)를 반환한다.
예를 들어
view name: home,
prefix: /WEB-INF/views/,
suffix: .jsp는 “/WEB-INF/views/home.jsp”라는 위치의 View(JSP)에 Controller에게 받은 Model을 전달한다.
이 후에 해당 View에서 이 Model data를 이용하여 적절한 페이지를 만들어 사용자에게 보여준다.
장점
Navigation control is centralized - 컨트롤러가 페이지들을 결정하는 모든 로직을 가지고 있다.
유지보수가 쉽다
확장성이 좋다
테스트 하기 용이하다
단점
컨트롤러 코드를 직접 써야 한다. 컨트롤러가 수정되면 다시 컴파일해서 다시 deploy 해야 한다.
final 연결 흐름
하드웨어 서버 - nginx (webserver) - Spring 부트 (톰캣이라는 웹 애플리케이션 서버 내장) - "스프링 부트 내부: 디스패처서버가 request 받고
1) 컨트롤러로 넘기고 서비스로 전달되어서 레포지토리에서 db에서 적절한 정보 꺼내오거나 데이터 저장하고 이를 다시 서비스 -> 컨트롤러에게 response 로 돌려주기
2) 뷰 resolver에게 전달해서 적절한 view를 response 로 돌려주기
