这是一个创建于 852 天前的主题，其中的信息可能已经有所发展或是发生改变。
我曾经有关注过火币还是币安来着，他们的 API 接口，经历过改革，想和大家讨论一下。
首先可确定的是，这个网站的接口请求量非常巨大，这是毋庸置疑的。
最开始我看到他们的接口和我们平时的也差不多，后来我发现他们把 API 接口改了，如 {"c":0, "m":"xxx", "r":{"q":"xxx"}}，基本上每个字段都是一个字母，不够用了就两个字母。
我个人琢磨猜测了一下，他们这么干的目的，应该是想减少传输量（为什么我不觉得他们是想迷惑别人呢，因为他们有一些公开的 API ，也是这么设计的，文档也是开放出来的），也算是提高并发能力的一个技巧了。当然这么干坏处就是对接使用的人挺麻烦的，不看文档压根不知道什么意思，好处就是传输量实实在在的减少了，虽然一个接口减少的流量看似不多，但是以他们网站的规模来看，减少的量就很可观了。
大家觉得，如果是为了减少传输量这么干，是值得还是不值得，就是收益大？还是得不偿失？
 |
1
vitovan 2022-07-23 11:41:39 +08:00
如果可以提供组件，让客户端开发时可以直接调用，生成压缩后的请求包，应该还好。
不过这个问题主要看计划资源投入和话语权在谁手里。 我纯粹是瞎说两句。 |
 |
2
westoy 2022-07-23 11:42:46 +08:00  1
服务端替换 key 变量也是要成本的啊， 我真不信他们开发是手撸写死这种变量。 数据传输也是最小包和对齐的， 省几个字节未必有实际用途的
这种接口命名更大的意义是避免语义化让你直接猜出用途吧....... |
 |
3
wanguorui123 2022-07-23 11:46:10 +08:00
开启 GZIP
|
 |
4
manecocomph 2022-07-23 11:46:42 +08:00
程序现阶段还是给人看的. LB 后边能加几台机器能解决的问题, 人脑和电脑都做个 mapping 是不值得的. 从节省资源或总体性能的角度看上去收益不大.
|
 |
5
brader OP @westoy 你别说，他们还就可能是写死的，我就觉得，这么干得到的好处和付出的成本，值不值得，其实说到成本，他们也算是财大气粗了，估计不差钱。 然后关于你说的避免猜出用途，我前面也说了，我觉得应该不是，他们有公开的 API 的，公开 API 还提供文档给用户使用，也是设计的一个字母的
|
|
6
brader OP @wanguorui123 gz 不用说的，他们网站都是专业的，已经打开了，浏览器本身支持，服务端 nginx 又支持，根本不需要应用层代码考虑这个东西，所以也就不讨论这个了
|
 |
7
deplivesb 2022-07-23 11:50:16 +08:00
主要是为了防止被轻易猜出来字段属性吧。减少传输量？能减少几个字节？说不定还被对齐了。
|
 |
9
xiangyuecn 2022-07-23 11:59:26 +08:00
10 年前我就是用的 c 、m 做 code 、message ，老铁 没毛病，这玩意最开始定义好了 就很难改了，反正都是 ctrl+c ctrl+v ，符号而已
|
|
10
deplivesb 2022-07-23 11:59:43 +08:00
@brader 那就是懒的取名字，节省传输量这个事儿没有这么做的。
我不知道你说他们接口的请求量巨大是有多巨大。 我司核心业务的中台接口日 pv 在 2.5 亿左右，应该也还算大吧，也没有靠这个减少传输量保证可靠性的。 |
 |
11
dougy592 2022-07-23 12:06:50 +08:00 via Android 1
币安的 websocket 每秒都要向海量客户端推送大量行情 /交易数据，这样做可能真的是为了减少传输
|
|
12
dougy592 2022-07-23 12:08:49 +08:00 via Android
我的币安客户端，每个月要使用超 10Gb 流量
|
 |
13
gam2046 2022-07-23 13:00:09 +08:00
protobuf 就是这么做的，key 都变成了索引，也就是一个数字，来压缩传输量。
|
 |
14
james2013 2022-07-23 13:25:05 +08:00 via Android
币安是值得这么做的
api 订阅某个市场的行情数据，一天几十 G ，这还是单个用户，而且是免费提供 |
 |
15
crysislinux 2022-07-23 13:49:01 +08:00 via Android
流量大的这么做的感觉也不少，比如 Google 也是这样
|
 |
16
levon 2022-07-23 13:49:35 +08:00
咸吃萝卜淡操心
|
 |
17
starrys 2022-07-23 14:08:52 +08:00
应该就是为了节省流量，尤其是更新频率很高的情形下。
另外的案例：  |
 |
18
mercury233 2022-07-23 14:11:07 +08:00
这样缩短再 gzip 之后真的有效果吗……
|
 |
19
Jooooooooo 2022-07-23 14:18:53 +08:00
为了节省那点根本察觉不到的流量不如把心思花在别的地方.
比如返回的字段是不是梳理梳理能减少一个? |
 |
20
wyx119911 2022-07-23 14:32:54 +08:00
这样只能省一点点吧，不如直接用 pb 二进制传输了
|
 |
21
felixlong 2022-07-23 14:46:13 +08:00
@brader 也不矛盾。估计他们所有的 API 都是这样混淆过的。至于文档，他们肯定是选择性的公开。然后那个文档是基于当前实现来写的。可能先有代码，然后混淆，运营一段时间。再从里面选择部分 API 写成文档来公开。
|
 |
22
hronro 2022-07-23 15:10:40 +08:00
说实话，如何这真的是为了节省带宽，我觉得这就是拍脑袋的设计。上了 GZIP 之后，这种缩短字段带来的收益太小，而维护成本却大幅提高
|
 |
23
fkdog 2022-07-23 15:20:43 +08:00
我觉得如果真的想缩短传输量，为什么不直接上 protobuf 这类结构体？
连字段名都可以省略 |
 |
24
nicholasxuu 2022-07-23 15:52:43 +08:00
看规模算算呗，一年真的可能能省几十万。1GB 流量 0.5-0.8 元 /GB 。缩短 key 能省的只是皮毛倒是咯。
|
 |
25
LeegoYih 2022-07-23 16:33:49 +08:00
响应的结果还是 JSON ，提升不了多少。既然都打算压缩了，不如前后端约定好一个协议，用非结构化的报文，不然没什么意义。
|
 |
26
tcfenix 2022-07-23 17:00:29 +08:00
json 的优点是对人类友好, 如果不需要这个优点就是希望减少传输数据量的话直接上 pb 或者自己弄个私有协议不是更好....
|
 |
27
dcsuibian 2022-07-23 17:40:13 +08:00
程序员的时间是值钱的
|
 |
28
wellsc 2022-07-23 17:40:43 +08:00
缓缓打出一个问号
|
 |
29
lawler 2022-07-23 18:04:19 +08:00
没做过巨量流量意识不到这个收益的大小。
七八年前，参加的一个 salon ，有百度的技术负责人讲到。 百度大部分时刻首页流量每秒在 1T~2T 。在已经极端压缩优化 js ，css 的前提下。又删减了一个字符，流量下降 1.5G~3G/s 。 |
 |
30
XiLingHost 2022-07-23 18:16:00 +08:00
如果要削减流量，为啥还用 json 而不用二进制呢
|
 |
31
freshmanc 2022-07-23 18:31:54 +08:00
也算混淆了、、
|
 |
32
lixintcwdsg 2022-07-23 18:37:22 +08:00
自己上阿里云买个服务器，选流量的时候自己看看 1M ，100M 的贷款价格就好了呀。
实际上服务器真没几个钱，钱都花在流量上了～ 尤其是高并发的服务，逻辑都简单 |
 |
33
akira 2022-07-23 19:43:10 +08:00
@XiLingHost 应该是各方面妥协的产物
|
 |
34
glovebx 2022-07-23 20:17:29 +08:00
大流量下收益肯定大，而且都有插件可以自动解决，不影响编码和调试效率
|
 |
35
shot 2022-07-23 20:42:40 +08:00
@lawler #29
> 百度大部分时刻首页流量每秒在 1T~2T 。在已经极端压缩优化 js ，css 的前提下。又删减了一个字符，流量下降 1.5G~3G/s 。 姑且不考虑 gzip 压缩传输，一个 UTF-8 字符 1 byte ，1.5 Gbit ÷ 8 byte / bit = 7.5 × 10⁸。 10 亿量级的 QPS ，相当于全中国人民每一秒钟都刷一次百度首页。这不太客观吧。 如果考虑 gzip ，压缩之后更不应该会有显著区别了。 |
|
36
shot 2022-07-23 20:45:22 +08:00
|
 |
37
p23XnFNH1Wq953rV 2022-07-24 10:29:08 +08:00
量大值得, 省服务器流量也省客户端流量
|
 |
38
jones2000 2022-07-24 10:30:41 +08:00
@starrys 这 Key ，value 哪里节省资源了， 导出都是 f1, f2 。。。。。 还不如 f1:[], f2:[] ..... 这样节省资源了， 只不过这样搞，前端转换麻烦点。
|
 |
39
xinshidai 2022-07-24 11:34:22 +08:00
有代码转换器呢?
|
 |
40
realpg 2022-07-24 13:18:05 +08:00
@shot #35
真干过大规模运维就知道,gzip 在 api 这种小数据量场景没卵用 很少见谁家 api 能过 2KB 的内容的 小内容再开 gzip 就是负优化 而普遍的 gzip 启用标准是 4KB, 这是一个充分权衡后对大多数场合很恰当的阈值 |
 |
41
ychost 2022-07-24 13:37:49 +08:00
JSON 本身就比较费字段，除非用 protobuf 之类的来优化
|
 |
42
securityCoding 2022-07-24 15:06:49 +08:00
先说结论，不值得且完全没有意义，想要优化消息体大小应该在框架的 transport 或者 codec 层做这件事。
比如：开启 gzip ，protobuffer 编解码。 |
 |
43
whoami9894 2022-10-10 10:41:57 +08:00
开眼了，有觉得网络传输要字段对齐的，有觉得压缩算法一定能压缩到比原始数据小的，有觉得缩减 json 字段名长度没用的。
|
Select Language