hertz和kitex的相关理解 | 青训营

直接使用kitex框架也可以实现RPC服务端和客户端,那么为什么还需要使用hertz生成代码呢?

主要原因有以下几点:

1. kitex支持的传输方式是TTHeader,而不是HTTP。如果要发布基于HTTP的服务,还需要额外的工作。
2. hertz生成的代码提供了基于HTTP的客户端和服务端实现。可以直接对外提供HTTP服务,不需要自己处理HTTP相关的内容。
3. hertz生成的客户端代码封装了HTTP调用细节。应用程序只需要简单调用,就可以访问Thrift定义的HTTP服务。
4. hertz的HTTP映射自动对应Thrift中的annotation,而kitex中的实现需要自己处理这层映射。
5. hertz默认提供了服务注册/发现、负载均衡等能力。这些都是基于HTTP服务需要的功能。
6. 对于需要http访问的IDL,hertz可以省去很多与底层HTTP协议相关的代码。

综上,对于需要HTTP访问的Thrift服务,使用hertz可以简化构建服务的工作,不需要处理底层网络传输。

kitex更适合构建RPC微服务。两者配合使用可以充分发挥Thrift的优势,既可以定义接口也可以实现不同类型的服务。

所以hertz主要是提供了基于HTTP的Thrift服务端/客户端实现,这对HTTP服务来说是很好的补充和支持。

当 Hertz 和 Kitex 结合使用时，Hertz 充当了 HTTP 服务器的角色，而 Kitex 充当了 RPC 框架的角色。Hertz 提供了 HTTP 服务的能力，可以接收来自客户端的 HTTP 请求，并将请求转发给 Kitex 处理。Kitex 则提供了 RPC 调用的能力，可以处理来自 Hertz 的请求，并将结果返回给 Hertz。这种结合使用的方式可以让开发者更加方便地构建高性能、易扩展、低时延的微服务1 。

为了更好地理解 Hertz 和 Kitex 的结合使用，我们可以想象一个场景：假设我们正在开发一个在线商城应用程序，需要提供商品查询、下单、支付等功能。我们可以使用 Hertz 提供 HTTP 服务，接收来自客户端的 HTTP 请求，并将请求转发给 Kitex 处理。Kitex 可以处理来自 Hertz 的请求，并调用后端服务进行商品查询、下单、支付等操作。最后，Kitex 将结果返回给 Hertz，Hertz 再将结果返回给客户端。这样，我们就可以通过 Hertz 和 Kitex 结合使用，构建一个高性能、易扩展、低时延的在线商城应用程序1 。