V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
brader
V2EX  ›  程序员

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

  •  
  •   brader · 134 天前 · 4285 次点击
    这是一个创建于 134 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我曾经有关注过火币还是币安来着,他们的 API 接口,经历过改革,想和大家讨论一下。

    首先可确定的是,这个网站的接口请求量非常巨大,这是毋庸置疑的。

    最开始我看到他们的接口和我们平时的也差不多,后来我发现他们把 API 接口改了,如 {"c":0, "m":"xxx", "r":{"q":"xxx"}},基本上每个字段都是一个字母,不够用了就两个字母。

    我个人琢磨猜测了一下,他们这么干的目的,应该是想减少传输量(为什么我不觉得他们是想迷惑别人呢,因为他们有一些公开的 API ,也是这么设计的,文档也是开放出来的),也算是提高并发能力的一个技巧了。当然这么干坏处就是对接使用的人挺麻烦的,不看文档压根不知道什么意思,好处就是传输量实实在在的减少了,虽然一个接口减少的流量看似不多,但是以他们网站的规模来看,减少的量就很可观了。

    大家觉得,如果是为了减少传输量这么干,是值得还是不值得,就是收益大?还是得不偿失?

    43 条回复    2022-10-10 10:41:57 +08:00
    vitovan
        1
    vitovan  
       134 天前
    如果可以提供组件,让客户端开发时可以直接调用,生成压缩后的请求包,应该还好。

    不过这个问题主要看计划资源投入和话语权在谁手里。

    我纯粹是瞎说两句。
    westoy
        2
    westoy  
       134 天前   ❤️ 1
    服务端替换 key 变量也是要成本的啊, 我真不信他们开发是手撸写死这种变量。 数据传输也是最小包和对齐的, 省几个字节未必有实际用途的

    这种接口命名更大的意义是避免语义化让你直接猜出用途吧.......
    wanguorui123
        3
    wanguorui123  
       134 天前
    开启 GZIP
    manecocomph
        4
    manecocomph  
       134 天前
    程序现阶段还是给人看的. LB 后边能加几台机器能解决的问题, 人脑和电脑都做个 mapping 是不值得的. 从节省资源或总体性能的角度看上去收益不大.
    brader
        5
    brader  
    OP
       134 天前
    @westoy 你别说,他们还就可能是写死的,我就觉得,这么干得到的好处和付出的成本,值不值得,其实说到成本,他们也算是财大气粗了,估计不差钱。 然后关于你说的避免猜出用途,我前面也说了,我觉得应该不是,他们有公开的 API 的,公开 API 还提供文档给用户使用,也是设计的一个字母的
    brader
        6
    brader  
    OP
       134 天前
    @wanguorui123 gz 不用说的,他们网站都是专业的,已经打开了,浏览器本身支持,服务端 nginx 又支持,根本不需要应用层代码考虑这个东西,所以也就不讨论这个了
    deplivesb
        7
    deplivesb  
       134 天前
    主要是为了防止被轻易猜出来字段属性吧。减少传输量?能减少几个字节?说不定还被对齐了。
    brader
        8
    brader  
    OP
       134 天前
    @deplivesb 防止猜出的话,就很矛盾啊,他们有公开 API ,还公布了文档,公开 API 也是这么设计的
    xiangyuecn
        9
    xiangyuecn  
       134 天前
    10 年前我就是用的 c 、m 做 code 、message ,老铁 没毛病,这玩意最开始定义好了 就很难改了,反正都是 ctrl+c ctrl+v ,符号而已
    deplivesb
        10
    deplivesb  
       134 天前
    @brader 那就是懒的取名字,节省传输量这个事儿没有这么做的。
    我不知道你说他们接口的请求量巨大是有多巨大。
    我司核心业务的中台接口日 pv 在 2.5 亿左右,应该也还算大吧,也没有靠这个减少传输量保证可靠性的。
    dougy592
        11
    dougy592  
       134 天前 via Android   ❤️ 1
    币安的 websocket 每秒都要向海量客户端推送大量行情 /交易数据,这样做可能真的是为了减少传输
    dougy592
        12
    dougy592  
       134 天前 via Android
    我的币安客户端,每个月要使用超 10Gb 流量
    gam2046
        13
    gam2046  
       134 天前
    protobuf 就是这么做的,key 都变成了索引,也就是一个数字,来压缩传输量。
    james2013
        14
    james2013  
       134 天前 via Android
    币安是值得这么做的
    api 订阅某个市场的行情数据,一天几十 G ,这还是单个用户,而且是免费提供
    crysislinux
        15
    crysislinux  
       134 天前 via Android
    流量大的这么做的感觉也不少,比如 Google 也是这样
    levon
        16
    levon  
       134 天前
    咸吃萝卜淡操心
    starrys
        17
    starrys  
       134 天前
    应该就是为了节省流量,尤其是更新频率很高的情形下。
    另外的案例:
    mercury233
        18
    mercury233  
       134 天前
    这样缩短再 gzip 之后真的有效果吗……
    Jooooooooo
        19
    Jooooooooo  
       134 天前
    为了节省那点根本察觉不到的流量不如把心思花在别的地方.

    比如返回的字段是不是梳理梳理能减少一个?
    wyx119911
        20
    wyx119911  
       134 天前
    这样只能省一点点吧,不如直接用 pb 二进制传输了
    felixlong
        21
    felixlong  
       134 天前
    @brader 也不矛盾。估计他们所有的 API 都是这样混淆过的。至于文档,他们肯定是选择性的公开。然后那个文档是基于当前实现来写的。可能先有代码,然后混淆,运营一段时间。再从里面选择部分 API 写成文档来公开。
    hronro
        22
    hronro  
       134 天前
    说实话,如何这真的是为了节省带宽,我觉得这就是拍脑袋的设计。上了 GZIP 之后,这种缩短字段带来的收益太小,而维护成本却大幅提高
    fkdog
        23
    fkdog  
       134 天前
    我觉得如果真的想缩短传输量,为什么不直接上 protobuf 这类结构体?
    连字段名都可以省略
    nicholasxuu
        24
    nicholasxuu  
       134 天前
    看规模算算呗,一年真的可能能省几十万。1GB 流量 0.5-0.8 元 /GB 。缩短 key 能省的只是皮毛倒是咯。
    LeegoYih
        25
    LeegoYih  
       134 天前
    响应的结果还是 JSON ,提升不了多少。既然都打算压缩了,不如前后端约定好一个协议,用非结构化的报文,不然没什么意义。
    tcfenix
        26
    tcfenix  
       134 天前
    json 的优点是对人类友好, 如果不需要这个优点就是希望减少传输数据量的话直接上 pb 或者自己弄个私有协议不是更好....
    dcsuibian
        27
    dcsuibian  
       134 天前
    程序员的时间是值钱的
    wellsc
        28
    wellsc  
       134 天前
    缓缓打出一个问号
    lawler
        29
    lawler  
       134 天前
    没做过巨量流量意识不到这个收益的大小。

    七八年前,参加的一个 salon ,有百度的技术负责人讲到。
    百度大部分时刻首页流量每秒在 1T~2T 。在已经极端压缩优化 js ,css 的前提下。又删减了一个字符,流量下降 1.5G~3G/s 。
    XiLingHost
        30
    XiLingHost  
       134 天前
    如果要削减流量,为啥还用 json 而不用二进制呢
    freshmanc
        31
    freshmanc  
       134 天前
    也算混淆了、、
    lixintcwdsg
        32
    lixintcwdsg  
       134 天前
    自己上阿里云买个服务器,选流量的时候自己看看 1M ,100M 的贷款价格就好了呀。
    实际上服务器真没几个钱,钱都花在流量上了~
    尤其是高并发的服务,逻辑都简单
    akira
        33
    akira  
       134 天前
    @XiLingHost 应该是各方面妥协的产物
    glovebx
        34
    glovebx  
       134 天前
    大流量下收益肯定大,而且都有插件可以自动解决,不影响编码和调试效率
    shot
        35
    shot  
       134 天前
    @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 ,压缩之后更不应该会有显著区别了。
    shot
        36
    shot  
       134 天前
    @shot #35

    呃……算错了。

    1.5 Gbit ÷ 8 byte / bit ≈ 2 × 10⁸,相当于全中国人民每十秒钟都刷一次百度首页。
    derrick1
        37
    derrick1  
       133 天前
    量大值得, 省服务器流量也省客户端流量
    jones2000
        38
    jones2000  
       133 天前
    @starrys 这 Key ,value 哪里节省资源了, 导出都是 f1, f2 。。。。。 还不如 f1:[], f2:[] ..... 这样节省资源了, 只不过这样搞,前端转换麻烦点。
    xinshidai
        39
    xinshidai  
       133 天前
    有代码转换器呢?
    realpg
        40
    realpg  
       133 天前
    @shot #35
    真干过大规模运维就知道,gzip 在 api 这种小数据量场景没卵用
    很少见谁家 api 能过 2KB 的内容的
    小内容再开 gzip 就是负优化
    而普遍的 gzip 启用标准是 4KB, 这是一个充分权衡后对大多数场合很恰当的阈值
    ychost
        41
    ychost  
       133 天前
    JSON 本身就比较费字段,除非用 protobuf 之类的来优化
    securityCoding
        42
    securityCoding  
       133 天前
    先说结论,不值得且完全没有意义,想要优化消息体大小应该在框架的 transport 或者 codec 层做这件事。
    比如:开启 gzip ,protobuffer 编解码。
    whoami9894
        43
    whoami9894  
       55 天前
    开眼了,有觉得网络传输要字段对齐的,有觉得压缩算法一定能压缩到比原始数据小的,有觉得缩减 json 字段名长度没用的。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2651 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 56ms · UTC 00:52 · PVG 08:52 · LAX 16:52 · JFK 19:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.