brpc 概览从 RPC 核心概念到工业级框架的实践指南【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/gh_mirrors/brpc6/brpcbrpc 是一个使用 C 编写的工业级 RPC 框架常用于搜索、存储、机器学习、广告、推荐等高并发系统中brpc 意为 better RPC。本文以仓库中的 docs/cn/overview.md 为骨架系统讲解 RPC 要解决的根本问题、brpc 的适用范围与多协议能力并结合仓库源码与示例如 echo_c剖析其三个用户类单端口多协议高并发低锁竞争等核心设计帮助读者快速建立对 brpc 的完整认知并能在实际项目中正确选型与上手。什么是 RPC互联网上的机器大都通过 TCP/IP 协议相互访问但 TCP/IP 只是向远端发送了一段二进制数据。要真正搭建起服务还必须抽象并解决一系列问题数据格式数据以什么格式传输不同机器、不同网络之间可能存在不同的字节序直接传输内存数据显然不合适随着业务变化数据字段往往要增加或删减如何兼容前后不同版本的格式连接复用一个 TCP 连接可以被多个请求复用以减少开销吗多个请求可以同时发往一个 TCP 连接吗机器管理如何管理和访问很多机器故障处理连接断开时应该做什么万一 server 不发送回复怎么办RPCRemote Procedure Call远程过程调用正是为了解决这些问题而生的抽象它把网络交互类比为client 访问 server 上的函数。client 向 server 发送 request 后开始等待直到 server 收到、处理、回复 client 后client 才再度恢复并根据 response 做出反应。RPC 如何解决上述问题数据序列化protobuf 在这方面做得很不错。用户填写protobuf::Message类型的 requestRPC 结束后从同为protobuf::Message类型的 response 中取出结果。protobuf 具备较好的前后兼容性方便业务调整字段。HTTP 生态则广泛使用 json 作为序列化方法。连接方式用户无需关心连接如何建立但可以选择不同的连接方式短连接、连接池、单连接。服务发现与负载均衡大量机器一般通过命名服务被发现可基于 DNS、ZooKeeper、etcd 等实现。在百度内部使用 BNSBaidu Naming Servicebrpc 也提供list://和file://两种命名服务。用户可以指定负载均衡算法让 RPC 每次选出一台机器发送请求包括 round-robin、randomized、consistent-hashingmurmurhash3 或 md5以及 locality-aware。故障恢复连接断开时可以重试如果 server 没有在给定时间内回复client 会返回超时错误。哪里可以使用 RPC几乎所有的网络交互都可以使用 RPC。当然RPC 不是万能的抽象否则我们也不需要 TCP/IP 这一层了但在绝大部分网络交互场景中RPC 既能解决问题又能隔离更底层的网络问题。对 RPC 常见的质疑brpc 也给出了务实回应我的数据非常大用 protobuf 序列化太慢了首先这可能是个伪命题你得用 profiler 证明慢了才是真的慢其次很多协议支持携带二进制数据以绕过序列化。我传输的是流数据RPC 表达不了事实上 brpc 中很多协议支持传递流式数据包括 http 中的 ProgressiveReader、h2 的 streams、streaming rpc以及专门的流式协议 RTMP。我的场景不需要回复简单推理可知这种场景中请求可丢可不丢、可处理也可不处理因为 client 总是无法感知你真的确认这是 OK 的吗即使场景真的不需要仍然建议用最小的结构体回复——这不大会是瓶颈而且可能是追查复杂 bug 时很有价值的线索。什么是 brpcbrpc 是百度内部最常使用的工业级 RPC 框架有 1,000,000 个实例不包含 client和上千种服务在百度内部称为 baidu-rpc目前只开源 C 版本该数据出自 docs/cn/overview.md为百度内部场景事实。单端口支持多协议brpc 可以搭建在一个端口上支持多协议的服务或访问各种服务HTTP 系restful http/https、h2、gRPC。使用 brpc 的 http 实现比 libcurl 方便得多可让其他语言通过 HTTP/h2json 访问基于 protobuf 的协议。缓存/存储协议redis 和 memcached 客户端线程安全比官方 client 更方便。流媒体协议rtmp、flv、hls可用于搭建流媒体服务。跨语言协议支持 thrift线程安全比官方 client 更方便。各类内部协议各种百度内使用的协议包括 baidu_std、streaming_rpc、hulu_pbrpc、sofa_pbrpc、nova_pbrpc、public_pbrpc、ubrpc以及使用 nshead 的各种协议。分布式一致性基于工业级 RAFT 算法实现搭建高可用分布式系统已在 braft 开源。Server 与 Client 的多种调用模式Server 可以同步或异步处理请求。Client 支持同步、异步、半同步或使用组合 channels 简化复杂的分库或并发访问。调试、性能剖析与扩展通过 http 界面调试服务使用 cpu、heap、contention profilers。获得更好的延时和吞吐。把你组织中使用的协议快速加入 brpc或定制各类组件包括命名服务dns、zk、etcd、负载均衡rr、random、consistent hashing。brpc 的优势更友好的接口只有三个主要的用户类brpc 只暴露三个主要用户类Server、Channel、Controller分别对应 server 端、client 端和参数集合。你无需推敲如何初始化 XXXManager如何组合各种组件XXXController 的 XXXContext 间的关系是什么之类的问题。从源码结构可以印证这一点class Serversrc/brpc/server.h承担服务端的注册与启动提供了多个Start()重载例如 Start(const char* ip_port_str, ...)、Start(const butil::EndPoint, ...)、Start(int port, ...) 等。class Channel : public ChannelBasesrc/brpc/channel.h代表到 Server 的一条通信线路且是线程安全的可被程序内所有线程共享。Controller继承自google::protobuf::RpcControllersrc/brpc/controller.h是 Server 和 Channel 共用的参数集合其方法明确分成了三段Client-side methodscontroller.h、Server-side methodscontroller.h和 Both-side methodscontroller.h。要做的事情很简单建服务包含brpc/server.h并参考注释或 echo 示例的 server.cppserver.AddService(...)注册服务server.Start(...)启动监听server.RunUntilAskedToQuit()等待退出。访问服务包含brpc/channel.h并参考注释或 echo 示例的 client.cppchannel.Init(...)初始化再构造 stub 发起调用。调整参数看看brpc/controller.h注意这个类是 Server 和 Channel 共用的分成了三段分别标记为 Client-side、Server-side 和 Both-side methods。brpc 还尝试让事情更加简单。以命名服务为例在其他 RPC 实现中你也许需要复制一长段晦涩的代码才可使用而在 brpc 中访问 BNS 可以这么写bns://node-nameDNS 是http://domain-name本地文件列表是file:///home/work/server.list——不用解释你也能明白这些代表什么。快速上手echo 示例的 server 与 client仓库中的 example/echo_c 是理解这三个类的最短路径。server 侧server.cpp展示了用 gflags 定义port、listen_addr、idle_timeout_s等启动参数实现EchoService的Echo方法通过brpc::ClosureGuard以 RAII 风格保证done-Run()被调用通过cntl-request_attachment()/cntl-response_attachment()演示绕过序列化直接透传二进制附件的用法server.AddService(echo_service_impl, brpc::SERVER_DOESNT_OWN_SERVICE)注册服务server.Start(point, options)启动。client 侧client.cpp展示了通过brpc::ChannelOptions设置protocol、connection_type、timeout_ms、max_retry等参数channel.Init(server, load_balancer, options)初始化 channel构造EchoService_Stub后同步调用stub.Echo(cntl, request, response, NULL)并通过cntl.Failed()、cntl.ErrorText()、cntl.latency_us()判断结果与统计时延。编译运行方式可参考 docs/cn/getting_started.md使用sh config_brpc.shmake或cmake -B build cmake --build build构建后进入example/echo_c执行./echo_server与./echo_client。使服务更加可靠brpc 在百度内被广泛使用map-reduce 服务和 table 存储、高性能计算和模型训练、各种索引和排序服务……它是一个经历过考验的实现。brpc 特别重视开发和维护效率你可以通过浏览器或 curl 查看 server 内部状态分析在线服务的 cpu 热点、内存分配 和锁竞争通过 bvar 统计各种指标并通过 /vars 查看。更好的延时和吞吐虽然大部分 RPC 实现都声称高性能但数字仅仅是数字要在广泛的场景中做到高性能仍是困难的。为了统一百度内的通信架构brpc 在性能方面比其他 RPC 走得更深。原文档从四个维度阐述了其设计对不同客户端请求的读取和解析完全并发。用户不用区分IO 线程和处理线程。其他实现往往会区分二者并把 fd对应一个客户端散列到 IO 线程中去当一个 IO 线程在读取其中的 fd 时同一个线程中的 fd 都无法得到处理当一些解析变慢时比如特别大的 protobuf message同一个 IO 线程中的其他 fd 都遭殃了。虽然不同 IO 线程间的 fd 是并发的但 IO 线程数量通常有限一个 fd 能影响到的其他 fd仍有相当大的比例10 个 IO 线程即 10%而工业级在线检索要求 99.99% 以上的可用性这个问题在 fd 没有均匀分布或多租户multi-tenancy环境中会更加恶化。在 brpc 中对不同 fd 的读取是完全并发的对同一个 fd 中不同消息的解析也是并发的——解析一个特别大的 protobuf message 不会影响同一个客户端的其他消息更不用提其他客户端的消息了。更多细节见 docs/cn/io.md#收消息。对同一 fd 和不同 fd 的写出高度并发。当多个线程都要对一个 fd 写出时常见于单连接第一个线程会直接在原线程写出其他线程会以 wait-free 的方式托付自己的写请求。多个线程在高度竞争下仍可以在 1 秒内对同一个 fd 写入 500 万个 16 字节的消息。更多细节见 docs/cn/io.md#发消息。尽量少的锁。高 QPS 服务可以充分利用一台机器的 CPU。比如为处理请求创建 bthread、设置超时、根据回复找到 RPC 上下文、记录性能计数器 都是高度并发的。即使服务的 QPS 超过 50 万用户也很少在 contention profiler 中看到框架造成的锁竞争。服务器线程数自动调节。传统的服务器需要根据下游延时调整自身的线程数否则吞吐可能会受影响。在 brpc 中每个请求均运行在新建立的 bthread 中请求结束后线程就结束了所以天然会根据负载自动调节线程数。brpc 和其他实现的性能对比见 docs/cn/benchmark.md。小结本文从 RPC 要解决的根本问题出发完整介绍了 brpc 的定位、适用范围、多协议能力、三个核心用户类与性能设计。整体上brpc 的设计可以概括为三点接口极简Server/Channel/Controller 三个类覆盖全部使用场景、能力内聚单端口多协议、服务发现、负载均衡、内置调试与 profiling 开箱即用、并发深入读写全并发、低锁竞争、bthread 自动调节线程数。对希望在一个端口上承接多协议、或需要极致并发性能的 C 服务而言docs/cn/overview.md 及其链接的 docs/cn/client.md、docs/cn/server.md、docs/cn/io.md、docs/cn/bthread.md 等文档是继续深入的最佳入口example/echo_c 则是可以立刻运行的实战起点。【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/gh_mirrors/brpc6/brpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 brpc 概览：从 RPC 核心概念到工业级框架的实践指南
brpc 概览从 RPC 核心概念到工业级框架的实践指南【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/gh_mirrors/brpc6/brpcbrpc 是一个使用 C 编写的工业级 RPC 框架常用于搜索、存储、机器学习、广告、推荐等高并发系统中brpc 意为 better RPC。本文以仓库中的 docs/cn/overview.md 为骨架系统讲解 RPC 要解决的根本问题、brpc 的适用范围与多协议能力并结合仓库源码与示例如 echo_c剖析其三个用户类单端口多协议高并发低锁竞争等核心设计帮助读者快速建立对 brpc 的完整认知并能在实际项目中正确选型与上手。什么是 RPC互联网上的机器大都通过 TCP/IP 协议相互访问但 TCP/IP 只是向远端发送了一段二进制数据。要真正搭建起服务还必须抽象并解决一系列问题数据格式数据以什么格式传输不同机器、不同网络之间可能存在不同的字节序直接传输内存数据显然不合适随着业务变化数据字段往往要增加或删减如何兼容前后不同版本的格式连接复用一个 TCP 连接可以被多个请求复用以减少开销吗多个请求可以同时发往一个 TCP 连接吗机器管理如何管理和访问很多机器故障处理连接断开时应该做什么万一 server 不发送回复怎么办RPCRemote Procedure Call远程过程调用正是为了解决这些问题而生的抽象它把网络交互类比为client 访问 server 上的函数。client 向 server 发送 request 后开始等待直到 server 收到、处理、回复 client 后client 才再度恢复并根据 response 做出反应。RPC 如何解决上述问题数据序列化protobuf 在这方面做得很不错。用户填写protobuf::Message类型的 requestRPC 结束后从同为protobuf::Message类型的 response 中取出结果。protobuf 具备较好的前后兼容性方便业务调整字段。HTTP 生态则广泛使用 json 作为序列化方法。连接方式用户无需关心连接如何建立但可以选择不同的连接方式短连接、连接池、单连接。服务发现与负载均衡大量机器一般通过命名服务被发现可基于 DNS、ZooKeeper、etcd 等实现。在百度内部使用 BNSBaidu Naming Servicebrpc 也提供list://和file://两种命名服务。用户可以指定负载均衡算法让 RPC 每次选出一台机器发送请求包括 round-robin、randomized、consistent-hashingmurmurhash3 或 md5以及 locality-aware。故障恢复连接断开时可以重试如果 server 没有在给定时间内回复client 会返回超时错误。哪里可以使用 RPC几乎所有的网络交互都可以使用 RPC。当然RPC 不是万能的抽象否则我们也不需要 TCP/IP 这一层了但在绝大部分网络交互场景中RPC 既能解决问题又能隔离更底层的网络问题。对 RPC 常见的质疑brpc 也给出了务实回应我的数据非常大用 protobuf 序列化太慢了首先这可能是个伪命题你得用 profiler 证明慢了才是真的慢其次很多协议支持携带二进制数据以绕过序列化。我传输的是流数据RPC 表达不了事实上 brpc 中很多协议支持传递流式数据包括 http 中的 ProgressiveReader、h2 的 streams、streaming rpc以及专门的流式协议 RTMP。我的场景不需要回复简单推理可知这种场景中请求可丢可不丢、可处理也可不处理因为 client 总是无法感知你真的确认这是 OK 的吗即使场景真的不需要仍然建议用最小的结构体回复——这不大会是瓶颈而且可能是追查复杂 bug 时很有价值的线索。什么是 brpcbrpc 是百度内部最常使用的工业级 RPC 框架有 1,000,000 个实例不包含 client和上千种服务在百度内部称为 baidu-rpc目前只开源 C 版本该数据出自 docs/cn/overview.md为百度内部场景事实。单端口支持多协议brpc 可以搭建在一个端口上支持多协议的服务或访问各种服务HTTP 系restful http/https、h2、gRPC。使用 brpc 的 http 实现比 libcurl 方便得多可让其他语言通过 HTTP/h2json 访问基于 protobuf 的协议。缓存/存储协议redis 和 memcached 客户端线程安全比官方 client 更方便。流媒体协议rtmp、flv、hls可用于搭建流媒体服务。跨语言协议支持 thrift线程安全比官方 client 更方便。各类内部协议各种百度内使用的协议包括 baidu_std、streaming_rpc、hulu_pbrpc、sofa_pbrpc、nova_pbrpc、public_pbrpc、ubrpc以及使用 nshead 的各种协议。分布式一致性基于工业级 RAFT 算法实现搭建高可用分布式系统已在 braft 开源。Server 与 Client 的多种调用模式Server 可以同步或异步处理请求。Client 支持同步、异步、半同步或使用组合 channels 简化复杂的分库或并发访问。调试、性能剖析与扩展通过 http 界面调试服务使用 cpu、heap、contention profilers。获得更好的延时和吞吐。把你组织中使用的协议快速加入 brpc或定制各类组件包括命名服务dns、zk、etcd、负载均衡rr、random、consistent hashing。brpc 的优势更友好的接口只有三个主要的用户类brpc 只暴露三个主要用户类Server、Channel、Controller分别对应 server 端、client 端和参数集合。你无需推敲如何初始化 XXXManager如何组合各种组件XXXController 的 XXXContext 间的关系是什么之类的问题。从源码结构可以印证这一点class Serversrc/brpc/server.h承担服务端的注册与启动提供了多个Start()重载例如 Start(const char* ip_port_str, ...)、Start(const butil::EndPoint, ...)、Start(int port, ...) 等。class Channel : public ChannelBasesrc/brpc/channel.h代表到 Server 的一条通信线路且是线程安全的可被程序内所有线程共享。Controller继承自google::protobuf::RpcControllersrc/brpc/controller.h是 Server 和 Channel 共用的参数集合其方法明确分成了三段Client-side methodscontroller.h、Server-side methodscontroller.h和 Both-side methodscontroller.h。要做的事情很简单建服务包含brpc/server.h并参考注释或 echo 示例的 server.cppserver.AddService(...)注册服务server.Start(...)启动监听server.RunUntilAskedToQuit()等待退出。访问服务包含brpc/channel.h并参考注释或 echo 示例的 client.cppchannel.Init(...)初始化再构造 stub 发起调用。调整参数看看brpc/controller.h注意这个类是 Server 和 Channel 共用的分成了三段分别标记为 Client-side、Server-side 和 Both-side methods。brpc 还尝试让事情更加简单。以命名服务为例在其他 RPC 实现中你也许需要复制一长段晦涩的代码才可使用而在 brpc 中访问 BNS 可以这么写bns://node-nameDNS 是http://domain-name本地文件列表是file:///home/work/server.list——不用解释你也能明白这些代表什么。快速上手echo 示例的 server 与 client仓库中的 example/echo_c 是理解这三个类的最短路径。server 侧server.cpp展示了用 gflags 定义port、listen_addr、idle_timeout_s等启动参数实现EchoService的Echo方法通过brpc::ClosureGuard以 RAII 风格保证done-Run()被调用通过cntl-request_attachment()/cntl-response_attachment()演示绕过序列化直接透传二进制附件的用法server.AddService(echo_service_impl, brpc::SERVER_DOESNT_OWN_SERVICE)注册服务server.Start(point, options)启动。client 侧client.cpp展示了通过brpc::ChannelOptions设置protocol、connection_type、timeout_ms、max_retry等参数channel.Init(server, load_balancer, options)初始化 channel构造EchoService_Stub后同步调用stub.Echo(cntl, request, response, NULL)并通过cntl.Failed()、cntl.ErrorText()、cntl.latency_us()判断结果与统计时延。编译运行方式可参考 docs/cn/getting_started.md使用sh config_brpc.shmake或cmake -B build cmake --build build构建后进入example/echo_c执行./echo_server与./echo_client。使服务更加可靠brpc 在百度内被广泛使用map-reduce 服务和 table 存储、高性能计算和模型训练、各种索引和排序服务……它是一个经历过考验的实现。brpc 特别重视开发和维护效率你可以通过浏览器或 curl 查看 server 内部状态分析在线服务的 cpu 热点、内存分配 和锁竞争通过 bvar 统计各种指标并通过 /vars 查看。更好的延时和吞吐虽然大部分 RPC 实现都声称高性能但数字仅仅是数字要在广泛的场景中做到高性能仍是困难的。为了统一百度内的通信架构brpc 在性能方面比其他 RPC 走得更深。原文档从四个维度阐述了其设计对不同客户端请求的读取和解析完全并发。用户不用区分IO 线程和处理线程。其他实现往往会区分二者并把 fd对应一个客户端散列到 IO 线程中去当一个 IO 线程在读取其中的 fd 时同一个线程中的 fd 都无法得到处理当一些解析变慢时比如特别大的 protobuf message同一个 IO 线程中的其他 fd 都遭殃了。虽然不同 IO 线程间的 fd 是并发的但 IO 线程数量通常有限一个 fd 能影响到的其他 fd仍有相当大的比例10 个 IO 线程即 10%而工业级在线检索要求 99.99% 以上的可用性这个问题在 fd 没有均匀分布或多租户multi-tenancy环境中会更加恶化。在 brpc 中对不同 fd 的读取是完全并发的对同一个 fd 中不同消息的解析也是并发的——解析一个特别大的 protobuf message 不会影响同一个客户端的其他消息更不用提其他客户端的消息了。更多细节见 docs/cn/io.md#收消息。对同一 fd 和不同 fd 的写出高度并发。当多个线程都要对一个 fd 写出时常见于单连接第一个线程会直接在原线程写出其他线程会以 wait-free 的方式托付自己的写请求。多个线程在高度竞争下仍可以在 1 秒内对同一个 fd 写入 500 万个 16 字节的消息。更多细节见 docs/cn/io.md#发消息。尽量少的锁。高 QPS 服务可以充分利用一台机器的 CPU。比如为处理请求创建 bthread、设置超时、根据回复找到 RPC 上下文、记录性能计数器 都是高度并发的。即使服务的 QPS 超过 50 万用户也很少在 contention profiler 中看到框架造成的锁竞争。服务器线程数自动调节。传统的服务器需要根据下游延时调整自身的线程数否则吞吐可能会受影响。在 brpc 中每个请求均运行在新建立的 bthread 中请求结束后线程就结束了所以天然会根据负载自动调节线程数。brpc 和其他实现的性能对比见 docs/cn/benchmark.md。小结本文从 RPC 要解决的根本问题出发完整介绍了 brpc 的定位、适用范围、多协议能力、三个核心用户类与性能设计。整体上brpc 的设计可以概括为三点接口极简Server/Channel/Controller 三个类覆盖全部使用场景、能力内聚单端口多协议、服务发现、负载均衡、内置调试与 profiling 开箱即用、并发深入读写全并发、低锁竞争、bthread 自动调节线程数。对希望在一个端口上承接多协议、或需要极致并发性能的 C 服务而言docs/cn/overview.md 及其链接的 docs/cn/client.md、docs/cn/server.md、docs/cn/io.md、docs/cn/bthread.md 等文档是继续深入的最佳入口example/echo_c 则是可以立刻运行的实战起点。【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/gh_mirrors/brpc6/brpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考