ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Spring Cloud Gateway (feat. spring.io)
    개발 일지/Cloud 2022. 6. 27. 14:30
    반응형

    오... 벌써 시간이 이렇게 지났네요.

     

    지난 서비스 탐색 관련 튜토리얼을 게시하고 나서 한달 이상 지났습니다.

    그동안 다른 자격증 시험도 보고(또 드랍... ㅠㅠ) 회사 일도 하느라 바빴죠...

     

    오늘은 spring.io에 기술된 "Getting Started with Spring Cloud Gateway" 튜토리얼을 따라해보려고 합니다.

    https://spring.io/blog/2019/06/18/getting-started-with-spring-cloud-gateway

     

    Getting Started with Spring Cloud Gateway

    <p>Microservice architectures are great, but as your application programming interfaces (APIs) start to grow, so do the challenges related to their maintenance. </p> <p>For example, as an existing API matures and adds new features it will need to take its

    spring.io

     

    와우... 벌써 3년이 지났군요! (2019.06.18. 게시물입니다.)

     

    아래는 위 페이지의 한글 번역입니다. (의역 포함)


    MSA(마이크로서비스 아키텍처)는 훌륭하지만 API가 증가함에 따라 유지 관리와 관련된 문제도 부각되기 시작합니다.

     

    예를 들어, 기존 API가 보완되고 새로운 기능이 추가됨에 따라 고객 여정에도 반영되어야 하죠.

    API의 세부 사항이 변경되면 클라이언트쪽에서도 이러한 변경 사항을 적용하기 위해 프로그램을 수정해야 합니다.

    이러한 프로세스는 시간이 필요하고, API 개선을 더디게할 수 있습니다.

     

    여러 API를 제공하면 이에 대한 근본적인 문제에 직면하게 됩니다.

    요청과 응답을 적합한 API로 라우팅 하는 방법이나 메시지 불일치를 관리하려면 어떻게 해야 할까요?

    그리고 엔드포인트가 바뀔 때 클라이언트를 지원하는 방법은?

     

    또한 레거시 시스템과의 통합하는 방법도 생각해봐야 합니다. 

    모든 사람이 완전히 새로운 환경에서 앱과 서비스를 구축하기는 현실적으로 불가능에 가깝죠. 

    그 대신 인증 및 기타 지원 서비스를 위해 기존 시스템을 잘 활용해야 합니다.

     

    API 게이트웨이로 이러한 문제들을 해결할 수 있습니다.

    마이크로서비스 아키텍처에서 메시지 라우팅, 필터링 및 프록시를 관리할 수 있습니다.

    많은 "API 관리 게이트웨이"는 SOA로 거슬러 올라가고, 이들은 중앙 집중식 서버로 구현되는 경향이 있습니다.

    하지만 마이크로서비스가 대중화되면서 Spring Cloud Gateway와 같은 경량화되고 독립적이면서 분산된 마이크로 게이트웨이 애플리케이션이 등장했죠.


    아래 튜토리얼에서는 1)게이트웨이로 들어오는 요청의 경로를 변경하고 2)이를 다른 곳의 다른 서비스로 전달합니다.

     

    필요한 tools:

    1. HTTPie - http 호출을 위한 command line 클라이언트

    2. JAVA IDE

    3. command line (bash, DOS, PowerShell, ...)

    4. Httpbin.org - Http Get 요청 데이터를 JSON 응답으로 변환하는 웹사이트 및 진단 도구

     

    Step 1: 프로젝트 생성

    새로운 폴더에 Spring Cloud Gateway 프로젝트를 다운로드하고 압축을 해제합니다.

    (Httpie도 해당 경로에 가져옵니다.)

    spring initializr 에서 의존성은 "Gateway", "Spring Boot Acuator" 2개를 선택합니다.

     

    그리고 IDE 에서 해당 프로젝트를 기동시키고 아래와 같이 정상 여부를 확인할 수 있습니다.

    (IDE에서 JDK 버전을 잘 잡아주세요..! - project/build tool 등 JDK 버전 확인)

    http://localhost:8080/actuator/health

     

    이제 다음 단계를 위해 서버를 내려줍니다. - STOP

     

    Step 2: 게이트웨이에 re-route 구성 추가

    이제 IDE로 다시 돌아가서, main() 메소드가 있는 ~~Application.java 클래스 파일을 엽니다.

    그리고 아래 메소드를 추가합니다.

        @Bean
        public RouteLocator myRoutes(RouteLocatorBuilder builder) {
            return builder.routes()
                // Add a simple re-route from: /get to: http://httpbin.org:80
                // Add a simple "Hello:World" HTTP Header
                .route(p -> p
                .path("/get") // intercept calls to the /get path
                .filters(f -> f.addRequestHeader("Hello", "World")) // add header
                .uri("http://httpbin.org:80")) // forward to httpbin
                .build();
        }

    게이트웨이에 새로운 경로를 추가했습니다. 

    "http://localhost:8080/get" 요청은 이 라우트에서 2개 변경 사항이 적용되겠죠.

    먼저 filters() 메소드는 헤더를 추가하거나 수정할 수 있는데, 위 코드에서는 "Hello" 헤더에 "World" 값을 구성했습니다.

    그리고 uri() 메소드에서는 우리의 요청을 새로운 호스트로 보내줍니다.

    메시지를 전달할 때 "/get" 경로가 유지된다는 것에 유의하세요.

     

    Step 3: 게이트웨이 테스트

    이번에는 HTTPie를 사용해서 앞서 구축한 게이트웨이를 테스트해 보겠습니다.

    GET /get HTTP/1.1
    Accept: */*
    Accept-Encoding: gzip, deflate
    Connection: keep-alive
    Host: localhost:8080
    User-Agent: HTTPie/1.0.2
    
    HTTP/1.1 200 OK
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Origin: *
    Content-Encoding: gzip
    Content-Length: 256
    Content-Type: application/json
    Date: Mon, 10 Jun 2019 13:13:36 GMT
    Referrer-Policy: no-referrer-when-downgrade
    Server: nginx
    X-Content-Type-Options: nosniff
    X-Frame-Options: DENY
    X-XSS-Protection: 1; mode=block
    
    {
        "args": {},
        "headers": {
            "Accept": "*/*",
            "Accept-Encoding": "gzip, deflate",
            "Forwarded": "proto=http;host=\"localhost:8080\";for=\"0:0:0:0:0:0:0:1:52144\"",
            "Hello": "World",
            "Host": "httpbin.org",
            "User-Agent": "HTTPie/1.0.2",
            "X-Forwarded-Host": "localhost:8080"
        },
        "origin": "0:0:0:0:0:0:0:1, 2.102.147.153, ::1",
        "url": "https://localhost:8080/get"
    }

    위 결과를 살펴보면 아래와 같습니다.

    1. 응답은 "Host" 헤더에서 보는 바와 같이 httpbin.org 에서 시작됩니다.

    2. "X-Forwared-Host"는 로컬에서 실행 중인 게이트웨이 애플리케이션 입니다. ("localhost:8080")

    3. Http 헤더 "Hello"는 "World"라는 값을 가지고 삽입되었습니다.

    4. 마지막으로 "uri" 는 본래 요청인 "https://localhost:8080/get" 입니다.

     

    위에서 경로는 1) HTTPie 에서 출발하여 -> 2) 게이트웨이(로컬) -> 3) httpbin.org 그리고 다시 돌아옵니다.

     

    정리하기

    간단하게 스프링 클라우드 게이트웨이 애플리케이션을 기동하고 실행해 봤습니다.

    이를 통해 수신한 요청을 다른 엔드포인트로 전달하는 방법을 살펴봤죠.

     

    이 방법을 사용하여 게이트웨이 애플리케이션에서 다른 서비스로 요청을 자동으로 전달할 수 있습니다.

     

    다음에 해볼만 한 것

    런타임에서 서비스 위치를 찾을 수 있는 동적 게이트웨이를 생성하는 방법을 살펴봅니다.

    Spring Cloud Gateway page(on spring.io), 공식 가이드 살펴보기

    반응형
Designed by Tistory.