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文件
需要go语言支持
服务发现和负载平衡
以上，grpc提供了数据传递的功能，但要把他微服务化还要支持服务发现和负载平衡，grpc并未实现这一块，因此要应用的话还需考虑此部分，grpc提供了设计思想，并在不同语言的gRPC代码API中已提供了命名解析和负载均衡接口供扩展（在python中并未找到有这部分）
方法一：运行在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的数据传递，其它方面大部份还要自行再架构
版权声明：本文来源CSDN，感谢博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/Candyabc/article/details/73850604
站方申明：本站部分内容来自社区用户分享，若涉及侵权，请联系站方删除。
