Spring MVC와 3-Layered Architecture

Spring과 Spring boot의 차이

Spring과 Spring boot의 관계는 React와 CRA 사이 관계와 유사한다. Spring 단독으로 사용하면 모든 의존성을 개발자가 관리해야하고 WAR을 실행하기 위해 별도의 웹 컨테이너(WAS)가 필요하다. 대신 Spring Boot는 Spring과 달리 JAR 파일로 패키징되기 때문에 단독으로 JRE(Java Runtime Environment)만 있어도 실행 가능하다. 그리고 내장 톰캣이 있기 때문에 언제 어디서나 동일한 JAR 파일을 가지고 같은 환경에서 Spring Boot를 배포할 수 있다.

MVC 패턴

MVC (모델-뷰-컨트롤러) 패턴은 소프트웨어의 비즈니스 로직과 화면을 구분하여 관심사 분리를 제공한다.

모델은 시스템에서 필요한 데이터를 관리하고 변경사항이 발생할 경우 뷰와 컨트롤러에게 알린다. 뷰는 시스템이 데이터를 보여주는 방식을 정의한다. 컨트롤러는 사용자로부터의 입력에 대한 응답으로 모델 또는 뷰를 업데이트하는 로직을 포함한다.

Spring MVC 프레임워크의 구성

Spring MVC는 Front Controller와 Controller가 model을 주고 받으면서 사용자의 요청에 view를 응답한다.

위 그림은 Spring MVC의 구조를 나타낸다. 사용자의 요청에대한 응답을 화면 상에 보여주기위해 아래와 같은 순서로 작업한다.

클라이언트의 요청을 DispatcherServlet이 받음, 정적 컨텐츠가 있다면 바로 응답
동적 컨테츠인 경우 DispatcherServlet은 Servlet Container에게 요청을 전달
Servlet Container는 Servlet을 생성하고 처리를 위임
Handler Mapping으로 요청에 맞는 컨트롤러 찾기
HandlerAdapter에게 요청을 위임
Controller는 적절한 로직(서비스, 레포지토리)을 수행
Controller를 통해 DispatcherServlet에 Model과 View를 응답
DispatcherServlet은 ViewResolver에게 응답에 맞는 템플릿이 있는지 확인
DispatcherServlet은 적절한 템플릿에 Model을 주입하고 결과를 클라이언트에게 응답

위 그림은 이전 그림보다 더 Spring MVC에 초점을 맞춘 그림이다. Spring MVC에서 DispatcherServlet은 Front controller로 요청에 맞는 Controller에 요청 처리를 위임하고, 응답 받은 View와 Model을 통합해서 응답하게된다.

Spring MVC의 컨테이너

DispatcherServlet은 클라이언트의 모든 요청을 핸들링. 정적인 페이지가 존재하는지 확인하고, 동적인 페이지는 Servlet Container에게 위임한다. 그리고 Servlet WebApplicationContext와 Root WebApplicationContext를 생성한다. Servlet WebApplicationContext(Servlet Container)에는 Controller Bean이 있고, Root WebApplicationContext(Spring Container)에는 Service나 Repository Bean처럼 비즈니스 로직과 관련된 Bean이 저장돼있다.

Servlet Container는 ServletContext(web.xml에 작성된 모든 웹 애플리케이션 자원 Servlet, filters,and listeners이 저장된 곳)를 생성한다. Servlet은 클라이언트의 요청, 처리, 응답을 수행하고 생명주기는 다음과 같다.

Servlet은 Servlet Container에 등록되어야하고, JEE나 Spring은 Servlet을 실행시킬 수 있다.
Servlet이 초기화되면, 클라이언트의 요청을 받을 준비가 된 것이다.
Container는 요청을 받아 Servlet에게 전달하고 Servlet이 처리하도록 한다.
Servlet이 제거되면 더 이상 요청을 받을 수 없다.

클라이언트의 요청은 Servlet Container가 생성하는 HttpServletRequest로, 응답은 HttpServletResponse 객체로 표현되고 Servlet에게 처리를 위임한다. 만약 Servlet이 Servlet WebApplicationContext에 필요한 빈을 못 찾으면 Root WebApplicationContext로 처리를 위임한다.

3계층 아키텍쳐 패턴

3계층 아키텍쳐 패턴의 목적은 관심사의 분리로 높은 유지보수성과 쉬운 테스트에 있다.

Presentation Layer : 클라이언트 요청에 따른 실행, 화면 생성 및 반환 = Spring MVC 구조 (@Controller)
Business Layer : 비즈니스 로직 수행 - Controller가 반환한느 Model에 채울 데이터 생성 (@Service)
Data Access Layer :애플리케이션 영속성 유지 및 CRUD
- DAO : DB에 바로 연결된 CRUD 함수 (구현체는 EntityManager를 통해 수행)
- Repository : 캡슐화된 DAO, CRUD 전부 쓰는게 아니라 필요한 함수만 쓴다.

Spring과 MSA

사용자 수가 많아짐에 따라 모놀리딕 아키텍쳐는 서버의 수직적 확장만 할 수 있고, 가용성에 제한이 있다. 그렇기 때문에 MSA가 등장했다. MSA를 위핸선 WAS의 경량화가 필수적이다. Spring이 이 필요성을 충족시켰다.

또한 모놀리딕 아키텍쳐는 한 WAS 내부에서 함수-함수 사이에 데이터가 이동했지만, MSA에서는 WAS-WAS 사이에 데이터가 이동될 일이 많아졌고, 그로 인해 API 개수가 기하급수적으로 증가했다. 수 많은 마이크로서비스의 API를 관리하기 위해 API GateWay(GW)가 등장했다.

MSA가 좋은 이유

각 도메인에 적합한 언어, DB를 사용할 수 있다.
하나의 마이크로서비스에서 변경이 발생하여도 다른 서비스에 영향 X
서로 다른 기술과 배포 일정을 선택할 수 있다. 유지 보수성을 향상시킬 수 있다.

목차