GraphQL 및 마이크로 서비스 아키텍처

GraphQL이 Microservice 아키텍처 내에서 사용하기에 가장 적합한 곳을 이해하려고합니다.

대상 마이크로 서비스에 대한 요청을 프록시하고 응답을 강제하는 API 게이트웨이로 작동하는 GraphQL 스키마가 1 개 밖에 없다는 논란이 있습니다. 마이크로 서비스는 여전히 커뮤니케이션 사고에 REST / Thrift 프로토콜을 사용합니다.

다른 방법은 마이크로 서비스 당 하나씩 여러 GraphQL 스키마를 사용하는 것입니다. 요청의 모든 정보 + GraphQL 쿼리를 사용하여 요청을 대상 마이크로 서비스로 라우팅하는 더 작은 API 게이트웨이 서버가 있습니다.

첫 번째 접근법

API 게이트웨이로 1 GraphQL 스키마를 사용하면 마이크로 서비스 계약 입력 / 출력을 변경할 때마다 API 게이트웨이 측에서 GraphQL 스키마를 변경해야하는 단점이 있습니다.

두 번째 접근법

마이크로 서비스 당 다중 GraphQL 스키마를 사용하는 경우 GraphQL이 스키마 정의를 시행하므로 소비자는 마이크로 서비스에서 제공된 입력 / 출력을 존중해야합니다.

질문

• 마이크로 서비스 아키텍처 설계에 적합한 GraphQL을 찾으십니까?

• 가능한 GraphQL 구현으로 API 게이트웨이를 어떻게 설계 하시겠습니까?

확실히 # 1에 접근하십시오.

고객이 여러 GraphQL 서비스에 접근하게되면 (접근법 # 2에서와 같이) GraphQL을 처음 사용하는 목적을 완전히 상실하게되는데, 이는 전체 애플리케이션 데이터에 대해 스키마를 제공 하여 단일 왕복으로 가져올 수 있도록하는 것입니다.

갖는 비공유 아키텍처하면 microservices 관점에서 합리적으로 보이지만, 당신은 당신이 업데이트해야 할, 당신의 microservices 중 하나를 변경할 때마다 때문에 클라이언트 측 코드는, 절대 악몽 수있는 모든 클라이언트의합니다. 당신은 그것을 후회하게 될 것입니다.

GraphQL과 마이크로 서비스는 고객에게 마이크로 서비스 아키텍처가 있다는 사실을 숨기므로 완벽하게 적합합니다. 백엔드 관점에서 모든 것을 마이크로 서비스로 분할하려고하지만, 프론트 엔드 관점에서 모든 데이터가 단일 API에서 제공되기를 원합니다. GraphQL을 사용하는 것이 내가 아는 가장 좋은 방법입니다. 백엔드를 마이크로 서비스로 분할하면서도 모든 애플리케이션에 단일 API를 제공하고 다른 서비스의 데이터를 조인 할 수 있습니다.

마이크로 서비스에 REST를 사용하지 않으려는 경우 각각 고유 한 GraphQL API를 보유 할 수 있지만 여전히 API 게이트웨이가 있어야합니다. 사람들이 API 게이트웨이를 사용하는 이유는 마이크로 서비스 패턴에 잘 맞지 않기 때문에 클라이언트 응용 프로그램에서 마이크로 서비스를보다 쉽게 ​​호출 할 수 있도록하기 위해서입니다.

접근법 # 1이 어떻게, 왜 더 나은지에 대한 기사를 참조 하십시오 . 또한 내가 언급 한 기사에서 가져온 아래 이미지를보십시오.

단일 엔드 포인트 뒤에있는 모든 것을 갖는 주요 이점 중 하나는 각 요청에 고유 한 서비스가있는 경우보다 데이터를보다 효과적으로 라우팅 할 수 있다는 것입니다. 이것이 복잡성과 서비스 크리프의 감소 인 GraphQL에서 종종 선전되는 가치 인 반면, 결과적인 데이터 구조는 또한 데이터 소유권을 매우 잘 정의하고 명확하게 설명 할 수있게합니다.

GraphQL을 채택하면 얻을 수있는 또 다른 이점은 기본적으로 데이터로드 프로세스를보다 효과적으로 제어 할 수 있다는 것입니다. 데이터 로더에 대한 프로세스는 자체 엔드 포인트로 진행되므로 요청을 부분적으로, 완전히 또는 경고로 처리하여 데이터가 전송되는 방식을 매우 세밀하게 제어 할 수 있습니다.

다음 기사에서는 이러한 두 가지 이점을 다른 것들과 함께 잘 설명합니다. https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

접근법 # 2의 경우 실제로 성가신 API 게이트웨이를 수동으로 유지 관리하는 것보다 훨씬 쉽기 때문에 이것이 내가 선택한 방식입니다. 이 방법으로 서비스를 독립적으로 개발할 수 있습니다. 인생을 훨씬 쉽게 : P

하나에 스키마를 결합하는 훌륭한 도구가 있습니다, 예를 들어 graphql - 버 와 아폴로의 graphql-도구 , 내가 사용하고 graphql-weaver, 사용하기 쉽고 잘 작동합니다.

2019 년 중반 1 차 접근법 의 솔루션 은 이제 아폴로 사람들이 만든 " 스키마 페더레이션 (Schema Federation) " 이라는 이름을 갖 습니다 (이전 명칭은 종종 GraphQL 스티칭이라고 함). 또한 모듈을 제안 @apollo/federation하고 @apollo/gateway이를 위해입니다.

ADD : Schema Federation에서는 게이트웨이 수준에서 스키마를 수정할 수 없습니다. 따라서 스키마에 필요한 모든 비트에 대해 별도의 서비스가 필요합니다.

2019 년 현재 가장 좋은 방법은 아폴로 게이트웨이 사양 을 구현하는 마이크로 서비스를 작성한 다음 접근 방법 1에 따라 게이트웨이를 사용하여 이러한 서비스를 서로 연결하는 것입니다. 게이트웨이를 구축하는 가장 빠른 방법은 같은 고정 표시기의 이미지 이와 동시에 모든 서비스를 시작하는 다음 사용 고정 표시기 - 작성 :

version: '3'

services:
    service1:
        build: service1
    service2:
        build: service2
    gateway:
        ports:
            - 80:80
        image: xmorse/apollo-federation-gateway
        environment: 
            - CACHE_MAX_AGE=5
            - "FORWARD_HEADERS=Authorization, X-Custom-Header" # default is Authorization, pass '' to reset
            - URL_0=http://service1
            - URL_1=http://service2

이 질문에서 설명하는 방식에 따라 사용자 지정 API 게이트웨이를 오케스트레이션 서비스로 사용하면 복잡한 엔터프라이즈 응용 프로그램에 많은 의미가 있다고 생각합니다. GraphQL은 최소한 쿼리가 진행되는 한 해당 오케스트레이션 서비스에 적합한 기술 선택이 될 수 있습니다. 첫 번째 접근 방식 (모든 마이크로 서비스에 대한 하나의 스키마)의 장점은 단일 요청으로 여러 마이크로 서비스의 데이터를 결합 할 수 있다는 것입니다. 상황에 따라 매우 중요 할 수도 있고 그렇지 않을 수도 있습니다. GUI가 한 번에 여러 마이크로 서비스에서 데이터를 렌더링해야하는 경우,이 접근 방식은 클라이언트 코드를 단순화하여 단일 호출이 Angular 또는 React와 같은 프레임 워크의 GUI 요소와 데이터 바인딩에 적합한 데이터를 리턴 할 수 있습니다. 이 장점은 돌연변이에는 적용되지 않습니다.

단점은 데이터 API와 오케스트레이션 서비스 간의 긴밀한 연결입니다. 릴리스는 더 이상 원자가 될 수 없습니다. 데이터 API의 주요 변경 사항을 거꾸로 도입하지 않으면 릴리스를 롤백 할 때만 복잡성이 발생할 수 있습니다. 예를 들어, 오케스트레이션 서비스에서 해당 변경 사항을 사용하여 두 개의 데이터 API의 새 버전을 릴리스하려고하고 해당 릴리스 중 하나를 롤백해야하지만 다른 릴리스는 롤백해야하는 경우 세 가지를 모두 롤백해야합니다.

GraphQL과 REST 를 비교할 때 GraphQL 이 RESTful API만큼 효율적이지 않다는 것을 알 수 있으므로 데이터 API에 대해 REST를 GraphQL로 바꾸지 않는 것이 좋습니다.

질문 1에 대해 Intuit은 One Intuit API 생태계로의 전환을 발표했을 때 몇 년 전 GraphQL의 힘을 인정했습니다 ( https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations) -quickbooks-connect-2017 ). Intuit은 접근 방식 1을 선택했습니다. 언급 한 단점은 실제로 개발자가 클라이언트 응용 프로그램을 중단시킬 수있는 주요 스키마 변경을 도입하지 못하게합니다.

GraphQL은 여러 가지 방법으로 개발자의 생산성을 향상시키는 데 도움이되었습니다.

1. 도메인을위한 새로운 마이크로 서비스를 설계 할 때 엔지니어 (백엔드 / 프런트 엔드 / 이해 관계자)는 도메인 엔터티에 대한 스키마에 동의합니다. 스키마가 승인되면 마스터 도메인 스키마 (유니버설)와 병합되고 게이트웨이에 배포됩니다. 프론트 엔드 엔지니어는이 스키마를 사용하여 클라이언트 응용 프로그램을 코딩하는 동안 백엔드 엔지니어는 기능을 구현할 수 있습니다. 하나의 범용 스키마가 있으면 중복 기능이있는 두 개의 마이크로 서비스가 없음을 의미합니다.

2. GraphQL은 클라이언트 응용 프로그램이 더 간단하고 빨라졌습니다. / update 데이터에서 여러 마이크로 서비스로 데이터를 검색 하시겠습니까? 모든 클라이언트 응용 프로그램은 ONE GraphQL 요청을 발생시키기 만하면되며 API Gateway 추상화 계층은 여러 소스 (마이크로 서비스)에서 데이터를 가져오고 수집합니다. Apollo ( https://www.apollographql.com/ ) 와 같은 오픈 소스 프레임 워크 는 GraphQL 채택 속도를 가속화했습니다.

3. 최신 응용 프로그램에서 모바일을 최우선으로 선택하려면 그라운드 제로에서 낮은 데이터 대역폭 요구 사항을 설계하는 것이 중요합니다. GraphQL은 클라이언트 앱이 특정 필드 만 요청할 수 있도록 도와줍니다.

질문 2 : API 게이트웨이에 어떤 서비스 (제공자)가 스키마의 어느 부분을 소유하는지 알고있는 사용자 지정 추상화 계층을 만들었습니다. 쿼리 요청이 도착하면 추상화 계층은 요청을 적절한 서비스로 전달합니다. 기본 서비스가 응답을 반환하면 추상화 계층이 요청 된 필드를 반환합니다.

그러나 오늘날에는 GraphQL 추상화 계층을 즉시 구축 할 수있는 여러 플랫폼 (Apollo 서버, graphql-yoga 등)이 있습니다.

GraphQL 및 마이크로 서비스와 협력하고 있습니다

내 경험에 따르면 기능 / 사용법에 따라 두 가지 접근 방식의 조합이 작동합니다. 접근법 1에서와 같이 단일 게이트웨이는 없지만 접근 방식 2와 같이 각 마이크로 서비스에 대한 graphql을 사용합니다.

예를 들어 Enayat의 답변 이미지를 기반 으로이 경우 내가 할 일은 3 개의 그래프 게이트웨이를 갖는 것입니다 (그림과 같이 5 아님)

• 앱 (제품, 바스켓, 배송, 재고, 기타 서비스와 연결 / 연결)

• 지불

• 사용자

이 방법으로 인증 토큰, 사용자 ID, 지불 ID, 지불 상태와 같은 종속 서비스에서 노출되는 필요 / 연결된 최소 데이터 디자인에 특별한주의를 기울여야합니다.

예를 들어 필자의 경험으로는 "User"게이트웨이가 있는데 GraphQL에는 사용자 쿼리 / 변경, 로그인, 로그인, 로그 아웃, 비밀번호 변경, 이메일 복구, 이메일 확인, 계정 삭제, 프로필 편집, 사진 업로드 등이 있습니다. , 등 ...이 그래프 자체는 상당히 큽니다! 결국 다른 서비스 / 게이트웨이는 userid, name 또는 token과 같은 결과 정보 만 신경 쓰므로 분리됩니다.

이 방법은 더 쉽습니다 ...

• 사용량에 따라 다른 게이트웨이 노드를 확장 / 종료합니다. 예를 들어 사람들이 항상 자신의 프로필을 수정하거나 비용을 지불하는 것은 아니지만 제품 검색이 더 자주 사용될 수 있습니다.

• 게이트웨이가 성숙하고, 성장하거나, 사용법이 알려 지거나 도메인에 대한 전문 지식이 있으면 게이트웨이를 소유 할 수있는 스키마의 일부를 식별 할 수 있습니다. (git 저장소와 상호 작용하는 거대한 스키마로 나에게 일어났습니다. , 나는 저장소와 상호 작용하는 게이트웨이를 분리했으며 필요한 입력 / 링크 된 정보는 ... 폴더 경로와 예상 분기라는 것을 알았습니다.)

• 리포지토리 기록은 더 명확하며 게이트웨이 및 관련 마이크로 서비스 전용 리포지토리 / 개발자 / 팀을 보유 할 수 있습니다.

최신 정보:

여기에 GraphQL을 사용하는 모든 백엔드와 함께 설명하는 것과 동일한 접근 방식을 사용하는 kubernetes 클러스터가 있습니다. 모든 오픈 소스는 여기에 기본 저장소입니다 : https://github.com/vicjicaman/microservice-realm

응답 / 접근 방식이 실행중인 코드를 백업하고 상담 / 검토 할 수있는 것이 더 좋다고 생각하기 때문에 이것은 내 대답에 대한 업데이트입니다.

마이크로 서비스 아키텍처는 적절한 정의가 없기 때문에이 스타일에 대한 특정 모델은 없지만 대부분 눈에 띄는 특징은 거의 없습니다. 애플리케이션 무결성에 영향을주지 않고 개별적으로 조정 및 배포 즉, 맞춤형 마이크로 서비스 앱 개발을 통해 애플리케이션 재배포를하지 않고도 몇 가지 서비스를 간단히 변경할 수 있습니다 .

마이크로 서비스에 대한 자세한 내용은 GraphQL이 서버리스 아키텍처에서도 완벽하게 작동 할 수 있다고 생각합니다. GraphQL을 사용하지 않지만 비슷한 프로젝트가 있습니다. 많은 함수를 호출하고 단일 결과에 집중 시키는 애그리 게이터 로 사용합니다 . GraphQL에 동일한 패턴을 적용 할 수 있다고 생각합니다.