构建弹性GraphQL应用程序并将其缩放到100万订阅

GraphQL为API提供了一种查询语言，使UX开发人员在查询API和数据库方面具有自主权。

在UX应用程序中使用GraphQL的优点得到了很好的理解。GraphQL客户端只能检索UI应用程序中所需的数据。GraphQL提供了一个强大的类型系统，它避免了手动代码解析和数据过滤，在将UI呈现给用户时占用了宝贵的处理周期。此外，GraphQL提高了UX开发的速度，并且最小化了设计API响应所需的反馈周期。

对于云本机API开发人员，GraphQL查询性能、处理基础设施中断和GraphQL应用程序的可伸缩性等因素与GraphQL提供的易用性同等重要。在企业应用程序开发中，开发人员如果不满足企业的扩展和恢复能力需求，就无法将应用程序发送到生产中。

图1：使用分布式SQL缩放GraphQL应用程序

这篇博客文章将探讨关于具有分布式SQL数据库的可伸缩和弹性GraphQL应用程序的详细信息(图1)。

我们将展示所有GraphQL体系结构组件–GraphQL客户端、GraphQL服务器和用于服务GraphQL查询的数据库–如何在不停机的情况下线性扩展。为了测试GraphQL应用程序的可伸缩性和弹性，我们使用Hasura图形QL发动机连接到YugabyteDB。

GraphQL订阅

GraphQL订阅用于在数据库上发生新的突变时实时获取数据(图2)。

图2：GraphQL订阅

在Hasura GraphQL引擎中，GraphQL订阅实现为实时查询，它们只不过是按一定的时间间隔(1秒)查询数据库。随着订阅数量的增加，数据库上的查询负载也会增加。

线性缩放到100万订阅

订阅性能工具用于使用分布式SQL数据库测试GraphQL订阅的线性可伸缩性。对基准设置进行了建模，以模拟一个真实的电子商务用户订单管理系统.基准测试组件将在博客文章的安装部分中详细解释。

下表提供了用于可伸缩性测试的资源的详细信息，这些结果是通过在Kubernetes集群上运行GraphQL订阅Perf工具获得的，在该集群中，Hasura GraphQL Engine和YugabyteDB集群的资源被线性缩放，以处理用户流量从25K用户增加到100万订户的问题。对结果的详细观察可以在这里的gitrepo中找到。

在Kubernetes集群上运行基准测试获得的结果如下：

注意：这个基准测试的所有组件都被容器化并部署在Kubernetes集群上。

高可用性：数据库Pod故障对GraphQL订阅的影响

此场景模拟新订单下发时数据库结荚故障的结果，这些订单由GraphQL客户端应用程序使用订阅来使用。

Hasura GraphQL引擎是无状态的，通过将查询重路由到另一个POD，可以很容易地减轻Hasura服务中一个吊舱的丢失。YugabyteDB服务是有状态的，因此本节测量失去一个YugabyteDB吊舱的影响。请注意，YugabyteDB集群中的YB-TServer服务负责为所有应用程序查询提供服务，因此也就是被杀死的POD。

通过使用100K订阅设置杀死一个YugabyteDBT-serverpod，观察到了以下结果。

图3：T服务器Pod故障期间观察到的YugabyteDB度量

对于不同故障场景下的度量的详细观察，请参见Git回购这里。

量表和反应试验的设置

GraphQL订阅：示例应用程序

为了对GraphQL订阅进行基准测试，我们创建了一个示例应用程序，该应用程序被建模为一个用户订单跟踪服务。用户下订单，需要交付。对这些订单进行跟踪，并实时发布通知，以启动订单的履行。

数据库模式

两个表用于对此场景进行建模。这个user_account表中包含有关用户的信息，而user_orders表中包含任何用户所下订单的列表。这些表的架构如下所示。

CREATE TABLE user_account (

    userID       BIGINT NOT NULL ,

    accountName  VARCHAR ,

    givenName    VARCHAR ,

    middleName   VARCHAR ,

    familyName   VARCHAR ,

    userGender   VARCHAR ,

    userAge      INT,

    Dob          TIMESTAMP,

    address1     VARCHAR ,

    address2     VARCHAR ,

    city         VARCHAR ,

    zip          VARCHAR ,

    email        VARCHAR ,

    homePhone    VARCHAR ,

    mobilePhone  VARCHAR ,

    country      VARCHAR ,

    company      VARCHAR ,

    companyEmail VARCHAR ,

    active       BOOLEAN ,

    PRIMARY KEY (userID HASH)

);

CREATE INDEX user_fname ON user_account (givenName) ;

CREATE INDEX user_lname ON user_account (familyName) ;

CREATE TABLE user_orders (

    userID         BIGINT NOT NULL ,

    orderID        VARCHAR NOT NULL ,

    orderTotal     VARCHAR NOT NULL ,

    orderDetails   VARCHAR NOT NULL ,

    deliveryStatus VARCHAR NOT NULL ,

    orderTime      TIMESTAMP NOT NULL ,

    PRIMARY KEY (userID HASH, orderID ASC)

);

subscription ($id: bigint!) {

  user_account (where: {userid: {_eq: $id}}) {

    accountname

    givenname

    familyname

    city

    user_orders(order_by: {orderid: desc}) {

      orderid

      ordertotal

      orderdetails

      ordertime

      deliveryStatus

    }

  }

 }