GraphQL을 (마이크로)서비스 아키텍처의 일부로 만들기

마이크로서비스 아키텍처는 복잡합니다. 부분적으로 이것은 당신이 돌봐야 하는 것의 수가 증가했기 때문입니다. GraphQL의 기능을 활용하여 마이크로서비스 아키텍처의 많은 이점을 여전히 달성하는 훨씬 더 간단한 아키텍처를 만들 수 있습니다. 이 게시물에서는 이해하기 쉬운 마이크로서비스 아키텍처를 구축하기 위해 어떻게 할 수 있는지 설명합니다.

마이크로서비스의 문제

다음 아키텍처를 상상해 보십시오.



이것은 여전히 ​​상대적으로 간결한 아키텍처이지만 실제 세계에서는 이러한 아키텍처가 훨씬 더 복잡해지는 것을 볼 수 있습니다. 특히 서비스 간의 관계는 추적하기 어렵습니다. 일반적으로 마이크로서비스로 구성된 시스템의 아키텍처는 술취한 거미가 만든 거미줄처럼 보입니다.

그렇다면 다른 서비스를 중단하지 않고 서비스를 변경하려면 어떻게 해야 할까요? 다른 서비스는 서비스 중단 시간을 어떻게 처리합니까? 요청이 오래 걸리지 않도록 하려면 어떻게 해야 합니까?

이러한 질문에 대한 답을 찾을 수 있습니다. 그러나 이미 복잡한 시스템에 복잡성을 더하면 됩니다. 이러한 종속성이 명시적으로 표시되는 경우는 거의 없기 때문에 서비스에 의존하는 사용자를 결정하기가 매우 어려운 경우가 많습니다.

GraphQL이 이를 해결하는 방법

다음 아키텍처는 동일한 작업을 수행하지만 훨씬 간단합니다.



세부 사항을 제외하면 이 애플리케이션의 GraphQL 스키마는 다음과 같을 수 있습니다.

type Order {
    customer: Customer!
    coupon: Coupon
    ...
}

스키마는 어떤 종속성이 필수이고 어떤 것이 선택적인지 명시합니다. 주문 요청 시 쿠폰을 돌려받지 못할 수 있습니다. 쿠폰 서비스가 중단된 경우 인기 있는 GraphQL 서버(예: apollo-server )가 이를 포착하고 여전히 주문을 반환합니다. 쿠폰을 검색할 수 없음을 나타낼 수 있습니다. 대부분의 구현에는 이러한 종류의 저하된 서비스가 내장되어 있습니다.

추가 이점으로 이 스키마를 사용하면 가능한 모든 응답 유형을 즉시 문서화할 수 있습니다. 여러 마이크로 서비스에 직접 또는 프록시를 통해 액세스하는 경우 훨씬 더 어려울 것입니다. 쿠폰 서비스의 스키마가 변경되면 주문 서비스의 스키마에도 반영되어야 하기 때문입니다.

GraphQL은 성능을 향상시키기 위해 현명한 일을 할 수 있습니다. 예를 들어 캐싱을 쉽게 추가할 수 있지만 리졸버를 병렬로 실행할 수도 있습니다. 모든 서비스에서 개별적으로 이 작업을 수행할 수도 있지만 더 많은 작업이 필요합니다.

클래식 설정에서 고객 서비스를 변경하면 직접 소비자뿐만 아니라 주문 서비스도 변경해야 합니다. 더 복잡한 아키텍처에서는 이것이 빠르게 제어할 수 없게 됩니다.

모든 서비스의 통합을 위해 GraphQL을 도입함으로써 마이크로서비스는 실제로 한 가지만 담당합니다. 다른 서비스와 상호 작용하는 방법을 알 필요가 없습니다. 다른 서비스를 찾을 위치를 알 필요가 없습니다. 주문을 검색하거나 고객 데이터를 관리하는 등 자체 작업을 수행하는 방법만 알면 됩니다.