gRPC

Google 开源的基于 HTTP/2 协议的，使用 Protocol Buffers 作为接口定义语言（IDL）和通信格式的 RPC 框架。

目前是 CNCF 的孵化项目，估计也将成为云原生的事实上的服务调用标准，前途不可限量。

Protocol Buffer

https://developers.google.com/protocol-buffers

Google 开源的语言与平台无关的可扩展的结构化数据序列化，用于通信，存储等，类似 XML，但是更加的小巧、简洁和高效。 定义构造数据的方式，然后生成各种语言的源代码（不止提供数据结构，还提供了存取和序列化反序列化接口）。

它的工作流程是，首先书写 .proto 文件，然后使用 protoc 编译器将 .proto 编译成具体语言的源代码，源代码提供了基本的 存取和序列化序列化接口，再然后在你的工程中引入源代码，开始使用。

gRPC

https://grpc.io/about/

应用场景：

  • 微服务架构下，高效的连接不同语言的服务 - 微服务通信
  • 移动设备、浏览器客户端与后端通信 - C/S 模式通信
  • 生成高效的客户端库（iOS, Android）

核心功能：

  • 10 种常用语言的客户端库 - 支持大部分常用语言
  • 一个简单的服务定义框架，实现高效的线上通信
  • 基于 HTTP/2 的双向传输流
  • 可插拔的身份验证，追踪，负载均衡和健康检测

文档：

gRPC for go

官方 Repo: https://github.com/grpc/grpc-go

工作流程：

  • 在 .proto 文件中定义服务
  • 使用 protobuf 编译器生成服务器和客户端代码
  • 使用 Go RPC API 写客户端和服务器
  • 调试

gRPC 生态

投入生产使用，只有协议本身是不够的，还要有与服务治理相关的周边才行。

gRPC Ecosystem 这个组织补充一些 gRPC 生态中所需要的组件，官方的。

资料

  • Motivation gPRC 的前身是谷歌内部用了十多年的微服务通信协议 Stubby，Stubby 有很多的优良特性，但是它的设计不遵循外面的协议标准， 与内部的基础架构紧耦合。随着 SPDY，HTTP/2 和 QUIC 的出现，Stubby 的很多特性已经逐渐称为公共的标准，甚至是 Stubby 不具备的特性。 gRPC 是 Stubby 标准化之后的结果。
  • HTTP/2 简介：HTTP/2 的前身是 Google 开发的实验性协议 SPDY，第一个 HTTP/2 草案也是基于 SPDY 的， HTTP/2 并不是为了取代 HTTP/1 而是作为扩展。HTTP 2 相比与 HTTP 1 优势：
    • 二进制传输，在 HTTP 2.0 和 TCP/UDP 中间，添加一个二进制分帧层（首部封装为 Header 帧，Body 封装成 Data 帧）
    • 多路复用：多个请求复用同一个 TCP 连接
    • 支持双向通信，服务器可以向客户端推送消息
  • Google: API 设计指南 适用于 REST API 和 gRPC API
  • gRPC On HTTP/2: Engineering A Robust, High Performance Protocol
  • Wire protocol gRPC 文档中不止一次出现了这个术语，姑且翻译成 有线协议，看下维基百科的解释，还是比较清楚的 在计算机网络中， wire protocol 指的是点对点获取数据的一种方法：如果多个应用必须有交互操作，则需要 wire protocol。 它通常是指高于物理层的协议。和传输层的传输协议（TCP/UDP）不同，属于 "wire protocol" 用来描述在应用级别上的表示信息的通用方法。 它仅指通用的应用层的协议，而不是应用程序的通用对象语义。在应用程序级别的这种标识需要公共信息集（比如 XML）和数据绑定（比如 XSD 这样的公共编码方案）。
  • The state of gRPC in the browser 当前 gRPC 用于 C/S 和微服务器之间的通信，鉴于浏览器与后端的通信方式大都还是 JSON RESTful API 的方式， 谷歌开源了 gRPC-web，原理是在浏览器和后端服务之间加了一层代理。用来生成前端所有需要的代码库和启用一个 proxy 代理，调用方式也是 RPC 的方式。 这玩意我看了，放到生产里面无论是架构还是协作起来有点复杂的，架构依赖于 envoy