250211 TIL - MSA(Microservice Architecture) 강의 마무리

2025.02.11 <오늘 배운 내용 복기 및 요약>

---

1-7강 보안 구성 - OAuth2, JWT 기반 보안 구성

OAuth2? 토큰 기반의 인증 및 권한 부여 프로토콜

4가지 역할 정의 - 리소스 소유자, 클라이언트, 리소스 서버, 인증 서버

---

JWT

- JSON 형식이 자가 포함된 토큰, 클레임을 포함한 정보를 전달함, 암호화를 통해 데이터의 무결성과 출처 보장(일종의 티켓)

구성 3 - 헤더, 페이로드, 서명   /   특징 3 - 자가 포함, 간결성, 서명 및 암호화

https://jst.io/주요 

 

- 실습내용 요약 

Auth Service 생성 ->  AuthConfig.java, AuthService.java, AuthController.java
순서대로 -> /auth/signIn 경로 허용, 사용자 ID로 JWT 토큰 생성 ,사용자 ID를 받아 토큰 발급 API 구현

Cloud Gateway 구현 -> LocalJwtAuthenticationFilter.java , application.yml
순서대로 -> JWT 인증 필터 추가, JWT 관련 설정 및 라우팅

 

 

 

---

1-8강 Config Server

Spring Cloud Config - 분산 시스템 환경에서 중앙 집중식 구성 관리를 제공하는 프레임워크, 실시간 반영 가능, 애플리케이션 설정을 중앙관리

Config 서버 - ConfigApplication.java , application.yml ,    config-repo 디렉토리 안에 product-service.yml, product-service-local.yml

Product 서비스 - Spring Cloud Config 의존성 추가하고 , application.yml Config 서버 설정 가져오게 port 값 0으로 설정, ProductController.java

결과적으로 Config 서버는 중앙 집중식으로 환경별 설정 파일을 관리하는걸 알수있고 Product 서비스는 설정을 Config 서버를 이용해서 불러올수있는 기능을 함

그리고 액츄에이터와 리프레시를 사용해서 실시간 반영 가능

 

 

---

1-9강 분산추적 - Spring Cloud Sleuth, Zipkin

분산추적이란? 서비스간의 요청흐름을 추적하고 모니터링하는 방법, 각서비르의 호출관계와 성능을 시각화해서 편의성이 좋음
Trace, Span, Context

필요한 이유 : 복잡한 호출관계를 보기 종게 정리할 수 있음 -> 빠른 흐름 파악 -> 성능 병목이나 오류 빠른 진단 가능

++수업에선 Docker를 사용했지만 Window기준으로는 wsl이 더 편하다고함

docker run -d -p 9411:9411 openzipkin/zipkin  

도커 서버에서 Zipkin서버 실행하면 관계를 화살표로 보여줌 = 트레이스 데이터 시각화

Product Service - Zinkin,분산 추적 관련 의존성 추가하고 yml 파일에 프로덕트에서 진킨 서버로 트레이스 데이터 전송하는거 설정해줌( "management: zipkin: tracing: endpoint: "http://localhost:9411/api/v2/spans" tracing: sampling: probability: 1.0")

Order Service - 프로덕트랑 같은 의존성 추가, 야믈파일에 오더 서비스에서 집킨서버 트레이스 데이터 전송 설정해줌 프로덕트랑 똑같음

 

유레카 서버 -> 오더 서비스 -> 프로덕트 서비스 실행하면됨 

정리하면 오더, 프로덕트 서비스의 트레이스랑 스팬을 집킨 서버로 전송해서 집킨이 시각화하고 분석해줌

집킨 서버 사용하는 애플리케이션(?)에는 Docker랑 wsl이 있음

---

1-10강 이벤트 드리븐 아키텍처와 스트림 처리 (Spring Cloud Stream)

이벤트 드리븐 아키텍처란? 시스템에서 발생하는 이벤트(상태 변화나 행동)를 기반으로 동작하는 소프트웨어 설계 스타일입니다. 이벤트는 비동기적으로 처리되며, 서비스 간의 느슨한 결합을 통해 독립적으로 동작할 수 있게 합니다.

이벤트, 이벤트 소스, 이벤트 핸들로, 이벤트 버스

장점 : 느슨한 결합, 확장성, 비동기 처리 / 단점 : 복잡성 증가, 장애전파

ex) 온라인 쇼핑몰이라면
1. 이벤트 소스: 사용자가 온라인 쇼핑몰에서 주문을 합니다.
- 주문 서비스가 '주문 생성' 이벤트를 발생시킵니다.
2. 이벤트 버스: Kafka나 RabbitMQ와 같은 메시지 브로커가 '주문 생성' 이벤트를 전달합니다.
3. 이벤트 핸들러
- 재고 서비스: '주문 생성' 이벤트를 수신하여 재고를 확인하고 업데이트합니다.
- 배송 서비스: '주문 생성' 이벤트를 수신하여 배송 준비를 시작합니다.
- 결제 서비스: '주문 생성' 이벤트를 수신하여 결제 처리를 합니다.

Spring Cloud Stream? 이벤트 드리븐 마이크로서비스를 구축하기 위한 프레임워크, Kafka, RabbitMQ 등의 메시지 브로커와 통합하여 이벤트 스트리밍을 처리, 프로듀서와 컨슈머 간의 통신을 추상화하여 간편하게 이벤트 기반 애플리케이션을 개발가능

하는 순서  :
1. 메시지 브로커 준비 (Kafka, RabbitMQ)
2. 이벤트 소스 서비스 (Producer) : Spring Cloud Stream 의존성 추가, 야믈파일에서 스프링 클라우드 스트림 바인더 설정, OrderProducer.java 파일에서 이벤트 발생 클래스 작성 @Service로, OrderController.java에서는 REST API를 통해 이벤트 발행 트리거
3. 이벤트 핸들러 서비스 (Consumer) : 프로듀서와 의존성 동일, 바인더 설정 동일, OrderConsumer.java 이벤트 수신하고 처리하는 클래스
결과: 메시지 브로커 실행 -> 프로듀서 서비스 실행 -> 컨슈머 서비스 실행  == 메시지 브로커 켜서 통신 연결, 프로듀서 서비스의 오더스 API로 이벤트 생성, 메시지 브로커에서 이벤트를 수신하고 처리 (컨슈머 서비스의 요구대로)

Producer 서비스 --> 메시지 브로커 --> Consumer서비스 순서

여기서 Spring Cloud Stream 의 역할? 메시지 브로커를 바인딩해서 메시지 송수신 과정을 추상화한 것, 아무 브로커로 자유롭게 변경할 수 있게됨 느슨하게 결합된 상태로 만들어서 비동기 메시지를 수행함(?)

== 그냥 메시지 브로커 관리