导读：GDP（Go Develop Platform）是百度内应用的 RPC 框架，具备欠缺的 RPC Client 和 RPC Server 能力，能够用来开发 API、Web 及后端服务等各种利用。GDP Streaming RPC 是基于 GDP RPC 能力开发的流式 RPC 框架，在实现性能根底上设计的一套面向流传输场景的传输框架，提供了流式传输利用场景的计划。百度内应用流式 RPC 计划首选为 baidu-rpc（开源我的项目为 brpc）streaming，GDP streaming 是 brpc streaming 的 Go 版本，为 Go 的开发者提供的流接口计划。
全文 4700 字，预计浏览工夫 12 分钟
一、streaming 介绍
1.1 解决的问题
在一些数据传输场景中，client / server 须要向对方发送 & 接管大量有序数据，这些数据十分大或者继续地在产生以至于无奈放在一个 RPC 的音讯体中。比方：分布式系统不同节点间传递的正本(replica) 或者语音数据。一个订单导出接口有 10 万条记录，如果应用传统 rpc，那么须要一次性接管到 10 万记录能力进行下一步的操作。
如果咱们应用 streaming rpc 那么咱们就能够接管一条记录解决一条记录，直到所以的数据传输结束。client / server 尽管能够通过屡次 RPC 把数据切分后传输过来，但存在如下问题：
- 如果并行发送，无奈保障接收端有序地收到数据，拼接数据的逻辑相当简单。
- 如果串行发送，每次传递都得期待一次网络 RTT + 解决数据的延时，特地是后者的延时可能是难以预估的。
RPC 框架常见的通信形式有 简略 RPC、服务端流式 RPC、客户端流式 RPC、双向流式 RPC。它们次要的特点是：
简略 RPC：传入一个申请，返回一个响应。
服务端流式 RPC：客户端传入一个申请，服务端能够继续的返回多个响应，一个典型的例子是客户端向服务端发送一个股票代码，服务端就把该股票的实时数据源源不断的返回给客户端。
客户端流式 RPC：客户端传入多个申请，服务端返回一个完结的响应，典型的例子是接管并解决日志文件。
双向流式 RPC 联合前两者 RPC 的特点，双端都能够传入多个申请，返回多个响应。
图 1. rpc 常见的四种通信模式
streaming 交互模型就是为了让大块数据以流水线的形式在 client / server 之间传递。实现的是双向流式 RPC。
1.2 设计指标
- 协定兼容 brpc
- 流状态可查问
- 接管音讯的程序和发送音讯的程序统一，不同流音讯并行
- 自定义序列化形式
- 一个 stocket 反对建设多个流
因为 brpc 的流式框架在公司内外曾经宽泛应用，GDP 在落地的实现首选是协定和性能对齐 brpc，指标是实现 brpc 的 Go 版本。一个传输工作能够不是由一个流来实现的，并行处理让效率更高。所有框架须要保障收发音讯的程序以及一致性和可并行个性。很多场景中，收发的数据可能是其余协定服务传入或者转发到其余协定的服务中，这样咱们思考实现自定义的序列化和反序列化形式，能够升高应用老本。
对于 IO 密集型的场景，tcp 的连贯开销是很大的，咱们常常会遇到一个 stocket 连贯把网口打满的状况。设计上一个 stocket 能够建设多个流，这个计划使得流的治理逻辑变得复杂，然而却能够做到节俭连贯的开销。也就是流的建设销毁的老本很小。
二、框架设计
2.1 基本概念
stream 流，让用户可能在 client/service 之间建设用户态连贯，称为 stream，stream 的传输数据以音讯为根本单位，输出端能够源源不断的往 Stream 中写入音讯，接收端会按输出端写入程序收到音讯，用户能够通过 stream client 来建设或者敞开一个流，流的客服端和服务端是一个对称构造。
message 音讯体，流传输数据以音讯为根本单位。
stream connector 流连贯，数据交互的实体，保护一个 stocket 连贯，一个流连贯上能同时存在多个 streamc。
event 触发事件，包含握手胜利 / 失败，数据处理 / 解决失败，解决超时，流敞开等。
handler 回调办法，不同的 event 对应执行的回调。
request 申请，蕴含流信息和音讯体，因为流传输是对称的，所有响应返回也是 reqeust。
2.2 框架性能
性能上来看，streaming rpc 能够划分为以下性能：
回调扩大
在服务端解决数据应用 handler 形式回调解决，每次申请时候解决 request，建设 server 时候注册 handler。也能够实现自定义的其余类型 handler，handler 注册后通过事件触发执行对应的回调 handler。
流组件
Streaming rpc 让用户可能在 client/service 之间建设用户态连贯，称为流。流的传输数据以音讯为根本单位。这一层是流解决逻辑的实体，包含事件的注册和散发，流状态查问，触发的回调，判断超时，协定的封装都在这层实现。流组件的公共局部是资源组件，负责流，连贯的治理，次要负责创立流时调配给流闲暇的流连贯，敞开时开释资源等工作。
流根底模块
流组件的公共局部是资源组件，负责流，连贯的治理，次要负责创立流时调配给流闲暇的流连贯，敞开时开释资源等工作。一个 tcp stocket 能够对应多个流，一个连贯一个读写通道，音讯体的边界个性能够让多个流共用一个 stocket，多个流并行处理数据，串行音讯传输。流治理次要负责创立流时抉择流闲暇的流连贯，敞开时开释资源，在呈现连贯读写超时或者谬误时候记录谬误连贯并敞开连贯上对应流的工作。
根底组件
提供了 rpc 的根底能力和依赖的组件，包含服务发现，负载平衡，网络拨号，提供了 stream 之下连贯的保护工作。
通用组件包含日志，配置，环境信息等根底性能，使 stream 层利用能够无感的与基础设施进行集成。因为流的架构是对称构造，所以流组件层和根底组件层的架构，是服务端和客户端共用的架构。
2.3 实现细节
stream 交互
一次残缺的交互包含：握手、通信、敞开 三个阶段。
stream client 先在本地创立一个 stream，再通过一次 RPC 与指定的 service 建设一个 stream，如果 service 在收到申请之后抉择承受这个 stream，那在 response 返回 client 后 stream 就会建设胜利。过程中的任何谬误都把 RPC 标记为失败，同时也意味着 stream 创立失败。
用 linux 下建设连贯的过程打比方，client 先创立 socket（创立 stream），再尝试与远端建设连贯（通过 RPC 建设 stream），远端 accept 后连贯就建设了（service 承受后创立胜利）。建设好后客户端和服务端别离生成一个 stream id。
建设好流后进入通信状态，应用 RPC（strm 协定）双工交互，stream 提供流式发送和接管音讯办法，框架负责创立流和 TCP stocket，服务端握手后生成一个 stream，stream id 与端 stream id 统一共用一个 stocket 连贯，建设好后执行 accept(context.Context) error 办法与客户端 Stream 交互。
在建设或者承受一个 stream 的时候，用户注册好的 handler 解决对端的写入数据，连贯敞开以及闲暇超时等。敞开操作由任意一段发动，通过一次 RPC 告知对端销毁 stream 并敞开本端资源，当 stocket 上没有流时候，同时敞开连贯。
如下图示意由 client 端建设并由 client 敞开的流状态图：
图 3. streaming 通信模型
2.4 解决的问题
如何保障一个 tcp 连贯上建设多个 stream
client 和 server 构造对称，都蕴含有 stream manager, stream connect，stream 构造，别离对应 stream 调配 (manager)，保留连贯(connect)，数据交互(stream) 的性能。
在建设流的过程，一条 tcp 连贯由 一个 stream connect 中保留，一个 stream connect 保留多个流，在 client/server 建设 stream 时，manager 会查看哪个 connect 处于未饱和状态，即能够寄存 stream，如果没有生成一个 connect，把 stream 寄存在此 connect 中并申请资源。
connect 保障各个 stream 并行收发数据，应用读通道异步发送，音讯体保障了数据边界，每次发送一个音讯体都是互斥的，读取 stocket 应用异步线程阻塞读取，通过 streamid 把数据调配到对应的 stream。
stream 解决异样
大多数状况下，流由 client 端传输实现后被动敞开，或者闲暇超时后服务端敞开，然而当呈现谬误或者网络异样的状况，须要保障双端的流的退出机制。当任意一端解决异样时，流会进入异样状态，进入敞开流程，发送敞开申请到对端，对端接管到申请后，也会进入敞开。
如下所示，服务端异样发动的流交互过程：
图 4. streaming 框架流异样的解决
stream 解决网络异样
比方当一个流发现读写失败后, 会进入敞开流程，同时告诉流的管理者，在与这个流共用一个连贯的所有流会收到管理者的告诉，全副敞开。因为流的对称构造，对端感知到网络异样会进入同样的流程。异样解决保障了谬误流不会承接后续的工作，保障异样连贯的退出。
图 5. streaming 网络异样的解决
当对 stream 读写失败后，本端的 stream 会感知到，这样双端 stream 的交互失败并且 stream 主动敞开，开释资源，同时告诉 stream manager，在这个 stream 共用一个 stocket 的 stream 通过 stream manager 告诉敞开，同样开释资源。
如何注册回调
框架在事件登程时执行对应的回调，服务端自定义回调办法，在框架中定义为 handler 接口，实现对应的接口即实现了回调，这样做的益处在于防止了多种回调办法注册导致的冗余代码以及扩展性的问题。
根底的 handler 为服务端解决 client request 的回调办法，定义相似：
根底 handler 定义
type Handler interface {Handle(context.Context, Stream, Request) error
}服务端的 server 构造提供注册办法注册 handler：
Handler 为根底回调办法，必须实现，其余类型的实现为可选实现，包含：握手响应、握手胜利、握手失败、超时回调、处理错误、敞开流等。
不同回调办法别离对应不同的 interface{}, 用户只须要实现对应的 interface{}，即实现了自定义的回调。
===
三、接入案例
咱们选取了一个语言接入模块，原架构应用 brpc 实现上下游的语音传输和解决，如图所示别离应用 Go 模块代替 client 和 server 端进行小流量验证，最终齐全替换，如图：
图 6. 应用 GDP streaming 对 brpc streaming 的替换
通过性能测试比照新模块新老模块的差别，其中，成功率、时延基本一致，实现了平滑降级。
GDP 的 Straming RPC 的性能指标上：
单实例小包（1k 以内）转发达到了 2.5w/s，同环境下达到了 brpc 的程度，能够满足高性能的需要，同吞吐率下 cpu 比照 brpc 增长 20% 左右。
四、总结
Go 有动静语言不具备的并发与性能，占用零碎线程少等劣势，比照 C++，Go 的语法简略，对私有协定的良好反对，能够让其兼顾性能的根底上能够反对业务高效率的开发，调试和运维。
GDP Streaming 提供了 brpc streaming 的 Go 版本，基于 S.O.L.I.D. 软件设计准则，使得框架具备很高的可扩展性，为百度内 Gopher 提供了流式利用的实际计划。
举荐浏览：
百度 APP 视频播放中的解码优化
百度爱番番实时 CDP 建设实际
当技术重构遇上 DDD，如何实现业务、技术双赢？
接口文档主动更改？百度程序员开发效率 MAX 的秘诀
技术揭秘！百度搜寻中台低代码的摸索与实际
百度智能云实战——动态文件 CDN 减速
化繁为简 – 百度智能小程序主数据架构实战总结
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边