마이크로서비스가 더 이상 "분실"되지 않도록 하세요: API 게이트웨이의 실제 코드 조각 및 애플리케이션 스토리

이런 상황에 직면한 적이 있습니까? 회사에는 점점 더 많은 마이크로서비스가 있고 각 서비스에는 고유한 인터페이스와 주소가 있으며 이를 호출하는 것은 미로에서 출구를 찾는 것과 같습니다. 잠시 동안 서비스 A는 B의 데이터를 호출해야 하고, 잠시 동안 C는 권한을 확인하기 위해 D를 찾아야 합니다. 이러한 통화 관계를 유지하는 것만으로도 골치 아픈 일입니다. 보안 통제는 말할 것도 없고요. 각 서비스마다 고유한 신원 확인 세트를 가질 수 없나요?

이것이 바로 우리가 API 게이트웨이에 대해 이야기해야 하는 이유입니다.

마이크로서비스 아키텍처가 활발한 파티라면 API 게이트웨이가 문 앞에 있는 안내원이라고 상상해 보세요. 초대자 명단 확인(신원확인), 손님을 올바른 방으로 안내(라우팅 요청), 입장 리듬 제어(전류 제한), 누가 들어오고 나가는지 기록(로그 모니터링) 등의 역할을 담당합니다. 그렇지 않으면 당은 쉽게 혼란에 빠질 수 있다.

코드에서는 어떻게 보일까요?

간단한 게이트웨이 라우팅 구성 예

Spring Cloud Gateway(Java 생태계에서 매우 일반적임)를 사용한다고 가정하면 기본 라우팅 구성은 다음과 같습니다.

@Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route("product_service", r -> r .path("/api/products/**") .filters(f -> f .addRequestHeader("X-Request-Source", "gateway") .circuitBreaker(config -> config .setName("productCB") .setFallbackUri("forward:/fallback/product"))) .uri("lb://PRODUCT-SERVICE")) .route("order_service", r -> r .path("/api/orders/**") .uri("lb://ORDER-SERVICE")) .build(); }

이 코드는 무엇을 합니까? 이는 게이트웨이에 다음을 알려줍니다. /api/products/로 시작하는 모든 요청은 PRODUCT-SERVICE라는 서비스로 전달됩니다. 그런데 요청 헤더가 추가되고 회로 차단기와 다운그레이드가 구성됩니다. 제품 서비스가 일시적으로 응답할 수 없는 경우 백업 계획으로 전환됩니다. 주문 서비스 라우팅이 더 간단하고 직접 전달됩니다.

단 몇 개의 회선만 있으면 외부 호출자는 마이크로서비스 수와 자신이 살고 있는 IP 주소를 알 필요가 없습니다. 게이트웨이만 연결하면 됩니다.

혜택은 진짜입니다

누군가는 다음과 같이 질문할 수 있습니다. 추가 레이어를 추가하면 시스템 속도가 느려지나요? 실제로 링크가 하나 더 있으면 항상 약간의 오버헤드가 발생합니다. 그러나 그것이 가져오는 이점에 비해 비용은 그만한 가치가 있는 경우가 많습니다.

예를 들어, 안전. 각 서비스에서 JWT 확인을 반복적으로 구현하는 대신 게이트웨이가 이를 균일하게 처리하도록 합니다.

# 게이트웨이 필터 필터의 구성 예: - name: JwtAuthFilter args: secretKey: "your-secret-key-here" includePaths: - "/api/public/login" - "/health"

이제 로그인 및 상태 확인이라는 두 가지 공개 인터페이스를 제외하고 다른 모든 요청은 먼저 토큰 확인을 통과해야 합니다. 확인 규칙을 수정하려면 이곳만 변경하면 됩니다.

또 다른 예는 모니터링입니다. 모든 트래픽이 게이트웨이를 통과하면 갑자기 이상적인 관찰 지점이 생깁니다. 가장 자주 호출되는 인터페이스는 무엇입니까? 평균 응답 시간은 얼마나 됩니까? 오류율에 이상이 있나요? 이러한 데이터는 게이트웨이 수준에서 수집되므로 각 서비스에 가서 로그를 검색하는 것보다 훨씬 편리합니다.

버전 관리도 있습니다. 특정 서비스의 API를 업그레이드하고 싶지만 모든 호출자가 이를 즉시 변경하도록 할 수 없는 경우 게이트웨이에서 소란을 피울 수 있습니다. 요청 헤더의 버전 번호를 기반으로 트래픽을 다른 버전의 서비스 인스턴스로 직접 보낼 수 있습니다. 기존 사용자는 기존 인터페이스를 계속 사용하는 반면 신규 사용자는 새로운 기능을 즐기며 전환이 원활합니다.

선택할 때 어떤 점에 주의해야 합니까?

시장에는 다양한 API 게이트웨이가 있습니다. 선택하는 방법? 가장 완벽한 기능을 추구할 필요는 없다고 생각합니다. 핵심은 다음 사항이 편리한지 여부입니다.

첫째, 성능 손실이 허용 가능한 범위 내에 있어야 합니다. 좋은 게이트웨이는 추가된 기능과 도입된 대기 시간 간의 균형을 찾아야 합니다. 둘째, 구성이 충분히 유연해야 합니다. 위의 코드 예제와 마찬가지로 구성이나 코드를 사용하여 라우팅 규칙을 정의하여 다양한 팀의 습관에 적응할 수 있습니다. 셋째, 모니터링 정보가 상세해야 한다. 문제가 발생하면 게이트웨이에 결함이 있는지 아니면 그 뒤에 있는 서비스 중 하나에 결함이 있는지 빠르게 확인할 수 있어야 합니다.

기존 기술 스택과의 호환성도 중요합니다. 마이크로서비스가 주로 Go로 작성된 경우 Go 친화적이고 커뮤니티 지원이 좋은 게이트웨이를 선택하는 것이 더 실용적일 수 있습니다.

실제 배포 중 몇 가지 고려 사항

종이 위에서 말하는 것은 궁극적으로 얕습니다. 실제로 사용하려면 몇 가지 세부 사항을 미리 생각해야 합니다.

예를 들어 게이트웨이 자체가 단일 실패 지점이 되면 어떻게 해야 합니까? 간단합니다. 인스턴스를 몇 개 더 배포하고 앞에 로드 밸런싱을 추가하세요. 또 다른 예로, 서비스를 다시 시작하지 않고 구성을 어떻게 업데이트할 수 있습니까? 일부 게이트웨이는 핫 업데이트 구성을 지원합니다. 라우팅 규칙을 변경하면 프로세스를 다시 시작할 필요가 없으며 이는 온라인 서비스에 매우 친숙합니다.

로깅도 신중하게 설계해야 합니다. 게이트웨이는 어떤 로그를 보관해야 합니까? 너무 많으면 성능에 영향을 미치고, 너무 적으면 문제 해결에 해로울 수 있습니다. 일반적으로 요청 및 응답의 메타데이터(시간, 경로, 상태 코드, 클라이언트 IP)가 필요하지만 요청 본문과 같이 잠재적으로 큰 콘텐츠의 경우 신중하게 선택해야 합니다. 특정 경로의 요청 본문만 기록하거나 레코드 샘플링만 할 수도 있습니다.

캐싱도 있습니다. 일부 쿼리 요청 결과는 단시간 내에 변경되지 않으며 게이트웨이 계층에 캐시된 후 직접 반환되어 백엔드 서비스에 대한 부담을 줄일 수 있습니다. 그러나 캐싱에 적합한 인터페이스와 캐싱 기간은 비즈니스 특성에 따라 다릅니다.

솔직하게 말하세요

마이크로서비스 아키텍처는 양날의 검과 같습니다. 이를 작은 서비스로 분할하면 개발 및 배포가 더 유연해지지만 관리가 더 복잡해집니다. API 게이트웨이는 이 복잡한 시스템의 "프론트 데스크"와 같습니다. 핵심 업무를 처리하지 못하지만, 이것이 없으면 전체 시스템이 원활하게 운영되기 어려울 것입니다.

몇 줄의 라우팅 구성으로 시작하여 보안, 모니터링 및 전류 제한 기능을 천천히 추가하면 이 "접수원" 역할이 점점 더 중요해지고 있음을 알게 될 것입니다. 이를 통해 백엔드 서비스는 교차 문제를 처리할 필요 없이 최선을 다할 수 있습니다.

좋은 도구는 사용하기 쉽고, 지저분하지 않으며, 중요한 순간에 도움이 되어야 합니다. 하루 종일 서비스에 전화하는 복잡한 세부 사항에 대해 더 이상 걱정할 필요가 없을 때 이 점을 높이 평가할 수 있습니다.

2005년에 설립되었으며,kpower는 중국 광둥성 둥관에 본사를 둔 전문 컴팩트 모션 유닛 제조업체에 전념해 왔습니다. 모듈식 드라이브 기술의 혁신을 활용하여,kpower고성능 모터, 정밀 감속기, 멀티 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다.kpower스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론, 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.