시스템 환경에 에지 서버 추가
그림에서처럼 모든 수신 request는 edge server를 통해 routing 된다
외부 클라이언트 --> 모든 요청을 에지 서버로 보냄 --> 에지 서버는 URL 경로를 기반으로 들어오는 요청을 라우팅 함
이전 장에 도커 컴포즈 파일에 product-composite 서비스와 넷플릭스 유레카(검색 서비스)의 포드를 선언해뒀었음 ==> 이건 외부에 공개한 것
❓ 이런 서비스를 에지 서버 뒤로 숨기려면
❗ 두 서비스의 포트 선언을 제거하면 된다.
이렇게 노출 됐던걸
숨겨
스프링 클라우드 게이트웨이 설정
스프링 클라우드 게이트웨이를 에지 서버로 설정하는 방법
책이 자꾸 틀리는데... 짱나게... ^^
-
gateway 스프링 부트 프로젝트를 생성
-
spring-cloud-starter-gateway 의존성을 추가
-
넷플릭스 유레카로 마이크로서비스 인스턴스를 찾고자 spring-cloud-starter-netflix-eureka-client 의존성도 추가
-
공통 빌드 파일 settings.gradle에 에지 서버를 추가
-
마이크로서비스와 같은 내용의 Dockerfile을 추가
-
3개의 도커 컴포즈 파일에 에지 서버를 추가
-
라우팅 규칙 등을 위한 구성을 추가 (스프링 클라우드 게이트웨이 구성 절)
- 에지 서버가 들어오는 모든 트래픽을 처리하므로 product-composite 서비스의 복합 상태 점검 << composite health check>> 을 에지 서버로 옮기기 (복합 상태 점검 추가 절)
복합 상태 점검 추가
- HealthCheckConfiguration 클래스에 상태표시기 선언
ReactiveHealthIndicator 와 getHealth()통해서 상태 표시함
- GatewayApplication클래스에 WebClient.Builder 선언
@LoadBalanced : (유레카) 검색 서버에 등록된 마이크로서비스 인스턴스를 인식하도록
스프링 클라우드 게이트웨이 구성
게이트웨이 구성 시 라우팅 규칙 설정이 중요 + 다른 구성들도 설정해줘야함
1 유레카 클라이언트를 구성 (b/c 게이트웨이는 넷플릭스 유레카를 사용해 트래픽을 보낼 마이크 로서비스를 찾으므로)
2 스프링 부트 actuactor 구성
3 로그 레벨을 구성 (b/c 스프링 클라우드 게이트웨이의 내부 처리 로그를 보기위해)
- 라우팅 규칙
설정 가능 by 자바 DSL을 사용한 프로그래밍 방식 or 구성 방식
--자바 DSL을 사용해 프로그래밍 방식: 규칙이 db 등의 외부 저장소에 저장되어 있는 경우 or RESTful API 또는 gateway로 전송된 메시지를 통해 런타임에 제공되는 경우에 유용.
보통은 구성 파일 src/main/resources/application.yml에서 라우팅 경로를 선언하는 방식 사용
-- 라우팅 경로 정의 규칙
1. 조건자(predicate) : 수신되는 HTTP 요청 정보를 바탕으로 경로를 선택
2. 필터(filter): 요청이나 응답을 수정
3. 대상 URI (destination URI) : 요청을 보낼 대상
4. ID: 라우트 경로 이름
URL 경로가 /product-composite로 시작하는 수신 요청을 product-composite 서비스로 라우팅하기
유레카는 API와 웹 페이지 모두를 클라이언트에게 공개하는데, 유레카의 API와 웹 페이지 를 명확하게 분리하고자
if ) 에지 서버로 전송된 경로 == /eureka/api/로 시작
then) 유레카 API에 대한 호출로 처리
if) /eureka/web/으로 시작하는 요청
then ) 유레카 웹 페이지에 대한 호출로 처리
웹 페이지 요청은 http://$app.eureka-server}:8761로 라우팅된다
++ 조건자와 필터를 이용한 요청 라우팅 실습
HTTP 코드 테스트용 사이트인 http://httpstat.us/를 이용해 HTTP 코드를 테스트
요청을 http://${hostname):8080/headerrouting으로 라우팅하기 위해서는 ==> 1 i feel lucky 호스트에 대한 호출은 200 OK를 반환하도록 설정 -> 2 im.a.teapot 호스트에 대한 호출은 418 반환 하도록 설정 -> 3 다른 호스트 이름에 대한 호출은 501 반환해야 하도록 설정
에지 서버 사용
에지서버 테스트
bash 테스트는 윈도우에서 안돼서 빌드만 해보겠음
도커 엔진 외부로 공개되는 항목 확인
1 서비스가 노출하는 포트를 확인
docker-compose ps gateway eureka product-composite product recommendation review
외부노출은 gateway만!
좀 복잡하긴 하지만 나오긴 나옴
라우팅 규칙 테스트
1 produc-composite API를 호출한 후 --> 2 유레카 API를 호출하고 --> 3 해당 웹 페이지를 방문한다 --> 4 호스트 이름 기반의 라우트 경로를 테스트
- 1 에지 서버를 통해 product-composite API 호출
docker-compose logs -f --tail=0 gateway
엇 근데 책에서처럼 지정한 조건자를 바탕으로 패턴 검색이 수행됐다는 것을 로그출력에서 확인하진 못했다
책처럼 Pattern "/product-composite/* *" matches gainst value 로 시작하는 로그는 못찾았지만
: http://a7d2c2b474e8:8080/product-composite/2 로 요청이 전송된건 확인가능
에지 서버를 통해 유레카 호출
http://localhost:8080/eureka/web
위의 인스턴스 목록과 동일
호스트 헤더 기반 라우팅
정리 및 느낀점
10장에서는 스프링 클라우드 gateway를 edge server로 사용하는 방법 (==마이크로서비스 기반 시스템 환경의 공개 API를 제어하는 방법)을 배웠음.
1 외부에서 -> <에지 서버를 통해> -> 마이크로서비스의 공개 API에 접근하는 방법과
2 마이크로서비스 환경 내부에서 -> 사설 API에 접근하는 방법을 봤음
여기서 공개는 : product-composite 서비스와 + 넷플릭스 유레카(검색 서비스) 가 에지 서버를 통해 공개됨
그리고 사설(외부 접근 차단) 은 : product와 recommendation, review 핵심 서비스
라우팅 규칙은 조건자, 필터, 대상 URI 바탕으로 설정가능했고
검색 서비스를 사용하도록 게이트웨이를 구성할 수도있었음.
프로젝트에서 사용한다면 유레카 까지는 필요없는 경우라면 게이트웨만을 이용해서 외부에서 공개 api에 접근하도록 까지는 설정할 수 있을 것 같기도 하다. 근데 검색 서버가 있을 때 가장 강한 강점을 갖는 것같기도
