[Book Study] 스프링 부트 핵심 가이드 - 2. 개발에 앞서 알면 좋은 기초 지식

[Book Study] 스프링 부트 핵심 가이드
2. 개발에 앞서 알면 좋은 기초 지식

 

---

 

2 - 1 서버 간 통산

▶ 마이크로 서비스 아키텍처(MSA: Microservice Architecture)

 

---

2 - 2 스프링 부트의 동작 방식

▶ 스프링 부트의 동작 방식

 

• 기본적으로 톰캣을 사용하는 스프링 MVC 구조를 기반으로 동작
• 서블릿은 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술
  • 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리
  • 서블릿 객체는 싱글톤 패턴으로 관리
  • 멀티 스레딩을 지원

​

---

2 - 3 레이어드 아키텍처

 

• 애플리케이션의 컴포넌트를 유사 관심사 기준으로 레이어를 묶어 수평적으로 구성한 구조
• 프레젠테이션 계층
  • 상황에 따라 유저 인터페이스 계층이라고도 함
  • 클라이언트와 접점
  • 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할
• 비즈니스 계층
  • 상황에 따라 서비스 계층이라고도 함
  • 핵심 비즈니스 로직을 구현하는 영역
  • 트랜잭션 처리나 유효성 검사 등의 작업도 수행
• 데이터 접근 계층
  • 상황에 따라 영속 계층이라고도 함
  • 데이터베이스에 접근해야 하는 작업을 수행

---

2 - 4 디자인 패턴

▶ 생성 패턴

• 객체 생성에 사용되는 패턴
• 객체를 수정해도 호출부가 영향을 받지 않음
• 생성패턴의 종류
  • 추상 팩토리 : 구체적인 클래스를 지정하지 않고 상황에 맞는 객체를 생성하기 위한 인터페이스를 제공하는 패턴
  • 빌더 : 객체의 생성과 표현을 분리해 객체를 생성하는 패턴
  • 팩토리 메서드 : 객체 생성을 서브클래스로 분리해서 위임하는 패턴
  • 프로토타입 : 원본 객체를 복사해 객체를 생성하는 패턴
  • 싱글톤 : 한 클래스마다 인스턴스를 하나만 생성해서 인스턴스가 하낭미을 보장하고 어느 곳에서도 접근할 수 있게 제공하는 패턴

▶ 구조 패턴

• 객체를 조합해서 더 큰 구조를 만드는 패턴
• 구조 패턴의 종류 
  • 어댑터 : 클래스의 인터페이스를 의도하는 인터페이스로 변환하는 패턴
  • 브리지 : 추상화와 구현을 분리해 각각 독립적으로 변행케하는 패턴
  • 컴포지트 : 여러 객체로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루는 패턴
  • 데코레이터 : 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 하는 패턴
  • 퍼사드 : 서브시스템의 인터페이스 집합들에 하나의 통합된 인터페이스를 제공하는 패턴
  • 플라이웨이트 : 특정 클래스의 인스턴스 한 개를 가지고 여러 개의 가상 인스턴스를 제공할 떄 사용하는 패턴
  • 프락시 : 특정 객체를 직접 참조하지 않고 해당 객체를 대행(프락시)하는 객체를 통해 접근하는 패턴

▶ 행위 패턴

• 객체 간의 알고리즘이나 책임 분배에 관한 패턴
• 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배
• 결합도와 최소화를 고려할 필요가 있음
• 행위 패턴의 종류
  
  • 책임 연쇄 : 요청 처리 객체를 집합으로 만들어 결합을 느슨하게 만드는 패턴
  • 커맨드 : 실행될 기능을 캡슐화해서 주어진 여러 기능을 실행하도록 클래스를 설계하는 패턴
  • 인터프리터 : 주어진 언어의 문법을 위한 표현수단을 정의하고 해당 언어로 구성된 문장을 해석하는 패턴
  • 이터레이터 : 내부 구조를 노출하지 않으면서 해당 객체의 집합 원소에 순차적으로 접근하는 방법을 제공하는 패턴
  • 미디에이터 : 한 집합에 속한 객체들의 상호작용을 캡슐화하는 객체를 정의한 패턴
  • 메멘토 : 객체의 상태 정보를 저장하고 필요 따라 상태를 복원하는 패턴
  • 옵저버 : 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버 목록을 객체에 등록해 상태가 변할 떄마다 메서드 등을 통해 객체가 직접 옵저버에게 통지하게 하는 디자인 패턴
  • 스테이트 : 상태에 따라 객체가 행동을 변경하게 하는 패턴
  • 스트래티지 : 행동을 클래스로 캡슐화해서 동적으로 행동을 바꿀 수 있게 하는 패턴
  • 템플릿 메서드 : 일정 작업을 처리하는 부분을 서브클래스로 캡슐화해서 전체 수행 구조는 바꾸지 않으면서 특정 단계만 변경해서 수행하는 패턴
  • 비지터 : 실제 로직을 가지고 있는 객체가 로직을 적용할 객체를 방문하며 실행하는 패턴

---

2 - 5 REST API

▶ REST란?

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

▶ REST API란?

• REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스라고 볼 수

▶ REST의 특징

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

▶ REST의 URI 설계 규칙

• URI의 마지막에는 "/"를 포함하지 않는다.
  • 옳은 예) http://localhost.com/product
    잘못된 예) http:/flocalhost.com/product/
• 언더바를 사용하지 않는다. 대신 하이픈을 사용한다.
  • 하이픈은 리소스의 이름이 길어지면 사용
    옳은 예) http://localhost.com/provider-company-name
    잘못된 예) http://locahost.com/provider_company_name
• URL에는 동사가 아닌 명사를 포함한다.
  • 옳은 예) http://localhost.com/product/123
    잘못된 예) http://localhost.com/delete-product/123
    행위는 HTTP 메서드로 표현할 수 있어야 합니다.
• URI는 소문자로 작성해야 한다.
  • URI 리소스 경로에는 대문자 사용을 피하는 것이 좋음
    일부 웹 서버의 운영체제는 리소스 경로 부분의 대소문자를 다른 문자로 인식하기 때문
    이러한 이유로 RFC3986은 UR 문법 형식을 정의하고 있는데, 호스트의 구성요소를 제외하고 UR의 대소문자를 구분해서 정의하고 있음
• 파일의 확장자는 URI에 포함하지 않는다.
  • HTTP에서 제공하는 Accept 헤더를 사용하는 것이 좋음

 

---