| 编辑推荐: |
| 本文来自于csdn,介绍了一个高性能、开源和通用的
RPC 框架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 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。
gRPC 基于如下思想：定义一个服务， 指定其可以被远程调用的方法及其参数和返回类型
gRPC 允许你定义四类服务方法：
单项 RPC，即客户端发送一个请求给服务端，从服务端获取一个应答，就像一次普通的函数调用。
| rpc SayHello(HelloRequest)
returns (HelloResponse){} |
服务端流式 RPC，即客户端发送一个请求给服务端，可获取一个数据流用来读取一系列消息。客户端从返回的数据流里一直读取直到没有更多消息为止。
| rpc LotsOfReplies(HelloRequest)
returns (stream HelloResponse){} |
客户端流式 RPC，即客户端用提供的一个数据流写入并发送一系列消息给服务端。一旦客户端完成消息写入，就等待服务端读取这些消息并返回应答。
| rpc LotsOfGreetings(stream
HelloRequest) returns (HelloResponse) {} |
双向流式 RPC，即两边都可以分别通过一个读写数据流来发送一系列消息。这两个数据流操作是相互独立的，所以客户端和服务端能按其希望的任意顺序读写，例如：服务端可以在写应答前等待所有的客户端消息，或者它可以先读一个消息再写一个消息，或者是读写相结合的其他方式。每个数据流里消息的顺序会被保持。
| rpc BidiHello(stream
HelloRequest) returns (stream HelloResponse){} |
兼容restapi方法,如果需要兼容restapi可使用grpc-gateway，可生成swagger文件
https://github.com/grpc-ecosystem/grpc-gateway
需要go语言支持
服务发现和负载平衡
以上，grpc提供了数据传递的功能，但要把他微服务化还要支持服务发现和负载平衡，grpc并未实现这一块，因此要应用的话还需考虑此部分，grpc提供了设计思想，并在不同语言的gRPC代码API中已提供了命名解析和负载均衡接口供扩展（在python中并未找到有这部分）
http://www.tuicool.com/articles/7NzYzuZ中介绍设计思想
方法一：运行在docker下，由docker来负责服务发现和负载平衡，公司目前似乎短时间无法做到
方法二：自行实现,服务发现在用etcd,zookeeper等,推荐使用etcd.
ETCD vs ZK
选取ZK作为典型代表与ETCD进行比较，而不考虑[Consul]项目作为比较对象，原因为Consul的可靠性和稳定性还需要时间来验证（项目发起方自身服务并未使用Consul,
自己都不用)。
一致性协议： ETCD使用[Raft]协议， ZK使用ZAB（类PAXOS协议），前者容易理解，方便工程实现；
运维方面：ETCD方便运维，ZK难以运维；
项目活跃度：ETCD社区与开发活跃，ZK已经快死了；
API：ETCD提供HTTP+JSON, gRPC接口，跨平台跨语言，ZK需要使用其客户端；
访问安全方面：ETCD支持HTTPS访问，ZK在这方面缺失；
综上，grpc对go语言支持度更好，使用ptyhon，grpc只做到rpc的数据传递，其它方面大部份还要自行再架构 |
