Grpc应用场景分析
gRPC 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。目前提供 C、Java 和 Go 语言版本，分别是：grpc, grpc-java, grpc-go. 其中 C 版本支持 C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持.
gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特性。这些特性使得其在移动设备上表现更好，更省电和节省空间占用（相比当前传统的http1.1+json）。
gRPC是由Google主导开发的RPC框架，使用HTTP/2协议并用ProtoBuf作为序列化工具。其客户端提供Objective-C、Java接口，服务器侧则有Java、Golang、C++等接口，从而为移动端（iOS/Androi）到服务器端通讯提供了一种解决方案。 当然在当下的环境下，这种解决方案更热门的方式是RESTFull API接口。该方式需要自己去选择编码方式、服务器架构、自己搭建框架（JSON-RPC）。gRPC官方对REST的声音是：和REST一样遵循HTTP协议(明确的说是HTTP/2)，但是gRPC提供了全双工流和传统的REST不同的是gRPC使用了静态路径，从而提高性能用一些格式化的错误码代替了HTTP的状态码更好的标示错误。
至于是否要选择用gRPC。对于已经有一套方案的团队，可以参考下。如果是从头来做，可以考虑下gRPC提供的从客户端到服务器的整套解决方案，这样不用客户端去实现http的请求会话，JSON等的解析，服务器端也有现成的框架用。
grpc主要使用场景：
在微服务场景中使用究竟是否要使用grpc呢？开源社区较为成熟的微服务框架有dubbo、spring cloud。dubbo虽然在服务治理上做的比较完善，但是不支持跨语言。个人觉得，如果不考虑跨语言问题，选用dubbo。考虑跨语言，可以选用grpc、Thrift，但是grpc、Thrift没有服务发现和负载均衡机制，一般使用代理转发负载均衡控制策略。
在移动端app应用场景中，grpc以其优异的性能，因pb和http2的特性，为移动端用户节省流量、电量。对比传统的http1.1+json方式，建议可以先尝试小范围使用grpc，待系统稳定后，再扩大grpc使用范围。
gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特性。这些特性使得其在移动设备上表现更好，更省电和节省空间占用（相比当前传统的http1.1+json）。
gRPC是由Google主导开发的RPC框架，使用HTTP/2协议并用ProtoBuf作为序列化工具。其客户端提供Objective-C、Java接口，服务器侧则有Java、Golang、C++等接口，从而为移动端（iOS/Androi）到服务器端通讯提供了一种解决方案。 当然在当下的环境下，这种解决方案更热门的方式是RESTFull API接口。该方式需要自己去选择编码方式、服务器架构、自己搭建框架（JSON-RPC）。gRPC官方对REST的声音是：和REST一样遵循HTTP协议(明确的说是HTTP/2)，但是gRPC提供了全双工流和传统的REST不同的是gRPC使用了静态路径，从而提高性能用一些格式化的错误码代替了HTTP的状态码更好的标示错误。
至于是否要选择用gRPC。对于已经有一套方案的团队，可以参考下。如果是从头来做，可以考虑下gRPC提供的从客户端到服务器的整套解决方案，这样不用客户端去实现http的请求会话，JSON等的解析，服务器端也有现成的框架用。
grpc主要使用场景：
- 低延时、高可用的分布式系统；
- 移动端与云服务端的通讯；
- 使用protobuf，独立于语言的协议，支持多语言之间的通讯；
- 可以分层扩展，如：身份验证，负载均衡，日志记录，监控等。
在微服务场景中使用究竟是否要使用grpc呢？开源社区较为成熟的微服务框架有dubbo、spring cloud。dubbo虽然在服务治理上做的比较完善，但是不支持跨语言。个人觉得，如果不考虑跨语言问题，选用dubbo。考虑跨语言，可以选用grpc、Thrift，但是grpc、Thrift没有服务发现和负载均衡机制，一般使用代理转发负载均衡控制策略。
在移动端app应用场景中，grpc以其优异的性能，因pb和http2的特性，为移动端用户节省流量、电量。对比传统的http1.1+json方式，建议可以先尝试小范围使用grpc，待系统稳定后，再扩大grpc使用范围。
