[Spring Boot] Chapter.2 개발에 앞서 알면 좋은 기초 지식

2.1 서버 간 통신

포털 사이트를 하나의 서비스 단위로 개발한다고 하면, 블로그, 카페, 메일 등의 기능들을 하나의 애플리케이션에 통합했다는 것이다. 이렇게 서비스를 구성한다면 서버를 업데이트하거나 애플리케이션을 유지보수할 때마다 사이트를 이용하지 못하게 된다. 이를 방지하기 위해 나온 것이 마이크로서비스 아키텍처이다.

• 마이크로서비스 아키텍처(MSA: Microservice Architecture)
  서비스 규모를 작게 나누어 구성한 아키텍처. 애플리케이션 하나에 여러 기능을 넣어 개발하지 않고 애플리케이션을 기능별로 나눠서 개발한다.

단일 서비스로 구성된 사이트에서는 내부 메서드 호출 등을 통해 원하는 자원을 사용 가능하다. 하지만 서비스 별로 구분한 사이트는 서버간에 통신을 해야 하는 경우가 생긴다. 이를 서버 간 통신이라고 한다.

서버 간 통신에서 한 대는 서버, 다른 한 대는 클라이언트가 된다. 이에 가장 많이 사용되는 방식은 HTTP/HTTPS 방식이다.

2.2 스프링 부트의 동작 방식

• 서블릿
  클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술. 일반적으로 서블릿 컨테이너에서 관리한다. 서블릿 컨테이너는 서블릿 인스턴스(Servlet Instance)를 생성하고 관리하는 역할을 수행한다. 톰캣은 WAS의 역할과 서블릿 컨테이너의 역할을 수행하는 대표적인 컨테이너이다.

• 서블릿 컨테이너의 특징

  • 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리한다.
  • 서블릿 객체는 싱글톤 패턴으로 관리된다.
  • 멀티 스레딩을 지원한다.

스프링에서는 DispatcherServlet이 서블릿의 역할을 수행. 서블릿 컨테이너와 DispatcherServlet은 자동 설정된 web.xml 설정값을 공유한다.

DispatcherServlet의 동작과정

🧡핸들러 매핑 인터페이스의 대표적인 구현체 클래스

• BeanNameUrlHandlerMapping
  • 빈 이름을 URL로 사용하는 매핑 전략
  • 빈을 정의할 때 /가 들어가면 매핑 대상이 됨.
  • 예) @Bean("/hello")
• ControllerClassNameHandlerMapping
  • URL과 일치하는 클래스 이름을 갖는 빈을 컨트롤러로 사용하는 전략
  • 이름 중 Controller를 제외하고 suffix를 소문자로 매핑.
• SimpleUrlHandlerMapping
  • URL 패턴에 매핑된 컨트롤러를 사용하는 전략.
• DefaultAnnotationHandlerMapping
  • 어노테이션으로 URL과 컨트롤러를 매핑하는 방법.

해당 서적에서는 뷰가 없는 REST 방식의 @ResponseBody를 사용할 예정. JSON 형식으로 응답한다.

• MessageConverter
  • 요청과 응답에 대해 Body값을 변환하는 역할. 스프링 부트는 HttpMessageConverter 인터페이스를 사용.

레이어드 아키텍처

애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조. 일반적으로 3계층 혹은 4계층을 의미한다.

💛스프링의 레이어드 아키텍처

• 프레젠테이션 계층
  • 상황에 따라 유저 인터페이스(UI) 계층이라고도 함.
  • 클라이언트와의 접점이 됨.
  • 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할.
• 비즈니스 계층
  • 상황에 따라 서비스(Service) 계층이라고도 함.
  • 핵심 비즈니스 로직을 구현하는 영역.
  • 트랜잭션 처리나 유효성 검사 등의 작업도 수행.
• 데이터 접근 계층
  • 상황에 따라 영속(Persistence) 계층이라고도 함.
  • 데이터베이스에 접근해야 하는 작업을 수행.
  • Spring Data JPA에서는 DAO 역할을 리포지토리가 수행하기 때문에 대체 가능.

디자인 패턴

소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기위해 고안된 해결책. 대표적인 분류 방식으로는 GoF 디자인 패턴이라는 것이 있다.

• 생성 패턴
  • 객체 생성에 사용되는 패턴으로, 객체를 수정해도 호출부가 영향을 받지 않는다.
• 구조 패턴
  • 객체를 조합해서 더 큰 구조를 만드는 패턴
• 행위 패턴
  • 객체 간의 알고리즘이나 책임 분배에 관한 패턴.
  • 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배. 결합도 최소를 고려할 필요가 있다.

2.5 REST API

💚 REST
REST란 'Representational State Transfer'의 약자로 분산 하이퍼미디어 시스템 아키텍처의 한 형식이다. 주고받는 자원에 이름을 규정하고 URI에 명시해 HTTP 메서드(GET, POST, PUT, DELETE)를 통해 해당 자원의 상태를 주고받는 것을 의미한다.

💙 REST API
REST API란 REST 아키텍처를 따르는 시스템 / 애플리케이션 인터페이스라고 볼 수 있으며, REST 아키텍처를 구현하는 웹 서비스를 'REUSTful하다'라고 표현한다.

💜 REST의 특징

• 유니폼 인터페이스
  • HTTP 표준 전송 규약을 따르기 때문에 어떤 프로그래밍 언어로 만들어졌느냐와 관계없이 플랫폼 및 기술에 종속되지 않고 타 언어, 플랫촘, 기술 등과 호환해 사용할 수 있다.
• 무상태성
  • REST는 서버에 상태 정보, 즉 요청에 대해 세션이나 쿠키 정보를 별도 보관하지 않는다. 따라서 모든 요청을 개별적으로 처리하고, 서버가 불필요한 정보를 관리하지 않아서 비즈니스 로직의 자유도가 높고 설계가 단순하다.
• 캐시 가능성
  • HTTP 표준을 사용하는 REST는 HTTP의 캐싱 기능을 적용할 수 있다. 이 기능을 이용하기 위해서는 응답과 요청이 모두 캐싱 가능한지(Cacheable) 명시가 필요하며, 캐싱이 가능하면 클라이언트에서 캐시에 저장한다.
• 레이어 시스템
  • REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있다. 하지만 서버의 복잡도와 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 된다.
• 클라이언트 - 서버 아키텍처
  • REST 서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계한다. 이 구성은 서로에 대한 의존성을 낮추는 기능을 한다.

🤎 REST의 URI 설계 규칙

• URI의 마지막에는 /를 포함하지 않는다.
• 언더바 _는 사용하지 않는다. 대신 하이픈 _을 이용한다.
• URL에는 행위(동사)가 아닌 결과(명사)를 포함한다.
• URI는 소문자로 작성해야 한다.
  • URI 리소스 경로에는 대문자 사용을 피하는 것이 좋다.(일부 웹 서버 운영체제는 리소스 경로의 대소문자를 구분한다.)
• 파일의 확장자는 URI에 포함하지 않는다.(HTTP에서 제공하는 Accept 헤더를 사용하는 게 좋음.)