ALex_zry的博客

本框架经过实际项目验证，在某省级气象监测系统中稳定处理日均10亿+数据点。通过本文介绍的技术体系，开发者可以构建出高性能、高可靠的服务系统，适应从物联网到金融交易等各种严苛场景。

在构建 gRPC 服务时，正确处理和返回错误状态对于确保服务的健壮性和易用性至关重要。以下是如何在 gRPC 服务中实现自定义返回状态，并遵循错误处理的最佳实践以及如何进行测试的一些示例。自定义返回状态允许我们提供详细的错误信息，帮助客户端开发者快速定位问题，并采取适当的行动。例如，如果数据库查询未返回结果，我们可以返回一个NOT_FOUNDreturn ::grpc::Status(::grpc::StatusCode::NOT_FOUND, "在数据库中没有找到数据");

针对grpc 目前在C++ 开发过程中存在初学难懂，使用没有成体系说明的问题，这里对c++下的grpc 如何在代码层面使用进行简单说明。希望能够帮到更多人。

proto文件是一种预编译的规定文件，用来告诉gRPC 的服务如何生成对应的代码。具体的说，一个proto文件分为三部分：指定环境，制定消息结构，制定接口。

proto文件是Google Protocol Buffers的定义文件，用于定义数据结构和消息格式。syntax：指定proto文件使用的语法版本。package：指定生成的代码所在的包名。import：导入其他proto文件。option：设置特定的选项。message：定义消息类型。enum：定义枚举类型。service：定义服务接口。rpc：定义远程过程调用方法。oneof：定义互斥字段，只能选择其中一个字段。map：定义映射类型，类似于字典。

这里的是根据我自己的proto文件生成的。而12 是我们客户端调这个服务接口后返回的错误码是的输出，根据这里的错误是指远端调用的函数 找不到，在确认，两边的函数使用一致的情况下，我们使用同一份proto 文件。那么，到底为什么呢？

在写proto文件的时候，想要百度一下都有哪些内容，但是找到的都是那个经典的官方样例，互相之间抄来抄去，所以这里干脆把git上的相关源码，和实际使用经历结合总结下来，给一潭死水里注入一点活力吧。

清理，而是新建了一个目录进行处理，原本想法是如果编译出现什么错误，可以使用原本正确的文件进行替换，但是原本的静态库依赖的相关库文件，已经被修改了。导致了一系列的错误。在 gRPC 编译时，一开始使用了makefile，由于缺少经验，找了半天的静态库链接，最后觉得太麻烦，搞个动态库让它自己解决库依赖好了。如果你出现了如 alist 库找不到这样的问题，或者在构建 gRPC 时在百分之十时显示构建错误。解决方式，我是使用了快照恢复，如果你没有快照的话，建议手动清理相关库文件。但是在再次编译的时候，并没有使用。

因为库实在有点多，为避免因为静态库顺序的坑，直接使用了“–start-group”和“–end-group”忽略顺序关系。建议使用CMake或automake编译，以省去处理依赖的麻烦。事情源于我最近在使用gRPC库，在编译时下意识使用了makefile编译，然后，编译时报错找不到库文件。然后就开始了漫长的查找过程，期间发现使用的是静态库，尝试编译成动态库，发现反而让库文件彻底混乱损坏了。从这里看到缺失的都是它自己的一些库依赖。你可以尝试使用这个makefile。其中引用的上级cmake 为。

在双向流 RPC 模式中，客户端以消息流的形式发送请求到服务器端，服务器端也以消息流的形式进行响应。客户端流模式：在这种模式下，客户端可以连续发送多个消息到服务器，但服务器只返回一个响应。服务端流模式：在这种模式下，客户端发送一个请求到服务器，然后服务器可以连续返回多个响应。这种模式适用于服务器需要返回大量数据，但客户端只发送一个请求的场景，例如数据下载。在gRPC中，双向流模式的C++实现涉及到创建一个服务，该服务在.proto文件中定义，然后在服务器端和客户端实现。类型的参数，用于连接gRPC服务器。

在客户端流 RPC 模式中，客户端会发送多个请求给服务器端，而不再是单个请求。但是，服务器端不一定要等到从客户端接收到所有消息后才发送响应。基于这样的逻辑，我们可以在接收到流中的一条消息或几条消息之后就发送响应，也可以在读取完流中的所有消息之后再发送响应。这个程序的作用是连接到gRPC服务器，发送大量请求，并处理服务器的响应。这是一个使用gRPC库编写的简单客户端程序，它连接到gRPC服务器并发送大量请求。然后，你可以使用gRPC的protobuf插件生成C++代码。类，你可以使用这个类来调用RPC。

在一元 RPC 模式中，gRPC 服务器端和 gRPC 客户端在通信时始终只有一个请求和一个响应。在服务器端流 RPC 模式中，服务器端在接收到客户端的请求消息后，会发回一个响应的序列。在将所有的服务器端响应发送完毕之后，服务器端会以 trailer 元数据的形式将其状态发送给客户端，从而标记流的结束。在gRPC中，服务端主动向客户端发送数据通常是通过服务器端流式RPC实现的。在这种模式下，客户端发送一个请求到服务器，获取一个读取服务端流的响应。客户端向服务端发送请求后的回复，通常是通过返回一个。

如果你需要传递多个状态信息，你可以将它们编码为一个字符串，例如JSON格式的字符串，然后设置为状态细节。如果状态细节是一个编码的字符串，例如JSON格式的字符串，客户端可以解析这个字符串来获取状态信息。在这个例子中，服务器将多个状态信息编码为一个JSON格式的字符串，然后设置为状态细节。: 如果客户端已经发送了多个RPC调用，但是得到了足够的信息来完成任务，它可能会取消剩余的调用，以节省服务器资源和网络带宽。请注意，这只是一个例子，实际的状态细节和trailer元数据会根据你的应用需求和服务器的实现来定。

gRPC是一个现代的、高性能、开源的和语言无关的通用 RPC 框架，基于 HTTP2 协议设计，序列化使用PB(Protocol Buffer)，PB 是一种语言无关的高性能序列化框架，基于 HTTP2+PB 保证了的高性能。好吧我知道对于一个初学者来说这并没有意义，首先我们需要提炼关键，来回答以下几个问题，从而真正明白gRPC到底是什么？gRPC 和 RPC 的区别HTTP2 协议是什么？基于他的设计是什么意思？序列化PB(Protocol Buffer) 是什么？

这里是我调用了一个 名为DeviceData.proto的文件，你可以换成自己的proto文件。把生成路径设置为了当前目录下的一个子文件夹，这样方便管理。这是一个使用Bash脚本编写的简单示例，用于将Protocol Buffers（protobuf）文件编译为gRPC库。最近在研究序列化，每次的proto文件手敲生成代码指令都很麻烦，干脆自己写一个泛用脚本，这样以后使用时候就方便了。这里是我调用了一个 名为DeviceData.proto的文件，你可以换成自己的proto文件。下面是对脚本的逐行解析。