1. 일반적인 웹 서비스의 배포 구조
사용자 브라우저 주소창에 주소를 넣으면 주소에 해당하는 컴퓨터로 요청이 가고 요청받은 컴퓨터에서 웹 페이지를 돌려준다.
도메인을 통해 요청이 들어오면 요청의 신호는 apache서버, nginx 등과 같은 웹 서버로 신호가 들어온다.
ip 콜론 뒤에 붙은 포트번호를 통해 컴퓨터 내부에 있는 프로세스에 접근하게 된다.
포트번호를 보고 웹서버 (apache서버, nginx) 로 들어왔다. 요청이 들어오면 폴더에 있는 파일을 돌려주는 것과 같은 설정을 할 수 있고 또는 그 요청을 다른 Web Aplication Server로 전달하는 설정을 해주기도 한다. Web Aplication Server (톰캣) 에서 Web Aplication인 스프링 부트를 사용한다.
2. java와 jar
스프링 부트 프로젝트를 빌드하면 jar파일이 나온다.
JAR = Java Archive
java로 작성 후 컴파일된 java Bytecode와 실행을 위해 필요한 다양한 자원을 배포를 위하여 모아놓은 파일의 형태 => 다른 형태의 압축 파일!
프로젝트 구조와 jar 파일의 구조는 유사하다.
즉 스프링부트 프로젝트를 배포한다고 하면 jar파일을 서버로 가져가서 실행한다 혹은 도커 이미지로 만들어서 실행을 한다고 볼 수 있다.
3. Web Application 구조
- 스프링부트의 구조
-Dispatcher Servlet : 프레임워크 내부에 구현되어 있는 부분 (우리가 구현하지 않는다.)
-Controller : Dispatcher Servlet의 요청을 직접적으로 받는 요청을 한다. class의 형태로 정의를 한다.
-Service : Controller가 검증해낸 요청을 받아서 사용자의 입력에 따른 데이터의 조작을 결정하는 부분이다. class의 형태로 정의를 한다.
-Repository : 데이터의 표현을 받아서 실제 데이터를 저장하고 데이터의 표현을 불러와서 데이터를 돌려주는 역할을 한다.
데이터 전달 과정
요청 -> Dispatcher Servlet에서 어떤 Controller에 요청을 보낼지 결정 -> Controller에서 요청에 대한 검증을 하고 Service에 요청을 보내준다. -> Service는 상황에 따라 데이터 조작을 위해 Repository에 요청을 한다. -> Repository는 외부에 있는 데이터베이스와 소통해서 데이터 표현의 일부를 받아온다. -> 진행 반대 순서롤 진행된 후 Dispatcher Servlet에서 응답을 한다.
※전체적인 구조
