路由配置

了解如何自定义您的行为GraphOS 路由器 或 Apollo 核心路由器 使用环境变量、命令行命令和选项以及 YAML 文件配置。

环境变量

如果您使用的是 GraphOS 路由器 与 托管联邦 和 GraphOS Studio，请在启动命令中设置以下环境变量：

1
APOLLO_KEY="..." APOLLO_GRAPH_REF="..." ./router

命令行选项

在当前工作目录中安装 Apollo Router Core之后，您可以运行以下示例命令来启动router：

1
./router --config router.yaml --supergraph supergraph-schema.graphql

本参考文档列出了并描述了router二进制支持的选项。在指示的地方，其中一些选项也可以通过环境变量提供。如果以两种方式提供了一个选项，则命令行值具有优先权。

开发模式默认值

设置 --dev 标志与以下配置选项运行 ./router --hot-reload 相当：

1
sandbox:
2
  enabled: true
3
homepage:
4
  enabled: false
5
supergraph:
6
  introspection: true
7
include_subgraph_errors:
8
  all: true
9
plugins:
10
  # Enable with the header, Apollo-Expose-Query-Plan: true
11
  experimental.expose_query_plan: true

config 子命令

GraphOS 路由器 和 Apollo 路由器核心 提供了一组用于与其配置交互的子命令。您可以使用以下语法运行这些子命令：

1
./router config schema
2
./router config upgrade <path-to-config-file.yaml>

YAML 配置文件

GraphOS 路由器 和 Apollo 路由器核心 通过--config 选项接收一个可选的 YAML 配置文件：

1
./router --config router.yaml

此文件使您能够自定义路由器行为的多方面，具体内容在下述子章节中介绍。

如果您将--hot-reload 标志传递给router 命令，当其配置文件被修改时，路由器将自动重新启动。

监听地址

默认情况下，路由器启动一个监听在127.0.0.1:4000的 HTTP 服务器。您可以通过设置supergraph.listen来指定不同的地址：

IPv4

1
supergraph:
2
  # The socket address and port to listen on
3
  listen: 127.0.0.1:4000

IPv6

1
supergraph:
2
  # The socket address and port to listen on.
3
  # Note that this must be quoted to avoid interpretation as an array in YAML.
4
  listen: '[::1]:4000'

Unix socket

1
supergraph:
2
  # Absolute path to a Unix socket
3
  listen: /tmp/router.sock

端点路径

默认情况下，router启动了一个 HTTP 服务器，该服务器在路径 /处暴露了 POST/GET 端点。

您可以通过设置 supergraph.path 来指定不同的路径：)

1
supergraph:
2
  # The path for GraphQL execution
3
  # (Defaults to /)
4
  path: /graphql

路径必须以 / 为开头。

支持路径参数和通配符。例如

• /:my_dynamic_prefix/graphql 会匹配 /my_project_a/graphql 和 /my_project_b/graphql。
• /graphql/* 会匹配 /graphql/my_project_a 和 /graphql/my_project_b。
• /g* 会匹配 /graphql, /gateway 和 /graphql/api。

检查

默认情况下，router 不解析 introspection 查询。您可以像这样启用 introspection：)

1
# Do not enable introspection in production!
2
supergraph:
3
  introspection: true

调试

• 要配置日志记录，请参阅 router 中的日志记录。

• 要配置 subgraph 错误的包含，请参阅 subgraph 错误包含。

落地页面

router 可以向访问其 端点路径 的浏览器提供以下任何一种落地页面：

• 一个基本的落地页面，显示示例 查询 curl 命令（默认）

  YAML

  router.yaml

  1
  # This is the default behavior. You don't need to include this config.
  2
  homepage:
  3
    enabled: true

  复制

• 无 落地页面

  YAML

  router.yaml

  1
  homepage:
  2
    enabled: false

  复制

• Apollo 沙箱，它使您能够使用探索器探索您的模式并对其执行操作。

  请注意使用沙箱所需的其他配置

  YAML

  router.yaml

  1
  sandbox:
  2
    enabled: true
  3
  
  4
  # Sandbox uses introspection to obtain your router's schema.
  5
  supergraph:
  6
    introspection: true
  7
  
  8
  # Sandbox requires the default landing page to be disabled.
  9
  homepage:
  10
    enabled: false

  复制

  ⚠️ 注意

  不要在生产环境中启用沙箱。 沙箱需要启用 introspection，这在生产环境中是强烈不建议的。

Subgraph 路由 URL

默认情况下，router 从您提供的组合 supergraph 模式 subgraphs 获得每个 subgraph 的路由 URL。在大多数情况下，不需要额外的配置。URL 可以用于通过 HTTP 和 HTTPS 网络访问 subgraph，或者具有以下形状用于 Unix socket 使用：unix:///path/to/subgraph.sock

然而，如果您需要重写特定子图的路由URL（例如，处理网络拓扑的变化），您可以使用override_subgraph_url选项来做到这一点：

1
override_subgraph_url:
2
  organizations: http://127.0.0.1:8080
3
  accounts: "${env.ACCOUNTS_SUBGRAPH_HOST_URL}"

在这个例子中，organizations 子图URL被重写，指向 https://127.0.0.1:8080，而 accounts 子图URL被重写，以使用变量展开指向一个新URL。超级图模式中指定的URL将被忽略。

任何在override_subgraph_url 中省略的子图将继续使用在超级图模式中指定的路由URL。

如果您需要在运行时根据每个请求重写子图URL，您可以使用请求自定义层级中的 SubgraphService。

缓存

默认情况下，路由器将以下数据存储在内存缓存中以提高性能：

• 生成的查询计划
• 自动持久查询（APQ）
• 内省响应

您可以为生成的查询计划和APQ （但不是内省响应）配置某些缓存行为。有关详情，请参阅路由器的内存缓存。

如果您有GraphOS企业计划：

• 您可以为使用Redis作为后端的多实例路由器配置一个分布式缓存，以便这些路由器实例可以共享缓存值。有关详情，请参阅GraphOS路由器的分布式缓存。
• 您可以为使用Redis作为后端的实体缓存进行配置，以便客户端查询能够检索分散在子图响应中的缓存的实体数据。有关详情，请参阅GraphOS路由器中的子图实体缓存。

您可以通过配置并行查询计划来提高 router's 查询计划 的性能。

默认情况下，查询计划 一次计划一个操作。它在一个操作完成之前不会计划下一个操作。当操作需要很长时间才能计划，从而妨碍查询计划处理其他操作时，这种串行计划可能导致问题。

为了解决此类阻塞场景，您可以选择启用并行 查询计划。在 router.yaml 中进行配置，使用supergraph.query_planning.experimental_parallelism：

1
supergraph:
2
  query_planning:
3
    experimental_parallelism: auto # number of available cpus

实验并行性的值是 query_planner_pool 中的查询计划器的数量。 query_planner_pool 是预分配的查询计划器集合， router 可以从中使用来计划操作。 池的总数是并行运行的最大查询计划器数量，因此也是可以同时处理的最大操作数量。

实验并行性的有效值：

• 从 1
• 特殊值 auto，设置查询计划器的数量等于 router 主机上的可用 CPU 数量

实验并行性的默认值是1。

在实践中，您应该根据从 router 收集的指标和基准来调整 experimental_parallelism

内省响应目前由查询计划生成，因此它们执行成本很高，并且 router 将它们存储在其查询计划器缓存中。不幸的是，它们可能会充满缓存，因此在我们将内省执行移出之前，有一个选项可以停用响应缓存。

1
supergraph:
2
  query_planning:
3
    legacy_introspection_caching: false

从v1.49.0版本开始，路由器支持增强的操作签名标准化。操作签名 标准化。Apollo的旧操作签名算法删除了关于某些字段的信息，例如输入对象和别名。这种删除意味着一些操作可能有相同的标准化签名，尽管它们是不同的操作。

增强的标准化结合输入类型和别名来生成签名。它还包括其他改进，这些改进使得两个仅在细微之处有所不同的操作具有相同签名的可能性更大。

在router.yaml中使用telemetry.apollo.experimental_apollo_signature_normalization_algorithm选项配置增强的操作签名标准化：

1
telemetry: 
2
  apollo:
3
    experimental_apollo_signature_normalization_algorithm: enhanced # Default is legacy

一旦启用此配置，带有增强签名的操作可能会在GraphOS Studio中出现与之前不同的操作ID。

输入类型

增强签名包括输入对象类型结构体，同时仍会掩盖任何实际值。旧签名将输入对象类型替换为{}。

以下是一个示例操作：

query InlineInputTypeQuery {
  inputTypeQuery(
    input: { 
      inputString: "foo", 
      inputInt: 42, 
      inputBoolean: null, 
      nestedType: { someFloat: 4.2 }, 
      enumInput: SOME_VALUE_1, 
      nestedTypeList: [ { someFloat: 4.2, someNullableFloat: null } ], 
      listInput: [1, 2, 3] 
    }
  ) {
    enumResponse
  }
}

旧标准化算法生成的以下签名：

query InlineInputTypeQuery {
  inputTypeQuery(input: {}) {
    enumResponse
  }
}

增强标准化算法生成的以下签名：

query InlineInputTypeQuery {
  inputTypeQuery(
    input: {
      inputString: "", 
      inputInt: 0, 
      inputBoolean: null, 
      nestedType: {someFloat: 0}, 
      enumInput: SOME_VALUE_1, 
      nestedTypeList: [{someFloat: 0, someNullableFloat: null}], 
      listInput: []
    }
  ) {
      enumResponse
  }
}

别名

增强签名包括在操作中使用到的任何字段别名。旧签名完全删除别名，这意味着如果同一个字段使用了多个别名，签名可能无效。

以下是一个示例操作：

query AliasedQuery {
  noInputQuery {
    interfaceAlias1: interfaceResponse {
      sharedField
    }
    interfaceAlias2: interfaceResponse {
      ... on InterfaceImplementation1 {
        implementation1Field
      }
      ... on InterfaceImplementation2 {
        implementation2Field
      }
    }
    inputFieldAlias1: objectTypeWithInputField(boolInput: true) {
      stringField
    }
    inputFieldAlias2: objectTypeWithInputField(boolInput: false) {
      intField
    }
  }
}

旧标准化算法生成的以下签名：

query AliasedQuery {
  noInputQuery {
    interfaceResponse {
      sharedField
    }
    interfaceResponse {
      ... on InterfaceImplementation1 {
        implementation1Field
      }
      ... on InterfaceImplementation2 {
        implementation2Field
      }
    }
    objectTypeWithInputField(boolInput: true) {
      stringField
    }
    objectTypeWithInputField(boolInput: false) {
      intField
    }
  }
}

增强标准化算法生成的以下签名：

query AliasedQuery {
  noInputQuery {
    interfaceAlias1: interfaceResponse {
      sharedField
    }
    interfaceAlias2: interfaceResponse {
      ... on InterfaceImplementation1 {
        implementation1Field
      }
      ... on InterfaceImplementation2 {
        implementation2Field
      }
    }
    inputFieldAlias1: objectTypeWithInputField(boolInput: true) {
      stringField
    }
    inputFieldAlias2: objectTypeWithInputField(boolInput: false) {
      intField
    }
  }
}

从 v1.50.0 版本开始，您可以配置路由器来报告枚举和输入对象引用，以实现增强的洞察和操作检查。Apollo 的传统引用报告不包括枚举值和输入对象字段的数据，这意味着您无法在GraphOS Studio中查看枚举和输入对象字段的使用情况。传统的报告也可能导致操作检查不准确。

在router.yaml中配置扩展引用报告，使用telemetry.apollo.experimental_apollo_metrics_reference_mode选项，如下所示：

1
telemetry: 
2
  apollo:
3
    experimental_apollo_metrics_reference_mode: extended # Default is legacy

配置效果时间

一旦您配置了扩展引用报告，您就可以在后续的所有操作中，在 GraphOS Studio 中查看枚举值和输入 字段的使用情况，以及对象 字段使用情况。

配置扩展引用报告会自动启用增强操作检查，尽管您不会立即看到操作检查行为的变化。

这种延迟是因为操作检查依赖于历史操作数据。为了区分真正未使用的数据和只是未在传统数据中报告的数据，增强检查需要一些启用扩展引用报告的操作。

增强操作检查

得益于扩展引用报告，操作检查可以更准确地标记枚举值和输入对象字段的变化问题。以下表显示了基于传统引用报告的标准操作检查与基于扩展引用报告的增强检查之间的差异。

使用持久查询进行白名单管理

您可以通过保持 图谱的安全，通过 GraphOS Router 维护一个 持久查询列表（PQL），这是一个由您的一方应用程序创建的操作白名单。与 自动持久查询（APQ）相反，其中操作会自动被缓存，操作必须在 PQL 中预先注册。一旦配置完成，路由器就会检查传入请求是否与 PQL 相匹配。

有关更多信息，请参阅 使用持久查询进行白名单管理。

HTTP头部规则

有关如何向子图发送HTTP头部的信息，请参阅 发送HTTP头部到子图。

流量整形

要配置客户端、路由器和子图之间的流量形状，请参阅 路由器的流量整形。

CORS（跨源资源共享）

有关在路由器中配置CORS的信息，请参阅 路由器中的CORS配置。

延迟支持

有关在路由器中支持 @defer 的信息，请参阅 路由器的@defer支持。

查询批处理支持

有关 GraphOS Router 对查询批处理的支持信息，请参阅 GraphOS Router 对查询批处理的支持。

订阅支持

有关在 GraphOS Router 中实现 GraphQL 订阅的信息，请参阅 GraphOS Router 中的 GraphQL 订阅。

授权支持

• 要配置授权 指令，请参阅 授权指令。

• 要配置授权插件，请参阅 配置选项。

JWT身份验证

要启用和配置JWT身份验证，请参阅 GraphOS Router 中的 JWT 身份验证。

CORS（跨站请求伪造）预防

要配置CORS防止，请参阅 路由器中的CORS防止。

子图身份验证

要配置使用 AWS SigV4 的子图身份验证，请参阅 配置示例。

外部协同处理

参见GraphOS Router中的外部协处理器。

遥测和监控

该路由器支持标准自定义仪器，从其请求和响应处理管道收集遥测数据以生成日志、指标和跟踪以导出。

参见路由器遥测概述。

TLS

该路由器支持TLS进行客户端和子图端的认证加密通信。如果子图URL以https://开头，将在子图端自动工作。

TLS支持在tls部分配置，对于客户端端是位于supergraph键下，对于子图端位于subgraph键下，可以针对所有子图进行配置，并覆盖单个子图设置。

支持的TLS版本和算法列表是静态的，无法配置。

支持的TLS版本

• TLS 1.2
• TLS 1.3

支持的密码套件

• TLS13_AES_256_GCM_SHA384
• TLS13_AES_128_GCM_SHA256
• TLS13_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

支持密钥交换组

• X25519
• SECP256R1
• SECP384R1

TLS终止

客户端可以直接通过HTTPS连接到路由器，无需在任何中介中终止TLS。您可以在tls配置部分中配置此操作：

1
tls:
2
  supergraph:
3
    certificate: ${file./path/to/certificate.pem}
4
    certificate_chain: ${file./path/to/certificate_chain.pem}
5
    key: ${file./path/to/key.pem}

要在配置中将文件路径以Unix风格进行扩展，您可以参考变量扩展指南中的示例。

路由器期望在certificate_chain值中引用的文件是几个PEM证书的连接，形成一个单一的文件（与Apache TLS配置中常见的情况一样）。

覆盖子图的证书颁发机构

路由器使用系统提供的证书颁发机构列表来验证与子图的TLS连接。您可以使用全球和每个子图设置的组合覆盖此列表：

1
tls:
2
  subgraph:
3
    # Use these certificate authorities unless overridden per-subgraph
4
    all:
5
      certificate_authorities: "${file./path/to/ca.crt}"
6
    # Override global setting for individual subgraphs
7
    subgraphs:
8
      products:
9
        certificate_authorities: "${file./path/to/product_ca.crt}"

路由器期望在certificate_chain值中引用的文件是几个PEM证书的连接，形成一个单一的文件（与Apache TLS配置中常见的情况一样）。

您只能通过路由器的配置来配置这些证书，因为使用SSL_CERT_FILE也覆盖了发送遥测和与Apollo Uplink通信的证书。

如果子图正在显示自签名证书，则必须使用适当的文件扩展名并禁用basicConstraints来生成它。您可以从证书签名请求使用以下命令行命令生成它，在此示例中，为server.csr：

1
openssl x509 -req -in server.csr -signkey server.key -out server.crt -extfile v3.ext

您可以生成一个v3.ext扩展文件，如下所示：

1
subjectKeyIdentifier   = hash
2
authorityKeyIdentifier = keyid:always,issuer:always
3
# this has to be disabled
4
# basicConstraints       = CA:TRUE
5
keyUsage               = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign
6
subjectAltName         = DNS:local.apollo.dev
7
issuerAltName          = issuer:copy

这将生成名为server.crt的文件，该文件可在certificate_authorities中使用。

TLS客户端身份验证用于子图请求

该router支持与子图的相互TLS身份验证（mTLS）。这意味着它可以使用证书链和加密密钥来验证自身。配置如下：

1
tls:
2
  subgraph:
3
    # Use these certificates and key unless overridden per-subgraph
4
    all:
5
      client_authentication:
6
        certificate_chain: ${file./path/to/certificate_chain.pem}
7
        key: ${file./path/to/key.pem}
8
    # Override global setting for individual subgraphs
9
    subgraphs:
10
      products:
11
        client_authentication:
12
          certificate_chain: ${file./path/to/certificate_chain.pem}
13
          key: ${file./path/to/key.pem}

Redis TLS配置

对于Redis TLS连接，您可以通过配置tls在您的router's YAML配置文件来设置客户端证书或覆盖根证书颁发机构。例如：

1
apq:
2
  router:
3
    cache:
4
      redis:
5
        urls: [ "rediss://redis.example.com:6379" ]
6
        tls:
7
          certificate_authorities: ${file./path/to/ca.crt}
8
          client_authentication:
9
            certificate_chain: ${file./path/to/certificate_chain.pem}
10
            key: ${file./path/to/key.pem}

请求限制

GraphOS Router支持强制执行以下三种类型的请求限制，以增强安全性：

• 网络限制
• 基于词法、解析器的限制
• 基于语义和操作的限制（这是一个企业功能）)

router会拒绝任何违反这些限制之一的所有请求。

1
limits:
2
  # Network-based limits
3
  http_max_request_bytes: 2000000 # Default value: 2 MB
4

5
  # Parser-based limits
6
  parser_max_tokens: 15000 # Default value
7
  parser_max_recursion: 500 # Default value
8

9
  # Operation-based limits (Enterprise only)
10
  max_depth: 100
11
  max_height: 200
12
  max_aliases: 30
13
  max_root_fields: 20

基于操作的限制（仅限企业版）

见此文章。

网络限制

http_max_request_bytes

限制从网络读取HTTP请求正文中的数据量，以保护免受无界内存消耗的影响。此限制在JSON解析之前进行检查。包括GraphQL 文档及其相关的变量的数量都在此限制内。

默认值为2000000字节，2 MB。

在显著提高此限制之前，请考虑在一个与您的生产环境相似的环境中测试性能，尤其是如果一些客户端不可信。大量并发的大请求可能导致router耗尽内存。

基于解析器的限制

parser_max_tokens

限制查询文档可以包含的标记数量。这包括所有标记，包括词法和忽略的标记。。

默认值为15000。

parser_max_recursion

限制router的GraphQL解析器允许的最大递归深度，以防止栈溢出。这对应于查询文档中定义的任何单个GraphQL 操作或 片段的最大嵌套级别。

默认值为500。

以下示例中，GetProducts 操作有三级递归，而ProductVariation 片段有二级递归。因此，查询文档的最大递归深度是三级。

1
query GetProducts {
2
  allProducts { #1
3
    ...productVariation
4
    delivery { #2
5
      fastestDelivery #3
6
    }
7
  }
8
}
9

10
fragment ProductVariation on Product {
11
  variation { #1
12
    name #2
13
  }
14
}

请注意，路由器会分别计算每个操作和片段的递归深度。even如果片段包含在操作中，该片段的递归深度也不会贡献到操作的递归深度。

需求控制

了解如何分析操作的需求控制以了解如何分析成本并拒绝超出可定制成本限制的请求。

提前取消

直到Apollo Router Core v1.43.1，客户端在等待响应之前关闭了连接，整个请求被取消，并且没有通过整个管道。由于这会导致请求监控问题，路由器在1.43.1中引入了新的行为。现在，如果检测到请求被取消，将执行整个管道，但subgraph请求实际上并未执行。响应将以499状态码报告，但不会实际发送到客户端。要返回立即取消请求的以前行为，可以使用以下配置：

1
supergraph:
2
  early_cancel: true

此外，自v1.43.1以来，路由器在检测到客户端取消请求时可以显示日志。此日志可以通过以下方式激活：

1
supergraph:
2
  experimental_log_on_broken_pipe: true

插件

您可以使用插件自定义路由器的行为。每个插件都可以在配置文件中有自己的部分，包含任意值：

1
plugins:
2
  example.plugin:
3
    var1: "hello"
4
    var2: 1

变量扩展

您可以直接在您 YAML 配置文件中引用变量。这有助于引用秘密而无需将其包含在文件中。

目前，路由器支持环境变量和文件路径的扩展。对应的变量分别以前缀env.和file.开头。

路由器使用Unix风格的扩展。以下是几个示例：

• ${env.ENV_VAR_NAME}展开为环境变量ENV_VAR_NAME的值。
• ${env.ENV_VAR_NAME:-some_default}展开为环境变量ENV_VAR_NAME的值，如果环境变量未定义则回退为some_default的值。
• ${file.a.txt}展开为文件a.txt的内容。
• ${file.a.txt:-some_default} 展开为文件 a.txt 的内容，如果文件不存在，则回退到值 some_default。

变量 扩展仅对 YAML 值 有效，而不是键：

1
supergraph:
2
  listen: "${env.MY_LISTEN_ADDRESS}" 
3
example:
4
  password: "${env.MY_PASSWORD}" 

片段重用和生成

默认情况下，路由器 将尝试在形成 子图 请求时重用原始 查询 的 片段。可以通过设置为 false 来禁用此行为：

1
supergraph:
2
  experimental_reuse_query_fragments: false

或者，可以配置 路由器 为子图请求生成 片段。当设置为 true 时，路由器 将在发送查询到子图之前，仅提取 内联片段 到片段定义中。这可以显着减少发送到子图的查询大小，但可能会增加规划所需的时间。请注意，此选项与 experimental_reuse_query_fragments 是互斥的；如果都明确设置为 true， generate_query_fragments 将具有优先权。

1
supergraph:
2
  generate_query_fragments: true

配置重用

您可以使用标准 YAML 别名 语法在多个位置重用配置文件的部分：

1
headers:
2
  subgraphs:
3
    products:
4
      request:
5
        - insert: &insert_custom_header
6
            name: "custom-header"
7
            value: "something"
8
    reviews:
9
      request:
10
        - insert: *insert_custom_header

在此，name 和 value 条目在 &insert_custom_header 下被重用于 *insert_custom_header。

文本编辑器中的配置感知

路由器可以为您在文本编辑器中生成 JSON 模式以进行配置验证。此模式可以帮助您正确格式化 YAML 文件，同时也提供内容辅助。

使用以下命令生成模式：

1
./router config schema > configuration_schema.json

生成模式后，请配置您的文本编辑器。以下是常用编辑器的说明：

• Visual Studio Code
• Emacs
• IntelliJ
• Sublime
• Vim

升级路由器配置

路由器的全新发布可能会对YAML配置文件的预期格式造成破坏性更改，通常是为了扩展现有功能或提高可用性。

如果您运行的路由器版本带有一个该版本不再支持的配置文件

1. 路由器在启动时发出警告。
2. 路由器尝试将您提供的配置转换为新的预期格式。
   • 如果转换成功且无错误，路由器将正常启动。
   • 如果转换失败，路由器将终止。

如果您遇到此警告，可以使用router config upgrade指令查看现有配置文件的新预期格式：

1
./router config upgrade <path_to_config.yaml>

您还可以查看升级现有配置文件所需的确切更改差异

1
./router config upgrade --diff <path_to_config.yaml>

相关主题

• 配置路由器的生产检查清单