云平台代理服务

用例4：云平台代理服务

背景

云平台部把使用 ubrpc 的模块改造为使用 brpc。由于使用了 mcpack2pb 的转换功能，这个模块既能被老的 ubrpc client 访问，也可以通过 protobuf 类的协议访问（baidu_std，sofa_pbrpc 等）。

原有使用 43 台机器（对 ubrpc 也有富余），brpc 使用 3 台机器即可（此时访问 redis 的 io 达到瓶颈）。当前流量 4w qps，支持流量增长，考虑跨机房冗余，避免 redis 和 vip 瓶颈，brpc 实际使用 8 台机器提供服务。

brpc 改造后的 connecter 收益明显，可以用较少的机器提供更优质的服务。收益分 3 个方面：

相同配置的机器 qps 和 latency 的比较

通过逐渐缩容，不断增加 connecter 的压力，获得单机 qps 和 latency 的对应数据如下：

机器配置：cpu: 24 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz || mem: 64G

混布情况：同机部署了逻辑层2.0/3.0和C逻辑层，均有流量

图中可以看到随着压力的增大：

• brpc 的延时，增加微乎其微，提供了较为一致的延时体验
• ubrpc 的延时，快速增大，到了 6000~8000qps 的时候，出现 queue full，服务不可用。

不同配置机器 qps 和延时的比较

qps 固定为 6500，观察延时。

由此可见：

• ubrpc 在不同配置下性能表现差异大，在配置较低的机器下表现较差。
• brpc 表现得比 ubrpc 好，在较低配置的机器上也能有好的表现，因机器不同带来的差异不大。

相同配置机器 idle 分布的比较

机器配置：cpu： 24 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz || mem：64G

在线上缩容、不断增大压力过程中：

• ubrpc cpu idle 分布在 35%~60%，在 55% 最集中，最低 30%；
• brpc cpu idle 分布在 60%~85%，在 75% 最集中，最低 50%；brpc 比 ubrpc 对 cpu 的消耗低。

---

最后修改于 2022 年 1 月 30 日：bRPC 网站 1.0 (92b925e8f)