Python-gRPC实践（1）--gRPC简介

前言

接触gRPC比较早， 但我不怎么喜欢在Python中使用gRPC， 因为Python中的官方gRPC框架易用性太烂了， 只提供基本功能， 附带的其他功能要不就不完善， 要不文档就只有简单几句话， 啥东西都得去原本的项目找, 用起来都不顺心（毕竟不是Goole的亲儿子，支持的力度肯定比较少）。

吐槽归吐糟， 但是还是得用， 因为其他语言的项目都用了gRPC, 不同团队服务的通信需要依赖gRPC进行通信， 所以这块硬骨头还是得啃下去。 在啃的过程非常艰辛， 因为官方文档太少了， 相关文章也不多， 中文社区零零散散， 英文社区的文章会比较多， 但很多搜索出来的都是Go-gRPC相关的， 这就很扎心了， 而这个系列文章就是我啃完的一个总结。

好了， 唠嗑完毕， 以下是文章的正式内容。

1.什么是RPC

在了解gRPC之前， 先了解什么叫RPC, RPC是Remote Procedure Call的简称， 中文称为远程过程调用， 它允许不同的进程或者不同的机器的程序互相调用。 其实按照这个定义，平时使用的HTTP（Restful API）请求也算RPC， 因为主流的HTTP（Restful API）在不同的服务之间兼容性虽是最棒的, 也有成熟的生态， 所以很多公司的内部服务还是以HTTP来互相调用， 但是由于传输体积很大， 这种方式的请求速度并不是很快， 传输性能不佳。

不过现在很多公司的内部服务间的调用越来越多， 调用链变长， 如果还用HTTP（Restful API）的方式做内部服务的调用， 那整个调用链的时间就变长, 同时增加了系统开销, 需要一些别的方案来解决这些问题;同时由于这些服务通常都是在内网， 这些服务只要内部协议兼容就行, 不用过多的去考虑外部因素， 追求的是更小的传输体积， 更快的传输速度（所以内网间用UDP也是可以的）， 同时对系统的性能消耗较低， 所以就有了各种RPC协议诞生。

目前市面上各种RPC协议虽然互不兼容， 但是他们基本上只有在传输协议和序列化协议有较大的不同， 传输协议和序列化这两点恰好就是与传输体积， 传输速度和系统性能消耗的问题有关。 其中传输协议是为了解决传输体积和传输速度的问题， 一般使用的是TCP， UDP传输协议或者是直接基于HTTP自定义的应用层协议， 而序列化协议主要解决的是通用性， 流行性， 成熟性, 空间占用，时间占用， 一般RPC定制的序列化, 都追求较少的空间占用（减少网络传输压力）和时间占用（减少机器的序列化时间）， 其次再满足其它3个特性， 兼容其它语言等。

2.gRPC

gRPC是Google开源的高性能、通用的RPC框架， 前面的g在不同的版本都有对应的意思 但是我觉得就是Google的意思， 毕竟在它的亲儿子Go使用gRPC太方便了， 基本上是开箱即用。 gRPC的特点是：

• gRPC使用HTTP/2协议，HTTP/2解决并优化了HTTP1.1的一些缺陷， 带来了更多强大功能，如多路复用、二进制帧、头部压缩、推送机制。这些功能给设备带来重大益处，如节省带宽、降低TCP连接次数、节省CPU使用等。而且目前很多框架都提供对HTTP的支持（如Nginx）， 所以适用范围广；
• 默认使用谷歌开源的Protocol Buffer(类似于XML、JSON的数据序列化结构协议)，传输速率、解析速度都很快、压缩率高，性能整体都比XML和JSON好， 同时支持类型声明，可以生成良好的文档和示例。
• 语言中立（功能提供上确实算中立…），支持各种流行语言(C++、C#、Java、Go、Python等)都能用，轻松实现跨语言通信；本身不限于任何平台。
• 基于 IDL 文件定义服务，通过 proto3 工具生成指定语言的数据结构、服务端接口以及客户端 Stub；
• 除了HTTP（Restful API）的一请求一响应外， 还支持单向，双向的流API。
</