1. 前言
有些场景下,比如交易 K 线,我们需要前端对后端进行轮询来不断获取或者更新资源状态。轮询的问题毫无以为是一种笨重的方式,因为每一次 http 请求除了本身的资源信息传输外还有三次握手以及四次挥手。替代轮询的一种方案是复用一个 http 连接,更准确的复用同一个 tcp 连接。这种方式可以是 http 长连接,也可以是 websocket。
说到和动态库查找路径相关的问题,总体上可以分为两类:
error while loading shared libraries: libxxx.so.y: cannot open shared object file: No such file or directory
。shadowsocks是我们常用的代理工具,它使用socks5协议,而终端很多工具目前只支持http和https等协议,对socks5协议支持不够好,所以我们为终端设置shadowsocks的思路就是将socks协议转换成http协议,然后为终端设置即可。
最新的 ShadowsocksX-NG 已经支持终端代理, 我们可以如下图复制得出:
1 | export http_proxy=http://127.0.0.1:1087;export https_proxy=http://127.0.0.1:1087; |
Protocol Buffer是Google的语言中立的,平台中立的,可扩展机制的,用于序列化结构化数据 - 对比XML,但更小,更快,更简单。您可以定义数据的结构化,然后可以使用特殊生成的源代码轻松地在各种数据流中使用各种语言编写和读取结构化数据。
gRPC 允许你定义四类服务方法:
简单RPC(Simple RPC)
即客户端发送一个请求给服务端,从服务端获取一个应答,就像一次普通的函数调用。
1 | rpc SayHello(HelloRequest) returns (HelloResponse){ |
服务端流式RPC(Server-side streaming RPC):
一个请求对象,服务端可以传回多个结果对象。即客户端发送一个请求给服务端,可获取一个数据流用来读取一系列消息。客户端从返回的数据流里一直读取直到没有更多消息为止。
1 | rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){ |
客户端流式RPC(Client-side streaming RPC)
客户端传入多个请求对象,服务端返回一个响应结果。即客户端用提供的一个数据流写入并发送一系列消息给服务端。一旦客户端完成消息写入,就等待服务端读取这些消息并返回应答。
1 | rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) { |
双向流式RPC(Bidirectional streaming RPC)
结合客户端流式rpc和服务端流式rpc,可以传入多个对象,返回多个响应对象。即两边都可以分别通过一个读写数据流来发送一系列消息。这两个数据流操作是相互独立的,所以客户端和服务端能按其希望的任意顺序读写。
1 | rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){ |