개발에 앞서 알면 좋은 기초 지식

서버 간 통신

예를들어 어떤 포탈 사이트를 하나의 서비스 단위로 개발한다고 가정하면 블로그, 카페, 메일등을 하나의 애플리케이션으로 통합했다는 뜻이고 이 방법에서 서비스를 업데이트 또는 유지보수할 때마다 "사이트 작업 중입니다"라는 팻말을 걸고 작업을 해야해서 개발에 보수적인 입장을 취할 수밖에 없고, 서비스 자체의 규모도 커지기 때문에 서비스 구동하는데 시간이 길어집니다.

이것을 해결하기위해 마이크로서비스 아키텍쳐(MSA: Microservice Architecture)입니다. 이 기능은 서비스 규모를 작게 나누어 구성한 아키텍쳐를 뜻합니다. 쉽게 말해서 앞에서 예시에서 블로그 프로젝트, 카페 프로젝트, 메일 프로젝트 등 애플리케이션을 기능별로 나눠서 개발합니다.

단일 서비스로 구성된 A포털 사이트는 내부 메서드 호출 등을 통해 원하는 자원을 가져와 사용할수 있습니다. 시비스 기능별로 구분해서 B포털 사이트와 같이 독립적인 애플리케이션을 개발하게 되면 각 서비슷 간에 통신해야 하는 경우가 발생합니다.

• 사용자가 블로그 기능을 사용하기 위해 로그인 서비스를 거쳐야만 하는 상황 이런 것이 서버 간 통신이라고 합니다.
• 서버 간 통신은 한 서버가 다른 서버에 통신을 요청하는 것을 의미합니다.
• 한 대는 서버, 다른 한 대는 클라이언트가 되는 구조입니다.
• 여러가지 프로토콜의 통신 방식을 적용하지만, 가장 많이 사용되는 방식은 HTTP/HTTPS입니다.

스프링 부트의 동작 방식

서블릿(Servlet)

서블릿(Servlet)은 클라이언트의 요청을 처리하고 결과를 반화하는 자바 웹 프로그래밍 기술 입니다. 서블릿은 서블릿 컨테이너가 관리합니다.

서블릿 컨테이너

서블릿 컨테이너는 서블릿 인스턴스(Servlet Instance)를 생성하고 관리하는 역할을 수행하는 주체로서 톰캣은 WAS의 역할과 서블릿 컨테이너의 역할을 수행하는 대표적인 컨테이너입니다.

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

DispatcherServlet

• 일반적으로 스프링은 톰캣을 임베드해 사용합니다.
• 서블릿 컨테이너와 DispatcherServlet은 자동 설정된 web.xml 설정값을 공유.

DispatcherServlet 동작

• DispatcherServlet 요청(HttpServletRequest) 들어오면 DispatcherServlet은 핸들러 매핑을 통해 요청 URI 매핑된 핸들러(Controller)를 탐색합니다.
• 핸들러 어뎁터(HandlerAdapter)를 호출합니다.
• 핸들러 어뎁터에 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공해 반환합니다.
• 뷰 형식으로 리턴하는 컨트롤러를 사용할때는 뷰 리졸버(View Resolver)를 통해 뷰(View)를 받아 리턴합니다.

대표적인 구현체 클래스:

BeanNameUrlHandlerMapping

• 빈 이름을 URL로 사용하는 매핑 전략입니다.
• 빈을 정의할 때 슬래시("/") 들어가면 매핑 대상입니다.
• @Bean("/hello")

ControllerClassNameHandlerMapping

• URL과 일치하는 클래스 이름을 갖는 빈을 컨트롤러로 사용하는 전략입니다.
• 이름 중 Controller를 제외하고 앞부분에 작성된 suffix를 소문자로 매핑합니다.

SimpleUrlHandlerMapping

• URL 패턴에 매핑된 컨트롤러를 사용하는 전략입니다.

DefaultAnnotationHandlerMapping

• 어노테이션으로 URL과 컨트롤러를 매핑하는 방법입니다.

하지만 우리는 REST 형식의 @ResponseBody를 사용합니다 뷰 리졸버를 호출하지 않고 MessageConverter를 거쳐 JSON 형식으로 변환해서 응답합니다.

MessageConverter는 요청과 응답에 대해 Body값을 변환하는 역할을 수행합니다.

레이어드 아키텍쳐

레이어드 아키텍쳐(Layered Architecture)란 애플리케이션의 컴포넌트를 유사 관심사 기준으로 레이어로 묶어 수평적으로 구성한 구조입니다.

일반적으로 레이어드 아키텍쳐라 하면 3계층 또는 4계층 구성을 의미합니다. 이 차이는 인프라(데이터베이스) 레이어의 추가 여부로 결정됩니다.

프레젠테이션 계층

• 애플리케이션의 최상단 계층으로, 클라이언트의 요청을 해석하고 응답하는 역활입니다.
• UI나 API를 제공합니다.
• 프레젠테이션 계층은 별도의 비즈니스 로직을 포함하고 있지 않으므로 비즈니스 계층으로 요청 위임하고 받은 결과를 응답하는 역할만 수행합니다.

비즈니스 계층

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

데이터 접근 계층

• 데이터베이스에 접근하는 인련의 작업을 수행합니다.

레이어 아키텍처는 하나의 애플리케이션에도 적용되지만 애플리케이션 간의 관계를 설명하는 데도 사용할 수 있습니다.

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

• 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받습니다.
• 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역활을 침범하지 않습니다.
-각 컴포넌트의 역할이 명확하므로 코듸 가독성과 기능 구현에 유리합니다.
-코드의 확장성도 좋아집니다.

스프링 레이어드 아키텍쳐

• Spring MVC는 Model-View-Controller의 구조로 View와 Controller는 프레젠테이션 계층 영역
• Model은 비즈니스와 데이터 접근 계층의 영역으로 구분할 수 있습니다.
• 비즈니스 계층에 서비스를 배치해 엔티티와 같은 도메인의 객채의 비즈니스 로직을 조합하도록 하고 데이터 접근 계층에는 DAO(Spring Data JPA에서는 Repository)를 배치해 도메인을 관리합니다.

스프링 레이어드 아키텍쳐 역활

프레젠테이션 계층

• 상황에 따라 유저 인터페이스(UI) 계층이라고도 불립니다.
• 클라이언트와의 접점이 됩니다.
• 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할입니다.

비즈니스 계층

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

데이터 접근 계층

• 상황에 따라 영속(Persistence) 계층이라고도 합니다.
• 데이터베이스에 접근해야 하는 작업을 수행합니다.
• DAO라는 컴포넌트는 Spring Data JPA에서는 DAO 역할을 리포지토리가 수행하기 때문에 리포지토리로 대체할 수 있습니다.

디자인 패턴

디자인 패턴은 소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해 고안된 해결책입니다.
디자인 패턴의 종류는 GoF 디자인 패턴 (Gang of Four)

생성 패턴

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

구조 패턴

• 객체를 조합해서 더 큰 구조를 만드는 패턴입니다.

행위 패턴

• 객체 간의 알고리즘이나 책임 분배에 관한 패턴입니다..
• 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배합니다. 결합도 최소화를 고려할 필요가 있습니다.

REST API

REST API는 대중적으로 가장 많이 사용되는 어플리케이션 인터페이스입니다. 이 인터페이스를 통해 클라이언트는 서버에 접근하고 자원을 조작할 수 있습니다.

REST란?

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

REST API란?

API란 Application Programming Interface의 약자로, 애플리케이션에서 제공하는 인터페이스를 의미합니다. API를 통해 서버 또는 프로그램 사이를 연결할 수 있습니다. 따라서 REST API는 REST 아키텍쳐를 따르는 시스템/애플리케이션 인터페이스 라고 볼 수 있습니다. REST 아키텍처를 구현하는 웹 서비슷를 "RESTful"하다라고 표현합니다.

REST 특징

유니폼 인터페이스

• 일관된 인터페이스를 의미
• HTTP 표준 전송 규약을 따라 타 언어, 플랫폼, 기술 등과 호환 가능한 기술

무상태성

• 서버에 상태 정보를 따로 보관 하지 않는다는 의미.
• 클라이언트가 보낸 요청에 대해 세션, 쿠기 정보를 보관하지 않음
• 개별적으로 처리하고 이것을 통해 불 필요한 정보 관리 하지않고 비즈니스 로직의 자유도가 높고 설계가 단수합니다.

캐시 가능성

• HTTP 표준을 그대로 사용하므로 HTTP의 캐싱 기능을 적용할 수 있습니다.
• 응답과 요청이 모두 캐싱이(Cacheable) 가능하지 명시가 필요합니다.
• 캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용합니다.
• 이 기능을 사용하면 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선됩니다.

레이어 시스템

• 네트워크 상의 여러 계층으로 구성될 수 있습니다.
• 그러나 서버의 복잡도와 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 됩니다.

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

• API를 제공하는 클라이언트는 사용자 정보를 관리하는 구조로 분리에 설계합니다.
• 이 구성은 서로에 대한 의존성을 낮추는 기능을 합니다.

REST의 URI 설계 규칙

URL의 마직막에는 '/'포함 하지 않습니다.

• 옳은 예) http://localhost.com/product
• 잘못된 예) http://localhost.com/product/

언더바(_)는 사용하지 않습니다. 대신 하이픈(-)을 이용합니다.

• 하이픈은 리소스의 이름이 길어지면 사용합니다..
• 옳은 예) http://localhost.com/provider-company-name
• 잘못된 예) http://localhost.com/product_comapny_name

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

• 하이픈은 리소스의 이름이 길어지면 사용합니다..
• 옳은 예) http://localhost.com/product/123
• 잘못된 예) http://localhost.com/delete-product/123

URL는 소문자로 작성해야 합니다.

• URL 리소스 경로에는 대문자 사용을 피하는 것이 좋습니다.

파일 확장자는 URL에 포함하지 않습니다.

• HTTP에서 제공하는 Accept 헤더를 사용하는 것이 좋습니다.