HTTP 헤더 라우팅 패턴

헤더 기반 라우팅을 사용하면 HTTP 요청에 HTTP 헤더를 지정하여 각 요청별로 적절한 서비스를 타겟팅할 수 있습니다. 예를 들어 x-service-a-action: get-thing 헤더를 보내면 Service A에서 get thing을 실행할 수 있습니다. 이 경우에도 요청 경로는 작업하려는 리소스에 대한 지침을 제공하기 때문에 중요합니다.

작업에 HTTP 헤더 라우팅을 사용하는 것 외에, 버전 라우팅, 기능 플래그 활성화, A/B 테스트 또는 이와 유사한 요구 사항을 위한 메커니즘으로 HTTP 헤더 라우팅을 사용할 수도 있습니다. 실제로는 강력한 API를 만들기 위해 헤더 라우팅을 다른 라우팅 방법 중 하나와 함께 사용하게 될 가능성이 높습니다.

HTTP 헤더 라우팅 아키텍처에서는 일반적으로 다음 다이어그램과 같이 올바른 서비스로 라우팅하고 응답을 반환하는 마이크로서비스 앞에 단순한 라우팅 계층을 둡니다. 이 라우팅 계층은 모든 서비스를 포함하거나 버전 기반 라우팅과 같은 작업을 지원하는 일부 서비스만 포함할 수 있습니다.

장점

구성 변경은 최소한의 작업으로 이루어지며 쉽게 자동화할 수 있습니다. 또한 이 방법은 유연하며 서비스에서 원하는 특정 작업만 노출할 수 있는 창의적인 방법을 지원합니다.

단점

호스트 이름 라우팅 방법과 마찬가지로, HTTP 헤더 라우팅은 사용자가 클라이언트를 완전히 제어할 수 있고 사용자 지정 HTTP 헤더를 조작할 수 있다고 가정합니다. 프록시, 콘텐츠 배포 네트워크(CDN), 로드 밸런서가 헤더 크기를 제한할 수 있습니다. 이 제한이 문제가 되는 경우는 드물지만, 추가하는 헤더와 쿠키의 수에 따라 문제가 될 수도 있습니다.