[SpringBoot] 2.1-3 스프링 부트 동작 방식, 레이어드 아키텍처

Summary : 효율을 위해 마이크로 아키텍처 구조를 가져야 하지만, 이를 위해선 서버간 통신이 필요
통신에서의 역할별로 계층을 나눈게 레이어드 아키텍처

🔍 목차

---

02 개발에 앞서 알면 좋은 기초 지식
     2.1 서버 간 통신
     2.2 스프링 부트의 동작 방식
     2.3 레이어드 아키텍처

📌 2.1 서버 간 통신 

---

단일 서비스 아키텍처 : 하나의 서비스 단위로 개발하는 것

• 장점 : 하나의 서비스에서 모든 자원을 공유하므로 원하는 자원에 쉽게 접근 가능
• 단점
  1) 서비스의 규모가 크므로 시간이 오래 걸림
  2) 한 부분이 고장 나면 전체가 다운될 수 있음
  이러한 문제를 해결하기 위해 나온 것이 마이크로 서비스 아키텍처(MSA)

마이크로 서비스 아키텍처 : 서비스를 작게 나누어 개발하는 것

• 장점
  1) 단일 모듈의 장애에 전체 어플리케이션이 크게 영향받지 않음
  2) 각 서비스를 테스트하기 용이
  3) 느슨한 결합으로 인해 의존 관계가 적고 유연
• 단점 : 자원 공유가 안되므로 서비스끼리 통신을 해야 정보를 주고받을 수 있음
• => 이런 상황에서의 통신을 '서버간 통신'이라고 함

📌 2.2 서블릿

---

• 서블릿의 특징
  1) 클라이언트의 요청에 동적으로 응답하는 웹 어플리케이션 컴포넌트
  2) HTTP 형식으로 응답
  3) JAVA의 스레드를 이용
  4) MVC 패턴의 Controller 역할을 담당
  5) 서블릿은 서블릿 컨테이너에서 관리됨
• 서블릿은 WAS내의 서블릿 컨테이너에서 동작하며,
  요청(Request)을 받으면 요청에 맞는 로직을 실행하고
  클라이언트에게 HTTP 형식으로 응답(Response)함
• 스프링에서는 DispatcherServlet이 서블릿의 역할을 수행

📌 2.2 서블릿 컨테이너

---

Introduction to Servlet Container (devmanuals.com)

톰캣의 작동 방식

• 톰캣은 대표적인 서블릿 컨테이너
• 톰캣은 클라이언트로부터 요청을 받았을 때, 
  요청에 대응할 수 있는 서블릿 클래스를 인스턴스화하여 요청을 처리함
• 이때 서블릿 객체는 컨테이너 안에서 싱글톤 패턴으로 생성됨

서블릿 컨테이너의 역할

• 웹서버와의 통신 지원 : 서블릿이 담당하지 않는 부가적인 기능을 처리해 주므로 개발에만 집중할 수 있음
• 서블릿 객체의 생명주기 관리 : 인스턴스 생성, 초기화 호출, 종료 etc..
• 멀티 스레드 지원

📌 2.2 스프링 부트의 동작 방식

---

1. DispatcherServlet 으로 요청(HttpServletRequest)이 들어오면
   DispatcherServlet은 핸들러 매핑(Handler Mapping)을 통해 요청 URL에 매핑된 핸들러를 탐색한다.
   여기서 핸들러는 컨트롤러(Controller)를 의미한다.
2. 이후, DispatcherServlet은 핸들러 어댑터(HandlerAdapter)로 컨트롤러를 호출한다.
3. 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 응답을 가공하여 DispatcherServlet에게 반환한다.
4. 응답을 가공하는 방법
   뷰 형식으로 리턴하는 컨트롤러를 사용할 경우 뷰 리졸버(ViewResolver)를 통해 뷰(View)를 받아 리턴한다.
   뷰 없이 JSON만 리턴하는 경우에는 MessageConverter을 사용해서 Json을 body에 넣어 HTTP 응답을 리턴한다.

cf. MessageConverter란?
JSON 데이터를 HTTP 메시지 바디안에 직접 읽거나 쓰는 경우 사용함
사용 예시 :
@RestController를 이루는 어노테이션 @ResponseBody은 자바 객체를 json으로 바꾸는 역할을 하는데,
이때 @ResponseBody의 내부에서 HttpMessageConverter가 동작함

📌 2.3.1 레이어드 아키텍처 (Layered Architecture)

---

• 정의 : 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조
• 각 레이어는 아래의 역할을 함

프레젠테이션 계층

• 클라이언트와의 유일한 접점
• 클라이언트로부터 데이터와 함께 요청을 받고, 처리 결과를 응답으로 전달하는 영역
• 상황에 따라 유저 인터페이스(UI / User Interface) 계층이라고도 함

비즈니스 계층

• 핵심 비즈니스 로직을 구현하는 영역
• 트랜잭션 처리나 유효성 검사 등의 작업도 수행함
• 상황에 따라 서비스(Service) 계층이라고도 함

데이터 접근 계층

• 데이터베이스에 접근해야 하는 모든 작업을 수행하는 영역
• 상황에 따라 영속(Persistence) 계층이라고도 함

레이어드 아키텍처 기반 설계의 특징

• 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받음
• 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역할을 침범하지 않음
• 각 컴포넌트의 역할이 명확하므로 코드의 가독성과 기능 구현에 유리함
• 코드의 확장성도 좋아짐
• 각 레이어가 독립적으로 작성되므로 다른 레이어와의 의존성을 낮춰 단위 테스트에 용이함

📌 2.3.2 스프링에서의 레이어드 아키텍처

---

• 스프링 부트는 별도의 설정 없이 spring-boot-starter-web의 의존성을 사용할 때
  기본적으로 Spring MVC(Model- View-Controller) 구조를 갖음
• Spring MVC를 레이어드 아키텍처로 생각하면
  View와 Controller는 프레젠테이션 계층이며,
  Model은 비즈니스와 데이터 접근 계층으로 구분할 수 있음
• 여기서 Model은 DTO와 같은 역할을 하고, DAO는 리포지토리와 같은 역할을 함

 

 

※ 이 글은 [스프링 부트 핵심 가이드] 책의 내용을 정리한 글입니다. ※

 

참고 블로그 :
https://code-lab1.tistory.com/210
https://jaimemin.tistory.com/1823