请求量巨大的情况下,缩短 API 字段单词长度是否值得?

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