MSA
서비스 구축 방법
- 모놀로식
- 모든 비지니스 로직이 하나의 프로젝트에 들어있다.
- MSA
- 각각의 비지니스 로직을 분리하여 개별 프로젝트로 개발한다.
- 가장 앞단에서 API Gateway를 통해 각 서비스에 요청을 분산하여 관리한다.
MAS 장단점
- 장점
- 서비스별 스케일링 가능
- 서비스별 다른 프레임워크로 사용 가능
- 하나의 서비스가 OFF 되더라도 나머지 서비스 동작 가능
- 부분적으로 로직 업데이트 가능
- 단점
- 초기 구성의 난이도
- 서버간 호출 비용
- 분산 관리
MAS 요소
- 서비스 로직
- 게이트웨이
- 모니터링 서버
- 변수관리 서버
스프링 MSA 모식도

- Spring Cloud Gateway: SCG
- URL 주소에 대해서 아래 세부 경로에 따라 각각의 스프링 부트 어플리케이션에 분배하는 분배기 역할을 수행
- Spring Cloud Eureka Server
- Eureka Client 설정을 해둔 서버를 Eureka Server에 띄워준다.
- 각 어플리케이션이나 Gateway가 활성화되어 있는지 확인하는 모니터링 서버
- Spring Cloud Gateway에 목록을 전달하여 Gateway가 로드밸런싱 대상을 설정하도록 작업을 한다.
- Spring Cloud Eureka Client
- Eureka Server에 등록되는 요소로 스프링 부트 어플리케이션과 같은 여러 스프링 프레임워크 서버에 설정이 가능하다.
- Spring Config Server
- 변수 값들을 제공하는 서버로 특정 경로로 접근하면 미리 사전에 설정해둔 변수 값들을 제공 받을 수 있다.
- MSA를 구축하면 각각의 스프링 부트 어플리케이션에 yml / properties에 값을 명시하는 것이 아닌 config server로 부터 데이터를 받아서 사용한다.
- Config Repository
- Config Server는 단순하게 데이터를 전달하는 매개체로 실제 데이터는 Config Server 뒷단에 깃허브 리포지토리와 같은 저장소를 물려서 사용한다.
Config Repository
Config 저장소의 종류
- Git Service(github, gitlab, git bucket)
- Redis
- RDB
- Document NoSQL
- File …
깃허브 레퍼지토리 생성
- private 레퍼지토리 생성
- creating a new file
- 이름-환경.yml
- e.g. ms1-dev.yml
- 비대칭 키 생성(Spring Cloud Server가 생성된 private 레퍼지토리에 접근하기 위함)
- Public Key: 깃허브 레퍼지토리에 등록
- Private Key: Spring Cloud Server에 저장(데이터를 가져오기 위해 증명에 필요)
- bash환경에서 Public & Private Key 생성
- ssh-keygen -m PEM -t rsa -b 4096 -C “fdsafdsafdsanwelwn2132ssle2sfsnedfs” - Public Key 복사 > 깃허브 레퍼지토리 Settings > Deploy keys > add Deploy keys: 키 붙여넣기
Config Server
private 깃허브 레퍼지토리 접근
- 깃허브 레퍼지토리 ssh 주소
- 생성한 private key 복사
- 새 프로젝트 생성(Config Server 용도)
- config-server, spring security 의존성 추가
- @EnableConfigServer
- yml 파일 변수 설정(privateKey 추가 등..)
- 시큐리티 설정(Config Server로의 외부 접속 차단)
- 프로젝트 빌드 후, http://IP:Port/이름/환경
Config Client
- 서비스 로직 수행하는 스프링 부트 어플리케이션
- 스프링 부트 어플리케이션에 Config Client 설정을 해줘서 Config Server에서 보내주는 데이터를 받는다.
- Config Client 의존성 추가 후, yml 파일에 Config Server를 바라보게 설정한다.
Eureka Server
- Eureka Server
- MSA를 구성하는 서비스들을 모니터링
- 가동되는 모든 Config Client의 모든 서버 정보를 목록으로 가지고 Cloud Gateway에 해당 목록을 전달한다.
- 구현 방법
- Eureka Server, Spring Security 의존성 추가
- @EnableEurekaServer 추가(Eureka Server로 동작하기 위한 어노테이션)
- 환경파일 설정
- 시큐리티 설정
Eureka Client
- 각 어플리케이션을 Eureka Client 로 등록하여 Eureka Server 가 관리하게 한다.
- Eureka Discovery Client 의존성 추가
- @EnableDiscoveryClient 추가
- Eureka 서버와 연결(yml 파일)
Spring Cloud Gateway
- Spring Cloud Gateway란?
- MSA 제일 앞단에서 클라이언트의 요청을 받아 경로와 조건에 알맞은 마이크로 서비스 로직에 요청을 전달한다.
- 무중지 상태로 모든 요청을 받아야하기에 설정이 까다롭다.
- Spring Cloud Gateway 특성
- 논 블로킹 방식으로 동작하는 WebFlux 프레임워크와 네티엔진 사용
- 구현 방법
- gateway 의존성 추가
- 마이크로 서버 어플리케이션 2개 준비
- 환경설정(yml / class)
Gateway & Eureka
- Gateway & Eureka 연동 이유
- 서비스 디스커버리: 각 서비스의 위치를 동적으로 발견하고, 게이트웨이가 이를 기반으로 요청을 적절한 서비스로 라우팅할 수 있다.
- 자동 스케일링 지원: 각 서비스 인스턴스의 추가 및 제거를 감지하고, 게이트웨이가 이를 기반으로 동적으로 라우팅을 조정할 수 있다.
- 로드 밸런싱: 각 서비스의 인스턴스를 파악하고, 게이트웨이가 이를 기반으로 로드 밸런싱을 수행할 수 있다.
- 서비스 상태 모니터링: 각 서비스의 상태를 모니터링하고, 게이트웨이가 이를 기반으로 요청을 건강한 서비스 인스턴스로 라우팅할 수 있다.
- Gateway & Eureka 연동 방법
- Gateway 서버에 Eureka Client 의존성 추가하여 연동
- 설정파일에서 같은 url 접근시 라우팅 유레카 로드 밸런싱이 가능하다.
Actuator를 활용한 라우팅
- Actuator
- gateway 동작 중에 서버를 멈추지 않고 라우팅을 추가한다. (예를 들어 msa 하나를 추가할 때 gateway를 중지하지 않고 서버 하나를 추가시킨다.)
- 구현 방법
- Spring Boot Actuator 의존성 추가
- 설정파일
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
# 일단 msa 1개만 설정 spring: cloud: gateway: routes: - id: ms1 uri: http://localhost:8081 predicates: - Path=/ms1/** # Actuator 설정 management: endpoint: gateway: enabled: true endpoints: web: exposure: include: gateway
- 라우팅 명령어
- 존재하는 라우팅 확인
- GET: /actuator/gateway/routes
- 라우터 추가
- POST: /actuator/gateway/routes/{id}
1 2 3 4 5 6
{ "predicate": "Paths: [/msa/**]", "filters": [], "uri": "http://localhost:8082", "order": 0 }
- POST: /actuator/gateway/routes/{id}
- 리프레쉬(라우터 추가/제거 시 리프레쉬 필요)
- POST : /actuator/gateway/refresh
- 라우터 제거
- DELETE : /actuator/gateway/routes/{id}
- 특정 라우터 확인
- GET : /actuator/gateway/routes/{id}
- 글로벌 필터 목록
- GET : /actuator/gateway/globalfilters
- 특정 라우터 필터 목록
- GET : /actuator/gateway/routefilters/{id}
- 존재하는 라우팅 확인
Filter

- Gateway Global Filter
- 모든 라우팅에 대해서 적용되는 필터
- 주로 로깅, 인증, 권한 검증 등의 작업
- Gateway Local Filter
- 특정 ms에 적용되는 필터
- 특정 서비스에 대한 요청 변환, 응답 변환, 특정 헤더 추가 등의 작업
- 모든 요청은 기본적으로 한 필터당 pre, post 각각 한 번씩 총 2번 필터를 거친다(설정으로 변경 가능)