编辑推荐:
本文来自于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的数据传递,其它方面大部份还要自行再架构