Spring Cloud Gateway 테스트 코드와 리펙터링 (Kotlin-DSL)

 

사진: Unsplash 의 Jeremy Perkins

 

 

게이트웨이 코드를 작성하다 보면, 이게 제대로 작동은 하는 것인가? 하고 의문이 들때가 있다

이러한 의문은 개인 프로젝트를 진행할 때뿐만 아니라 회사에서 동료들과 일할 때도 자주 떠올랐다

그리고, 비슷한 URI와 Route들의 순서 배열에 따라 몇몇 Route들이 동작하지 않기도 했다

길어진 Route 명세를 파악하기 위해 모니터를 위 아래로 훑는 시간도 많이 들고,

이 과정에서 실수할 소지가 많다는 것을 느꼈다

 

그래서 시간을 내서 리펙터링을 했고 성공적이었다

 

아래는 그때의 노하우를 좀 더 가다듬은 방식으로 진행한 것이다

 

문제의 YAML 명세

spring:
  cloud:
    gateway:
      routes:
        - id: ITEM-SERVICE
          uri: lb://ITEM-SERVICE
          predicates:
            - Path=/items/**
          filters:
            - RemoveRequestHeader=Cookie
        - id: ORDER-SERVICE
          uri: lb://ORDER-SERVICE
          predicates:
            - Path=/orders/**
            - Method=POST,GET
          filters:
            - RemoveRequestHeader=Cookie
        - id: USER-SERVICE
          uri: lb://USER-SERVICE
          predicates:
            - Path=/users/**
          filters:
            - RemoveRequestHeader=Cookie

 

 

위 명세는 각 상품, 주문, 회원 서비스에 대한 것이다

 

그리고 아직 필터가추가되지 않았다

예를 들면, 특정 API에 대해 인증을 하는 경우가 일반적이다

추가하면 아래처럼 바뀌게 된다

 

spring:
  cloud:
    gateway:
      routes:
        - id: ITEM-SERVICE
          uri: lb://ITEM-SERVICE
          predicates:
            - Path=/items/**
            - Method=GET
          filters:
            - RemoveRequestHeader=Cookie
        - id: ITEM-SERVICE
          uri: lb://ITEM-SERVICE
          predicates:
            - Path=/items/**
            - Method=POST,UPDATE,DELETE
          filters:
          	- AuthenticationFilter
            - RemoveRequestHeader=Cookie
        - id: ORDER-SERVICE
          uri: lb://ORDER-SERVICE
          predicates:
            - Path=/orders/**
            - Method=POST,GET,UPDATE,DELETE
          filters:
            - AuthenticationFilter
            - RemoveRequestHeader=Cookie
        - id: USER-SERVICE
          uri: lb://USER-SERVICE
          predicates:
            - Path=/users/**
          filters:
            - RemoveRequestHeader=Cookie

 

 

아마 이 글을 보는 여러분들은 그럴수도 있겠구나라고 생각할지도 모른다

 

하지만 10개가 훨씬 넘는 마이크로서비스라면 ..

각 서비스마다 평균 Endpoint가 10개 이상이라면 ..

 

내가 본 건 800 라인이 넘어가는 yaml 이었였다

난 수기로 작성한 설정 파일이 그렇게 긴 것을 많이 본적이 없었다

 

문제는 길고 동작을 잘 하면 되는데,

문제가 생길 경우 위 아래를 훑으면서 문제의 소지가 있을 만한 URI를 찾아야 하는 것이었다...

또 수십개의 Endpoint가 등록되었다고 해서 그 모두가 잘 동작하는지 확신할 수 없었다

 

라우터 테스트 코드 by Kotlin DSL

그럴 경우에 대한 대비책이다. 우선 방어 코드가 있어야 한다

    @Test
    fun `route 목록을 검증한다`() {

        val routes = routes()

        routes["ITEM-SERVICE"] shouldBeRoute {
            path("/items")
            httpMethods(GET, POST)
            filter<AuthFilter>()
        }

        routes["ORDER-SERVICE"] shouldBeRoute {
            path("/orders")
        }
    }

 

KotlinDSL이 있으면 Java로 작성한 장황한 코드보다 훨씬 우아하게 작성할 수 있다

(실제 초창기 회사에서 작성한 코드는 저렇게 우아하지는 않았다.. 저건 화장이 된 코드다)

 

일부러 URI값을 조금씩 수정하면서 Red / Green을 정상적으로 확인하면 안심하고 쓸 수 있다

 

라우터 코드 리펙터링 버전

프로덕션  코드는 default parameter 문법을 사용하면 쉽게 여러 상황에 대한 코드를 작성할 수 있다

 

 

 

    @Bean
    fun routes(builder: RouteLocatorBuilder, loggingFilter: GlobalLoggingFilter): RouteLocator {

        return builder.routes()
            .route { it.simpleRoute(serviceName = "micro-service-1", path = "/ms-1", filter = authFilter) }
            .route { it.simpleRoute(serviceName = "micro-service-2", path = "/ms-2", methods = arrayOf(POST, PUT, DELETE)) }
            .build()
    }

 

filter가 있거나, 없거나, http method 유무에 관계 없이 동작하는 코드를 쉽게 작성가능 하다

 

* 참고로 filter 등록 부분은 구현되지 않았다