기초 지식 - 1

서버 간 통신

• 어떤 포털 사이트를 하나의 서비스 단위로 개발한다고 가정.
• 즉, 블로그, 카페, 메일 등의 기능들을 하나의 애플리케이션에 통합
• 이렇게 구성한다면 서버를 업데이트하거나 애플리케이션을 유지보수할 때마다 '사이트 작업 중입니다.' 팻말을 걸고 작업해야함
• 그만큼 개발에 보수적인 입장을 취할 수 밖에 없고, 서비스 자체의 규모도 커지기 때문에 서비스를 구동하는데 걸리는 시간도 길어짐

→ 이러한 문제를 해결하기 위한 것이 마이크로서비스 아키텍처(MSA; Microservice Architecture)
→ 서비스 규모를 작게 나누어 구성한 아키텍쳐

• 앞선 예로 든 포털 사이트에 적용한다면, 애플리케이션 하나에 여러 기능을 넣어 개발하지 않고 블로그 프로젝트, 카페 프로젝트, 메일 프로젝트 등 애플리케이션을 기능별로 나눠서 개발하게 됨

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

예를 들어, 사용자가 블로그 기능을 사용하기 위해 로그인 서비스를 거쳐야만 하는 상황등이 있음
이런 상황에서의 통신을 서버 간 통신이라고 함

✅ 서버 간 통신은 한 서버가 다른 서버에 통신을 요청하는 것을 의미하며, 한 대는 서버, 다른 한 대는 클라이언트가 되는 구조

몇 가지 프로토콜에 의해 다양한 통신 방식을 적용할 수 있지만 가장 많이 사용되는 방식은 HTTP/HTTPS 방식

---

스프링 부트의 동작 방식

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

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

일반적으로 서블릿은 서블릿 컨테이너에서 관리.
서블릿 컨테이너 : 서블릿 인스턴스를 생성하고 관리하는 역할을 수행하는 주체
톰캣은 WAS의 역할과 서블릿 컨테이너의 역할을 수행하는 대표적 컨테이너

서블릿 컨테이너 특징

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

스프링에서는 DispatcherServlet이 서블릿 역할을 수행. 일반적으로 스프링은 톰캣을 임베드해 사용
→ 서블릿 컨테이너와 DispatcherServlet은 자동 설정된 web.xml의 설정값을 공유

DispatcherServlet 동작

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

• 핸들러 매핑 : 요청 정보를 기준으로 어떤 컨트롤러를 사용할지 선정하는 인터페이스. 여러 구현체를 가짐

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

• BeanNameUrlHandlerMapping
  • 빈 이름을 URL로 사용하는 매핑 전략
  • 빈을 정의할 때 슬래시("/")가 들어가면 매핑 대상이 됨
  • ex. @Bean("/hello")
• ControllerClassNameHandlerMapping
  • URL과 일치하는 클래스 이름을 갖는 빈을 컨트롤러로 사용하는 전략
  • 이름 중 Controller를 제외하고 앞부분에 작성된 suffix를 소문자로 매핑
• SimpleUrlHandlerMapping
  • URL 패턴에 매핑된 컨트롤러를 사용하는 전략
• DefaultAnnotationHandlerMapping
  • 어노테이션으로 URL과 컨트롤러를 매핑하는 방법
• 뷰 리졸버 : 뷰의 렌더링 역할을 담당하는 뷰 객체를 반환함

---

레이어드 아키텍쳐 (Layered Architecture)

애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어를 묶어 수평적으로 구성한 구조를 의미

Spring MVC는 Model-View-Controller의 구조로 View와 Controller는 프레젠테이션 계층 영역이며, Model은 비즈니스와 데이터 접근 계층의 영역으로 구분할 수 있음
다만, 스프링 MVC 모델로 레이어드 아키텍처를 구현하기 위해서는 역할을 세분화함
비즈니스 계층에 서비스를 배치해 엔티티와 같은 도메인 객체의 비즈니스 로직을 조합하도록 하고 데이터 접근 계층에는 DAO (Spring Data JPA에서는 Repository)를 배치해 도메인을 관리함

스프링 레이어드 아키텍쳐

• 프레젠테이션 계층

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

• 비즈니스 계층

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

• 데이터 접근 계층

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

가장 중요한 부분은 비즈니스 계층 영역인데, 비즈니스 로직을 어디서 담당할지 결정하고 설계하는 것이 좋음
비즈니스 로직은 도메인 계층에서 담당하는 것이 일반적
스프링에서 JPA를 사용하면 @Entity를 정의한 클래스가 도메인 객체가 되며, 이곳에서 비즈니스 로직을 설계하면 좋음

---

디자인 패턴

소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해 고안된 해결책
'패턴'이라는 단어는 애플리케이션 개발에서 발생하는 문제는 유사한 경우가 많고 해결책도 동일하게 적용할 수 있다는 의미를 내포
그러나 모든 문제의 정답은 아니며 상황에 맞는 최적 패턴을 결정해서 사용하는 것이 바람직

종류

GoF 디자인 패턴 : 디자인 패턴을 구체화해서 정리한 대표적인 분류 방식

생성(Creational) 패턴	구조(Structural) 패턴	행위(Behavioral) 패턴
추상 팩토리	어댑터	책임 연쇄
빌더	브리지	커맨드
팩토리 메서드	컴포지트	인터프리터
프로토타입	데코레이터	이터레이터
싱글톤	퍼사드	미디에이터
	플라이웨이트	메멘토
	프락시	옵저버
		스테이트
		스트레티지
		템플릿 메서드
		비지터

GoF 디자인 패턴은 생성 패턴, 구조 패턴, 행위 패턴 총 세가지로 구분됨

• 생성 패턴

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

• 구조 패턴

  • 객체를 조합해도 더 큰 구조를 만드는 패턴

• 행위 패턴

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

생성 패턴

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

구조 패턴

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

행위 패턴

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