本文会介绍gRPC和协议缓冲。gRPC可以使用协议缓冲作为它的IDL和底层信息交换格式。如果你刚接触gRPC或者协议缓冲，那就看本文！如果你想深入或者实战，查看Quick Starts。
概述在GRPC里，客户端可以直接调用不同机器上的服务应用的方法，就像是本地对象一样，所以创建分布式应用和服务就很简单了。在很多RPC(Remote Procedure Call Protocol)系统里，gRPC是基于定义一个服务，指定一个可以远程调用的带有参数和返回类型的的方法。在服务端，服务实现这个接口并且运行gRPC服务处理客户端调用。在客户端，有一个stub提供和服务端相同的方法。
在各种环境里，gRPC客户端和服务端都能运行并且互相通讯 - 从谷歌内部服务到你自己的桌面 - 并且可以写在任何gRPC支持的语言。比如，可以简单的创建java作为gRPC的服务端，Go，Python或者Ruby作为客户端。另外，最新的谷歌APIs将会有gRPC版本的接口，可以方便的在应用里构建Google功能。
使用协议缓冲
默认gRPC使用protocol buffers,Google成熟开源的序列化结构数据(尽管可以使用其他数据格式，比如JSON)。这里有简单的介绍他是如何工作的。如果你已经熟悉了协议缓冲，可以直接看下一章节。
使用协议缓冲的第一步是在proto file里为数据定义你想序列化的结构：可以是普通的.proto扩展的文本文件。协议缓冲数据结构为messages，每条message是一个小的逻辑记录的信息包含一些name-value对名为fields。比如：
message Person {
string name = 1;
int32 id = 2;
bool has_ponycopter = 3;
}
然后，一旦你指定了你的数据结构，使用协议缓冲解析器protoc生成数据访问类在proto定义的语言。这些为每个字段(比如name()和set_name())和方法序列化/解析整个结构到/从raw bytes提供了简单的访问器 - 比如，你选择的语言是C++，对上面的例子运行编译会生成一个Person类。然后就可以在应用里使用这个类去populate，序列化和获取Person协议缓冲messages。
你将会在示例里看到更详细的定义在普通proto文件里的gRPC services，有RPC方法参数和指定的返回类型作为协议缓冲messages:
// The greeter service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
// The response message containing the greetings
message HelloReply {
string message = 1;
}
gRPC同样使用protoc和指定的gRPC插件从你的proto文件里生成代码。但是，使用gRPC插件，你会得到生成的gRPC客户端和服务端代码和普通的用来populating，序列化和获取你的消息类型protocol buffer代码。我们将会在下面的实例详细说明。
可以在Protocol Buffers documentation查看更多的关于protocal buffers, 和如何安装相应语言的protoc和插件。
Protocol buffer versions
虽然protocal buffers有些时候对开源用户可用，我们的示例使用了新风格的protocal buffers，叫做proto3,有着更简单的语法，一些有用的新特性，并且支持更多的语言。现在对以下语言可用：Java,C++,Python,Objective-C,C#,alite-runtime(Android Java),Ruby和JavaScript from theprotocol buffers Github repo，同时Go语言生成器golang/protobuf Github repo，还有更多语言在开发中。查看proto3 language guide了解更多，还有相关可用的每种语言的文档，在release notes查看每个版本的区别。更多的proto3文档还在更新中。
一般，虽然可以使用proto2(当前默认的protocal buffers版本)，我们还是建议你使用proto3搭配gRPC，让你可以使用全部的gRPC支持的语言，同时避免与proto2客户端与proto3服务端通选的兼容问题(或者proto3客户端-proto2服务端的问题)。
应用场景
gRPC已经应用在Google的云服务和对外提供的API中，其主要应用场景如下：
- 低延迟、高扩展性、分布式的系统
- 同云服务器进行通信的移动应用客户端
- 设计语言独立、高效、精确的新协议
- 便于各方面扩展的分层设计，如认证、负载均衡、日志记录、监控等
与其他rpc比较
与thrift,dubbo,motan等比较
grpc vs thrift:
gRPC优缺点：
> 优点：
protobuf二进制消息，性能好/效率高（空间和时间效率都很不错）
proto文件生成目标代码，简单易用
序列化反序列化直接对应程序中的数据类，不需要解析后在进行映射(XML,JSON都是这种方式)
支持向前兼容（新加字段采用默认值）和向后兼容（忽略新加字段），简化升级
支持多种语言（可以把proto文件看做IDL文件）
Netty等一些框架集成
> 缺点：
1）GRPC尚未提供连接池，需要自行实现
2）尚未提供“服务发现”、“负载均衡”机制
3）因为基于HTTP2，绝大部多数HTTP Server、Nginx都尚不支持，即Nginx不能将GRPC请求作为HTTP请求来负载均衡，而是作为普通的TCP请求。（nginx1.9版本已支持）
4） Protobuf二进制可读性差（貌似提供了Text_Fromat功能）
默认不具备动态特性（可以通过动态定义生成消息类型或者动态编译支持）
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
用人品去感动别人，用改变去影响别人，用状态去燃烧别人，用行动去带动别人，用阳光去照耀别人，用坚持去赢得别人，要求自己每天都去做与目标有关的事情，哪怕每天只进步一点点，坚持下来你就是最优秀卓越的！欢迎大家加入大数据交流群：725967421 一起交流，一起进步！！
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------