【Hertz 新手小册】Day 3. 如何用 Hertz 实现 HTTP 请求

本期内容介绍：

   1. 如何用 Hertz 实现 HTTP 请求            

   2. 请求背后的流程与运行逻辑

   3. Hertz 三高特性的详细解读

01 如何用 Hertz 实现 HTTP 请求

如果要用一个软件或者一个网页来模拟是什么样子的呢？这里选用了一个非常常用的调试工具叫 Postman 进行一个模拟的请求。

首先在下图第一个红框位置，选好我们的 HTTP Method 就是 POST。在这里写好 URL 和请求地址，以及我们的数据所在的对应位置。之后我们可以点击 Send 按钮进行发送。发送完毕后就可以看到我们收到了小姐姐的一个响应，这就是来自 Server 的一个响应。

如果我们选择使用 Hertz 实现这个代码，只需短短几行就可以实现（如下图所示）。

第一步，初始化 Hertz 的 Engine；

第二步，选择一个对应的 HTTP Method 和注册的路由地址；

第三步，将真正的处理函数注册到这个路由上。

这个项目就可以运行了。

那么如此简单的一个代码背后隐藏了什么东西呢？这就涉及到请求背后的流程与运行逻辑。

02 请求背后的流程与运行逻辑

1. 业务层。业务层的作用是使用框架提供的 API 完成业务逻辑，框架提供 API 的易用性很大程度上决定了开发体验。

2. 服务治理层/中间件层。在编写完业务逻辑之后，会进入到服务治理层，服务治理层包括熔断、限流等等。具体举例如下：

• 熔断：比如说你经常邀请小姐姐去吃烧烤，但是邀请了几次对方没有回应，于是你下一次选择不再进行邀请，这个就是熔断。对应到微服务体系，如果某一个下游一直出错，我们可以选择不请求这个下游。
• 限流：对于 Server，也就是小姐姐，如果你的请求又要吃烧烤，吃完烧烤还要去看电影等等，小姐姐为了防止压力过大，会先拒绝几个请求，这就叫做限流。

服务治理层其实是依托于中间件层的，中间件层是和请求级别绑定的，有前处理逻辑和后处理逻辑。它的存在是为了将一些核心逻辑和通用逻辑区分开。除了服务治理相关的逻辑外，中间件还可以有很多其他的用处，比如 Recovery 捕获异常的中间件、Metrics 组件获得请求的耗时、以及链路追踪。

那么链路追踪具体是什么呢？比如小明由于腼腆不敢直接邀请小姐姐吃烧烤，于是找了朋友老王帮忙询问，但老王一直没有回应。那么是老王没有帮忙询问还是询问之后小姐姐没有回应呢？此时对于小明而言无法得知的。因此我们可以用链路追踪查看具体情况，现在 Hertz 也集成了 OpenTelemetry 和 OpenTracing 两种社区中非常主流的链路追踪实践。

3. 协议编解码层。经过中间件层后，就可以进入协议编解码层。协议编解码层就是上述例子当中的明文协议，除此之外，还可能会涉及到其他的一些协议。例子中使用了 H1 协议，基于 H1 的不足，现在逐步出现了 H2、H3 等。

4. 传输层。编码完成后即可传输编码后的数据 Server，小姐姐按照对应的流程进行解码就完成了。

5. 路由层。相比请求的流程，小姐姐这边会多一个路由层。小姐姐可能会同时处理多个请求，针对不同的事情要用不同的优先级和不同的处理方式，这个时候可以通过路由判断针对不同的请求采用怎样的处理方式。

基于此，我们的框架需要提供以下方面的支持：

• 业务层，提供丰富好用的 API ，帮助用户更快地去构造出代码。

• 中间件层，除了 Server 的中间件支持外，Client 也希望能够支持中间件，由此 Client 和 Server 的服务治理能力和一些可观测性的能力都会有很大提升。同时中间件能够将通用逻辑和业务逻辑分开，用户只需要专注于自己的业务逻辑。

• 路由层，能够提供丰富的路由功能。

• 协议编解码层，满足多协议的支持，如 H1、 H2 等等。

• 传输层，不同的网络库适用的场景不一样，能够灵活地替换网络库。

03 Hertz 三高特性的详细解读

1. Hertz 是一个超大规模的企业级 HTTP 框 架，峰值 QPS 超过了 7 千万，最近这个数字仍在提高。 除了业务在用之外，还有很多其他的基础组件也在用 Hertz ，比如 Mesh 的控制面、压测平台、函数及服务 FaaS 等等，这验证了 Hertz 很强的稳定性。可以应对以下情景：

• 我们写代码时，发现了与一期不一致的结果，此时可能会想是代码出了问题。但是如果发现自己的代码没有问题，反而这个问题来自于框架，这种体验是非常不好的。
• 如果用户随便改 API，可能会导致框架不兼容。但是对于 Hertz 这样一个超大规模企业级的框架，包括字节内部也采用了套壳的形式，版本管理就会非常地严格，不会出现很严重的不兼容情况，这是我们拥有的一些其他框架无法比拟的稳定性优势。

2. 业界领先的吞吐和超低的时延。

• 重点突出“超低的时延”是因为现在时延对标的是用户体验。比如抖音 APP，如果一个视频刷了一分钟还没有呈现，那用户就会放弃使用。相反时延越低，用户体验会越好。
• “业界领先的吞吐”没有重点突出是因为如果存在吞吐差的问题，其实可以通过一些横向水平扩展的、加机器的手段进行解决，这并不是一个瓶颈。但是水平扩展的方法没有办法解决时延问题。

3. Hertz 是一个开箱即用的框架，开箱即用代表 Hertz 的易用性。

• Hertz 具有稳定性和时延的优越性，那如何让用户使用起来呢？如果框架用起来非常麻烦，用户还是难以接受的。降低用户使用框架的成本，才是优先级更高的事情。
• Hertz 提供了一个一键生成脚手架的工具 Hz，大家可以在 CloudWeGo 官网上找到相关的介绍，源码解读活动第二场直播也会主要对 Hz 的使用做一些实践分享。

4. 高扩展性、高应用性和高性能。

• 三高是 CloudWeGo 所有项目都具有的一些特点，这里就不再详细展开。
• 用户在使用中希望能够提供一个大而全的框架，Hertz 也是提供了一些很多默认的实践，比如链路追踪提供了 OpenTracing 和 OpenTelemetry 两套实践，对于很多用户来说已经能够满足其大部分的需求了。如果用户觉得不能够满足他们的某些需求，他们也可以通过框架提供的接口进行注入，这就是高扩展性的体现。

---

相关信息

官方 GitHub：github.com/cloudwego/h…

官方文档：www.cloudwego.io/zh/docs/her…

项目地址

GitHub：github.com/cloudwego

官网：www.cloudwego.io