Grpc的介绍
Grpc是由Google主导开发的RPC框架，使用HTTP/2协议并用ProtoBuf作为序列化工具。其客户端提供Objective-C、Java接口，服务器侧则有Java、Golang、C++等接口，从而为移动端（iOS/Androi）到服务器端通讯提供了一种解决方案。Google对其的声音是：
- 基于Http2.0标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用
- 可以一次性的在一个 .proto 文件中定义服务并使用任何支持它的语言去实现客户端和服务器，反过来，它们可以在各种环境中，从Google的服务器到你自己的平板电脑- gRPC 帮你解决了不同语言间通信的复杂性以及环境的不同.使用 protocol buffers 还能获得其他好处，包括高效的序列号，简单的 IDL 以及容易进行接口更新
Grpc的缺点
Grpc的优点都由Google说了，就来谈谈Grpc的缺点吧（这是个人见解）
数据对象的不友好性
- Grpc的数据对象是基于ProtobufV3的Message对象来构建其入参及出参，这个数据对象不是一个真正的PoJo数据对象，基于链式管理的风格有的人习惯有的人不习惯，这个是其数据不友好性之一
- Grpc的接口调用，如果是要参数为空，不好意思，不支持，必须要有一个Message对象，必须要有一个数据对象，空的也好，必须传入
- Grpc使用Protobuf来作为其序列化的底层框架，而Protobuf对于任何一个数据对象的序列化必须要有一个单例的DEFAULT_INSTANCE，这个是他获取序列化,这个是Protobuf的真正的弊端，估计有人说这个无所谓，但是如果要实现Api gateway，这种弊端就体现出来了，我们知道任何一个数据对象都能以元数据的方式来传入动态的把这个元数据进行序列化，而Grpc无法做到这点，这也导致现在Grpc的gateway必须是依据Proto的定义改变而改变，也就是Proto定义改变了，gateway必须重启，这种体验是无法忍受的
服务契约的不友好性
Java走到服务化这一步，其interface大行其道，像现在主流的Rpc框架中许多都是使用java的接口来做为服务契约，这种方式还是比较根深蒂固的，但是Grpc不是如此，利用protobuf生成的stub存根，可读性实在是太差了，想要真正的了解序列化逻辑实在是太麻烦了基于流方式的传输的复杂性
Grpc可以基于streaming流的方式来进行数据传输，这是啥意思呢，也就是我传了多少数据给服务端，我先告诉你，服务端拿到之后，再去把数据反序列化出来，理想很丰满，现实很骨感，这个通知，Grpc是咋做的呢，其服务定义必须要有一个这样显式的定义接口，通过这个接口来定义这种流式的传输，这种对Idl的无关定义侵入让人很不舒服
Grpc的优点
谈了谈Grpc的缺点，我来说说优点吧
多语言
Grpc的多语言是他做的很牛逼的地方，特别是在设备端，客户端支持ios，android，而基于http2.0的多路复用也的确让设备真正的省了流量，省了电，也省了空间基于Http2.0
采用HTTP2的好处在于,因为添加了头信息,可以方便在框架层面对调用做拦截和控制(比如说限流,调用链分析,安全认证等)而且http2为标准协议,也方便以后扩展兼容其它调用端
暂时就谈这么多，最后打一个广告
<a href=”https://github.com/quancheng-ec/saluki”> 传送门</a>
这个是基于grpc的扩展，能够进行注册，发现，并且初步的解决了数据对象不友好性
