当前位置: 首页>编程语言>正文

gRPC 学习笔记

  • gRPC 主要使用同步请求-响应模型来交互,但是在初次连接建立后,可以实现全异步或者流模式;

  • SOAP:Simple Object Access Protocol,是面向服务架构(SOA——service-oriented architecture)的标准沟通技术,用来在服务间传输基于XML结构的数据。传输可以基于任意底层传输协议,如HTTP;

  • REST:Repressentational State Transfer ,是面向资源架构(ROA——resource-oriented architecture)的基础;

    • 面向资源架构:将分布式应用建模为一个资源的集合,访问这些资源的客户端可以修改资源的状态(创建、读取、更新、删除等)
  • gRPC的优势:

    • 高效的内部进程沟通(inter-process communication)

    • 简单、优雅的服务接口和框架定义

    • 强类型,支持多种语言,便于约定服务和消息体

    • 支持双向流

  • gRPC的缺点:

    • 可能不适合面向外部服务的场景

      • gRPC 服务协议驱动、强类型的特征可能会限制对外服务的灵活性,同时会削弱使用者的控制能力(The contract-driven, strongly typed nature of gRPC services may hinder the flexibility of the services that you expose to the external parties, and consumers get far less control)
    • 当有大量的服务定义被修改时,需要重新生成客户端和服务端的代码

  • gRPC 中,所有的请求都是 HTTP POST 请求,需要在 content-type 里加上 application/grpc前缀;待调用的远程方法作为一个单独的 HTTP 头部发送

  • Protocol buffer 的编码方式:

    gRPC 学习笔记,第1张
    pb.png
  • Tag 由两部分组成:

    | Field Index | Wire Type |

    • Field Index:定义 message 时加在每个字段前的数字

    • Wire Type:由字段的实际类型决定,占 3 个bit,用来定位 Value 的长度

      gRPC 学习笔记,第2张
      Tag.png
    • 注意:在处理负数时,使用 sint 比使用 int 更高效

    • Tag value = (field_index << 3) | wire_type

  • 当消息被编码时,它的 tags 和 values 被连接到一个比特流中,流的结尾处用一个值为0的tag来标记

  • Length-Prefixed Message Framing:

    • gRPC 使用 Length-Prefixed Message Framing 技术来进行消息分帧,即,在写入消息本身之前,先写入消息的长度;

    • 在编码二进制消息之前,可以分配4个字节来指定消息的长度,这意味着 gRPC communication 可以处理上限为 4G 的消息

      gRPC 学习笔记,第3张
      frame.png
    • 写在消息长度之前的是一个1字节的无符号整数,用来指示数据是否压缩过

      • 压缩标志设为1,代表数据经过了压缩,压缩方法写在HTTP头中
  • gRPC 使用 HTTP/2 作为传输协议;

  • 请求消息:

    • 包含三个主要部分:请求头,带长度前缀的消息以及一个流结束的标志
        HEADERS (flags = END_HEADERS)
        :method = POST
        :scheme = http // 如果允许TLS,则使用 https
        :path = /ProductInfo/getProduct // 端点的路径:/{service name}/{method name}
        :authority = abc.com // 定义目标 URI 的虚拟主机名
        te = trailers // 定义不兼容代理的检测,gRPC 必须是 trailers
        grpc-timeout = 1S // 定义超时时间,如果不定义,则默认为无穷大
        content-type = application/grpc
        grpc-encoding = gzip // 定义消息压缩的方式
        authorization = Bearer xxxxxx</pre>
    
    • 注意 content-type 必须以 application/grpc 为前缀,否则的话,gRPC 服务器会返回一个 415(Unsupported Media Type)状态码

    • : 开头的字段称为保留头,HTTP/2 要求保留头必须写在其他头部字段之前

    • gRPC 的头部字段可以分为两类:call-definition headers 和 custom metadata

      • call-definition header:由 HTTP/2 预定义的头部,必须设置在 custom metadata 之前

      • custom metadata:由应用层定义的任意键值对,注意自定义时不要使用grpc-开头的键名,这些是保留的键名

    • 通过在最后一个数据帧上加上 END_STREAM 标志来结束请求消息

        DATA (flags = END_STREAM)
        <Length-Prefixed Message></pre>
    
  • 响应消息:

    • 通常也包含三个部分:响应头,带长度前缀的消息和trailers,但是可以不包含带长度前缀的消息
        HEADERS (flags = END_HEADERS)
        :status = 200
        grpc-encoding = gzip
        content-type = application/grpc</pre>
    
    • 结束标志不与数据帧一起发送,而是作为单独的头部发送,称为 trailer
        HEADERS (flags = END_STREAM, END_HEADERS)
        grpc-status = 0 # OK 
        grpc-message = xxxxxx</pre>
    
    • 如果在请求调用的过程中出现错误,server 只发送一个 trailer 作为响应,不发送数据帧,以下头部会包含在 trailer 中:
        HEADERS (flags = END_STREAM, END_HEADERS)
        grpc-status = 0 # OK 
        grpc-message = xxxxxx</pre>
    
  • gRPC 沟通模型中的不同消息流:

    • Simple RPC

      gRPC 学习笔记,第4张
      simpleRPC.png
    • Server-streaming RPC

      gRPC 学习笔记,第5张
      ServerStreamRPC.png
    • Client-streaming RPC

      gRPC 学习笔记,第6张
      ClientStreamRPC.png
    • Bidirectional-streaming RPC

      gRPC 学习笔记,第7张
      BidirectionalStreamRPC.png
  • gRPC 实现架构

    gRPC 学习笔记,第8张
    gRPCArchitecture.png
    • grpc 基于两个快速高效的协议构建:protocol buffers 和 HTTP/2

    • protocol buffers:一个语言无关、平台无关,具有可扩展结构数据序列化机制的数据序列化协议;

      • 生成的是二进制负载
  • 负载均衡:

    • 负载均衡可以在服务器端实现(反向代理),也可以在客户端实现

      • 服务器端实现:客户端将请求发送到代理服务器,由代理服务器选择一个后端服务器重新建立连接转发请求,最后将结果返回给客户端

      • 客户端实现:客户端自己实现对服务器状态的监控和选择算法,服务器将自身状态与请求结果一并返回给客户端,客户端更新服务器状态

    • gRPC 学习笔记,第9张
      负载均衡的模式.png
    • 服务端负载均衡:

      • 分为传输层(L3/L4)和应用层(L7)两种;

      • 传输层负载均衡:负载均衡器与选中的服务器建立新的连接,将来自客户端的请求拷贝转发到选中的服务器。

        • 优点:不需要做太多额外处理,延迟小,消耗资源少
      • 应用层负载均衡:负载均衡器解析 HTTP/2 请求,根据请求的内容决定转发到哪个服务器

        gRPC 学习笔记,第10张
        服务端负载均衡.png
    • 客户端负载均衡:

      • 胖客户端(thick client):由客户端全权处理服务器的所有信息,包括通过类库整合服务发现、名字解析、配置中心等

      • 后备负载均衡器(lookaside load balancer):由一个单独的负载均衡器来管理服务器的相关信息,客户端向该负载均衡器发起请求,获得服务器的地址,然后自己根据地址向服务器发起请求。服务器日常将自己的状态上报给负载均衡器

    • 最佳实践:

      gRPC 学习笔记,第11张
      负载均衡最佳实践.png

参考资料

  • 《gRPC: Up and Running》

  • RPC的负载均衡


https://www.xamrdz.com/lan/5xm2016586.html

相关文章: