주요사항
- 클라우드에서는 어플리케이션 이 확장 가능해야 한다
- 인스턴스가 동적으로 생성되고 제거 되기에 클라우드 내에서 요청한 서비스로 호스팅이 가능해야 한다
- 서비스는 클라우드를 인식 하고 있어야 한다
주요 패턴
- 컨피그 서버(Config Server)
- 클라우드가 변경되면 설정도 변경되어야 하는데 이를 앱에 정적으로 설정해두면 변경시마다 매번 수정을 해야함
- 설정값을 보관해둔 서버를 만들어 구동시에 설정을 가져오도록 하여 빠르게 인스턴스 생성 가능
- 의문점
- 초기 구동시에만 설정을 가져온다면 앱 마다 따로 설정을 해두어도 별로 문제가 없을것 같은데?
원격으로 서비스를 배포할때는 의마가 있을것 같다 → 설정값 암호화
- 생각
- 모든 앱의 설정을 컨피그 서버에서 모두 관리가 가능해질듯하다
- 개발, 테스트, 배포 설정을 한번에 변경 가능하겠네
- 필요에 따라 동적으로 설정값 업데이트도 가능할듯
- 서비스 탐색(Service Discovery) → Eureka
- 연결하려는 서비스의 정보(URL, IP, PORT)와 사용가능한 정보를 등록해서 필요에 따라 라우팅 하기 위해 필요한 기능
- 서비스 탐색 서버가 존재하며 유기적으로 서비스가 등록되며 이를 조회 할 수 있다.
- 로드밸런싱(Ribbon)의 역활도 수행함 → 동일한 요청에 대한 부하분산이 주 목적
- 의문점
- 서비스가 강제 종료되면 어떡하나? → API 주기적으로 쏴서 점검 하면 되겠네.
- 게이트웨이(Gateway) → Zuul
- 서비스의 엔드포인트를 단순화 해 서비스 탐색 서버나 로드밸런서가 경로를 찾기 위한 미들웨어
- 요청에 대한 라우팅 처리도 진행 → 특정 요청에 대한 최적 경로 전달이 목적
- 서킷 브레이커(Circuit Breaker) → Hystrix
- 마이크로서비스간 호출시 특정 서비스가 고장나 망가져도 나머지는 동작 할 수 있도록
고장난 특정 서비스만 차단 하는것
- 고장난 서비스에 대한 요청을 차단 하고 주기적으로 상태를 점검해 복구가 되면 다시 요청을 전달한다