1주차 02: 개발에 앞서 알면 좋은 기초 지식

2.1 서버 간 통신

하나의 서비스 단위로 개발 - > 다양한 기능들을 하나의 애플리케이션에 통합했다는 뜻.

규모가 커지면 서비스 구동이나 유지보수관리에 취약함.

 

이를 해결하기 위해 나온 것이 마이크로서비스 아키텍쳐(MSA, Microservice Architecture)

서비스 규모를 작게 나누어 구성한 아키텍쳐. 기능별로 나눠서 개발함.

 

예 ) 네이버, 다음 등 블로그, 카페, 메일 등

단일 서비스 아키텍쳐에서는 내부 메서드 호출로 원하는 자원을 가져와 사용 가능하지만,

마이크로서비스 아키텍쳐에서는 서버 간 통신을 해야 함.

 

서버 간 통신이란 한 서버가 다른 서버에 통신을 요청 하는 것.

클라이언트 -> 서버

가장 많이 사용되는 방식 HTTP/HTTPS

 

 

2.2 스프링 부트의 동작 방식

spring-boot-starter-web 모듈은 톰캣(Tomcat)을 사용하는 스프링 MVC 구조 기반으로 동작.

서블릿(Servlet)은 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술.

톰캣은 WAS의 역할과 서블릿 컨테이너의 역할을 수행하는 대표적인 컨테이너.

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

스프링에서는 DispatcherServelt이 서블릿 역할을 수행하며, 임베드된 톰캣과 자동 설정된 web.xml의 설정값을 공유함.

1. DispatcherServlet으로 요청(HttpServletRequest)이 들어오면, 핸들러 매핑(Handler Mapping)을 통해 요청 URI에 매핑된 핸들러를 탐색. 핸들러는 컨트롤러(Controller)를 의미.
2. 핸들러 어댑터(HandlerAdapter)로 컨트롤러 호출
3. 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공해 반환.
4. 뷰 형식으로 리턴하는 컨트롤러 사용시, 뷰 리졸버( View Resolver)를 통해 뷰(View)를 받아 리턴

뷰가 없는 Rest 형식의 @ResponseBody를 사용할 경우, 뷰 리졸버를 호출하지 않고 MessageConverter를 거쳐 JSON 형식으로 변환해서 응답. 자동 설정 내역을 보면 HttpMessageConverter 인터페이스 사용.

 

2.3 레이어드 아키텍처

레이어드 아키텍처(Layered Architecture)란 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조. 일반적으로 3계층 또는 4계층 구성을 의미. 차이는 인프라(데이터베이스) 레이어의 추가 여부로 결정.

프레젠테이션 계층

• 애플리케이션의 최상단 계층, 클라이언트의 요청을 해석하고 응답하는 역할.
• UI나 API제공
• 비즈니스 계층으로 요청을 위임하고 받은 결과를 읍답하는 역할 수행(비즈니스 로직 포함X)

비즈니스 계층

• 애플리케이션이 제공하는 기능을 정의하고 세부 작업을 수행하는 도메인 객체를 통해 업무를 위입하는 역할 수행
• DDD(Domain-Driven Design) 기반의 아키텍처에서는 비즈니스 로직에 도메인이 포함되기도 하고, 별도로 도메인 계층을 두기도 함.

데이터 접근 계층

• 데이터베이스에 접근하는 일련의 작업 수행

 

레이어드 아키텍처 기반 설계는 다음과 같은 특징을 가짐.

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

Spring-boot-starter-web의 의존성을 사용할 때에는 기본적으로 MVC구조를 띄게되며 라애와 같은 레이어드 아키텍처를 이룸.

Model-View-Controller 구조

View와 Controller는 프레젠테이션 계층 영역

Model은 비즈니스와 데이터 접근 계층의 영역

 

스프링 MVC모델로 레이어드 아키텍처를 구현하기 위해서는 역할 세분화.

비즈니스 계층에 서비스를 배치해 엔티티와 같은 도메인 객체의 비즈니스 로직을 조합하고, 데이터 접근 계층에는 DAO(JPA에서는 Repository)를 배치해 도메인 관리;.

 

스프링의 레이더드 아키텍처

프레젠테이션 계층

• 유저 인터페이스(UI; User Interface) 계층이라고도 함.
• 클라이언트와의 접점이 됨
• 클라이언트로부터 데이터화 함께 요청 받고, 처리 결과를 응답으로 전달하는 역할.

비즈니스 계층

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

데이터 접근 계층

• 상황에 따라 영속(Persistence)계층이라고도 함.
• 데이터베이스 접근 작업 수행
• JPA에서는 DAO역할을 리포지토리가 수행하므로 대체 가능

2.4 디자인패턴

'패턴'은 애플리케이션 개발에서 유사한 경우와 해결책도 동일하게 적용할 수 있다는 의미를 내포. 디자인 패턴이 모든 문제의 정잡은 아니므로, 상황에 맞는 최적 패턴을 결정해서 사용하는 것이 바람직.

2.4.1 디자인 패턴의 종류

GOF 디자인 패턴은 4명의 인물이 디자인 패턴을 구체화하고 체계화 하여 분류한 방식.

생성 패턴, 구조 패턴, 행위 패턴의 총 세가지로 구분.

생성 패턴

• 객체 생성에 사용되는 패턴으로, 객체를 수정해도 호출부가 영향을 받지 않게 함.

구조 패턴

• 객체를 조합해서 더 큰 구조를 만듦.

행위 패턴

• 객체 간 알고리즘이나 책임 분배
• 객체 하나로 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배. 결합도 최소화를 고려할 필요가 있음.

2.5 REST API

2.5.1 REST란?

'Representational State Transfer'의 약자로, 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템 아키텍처의 한 형식.

주고 받는 자원(Resource)에 이름을 규정하고 URI에 명시해 HTTP 메서드(GET, POST,  PUT, DELETE) 를 통해 자원의 상태를 주고 받음.

2.5.2 REST API란?

API는 'Application Programming Interface'의 약자.

즉 Rest 아키텍처를 따르는 시스템/애플리케이션 인터페이스.

'RESTful'하다.

 

2.5.3 REST의 특징

유니폼 인터페이스

일관된 인터페이스로 HTTP 표준 전송 규약을 따르므로 타 언어, 플랫폼, 기술 등과 호환해 사용 가능

무상태성

Stateless는 서버에 상태 정보를 따로 보관하거나 관리하지 않음을 의미함. 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리함. 이렇게 구성된 서비스는 비즈니스 로직의 자유도가 높고 설계가 단순.

레이어 시스템

REST서버는 네트워크 상의 여러 계층으로 구성될 수 있음(Layred System).  클라이언트는 서버와 연결되는 포인트만 알면 됨.

클라이언트-서버 아키텍처

REST서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설꼐. 이 구성은 서로에 대한 의존성을 낮추는 기능을 함.

 

2.5.4 REST의 URI 설계 규칙

URI의 마지막에는 '/'를 포함하지 않음.

언더바(_)대신 하이픈(-)이용.

URL에는 행위(동사)가 아닌 결과(명사)를 포함.

URI는 소문자로 작성

파일의 확장자는 URI에 포함하지 않음.