🖥️ 백엔드/스프링

[스프링] 스프링 부트 개념 정리

케로⸝⸝◜࿀◝ ⸝⸝ 2024. 5. 30. 17:06

[지금 무료] 스프링부트 개념정리(이론) | 최주호 - 인프런

최주호 | 스프링부트를 공부하며 헷갈리는 개념이 많았던 분 스프링부트에 대해 공부하고 싶었던 모든 분, 스프링부트의 핵심은확실한 개념으로부터! 스프링부트 너무 어려운데 어떻게 시작하

www.inflearn.com

1. 스프링이란?

  • 스프링은 프레임워크이다.
  • 스프링은 오픈소스이다.
  • 스프링은 IoC 컨테이너를 가진다.
  • 스프링 DI를 지원한다.
  • 스프링은 엄청나게 많은 필터를 가지고 있다.
  • 스프링은 엄청나게 많은 애노테이션을 가지고 있다. (리플렉션, 컴파일체킹)
  • 스프링은 MessageConverter를 가지고 있다. 기본값은 현재 JSON이다.
  • 스프링은 BufferedReader와 BufferedWriter를 쉽게 사용할 수 있다.
  • 스프링은 계속 발전 중이다.

[스프링] 스프링 부트와 스프링의 중요 컨셉

스프링 부트스프링 부트는 스프링 프레임워크를 더 쉽고 빠르게 이용할 수 있도록 만들어주는 도구로, 개발자가 조금 더 비즈니스 로직 개발에만 집중할 수 있도록 해줌!톰캣, 제티, 언더토우

progfrog.tistory.com

자바 리플렉션 (Reflection) 기초

리플렉션 (Reflection) JVM은 클래스 정보를 클래스 로더를 통해 읽어와서 해당 정보를 JVM 메모리에 저장한다. 그렇게 저장된 클래스에 대한 정보가 마치 거울에 투영된 모습과 닮아있어, 리플렉션

hudi.blog

 

2. JPA란

  • JPA는 Java Persistence* API이다.
  • JPA는 ORM 기술이다.
  • JPA는 반복적인 CRUD 작업을 생략하게 해 준다.
  • JPA는 영속성 컨텍스트*를 가지고 있다.
  • JPA는 DB와 OOP의 불일치성을 해결하기 위한 방법론을 제공한다. (DB는 객체 저장 불가능)
  • JPA는 OOP 관점에서 모델링을 할 수 있게 해 준다. (상속, 컴포지션*, 연관관계)
  • 방언(dialect) 처리가 용이하며, 마이그레이션 & 유지보수에 좋다.
  • JPA는 쉽지만 어렵다ㅋㅋㅋ...

* 영속성(persistence)
데이터를 메모리에서 영구적으로 저장 매체(ex. 데이터베이스, 파일 등)에 저장하여 애플리케이션이 종료되거나 시스템이 재부팅된 후에도 데이터를 유지할 수 있게 하는 개념
 
[영속성의 기본 개념]
1. 데이터 저장: 데이터를 데이터베이스와 같은 영구 저장소에 저장
2. 데이터 조회: 저장된 데이터를 필요할 때 다시 조회할 수 있음
3. 데이터 수정: 저장된 데이터를 수정할 수 있음
4. 데이터 삭제: 저장된 데이터를 삭제할 수 있음
 
* 컨텍스트(context)
컨텍스트란 그 대상의 모든 정보를 가지고 있는 것

 
* 컴포지션

[Java] 상속(inheritance)과 컴포지션(composition)에 대해서

느슨하게 결합된 코드는 더 많은 유연셩을 제공하기 때문에 상속보다는 컴포지션을 사용하는 것을 권장함. effective java에서도 상속보다는 컴포지션을 사용하기를 권장한다.(item 18) 하지만 권장

velog.io

 

3. 톰캣이란?

웹 서버란?

  • Web Server
  • HTTP 기반으로 동작
  • 정적 리소스 제공, 기타 부가기능
  • 정적(파일) HTML, CSS, JS, 이미지, 영상
  • ex) Nginx, 아파치

 

웹 애플리케이션 서버란?

  • Web Application Server, WAS
  • HTTP 기반으로 동작
  • 웹 서버의 기능을 포힘 + (정적 리소스 제공 가능)
  • 프로그램 코드를 실행해서 애플리케이션 로직을 수행
    • 동적 HTML, HTML API(JSON)
    • 서블릿, JSP, 스프링 MVC
  • ex) 톰캣, 제티, 언더토우

 

웹 서버 vs. 웹 애플리케이션 서버

  • 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직
  • 사실 둘의 용어도, 경계도 모호함...
    • 웹 서버도 프로그램을 실행하는 기능을 포함하기도 함
    • 웹 애플리케이션 서버도 웹 서버의 기능을 제공함
  • 자바는 서블릿 컨테이너 기능을 제공하면  WAS
    • 근데 서블릿 없이 자바 코드를 실행하는 서버 프레임워크도 존재...
  • WAS는 애플리케이션 코드를 실행하는 데 더 특화

 

4. 서블릿 컨테이너

https://siliconvalleygazette.com/posts/different-containers-available-in-servlet.png
  • 서블릿 컨테이너는 Java EE(Enterprise Edition) 애플리케이션 서버의 일부
  • Java 서블릿(Servlet)을 실행하고 관리하는 역할을 함
  • 서블릿은 서버 측에서 실행되는 Java 프로그램으로, 주로 웹 요청을 처리하는 데 사용
  • 서블릿을 지원하는 WAS가 서블릿 컨테이너
  • 서블릿 객체 생성, 초기화, 호출, 종료하는 생명주기를 관리

 

서블릿 컨테이너와 DispatcherServlet의 관계

1. 배포 및 초기화

  • 서블릿 컨테이너는 웹 애플리케이션을 배포하고, web.xml 파일이나 애노테이션을 통해 서블릿 설정을 읽음
  • DispatcherServlet은 일반 서블릿처럼 서블릿 컨테이너에 의해 초기화
  • web.xml 파일이나 스프링의 Java Config를 통해 서블릿 컨테이너에 등록

 

2. 요청 처리 흐름

  • 클라이언트가 HTTP 요청을 보내면, 서블릿 컨테이너가 이 요청을 받음
  • 서블릿 컨테이너는 요청 URL에 따라 적절한 서블릿에 요청을 전달
    • 스프링 애플리케이션에서는 이 서블릿이 DispatcherServlet!!
  • DispatcherServlet은 요청을 받아 핸들러 매핑을 통해 적절한 컨트롤러를 찾고, 해당 컨트롤러 메서드를 실행
  • 컨트롤러 메서드는 비즈니스 로직을 처리한 후, 결과를 뷰 이름과 함께 DispatcherServlet에 반환
  • DispatcherServlet은 뷰 리졸버를 통해 논리적인 뷰 이름을 실제 뷰로 변환하고, 최종 HTML 등의 응답을 생성하여 서블릿 컨테이너에 반환
  • 서블릿 컨테이너는 이 응답을 클라이언트에 전달
<!-- web.xml -->
<servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>
  • 위의 web.xml 설정 예시에서 서블릿 컨테이너는 DispatcherServlet을 / 경로로 매핑하여 모든 요청을 이 서블릿이 처리하도록

결론적으로, 서블릿 컨테이너는 Java 웹 애플리케이션의 기본 인프라를 제공하고 DispatcherServlet은 스프링 MVC 애플리케이션의 프론트 컨트롤러로서 요청을 처리하는 역할을 함. 서블릿 컨테이너는 DispatcherServlet을 초기화하고, DispatcherServlet은 적절한 컨트롤러에 요청을 전달하여 응답을 생성함!!!
 

주요 기능

1. 서블릿 생명 주기 관리

  • 로딩 및 인스턴스화: 서블릿 컨테이너는 서블릿 클래스가 처음 요청될 때 해당 클래스를 로드하고 인스턴스를 생성
  • 초기화: 서블릿 인스턴스가 생성된 후, 컨테이너는 `init()`을 호출하여 서블릿을 초기화
  • 서비스: 클라이언트 요청이 들어오면, 서블릿 컨테이너는 `service()`를 호출하여 요청을 처리하고 응답을 생성
  • 소멸:  서블릿이 더 이상 필요 없거나 컨테이너가 종료될 때 `destroy()`를 호출하여 서블릿을 소멸시킴

2. 요청 및 응답 처리

  • 서블릿 컨테이너는 HTTP 요청을 받아 적절한 서블릿에 전달하고, 서블릿이 생성한 응답을 클라이언트에게 반환
  • 요청/응답 객체(HttpServletRequest, HttpServletResponse)를 생성하고 서블릿에 전달하여 클라이언트와 서버 간의 통신을 처리

 

3. 쓰레드 관리

  • 서블릿 컨테이너는 여러 클라이언트 요청을 동시에 처리하기 위해 요청마다 새로운 쓰레드를 생성하거나 쓰레드 풀을 관리
  • 이를 통해 동시성 문제를 해결하고 성능을 최적화함
https://velog.io/@jihoson94/Servlet-Container-%EC%A0%95%EB%A6%AC

4. 보안 관리

  • 인증 및 권한 부여: 서블릿 컨테이너는 보안 설정을 통해 사용자의 인증 및 권한 부여를 처리
  • SSL/TLS 지원: 안전한 통신을 위해 SSL/TLS 암호화를 지원

 

5. 세션 관리

  • 서블릿 컨테이너는 클라이언트 세션을 관리하여 상태 정보를 유지할 수 있게 함
  • 이를 통해 사용자는 서버와의 여러 요청 간에 상태를 유지할 수 있음

 

6. 애플리케이션 배포 및 관리

  • 서블릿 컨테이너는 WAR(Web Application Archive) 파일 형태로 웹 애플리케이션을 배포하고 관리할 수 있음
  • 배포된 애플리케이션의 설정을 읽고, 서블릿 매핑 및  초기화 매개변수 등을 관리

 

5. 웹 배포서술자(web.xml)

  • ServletContext의 초기 파라미터
  • Session의 유효시간 설정
  • Servlet/JSP에 대한 정의
  • Servlet/JSP 매핑
  • Mime Type 매핑
  • Welcome File list
  • Error Pages 처리
  • 리스터/필터 설정
  • 보안

 
여기에서 Servlet/JSP 매핑 시(web.xml에 직접 매핑 or @WebServlet 애노테이션 사용)에 모든 클래스에 매핑을 적용시키기에는 코드가 너무 복잡해지기 때문에 FrontController 패턴을 이용
 

6. FrontController 패턴

최초 앞단에서 request 요청을 받아서 필요한 클래스에 넘겨준다. 왜? web.xml에 다 정의하기가 너무 힘듦ㅠㅠ
이때 새로운 요청이 생기기 때문에, request와 response가 새롭게 new 될 수 있다. 그래서 아래의 RequestDispatcher가 필요하다.
 

7. RequestDispatcher

필요한 클래스 요청이 도달했을 때 FrontController에 도착한 request와 response를 그대로 유지시켜 준다.
 

8. DispatcherServlet

FrontController 패턴을 직접 짜거나, RequesstDispatcher를 직접 구현할 필요가 없다.
DispatcherServlet = FrontController + RequestDispatcher
 
DispatcherServlet이 자동 생성되어질 때 수많은 객체가 생성(IoC)된다.
보통 필터들인데, 기본적으로 필요한 필터들은 자동 등록되고 직접 등록할 수도 있다.
 

9. 스프링 컨테이너

DispatcherServlet에 의해 생성되는 수많은 객체들은 ApplicationContext에서 관리된다. 이것을 IoC라고 한다.
 

ApplicationContext

  • IoC란 제어의 역전을 의미한다.
  • 개발자가 직접 new를 통해 객체를 생성하게 되면, 해당 객체를 가리키는 레퍼런스 변수를 관리하기 어렵다.
  • 그래서 스프링이 직접 해당 객체를 관리한다!
  • 따라서, 우리는 주소를 몰라도 된다. 왜냐하면 필요할 때 DI 하면 되기 때문
  • DI를 의존성 주입이라고 한다. 필요한 곳에서 ApplicationContext에 접근하여 필요한 객체를 가져올 수 있다.
  • ApplicationContext는 싱글톤으로 관리되기 때문에 어디에서 접근하든 동일한 객체라는 것을 보장해 준다.

 
Application에는 두 가지 종류가 있다.

1. Root WebApplicationContext

Service, Repository 등을 스캔하고, DB 관련 객체를 생성한다 해당 파일은 ContextLoaderListener에 의해서 실행된다. ContextLoaderListener를 실행해 주는 것은 web.xml이기 때문에,Root WebApplicationContext는 Servlet WebApplicationContext보다 먼저 로드된다.
 

2. Servlet WebApplicationContext

ViewResolver, Interceptor, MultipartResolver 객체를 생성하고 웹과 관련한 애노테이션인 @Controller와 @RestController를 스캔한다. 해당 파일은 DispatcherServlet에 의해 실행된다.
 

Bean Factory

  • 필요한 객체를 Bean Factory에 등록할 수도 있다.
  • 여기에 등록하면 초기에 메모리에 로드되지 않고, 필요할 때 getBean()이라는 메서드를 통하여 호출해서 메모리에 로드할 수 있다.
  • 이것 또한 IoC이다. 그리고 필요할 때 DI 하여 사용할 수 있다.
  • ApplicationContext와 다른 점은 Bean Factory에 로드되는 객체들은 미리 로드되지 않고, 필요할 때 호출하여 로드하기 때문에 lazy-loading이 된다는 점이다.

 

10. Handler Mapping

요청 주소에 따른 적절한 컨트롤러로 요청
 

11. 응답

  • html 파일을 응답할지, Data를 응답할 지 결정해야 하는데 html 파일을 응답하게 되면 ViewResolver가 관여하게 된다.
  • Data를 응답하게 되면 MessageConverter가 작동하게 되며, 메시지를 컨버팅 할 때 기본전략을 JSON이다.
반응형