HiDevelop

Spring Boot!란? 본문

Spring

Spring Boot!란?

꽃달린감나무 2023. 3. 12. 18:04
728x90

Spring Framework

 
- 자바 언어를 이용해 엔터프라이즈급 개발을 편리하게 만들어주는 '오픈소스 경량급 어플리케이션 프레임워크'로, 쉽게 말하자면, 자바를 이용해 어플리케이션을 개발하는 데 필요한 기능을 제공하고 쉽게 사용하도록 돕는 도구입니다. 
 
 

스프링의 특징!

 

1. 제어 역전(Ioc)

 기존의 Java에서는 사용하고자 하는 객체를 선언하고 해당 객체의 의존성을 생성한 후 객체의 클래스에서 제공된 메소드는 멤버변수를 사용합니다.
 

public class MyController {

    public static void main(String[] args){
    	private MyService myService = new MyService; //객체 생성
    	myService.add(1,3) // 해당 객체의 클래스 멤버메소드 사용
    }
}

 
하지만, 제어역전의 경우 사용할 객체를 생성하는 대신 객체의 생명주기 관리를 외부(Spring Container, IoC Container)에 위임 합니다. 이렇게, 객체의 관리를 컨테이너에게 맡겨 제어권이 넘어간 것을 제어 역전(Ioc)이라고 합니다. 제어역전을 통해 의존성 주입(DI), 관점 지향 프로그래밍(AOP)를 가능하게 할 수 있습니다.
 
 

2. 의존성 주입(DI)

 
 의존성 주입(DI: Dependency Injection)는 제어 역전의 방법 중 하나로, 사용할 객체를 직접 생성하지 않고, 외부 컨테이너가 생성한 객체를 주입받아 사용하는 방식입니다. 스프링에서는 @Autowired라는 어노테이션을 통해 의존성을 주입할 수 있습니다.
 
스프링에서 의존성 주입 방벙은 3가지 입니다.
 

  • 생성자를 통한 의존성 주입
@RestController
public class MyController {
	
    MyService myService;
    
    @Autowired
    public MyController(MyService myService){
		this.myService = myService;
    }
    
    
    @GetMapping("/my/hello")
    public String getHello(){
    	return myService.getHello();
    }
    
}

 

  • 필드 객체 선언을 통한 의존성 주입
@RestController
public class CatsController{

	@Autowired
    private CatService catService;
    
}

 
 

  • setter 메서드를 통한 의존성 주입
@RestController
public class CatsController{

	
    private CatService catService;
    
    @Autowired
    public void setCatService(CatService catSerivce){
    	this.catService = catService;
    }
    
}

 
위 3가지 방식중 스프링에서 추천하는 방식은 생성자를 통해 의존성을 주입받는 방식 입니다. 다른 방식과는 다르게 생성자를 통해 의존성을 주입받는 방식은 래퍼런스 객체 없이는 객체를 초기화할 수 없기 때문입니다.



관점지향 프로그래밍

- 관점을 기준으로 묶어 개발하는 방식을 의미합니다. 여기서 관점(aspect)란 어떤 기능을 구현할 때 그 기능을 '핵심 기능'과 '부가 기능'으로 구분해 각각을 하나의 관점으로 보는 것을 의미 합니다.

- 핵심 기능 :  비즈니스 로직을 구현하는 과정에서 비즈니스 로직이 처리하려는 목적 기능 ( 계좌 정보를 저장하고, 이를 조회한다 라는 기능)
- 부가 기능 :  비즈니스 로직 사이에 로깅, 로깅 처리, 트랜잭션을 처리하려는 목적기능

간단한 형식으로 이를 표현하자면,

계좌 정보 등록 :  로깅1 > 로직1 > 로깅2 > 로직2 >  트랜잭션 > 로깅 >로직
계좌 정보 조회 :  로깅1 > 로직1 > 로깅2 > 로직2 >  트랜잭션 > 로깅 >로직

위 형식에는 정보 등록, 조회에 같은 로깅(1,2)와 트랙잭션이 들어가 있습니다. 이는  동일한 코드가 등록, 조회에 들어가 있다는 것입니다. 이처럼 여러 비즈니스 로직에서 반복되는 부가 기능을 하나의 공통 로직으로 처리하도록 모듈화를 삽입하는 방식이 AOP입니다

AOP로 바꾼 간단한 형식

계좌 정보 등록 :  logging( ) > 로직1 >logging( ) > 로직2 > Transaction( ) > logging( ) >로직
계좌 정보 조회 :  logging( ) > 로직1 >logging( ) > 로직2 >  Transaction( )> logging( ) >로직

logging( ) : 로깅을 처리하는 함수
Transaction( ) : 트랙잭션을 처리하는 함수

AOP를 구현하는 방법

 

1. 컴파일 과정에 삽입하는 방식

2. 바이트코드를 메모리에 로드하는 과정에 삽입하는 방식

3. 프락시 패턴을 이용한 방식

 

 스프링 프레임워크의 다양한 모듈

스프링 프레임 워크는 기능별로 구분된 약 20여 개의 모듈로 구성돼 있습니다. 하지만 스프링 프레임워크를 이용한다해서 위에 있는 모든 모듈을 사용할 필요는 없습니다. 어플리케이션 개발에 필요한 모듈만을 선택해서 사용하게끔 설계되어 있기 때문입니다. 이를 경량 컨테이너 설계라고 부릅니다.

 

Spring VS Spring Boot

 

스프링의 경우 필요한 모듈을 추가하다보면, 설정이 매우 복잡해지기 시작합니다. 이를 보완하기위해 나온 것이 바로 스프링 부트입니다.

 

스프링 부트를 이용하면 단독으로 실행 가능한 상용 수준의 스프링 기반 어플리케이션을 손쉽게 만들 수 있다.


그럼 어떻게 편리하게 만든다는 걸까? 그 특징을 한 번 알아보겠습니다.

 

1. 의존성 관리

 

 스프링 프레임워크에서는 개발에 필요한 모든 모듈의 의존성을 하나하나 직접 설정해야했습니다. 또 호환되는 버전에 따라 오류가 나기도, 정상 동작을 하기도 합니다. 개발자가 이를 다 하나하나 설정하다보니 환경을 구성하는데만 해도 많은 시간을 소비하게 됩니다. 

 

스프링 부트에서는 이 불편함을 해소하기 위해 'spring - boot -starter' 라는 의존성을 제공합니다. spring - boot - starter는 여러 종류가 있고, 각 라이브러리의 기능과 관련해서 자주 사용되고 서로 호환되는 버전의 모듈 조합을 제공합니다. 이를 통해 개발자는 각 라이브러리의 호환되는 버전을 다 하나하나 설정해 줄 필요가 없습니다.

 

2. 자동 설정

자동 설정은 어플리케이션에 추가된 라이브러리를 실행하는 데 필요한 환경 설정을 알아서 찾아줍니다. 즉, 어플리케이션을 개발하는데 필요한 의존성을 추가하면 프레임워크가 이를 자동으로 관리하게 해줍니다.

 

 

3. 내장 WAS

스프링 부트의 각 웹 어플리케이션에는 내장 WAS가 존재합니다. 이는, 'spring -boot - starter - web'에 내장되어있으면, 기본적인  WAS로 톰캣이 내장되어있습니다. 다른 WAS로 바꿀수 있습니다.

 

4. 모니터링

개발이 끝나고 서비스를 운영하는 시기에는 해당 시스템이 사용하는 스레드, 메모리, 세션 등의 주요 요소들을 모니터링 해야하는데,  스프링 부트에서는 액추에이터라는 자체 모니터링 도구를 지원해줍니다.

 

 

 

서버간 통신

 

마이크로서비스 아키텍쳐(MSA: Microservice Architecture) : 서비스 규모를 작게 나누어 구성한 아키텍쳐

 

금융 홈페이지를 만든다고 할 때, 은행, 주식, 보험 프로젝트가 한 서비스로 이루어져 있다면, 한 서비스에 주식, 은행, 보험이 존재한다면, 서비스의 자체 규모가 커지면서, 서비스를 구동해야하는 오랜시간이 걸릴 수도있고, 이를 유지보수하기도 쉽지 않을 것입니다. 이를 은행은 은행 서비스에, 주식은 주식 서비스에, 보험은 보험 서비스로 분리하여 기능별로 나눠서 개발하는 것을 마이크로서비스 아키텍쳐(MSA: Microservice Architecture) 입니다.

 

MAS로 어플리케이션을 개발하다보면, 서버간의 통신이 필요하게 됩니다. 서버 간 통신은 한 서버가 다른 서버에 통신을 요청하는 것을 의미하는데, 한 대는 서버, 다른 한 대는 클라이언트가 되는 구조 입니다. 여기서 사용되는 프로토콜은 다양하지만, 대표적으로 사용하는 프로토콜은 HTTP/HTTPS 방식 입니다.

 

 

스프링 부트의 동작 방식

스프링 부트의 spring -boot - starter - web 모듈을 사용하면 , 톰캣을 사용하는 스프링 MVC 구조를 기반으로 동작합니다.

 

 

스프링 부트의 동작 구조

 

서블릿 (Servelet)

 

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

 

서블릿 특징

1. 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리

2. 서블릿 객체는 싱글톤 패턴으로 관리

3. 멀티 스레딩 지원

 

스프링에서는 DispatcherServlet이 서블릿의 역할을 수행합니다.

 

DispatcherServelet

일반적으로 스프링은 톰캣을 내장해 사용하기 때문에, 서블릿 컨테이너와 DispatcherServlet은 자동 설정된 web.xml의 설정값을 공유합니다.

 

DispatcherServelet의 동작

 

View를 사용하는 DispathcerServlet의 동작 방식

 

1. DispatcherServelet으로 요청이(HttpRequest)가 들어오면, DispatcherServlet은 핸들러 매핑을 통해 요청  URL 매핑된 핸들러를 탐색합니다. 여기서 핸들러는 컨트롤러를 의미합니다.

2. 핸들러 어댑터로 컨트롤러를 호출합니다.

3. 핸들러 어댑터에 컨틀롤러의 응답이 들어오면 ModelAndView로 응답 가공해 변환합니다.

4. 뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 뷰 리졸버를 통해 뷰를 받아 리턴합니다.

 

View를 사용하는 DispathcerServlet의 동작 방식

@RestController를 사용하는 DispathcerServlet의 동작 방식

 

RestController를 사용할 때에는, View 리졸버를 호출하지 않고, MessageConverter를 거쳐 JSON 형식으로 변환해서 응답합니다. 여기서 MessageConverter는 요청과 응답에 대해 Body값을 변환하는 역할을 수행합니다.

@RestController를 사용하는 DispathcerServlet의 동작 방식

 

레이어드 아키텍쳐

레이어드 아키텍쳐는 어플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조를 의미합니다. 일반적으로 레이어드 아키텍처라는 3계층 또는 4계층을 구성합니다. 

 

스프링의 레어이드 아키텍쳐

프레젠테이션 계층 -  상황에 따라 유저 인터페이스라고 불리며, 클라이언트와 접점이 되는 지점, 클라이언트로부터 데이터와 함께 요청 받고 처리 결과를 응답으로 전달하는 역할입니다

 

비즈니스 계층 - 상황에 따라 서비스 계층이라고 불리며, 핵심 비즈니스 로직이 구현되는 계층입니다. 트랜잭션 처리나 유효성 검사 등의 작업을 주로 수행합니다 

 

데이터 접근 계층 - 상황에 따라 영속 계층이라 불리며, 데이터베이스에 접근해야 하는 작업을 수행합니다. 이를 보통 DAO라는 컴포넌트가 수행하지만, JPA를 사용할 경우 이 역할을 Repository가 수행하게 됩니다.

 

 

디자인 패턴

디자인 패턴은 소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해 고안된 해결책입니다.  다음과 패턴의 종류로 나뉩니다.

 

 

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

 

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

 

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

 

 

REST 

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

 

 

REST API

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

 

 

REST의 URI의 설계 규칙

1. url의 마지막에는 '/'를 포함하지 않습니다

 - localhost:8080/account

 

2. 언더바 대신, 하이픈을 사용합니다.

 - localhost:8080/account-name

 

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

 - localhost:8080/account/name/12

 

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

 - localhost:8080/account/name/12

 

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

728x90

'Spring' 카테고리의 다른 글

간단한 서버 간 통신 @FeignClient  (0) 2023.08.03
OAuth2 (이론 및 준비)  (0) 2023.07.20
ORM(Object Relational Mapping)  (0) 2023.04.09
API 작성  (0) 2023.03.19
Maven pom.xml?  (0) 2023.03.19