Go微服务精讲:Go-Zero全流程实战即时通讯(超清)

166 阅读5分钟

Go微服务精讲:Go-Zero全流程实战即时通讯(超清)

 

download :Go微服务精讲:Go-Zero全流程实战即时通讯(超清)

一、掌握rpc/grpc并探究内在本质

理解 RPC(Remote Procedure Call)和 gRPC 的内在本质有助于深入了解它们的工作原理和优势。

  1. RPC(远程过程调用)
  2. RPC 是一种通信协议,允许一个进程调用另一个进程的过程(函数)而不需要显式编写网络通信代码。
  3. RPC 的基本原理是将本地调用转换为远程调用。当客户端调用远程过程时,RPC 框架会负责序列化参数并将其发送到远程服务器,服务器执行相应的过程并返回结果给客户端。
  4. RPC 框架通常包括客户端和服务器端的代码生成工具,用于生成客户端和服务器端的代码,以便进行通信和数据序列化。
  5. 传统的 RPC 协议包括 CORBA、XML-RPC、Java RMI 等,它们使用不同的协议和序列化格式。
  6. gRPC
  7. gRPC 是由 Google 开发的高性能、开源的 RPC 框架,基于 HTTP/2 和 Protocol Buffers。
  8. gRPC 使用 Protocol Buffers 作为默认的数据序列化和接口定义语言(IDL),它提供了更高效的数据序列化和更强的接口定义能力。
  9. gRPC 支持多种语言(如 C、C++、Java、Go、Python 等),并提供自动生成客户端和服务器端代码的工具。
  10. gRPC 基于 HTTP/2,可以实现双向流、流控制、头部压缩等功能,提供了更高效的网络传输和更低的延迟。
  11. gRPC 使用基于 HTTP/2 的传输层,支持多路复用,因此可以在单个 TCP 连接上同时处理多个请求,提高了网络利用率。

在内在本质上,RPC 和 gRPC 都是实现远程过程调用的协议,但 gRPC 在性能、可扩展性和接口定义等方面具有更多的优势,使其成为当前流行的选择之一。

二、rpc是什么?又如何实现服务通信?

RPC(Remote Procedure Call)是一种远程过程调用的协议,用于使一个计算机程序能够请求另一个计算机上的服务而不需要了解底层网络细节。简单来说,RPC允许一个程序调用另一个程序或服务的子程序(或函数)而不需要显式编码跨网络的细节。

实现服务通信的一种常见方式是通过使用RPC框架。以下是实现服务通信的一般步骤:

  1. 定义接口
  2. 首先,需要定义服务接口,即指定服务提供的方法和参数。这可以使用一种接口定义语言(IDL)来完成,如Protocol Buffers或Thrift。
  3. 生成客户端和服务端代码
  4. 使用定义的接口,可以生成客户端和服务端代码。这些代码负责将RPC调用转换为网络通信,并处理返回结果。
  5. 客户端调用
  6. 在客户端代码中,通过调用生成的客户端代理代码来发起RPC请求。客户端代理负责将调用转换为网络请求,并将返回结果传递给调用者。
  7. 服务端实现
  8. 在服务端代码中,实现生成的服务接口的方法。当收到RPC请求时,服务端代码负责解析请求、执行相应的操作,并将结果返回给客户端。
  9. 通信协议
  10. RPC框架通常使用一种特定的通信协议来进行数据传输,如HTTP、TCP或自定义的二进制协议。
  11. 序列化和反序列化
  12. 在将数据传输到网络上之前,需要将数据序列化为适合在网络上传输的格式。同样,在接收到数据后,需要将其反序列化为原始数据格式。

通过使用RPC框架,开发人员可以更轻松地实现跨网络的服务通信,而不必担心底层的网络细节。常见的RPC框架包括gRPC、Apache Thrift、Protocol Buffers等。

三、为什么是以rpc为主而不是restful?

RPC 和 RESTful 是两种不同的远程通信协议,它们各有优势和适用场景,因此在不同的情况下选择使用其中一种可能更合适。

一些情况下 RPC 被选为主要的通信协议的原因包括:

  1. 性能:在某些情况下,RPC 可能比 RESTful 更高效。由于 RPC 通常使用二进制协议,如 Protocol Buffers 或 Thrift,它们可以更有效地序列化和反序列化数据,从而减少了网络传输的数据量和处理时间。
  2. 严格的接口定义:RPC 通常使用接口定义语言(IDL)来定义服务接口,这样可以确保客户端和服务端之间的接口定义是严格一致的,减少了由于接口不一致而导致的错误。
  3. 强类型支持:RPC 通常具有强类型的特性,因此在某些情况下更容易进行类型检查和错误处理。
  4. 生态系统支持:某些情况下,特定的应用场景或生态系统可能更倾向于使用 RPC。例如,Google 内部的服务通常使用 gRPC,因为它与其他 Google 技术集成更紧密。

然而,RESTful 也有其自身的优势,例如:

  1. 简单性和可读性:RESTful 接口通常使用简单的 HTTP 方法(GET、POST、PUT、DELETE)和 URL 结构,易于理解和调试。
  2. 灵活性:RESTful 接口不受限于特定的编程语言或平台,因此可以更容易地与各种不同的客户端和服务端进行集成。
  3. 缓存机制:RESTful 接口天生支持 HTTP 的缓存机制,可以减少服务器的负载并提高性能。

综上所述,选择 RPC 还是 RESTful 主要取决于具体的应用场景、性能需求、团队技术栈和个人偏好等因素。