使用 GraphQL 作为 API 网关来监控微服务
GraphQL 微服务

> 
> 在问题导致关键的微服务瘫痪之前，使用 GraphQL 的监控功能帮助你及早发现问题。
> 
> 
> 


![](/data/attachment/album/202009/06/205052ve8eebyamcace4v8.jpg)


[微服务](https://opensource.com/resources/what-are-microservices)和 [GraphQL](https://opensource.com/article/19/6/what-is-graphql) 就像面包和黄油一样，是一个很好的组合。它们本身都很棒，结合起来就更棒了。了解你的微服务的健康状况是很重要的，因为它们运行着重要的服务。如果等到某个关键的服务崩溃了才诊断问题，那是很愚蠢的。让 GraphQL 帮助你及早发现问题并不需要花费太多精力。


![GraphQL in Microservices](/data/attachment/album/202009/06/205139mi1icisfjshcgspm.png "GraphQL in Microservices")


常规的健康检查可以让你观察和测试你的服务，在问题影响到你的业务、客户或项目之前，尽早得到通知。说起来很简单，但健康检查到底要做什么呢？


以下是我在设计服务检查时考虑的因素：


服务器健康检查的要求：


1. 我需要了解我的微服务的可用性状态。
2. 我希望能够管理服务器的负载。
3. 我希望对我的微服务进行端到端（e2e）测试。
4. 我应该能够预测中断。


![Service health in microservices](/data/attachment/album/202009/06/205142p8u5addu33gzu4gu.png "Service health in microservices")


### 做服务器健康检查的方法


进行健康检查可能比较棘手，因为理论上，你可以检查的东西几乎是无穷无尽的。我喜欢从小处着手，运行最基本的测试：ping 测试。这只是测试运行应用的服务器是否可用。然后，我加强测试以评估特定问题，思考服务器中最重要的元素。我想到那些如果突然消失的话将是灾难性的事情。


1. \*\*Ping 检查：\*\*Ping 是最简单的监控类型。它只是检查你的应用是否在线。
2. \*\*脚本化浏览器：\*\*脚本化浏览器比较高级。像 [Selenium](https://www.selenium.dev/) 这样的浏览器自动化工具可以让你实现自定义的监控规则集。
3. \*\*API 测试：\*\*API 测试用于监控 API 端点。这是 ping 检查模型的高级版本，你可以根据 API 响应来定义监控计划。


### 使用 GraphQL 进行健康检查


在一个典型的基于 REST 的微服务中，你需要从头开始构建健康检查功能。这是一个时间密集型的过程，但使用 GraphQL 就不用担心了。


根据它的[网站](https://graphql.org/)称：



> 
> “GraphQL 是一种用于 API 的查询语言，也是一种用现有数据完成这些查询的运行时环境。GraphQL 为你的 API 中的数据提供了一个完整的、可理解的描述，让客户有能力精确地仅查询他们所需要的东西，让 API 更容易随着时间的推移而进化，并实现强大的开发者工具。”
> 
> 
> 


当你启动一个 GraphQL 微服务时，你还可以获得监控微服务的运行状况的供给。这是一个隐藏的宝贝。


正如我上面提到的，你可以用 GraphQL 端点执行 API 测试以及 ping 检查。


Apollo GraphQL 服务器提供了一个默认的端点，它可以返回有关你的微服务和服务器健康的信息。它不是很复杂：如果服务器正在运行，它就会返回状态码 200。


默认端点是 `<server-host>/.well-known/apollo/server-health`。


![Health Check with GraphQL](/data/attachment/album/202009/06/205144cpb2h7udbv73bavd.png "Health Check with GraphQL")


### 高级健康检查


在某些情况下，基本的健康检查可能不足以确保系统的完整性。例如，紧密耦合的系统需要更多的业务逻辑来确保系统的健康。


Apollo GraphQL 在定义服务器的同时，通过声明一个 `onHealthCheck` 函数来有效地管理这种情况。



```
* Defining the Apollo Server */
const apollo = new ApolloServer({
  playground: process.env.NODE_ENV !== 'production',
  typeDefs: gqlSchema,
  resolvers: resolver,
  onHealthCheck: () => {
    return new Promise((resolve, reject) => {
      // Replace the `true` in this conditional with more specific checks!
      if (true) {
        resolve();
      } else {
        reject();
      }
    });
  }
});

```

当你定义一个 `onHealthCheck` 方法时，它返回一个 promise，如果服务器准备好了，它就会返回 `resolve`，如果有错误，它就会返回 `reject`。


GraphQL 让监控 API 变得更容易。此外，在你的服务器基础架构中使用它可以使代码变得可扩展。如果你想尝试采用 GraphQL 作为你的新基础设施定义，请参见我的 GitHub 仓库中的[示例代码和配置](https://github.com/riginoommen/example-graphql)。




---


via: <https://opensource.com/article/20/8/microservices-graphql>


作者：[Rigin Oommen](https://opensource.com/users/riginoommen) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
[Microservices](https://opensource.com/resources/what-are-microservices) and [GraphQL](https://opensource.com/article/19/6/what-is-graphql) are a great combination, like bread and butter. They're both great on their own and even better together. Knowing the health of your microservices is important because they run important services—it would be foolish to wait until something critical breaks before diagnosing a problem. It doesn't take much effort to let GraphQL help you detect issues early.

![GraphQL in Microservices GraphQL in Microservices](https://opensource.com/sites/default/files/uploads/graphql-microservices.png)

Routine health checks allow you to watch and test your services to get early notifications about problems before they affect your business, clients, or project. That's easy enough to say, but what does it really mean to do a health check?

Here are the factors I think about when designing a service checkup:

**Requirements for a server health check:**

- I need to understand the availability status of my microservice.
- I want to be able to manage the server load.
- I want end-to-end (e2e) testing of my microservices.
- I should be able to predict outages.

![Service health in microservices Service health in microservices](https://opensource.com/sites/default/files/uploads/servicehealth.png)

## Ways to do server health checks


Coming up with health checks can be tricky because, in theory, there's nearly an infinite number of things you could check for. I like to start small and run the most basic test: a ping test. This simply tests whether the server running the application is available. Then I ramp up my tests to evaluate specific concerns, thinking about the elements of my server that are most important. I think about the things that would be disastrous should they disappear suddenly.

**Ping check:**Ping is the simplest monitor type. It just checks that your application is online.**Scripted browser:**Scripted browsers are more advanced; browser automation tools like[Selenium](https://www.selenium.dev/)enable you to implement custom monitoring rule sets.**API tests:**API tests are used to monitor API endpoints. This is an advanced version of the ping check model, where you can define the monitoring plan based on the API responses.

## Health check with GraphQL

In a typical REST-based microservice, you need to build health check features from scratch. It's a time-intensive process, but it's not something you have to worry about with GraphQL.

According to its [website](https://graphql.org/):

"GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools."


When you bootstrap a GraphQL microservice, you also get a provision to monitor the health of the microservice. This is something of a hidden gem.

As I mentioned above, you can perform API tests as well as ping checks with the GraphQL endpoint.

Apollo GraphQL Server provides a default endpoint that returns information about your microservices and server health. It's not very complex: it returns status code 200 if the server is running.

The default endpoint is `<server-host>/.well-known/apollo/server-health`

.

![Health Check with GraphQL Health Check with GraphQL](https://opensource.com/sites/default/files/uploads/healthcheck.png)

## Advanced health checks

In some cases, basic health checks may not be enough to ensure the integrity of a system. For example, tightly coupled systems require more business logic to ensure the health of the system.

Apollo GraphQL is efficient enough to manage this use case by declaring an `onHealthCheck`

function while defining the server:

```
* Defining the Apollo Server */
const apollo = new ApolloServer({
playground: process.env.NODE_ENV !== 'production',
typeDefs: gqlSchema,
resolvers: resolver,
onHealthCheck: () => {
return new Promise((resolve, reject) => {
// Replace the `true` in this conditional with more specific checks!
if (true) {
resolve();
} else {
reject();
}
});
}
});
```


When you define an `onHealthCheck`

method, it returns a promise that *resolves* if the server is ready and *rejects* if there is an error.

GraphQL makes monitoring APIs easier. In addition, using it for your server infrastructure makes things scalable. If you want to try adopting GraphQL as your new infrastructure definition, see my GitHub repo for [example code and configuration](https://github.com/riginoommen/example-graphql).

## Comments are closed.