网站运营与管理实训报告,电商是干什么的,wordpress更改地址,wordpress搭建ctf文章目录 gRPC知识归档gRPC原理什么是gRPCgRPC的特性gRPC支持语言gRPC使用场景gRPC设计的动机和原则 数据封装和数据传输问题网络传输中的内容封装和数据体积问题JSONProtobuf#xff08;微服务之间的服务器调用#xff0c;一般采用二进制序列化#xff0c;比如protobuf微服务之间的服务器调用一般采用二进制序列化比如protobuf网络传输效率问题 gRPC的4种模式一元RPC模式服务端流RPC模式客户端流RPC双向流RPC模式 gRPC同步异步gRPC调用关系图proto文件Clientserver异步相关概念异步Client异步Server关系图 gRPC知识归档
gRPC原理
什么是gRPC
RPC是远程调用协议Remote Procedure Call Protocol)可以让我们像调用本地对象一样发起远程调用。RPC凭借强大的治理功能成为解决分布式系统问题的一大利器。 gRPC是一个现代的高性能的开源的和语言无关的通用RPC框架HTTP2协议设计序列化使用PBProtocol Buffer高性能序列化框架基于HTTP2PB保证高性能。 gRPC的Server和Client工作流程大致如下 tars兼容grpcbrpc也兼容grpcgrpc不兼容tars和brpc
gRPC的特性
gRPC基于服务的思想定义一个服务描述这个服务的方法和出入参数服务端有这个服务的具体实现客户端保有一个存根提供与服务端相同的服务。gRPC默认采用protobuf作为IDLInterface Description接口描述语言服务之间通信数据序列化和反序列化也是基于protocol buffer的因为protocol buffer的特殊性所以gRPC框架是跨语言的通信框架可就是说用jave开发的gRPC服务可以用GoLangC等语言调用。gRPC同时支持同步和异步调用同步RPC调用会一直阻塞到服务端处完成返回数据异步RPC是客户端调用服务端时不等待服务端处理完成返回结果而是服务端处理完成后主动回调客户端高速客户端处理完成。gRPC是基于HTTP2.0协议实现的http2提供了很多新特性并且在性能上相比http1提高了许多所以gRPC的性能是非常好的。gRPC并没有直接实现负载均衡和服务发现的功能但是已经提供了自己的设计思路。已经为命名解析和负载均衡提供了接口。基于http2的协议特性gRPC允许自定义4类服务方法 一元RPC服务端流式RPC客户端流式RPC双向流式RPC
gRPC支持语言
CJava包括安卓OCPythonRubyGoC#Node.js。
gRPC使用场景
低延迟高可扩展性的分布式系统开发与云服务器的客户端设计一个准确高效与语言无关的新协议分层设计实现扩展例如身份验证负载平衡日志记录和监控。
gRPC设计的动机和原则
自由开放所有人所有平台都可以使用开源跨平台跨语言协议可插拔不同的服务需要使用不同的消息类型和编码机制例如JSONXML和Thirft所以协议应允许可插拔机制还有负载均衡日志监控等都支持可插拔机制。阻塞和非阻塞支持客户端和服务器交换的消息序列的异步和同步处理。取消和超时一次RPC操作可能是持久并且昂贵的应该允许客户设置取消RPC通信和对这次通信加上超时时间。拒绝必须允许服务器通过在继续处理请求的同时拒绝新请求的到来并且优雅地关闭流处理存储系统依靠流和流控制来表达大型数据集其他服务如语音到文本或者股票行情依赖流来表达与时间相关的消息序列。流控制计算能力和网络容量在客户端和服务器之间通常是不平衡的。流控制允许更好的缓冲区管理以及过度活跃的对等提供DOS保护。元数据交换认证或跟踪常见的跨领域问题依赖于不属于服务器的接口数据交换。依赖他们的将这些特性演进到服务暴露API来提供能力。标准化状态骂客户端通常以有限的方式相应API调用返回的错误。应约束状态码名称空间以使这些错误处理决策更加清晰。如果需要更加丰富的特定领域的状态则可以使用元数据交换机制来提供状态。互通性报文协议必须遵循普通互联网服务基础框架
数据封装和数据传输问题
网络传输中的内容封装和数据体积问题
早期的RPCJSON的方式目前的RPC基本上都采用类似的Protobuf的二进制序列化方式。 其差别在于json的设计是给人看的protobuf的设计是给机器看的
JSON
优点在body中对JSON内容编码极易跨语言不需要约定特定的复杂编码格式和Stub文件。在版本兼容性上很好扩展容易。 缺点JSON难以表达复杂的参数类型如结构体等数据冗余和低压缩率使得传输特性能差。
Protobuf微服务之间的服务器调用一般采用二进制序列化比如protobuf
// XXXX.proto
// rpc服务的类 service关键字 Test服务类名
service Test {
// rpc 关键字rpc的接口rpc HowRpcDefine (Request) returns (Response) ; // 定义一个RPC方法
}
// message 类c class
message Request {
//类型 | 字段名字| 标号int64 user_id 1;string name 2;
}
message Response {repeated int64 ids 1; // repeated 表示数组Value info 2; // 可嵌套对象mapint, Value values 3; // 可输出map映射
}
message Value {bool is_man 1;int age 2;
}网络传输效率问题
grpc采用HTTP2.0相对于HTTP1.0在更快的传输和更低的成本上做了改进。有一下几个基本点
HTTP2未改变HTTP的语义如GET/POST等只是在传输上优化引入帧流的概念在TCP连接中可以区分多个request和response一个域名只会有一个TCP连接借助帧流可以实现多路复用降低资源消耗引入二进制编码降低header带来的空间占用
HTTP1.1核心问题在于在同一个TCP连接中没办法区分response是属于哪个请求一旦多个请求返回的文本内容混在一起则没法区分数据归属于哪个请求所以请求只能一个个串行排队发送。这直接导致了TCP资源的闲置。HTTP2为了解决这个问题提出了 流 的概念每一次请求对应一个流有一个唯一ID用来区分不同的请求。基于流的概念进一步提出了 帧 一个请求的数据会被分成多个帧方便进行数据分割传输每个帧都唯一属于某一个流ID将帧按照流ID进行分组即可分离出不同的请求。这样同一个TCP连接中就可以同时并发多个请求不同请求的帧数据可穿插在一起根据流ID分组即可。HTTP2.0基于这种二进制协议的乱序模式 (Duplexing)直接解决了HTTP1.1的核心痛点通过这种复用TCP连接的方式不用再同时建多个连接提升了TCP的利用效率。 gRPC的4种模式
一元RPC模式
一元RPC模式也被称为简单RPC模式当客户端调用服务端的远程方法时客户端发送请求到服务端并且获取一个响应与响应一起发送的还有状态细节以及trailer元数据。 服务端流RPC模式
在服务器端流RPC模式中服务器端在接受到客户端额请求消息后会发回一个响应的序列。这种多个响应所组成的序列被称为流。在将所有的服务器端响应发送完毕之后服务器端会以trailer元数据的形式将其状态发送给客户端从而标记流结束。 客户端流RPC
在客户端流 RPC 模式中客户端会发送多个请求给服务器端而不再是单个请求。服务器端则会发送一个响应给客户端。但是服务器端不一定要等到从客户端接收到所有消息后才发送响应。基于这样的逻辑我们可以在接收到流中的一条消息或几条消息之后就发送响应也可以在读取完流中的所有消息之后再发送响应。 双向流RPC模式
在双向流RPC模式中客户端以消息流的形式发请求给服务端服务端也以消息流的形式响应。调用必须有客户端发起但在此之后通信完全基于gRPC客户端和服务端的应用程序逻辑。 gRPC同步异步
gRPC调用关系图 上图列出了gRPC基础概念及其关系图。其中包括Service定义、RPC、API、Client、Stub、Channel、Server、Service实现、ServiceBuilder等。
接下来以官方提供的example/helloworld为例说明。
proto文件
syntax proto3;option java_multiple_files true;
option java_package io.grpc.examples.helloworld;
option java_outer_classname HelloWorldProto;
option objc_class_prefix HLW;package helloworld;// The greeting service definition.
service Greeter {// Sends a greetingrpc SayHello (HelloRequest) returns (HelloReply) {}
}// The request message containing the users name.
message HelloRequest {string name 1;
}// The response message containing the greetings
message HelloReply {string message 1;
}Client
class Greeterclient是Client是对Stub封装通过Stub可以真正调用RPC请求。
class GreeterClient {public:GreeterClient(std::shared_ptrChannel channel): stub_(Greeter::NewStub(channel)) {}// Assembles the clients payload, sends it and presents the response back// from the server.std::string SayHello(const std::string user) {// Data we are sending to the server.HelloRequest request;request.set_name(user);// Container for the data we expect from the server.HelloReply reply;// Context for the client. It could be used to convey extra information to// the server and/or tweak certain RPC behaviors.ClientContext context;// The actual RPC.Status status stub_-SayHello(context, request, reply);// Act upon its status.if (status.ok()) {return reply.message();} else {std::cout status.error_code() : status.error_message() std::endl;return RPC failed;}}private:std::unique_ptrGreeter::Stub stub_;
};
Channel提供一个特定gRPC server的主机和端口简历的连接。 Stub就是在Channel的基础上创建而成。
target_str localhost:50051;
auto channel grpc::CreateChannel(target_str, grpc::InsecureChannelCredentials());
GreeterClient greeter(channel);
std::string user(world);
std::string reply greeter.SayHello(user);server
Server端需要实现对应的RPC所有的RPC组成了Sevice
// Logic and data behind the servers behavior.
class GreeterServiceImpl final : public Greeter::Service {Status SayHello(ServerContext* context, const HelloRequest* request,HelloReply* reply) override {std::string prefix(Hello );reply-set_message(prefix request-name());return Status::OK;}
};Server的创建需要一个Builder添加上监听的地址和端口注册上该端口上绑定的服务最后构建出Server并且启动。
ServerBuilder builder;// Listen on the given address without any authentication mechanism.builder.AddListeningPort(server_address, grpc::InsecureServerCredentials());// Register service as the instance through which well communicate with// clients. In this case it corresponds to an *synchronous* service.builder.RegisterService(service);// Finally assemble the server.std::unique_ptrServer server(builder.BuildAndStart());RPC和API的区别RPCRemote Procedure Call是一次远程过程调用的整个动作而APIApplication Programming Interface是不同语言实现RPC中的具体接口。一个RPC可能对应多种API比如同步的异步的回调的。
异步相关概念
不管Client还是Server异步gRPC都是利用CompletionQueue API进行异步操作。基本流程 - 绑定一个CompletionQueue到一个RPC调用 - 利用唯一的void* Tag进行读写 - 调用CompletionQueue::Next()等待操作完成完成后通过唯一的Tag来判断对应什么请求/返回进行后续操作
异步Client
greeter_async_client.cc中是异步Client的Demo其中只有一次请求逻辑简单
创建CompletionQueue创建RPC即clientAsyncResponseReaderHelloReply这里有两种方式 stub_-PrepareAsyncSayHello() rpc-StartCall()stub_-AsyncSayHello() 调用rpc-Finish()设置请求消息reply和唯一的tag关联将请求发送出去。使用cq.Next()等待Completion Queue返回响应消息体通过tag关联对应请求。
异步Server
RequestSayHello()这个函数没有任何说明。只是说“we request that the system start processing SayHello requset.”也没有说和cq_-Next(tag, ok);的关系。我来说一下流程 - 创建一个CallData初始构造列表中将状态设置为CREATE - 构造函数中调用Process()成员函数调用service_-RequestSayHello()后状态变更为PROCESS: - 传入ServerContext ctx_ - 传入HelloRequest request_ - 传入ServerAsyncResponsewriterHelloReply responder_ - 传入ServerCompletionQueue* cq_ - 将对象自身的地址作为tag传入 - 该动作能将事件加入事件循环可以在CompletionQueue中等待 - 收到请求cp-Next()的阻塞结束并且返回得到tag即上次传入的CallData对象 - 调用tag对应CallData对象Process()此时状态Process - 创建新的CallData对象以接受新请求 - 处理消息并且设置reply_ - 将状态设置为FINISH - 调用responder_.Finish()将返回发送给客户端 - 该动作能将事件加入到循环可以将CompletionQueue中等待 - 发送完毕cp-Next()的阻塞结束并且返回得到tag。现实中如果发送有异常应当有其他处理。 - 调用tag对应的CallData对象proceed此时状态为FINISHdelete this清理自己一条消息处理完成。
关系图
