스프링 프레임워크를 사용하여 마이크로서비스 아키텍처를 구현
마이크로서비스 아키텍처는 각 컴포넌트를 API를 통해 다른 서비스와 통신을 하고, 모든 서비스는 각각 독립된 서버로 운영하고 배포하여 서로 의존성이 없는 개발 방법
각각의 서비스들은 독립적으로 운영되고, 서로에게 의존성이 없어 한 서비스에 문제가 발생하여도 다른 서비스에 영향을 주지 않음
-
Apigateway-service
외부(Client)에서 마이크로서비스를 호출할 때, 등록되어 있는 애플리케이션의 Endpoint를 관리하고, Endpoint에 진입하게 해주는 진입로의 역할을 함
인증 및 권한 부여 기능이 있고, 로깅, 추적의 기능을 할 수 있음
AuthorizationHeaderFilter를 통해 인증이 필요한 Endpoint에 인증 및 인증 권한을 부여할 수 있음
ex) login 페이지는 인증이 login 이전까지는 인증이 필요하지 않지만, login을 하고 난 후의 모든 user-service의 기능은 인증이 필요함
-
인증 방법 (JWT 토큰 사용)
-
POST -> /authenticate(인증 요구) username = ... & password = ...
-
서버에선 DB에 저장된 것과 같은지 확인하는 절차를 밟음
-
같다면 Bearer Token 기반의 JWT토큰을 리턴해줌
-
Client는 리턴받은 JWT와 함께 원하는 기능을 추가적으로 요청함 (Authorization : JWT(Bearer Token))
-
서버에선 JWT토큰을 비교하고, 같다면 Client가 요청한 기능의 정보를 처리해줌
- ApiGateway-service와 User-service는 개인 Github에 저장되어있는 token.secret 값을 통해 토큰을 인코딩하고, 디코딩하여 인증여부를 판단함
- 각 service가 인증할 때 사용하는 token.secret이 다르면 인증이 허가되지 않으므로 Github에 개인저장소를 사용한 것
-
JWT토큰 처리과정 1,2에 해당
Client가 로그인을 시도하였을 때의 이메일, 비밀번호 값을 Token에 저장하고 인증처리를 요구함
-
JWT토큰 처리과정 3에 해당
인증이 처리되면, 그 결과를 가지고 JWT token을 생성해줌
JWT token은 로그인이 성공한 계정의 정보와 Github개인 저장소의 token.secret을 HS512로 암호화한 것과 함께 builder()메서드를 통해 만들어냄
setExpiration으로 유효기간을 설정할 수 있음
-
JWT토큰 처리과정 4에 해당
Client가 반환받은 JWT토큰과 함께 기능을 요청하면, 서버 내부에서 JWT토큰의 유효성을 판단함
처음엔 JWT토큰이 실려 있는지 확인하고, 실려 있다면 인증을 위한 형식으로 바꿔주고 isJwtValid() 메서드를 통해 인증을 진행함
-
JWT토큰 처리과정 5에 해당
서버는 Client가 실어준 토큰을 디코딩하여 비교하여 인증여부를 확인함
-
-
비밀번호 암호화
회원이 회원가입 시 랜덤한 userId를 생성해주고, 입력한 비밀번호가 DB에 저장될 때 비밀번호를 암호화하여 저장함
userId는 UUID의 랜덤ID를 이용하여 생성함
-
이미지 업로드
Amazon의 S3(객체 스토리지)를 사용하여 이미지를 업로드하고 관리함
-
Circuitbreaker
장애가 발생하는 서비스에 반복적인 호출이 되지 못하게 차단하고, 특정 서비스가 정상적으로 동작하지 않을 경우 장애를 회피하게 해주는 기술
마이크로서비스 아키텍처는 하나의 서비스에 문제가 생겨도 다른 서비스에는 영향을 끼치지 않아야 하는데, Circuitbreaker를 통해 이를 구현할 수 있음- 모든 서비스가 정상적으로 동작하는 rudd
- Cell-service가 강제로 종료됐을 경우, User-service에 영향을 미치지 않음
- 모든 서비스가 정상적으로 동작하는 rudd