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

服务部署流程中,如何节省流量费用?

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

    当下情况

    有个项目,部署在某家上市云商中,接口大概每天 20 亿左右的请求响应,流量费用在服务器架构中占比较高,目前已经实施了 2 种优化方案,请问有没有更好的优化方案推荐?

    目前已经做过的优化方案

    1. 找云商谈优惠
    2. 要求调用接口的合作商加上 gzip 压缩

    暂不考虑的方案

    1. 按带宽计费(目前业务量级,按量计费/按带宽计费消耗差不多)

    有想法还未实现的方案

    1. 使用 Protocol Buffers 替代 json ,和 gzip 同时使用。

    请教

    1. 有没有推荐的优化方案? PS: 可以是服务部署方面 或者 流量优化方面
    43 条回复    2024-06-06 22:48:13 +08:00
    Ipsum
        1
    Ipsum  
       186 天前
    日 20 亿,恕我直言,已经打败了 99.99999%的群友了。
    dragonfsky1
        2
    dragonfsky1  
       186 天前
    日 20 亿 还需要考虑流量费用吗,这种直接升级按口子计费的
    javalaw2010
        3
    javalaw2010  
       186 天前   ❤️ 1
    如果场景允许的话,先上个限流,避免下游无节制调用接口。
    如果是收费接口,提高费用,下游会自己想办法做缓存。
    如果场景允许静态化,那改成生成 json 文件分发到 CDN ,CDN 一般价格好谈一点。
    yuandj
        4
    yuandj  
    OP
       186 天前
    @dragonfsky1
    盈利不是靠请求次数多少决定的,技术侧只能尽力减少服务成本了。
    运营侧在做业务时,也得算着请求量级的营收比。
    如果技术侧把服务成本做得更低,运营就有更多的施展空间。
    yuandj
        5
    yuandj  
    OP
       186 天前
    @javalaw2010
    1. 业务层的限流已经做了,目前接口调用频次都在可控范围内。
    2. 必须实时调用接口,在业务逻辑中,调用侧和接收侧都不允许缓存。
    northbrunv
        6
    northbrunv  
       186 天前 via Android
    使用按带宽计费(不限流量)的服务器。如果你使用按流量计费的,成本很高
    supersadmin
        7
    supersadmin  
       186 天前
    蹲一个解决方案。
    supersadmin
        8
    supersadmin  
       186 天前
    日均 2 亿请求,之前测试使用按量计费比包月贵,现在直接包月了。
    mightybruce
        9
    mightybruce  
       186 天前
    如果你们技术过硬, 可以考虑修改服务使用 HTTPP3/QUIC 协议, 要考虑云商的各个组件是否支持(尤其是负载均衡)。
    HTTP3 复用 比 HTTP2 更好,也更加节省流量。

    其他很多方面,托管云是做不了太多的, 看是否能够对 linux 内核参数做一些调整
    vivisidea
        10
    vivisidea  
       186 天前
    是 In 流量 还是 Out 流量?我记得阿里云 ECS 绑定 外网 IP 的话,200Mbps 的 In 带宽是不收费的

    Out 流量没啥办法,gzip 可以看下数据都是怎样的,测算下压缩比,有多少收益

    威胁不给优惠就迁移去友商,谈优惠
    xueling
        11
    xueling  
       186 天前
    1 、使用 snappy/gzip 实时压缩;
    2 、使用枚举 ID 代替不必要的文本传输,减少类似描述信息等文本内容的传输,数值类型参数不要使用字符串,键值也可以使用 id 替代;
    3 、使用字节流类型接收和返回数据,根据二进制位自定义传入和返回数据协议(最好统一封装 http 请求和解析工具类给交互方);

    了解一下我的开源项目: https://github.com/xl-xueling/xl-lighthouse 实时监控接口数据传输量,便于衡量优化效果。
    mightybruce
        12
    mightybruce  
       186 天前
    腾讯的张彦飞的《深入理解 Linux 网络》可以看看, 他写的文章很有深度, 这里给一个链接

    https://mp.weixin.qq.com/s/-xiWjPRiRsPcxODnJ3921Q
    Kinnice
        13
    Kinnice  
       186 天前
    1. 首先看看你们流量峰值和流量模型
    2. 可以开低带宽计费机器来和流量计费负载均衡一下,流量计费基本是 95 ,这样负载一下可能要便宜不少
    3. 接口可以改 json => grpc
    4. gzip => br
    matrix1010
        14
    matrix1010  
       186 天前
    要不你先说说业务是什么类型? No Silver Bullet 和 XY problem 大家都懂。具体问题具体分析,说不定直接 client side cache 一下都不用发请求
    gam2046
        15
    gam2046  
       186 天前
    这种量级,考虑一下,HTTPS 能否降级成 HTTP ,光证书流量就节约非常多。

    如果计划响应结构变为 protobuf ,那么 gzip 的效果就很一般了。
    duan602728596
        16
    duan602728596  
       186 天前
    什么,居然没开 gzip 吗? https 也可以尝试 br 压缩,效果更好
    GeekGao
        17
    GeekGao  
       186 天前
    思路:
    使用 Protocol Buffers 代替 JSON ,以减少数据传输量。
    使用 CDN ,将静态资源和 API 响应缓存并且靠近用户交付,以降低延迟和提高响应时间。
    在 API 层集成缓存机制,快速提供缓存数据,减轻后端系统负担,改善响应时间。
    采用现代网络协议,如 HTTP/2 ,减少建立新连接的开销,提高网络效率。
    优化数据库查询,避免检索不必要的数据,减少网络流量,提高性能。
    优化日志收集,仅收集和保留必要的日志数据,优化日志分析成本。
    考虑其他压缩算法,如 lz4 、snappy 或 zstd ,以提高压缩性能。
    zeusho871
        18
    zeusho871  
       186 天前
    买那种大宽带机房 我这每天 20e 可能没有 几千万还是有
    就那种大宽带服务器 500m 上下行拉满的 比阿里云便宜 然后作为缓存层通你你现在阿里云的服务 这样流量基本不计
    如果还想便宜就移动大带宽的比电信便宜更多
    zeusho871
        19
    zeusho871  
       186 天前
    @zeusho871 没看到楼下的补充。。。如果不能缓存最简单的便宜的是买 5m 的阿里云 几十台堆起来 20 台 5m 的阿里云比一台 100m 的便宜很多
    tool2dx
        20
    tool2dx  
       186 天前
    @duan602728596 楼主说请求都是实时的,估计用 br 很难,这算法太慢了。

    zstd 可以,gzip 也可以。
    northbrunv
        21
    northbrunv  
       186 天前 via Android
    机房托管,1g 带宽 5000-8000 左右,单线 bgp 价格不同
    isno
        22
    isno  
       186 天前   ❤️ 1
    1. 如果接口的内容是 HTML 类型的文本 br 压缩能比 gzip 高 17~30%的压缩率。 [推荐使用]
    https://www.thebyte.com.cn/http/compress.html#_2-%E4%BD%BF%E7%94%A8-brotli-%E5%8E%8B%E7%BC%A9

    2. protobuf 比 JSON 会一点点,但影响不大 [花大力气,换来少收益]
    https://www.thebyte.com.cn/http/protobuf.html

    3. 优化一下 SSL 的证书 [花大力气,换来少收益]
    https://www.thebyte.com.cn/http/ssl.html
    scys
        23
    scys  
       186 天前
    找云商谈优惠 这个最实际。
    milzero
        24
    milzero  
       186 天前
    @mightybruce #12 等看完,再实践,OP 可能都被裁了!
    cjd6568358
        25
    cjd6568358  
       186 天前
    1.通用方案
    前端底层使用 websocket 代理业务层接口,传输使用 gzip 压缩。
    2.业务层改造
    参考 osi 模型协议,用 bit 位来表示业务减少传输数据体积。
    seth19960929
        26
    seth19960929  
       186 天前


    上 rpc 吧, HTTP header 还是占用挺多的. 看你的使用商能不能接受了.
    可以再补充具体一点业务
    hongfs
        27
    hongfs  
       186 天前
    某家上市云商是谁,可以参考下拼多多,走内网来链接,费用会降低些。
    zizon
        28
    zizon  
       186 天前
    看 request/response 的大小是什么区间了.
    如果不大的话相比可能 HTTP 协议本身的 overhead 就很冗余,可以考虑换协议.
    yuandj
        29
    yuandj  
    OP
       186 天前
    @hongfs
    #27 这个方案云商提过,找出最大的流量方,直接跟他家的服务器扯根网线,前提是对方要同意。

    @gam2046
    #15 目前用的就是 HTTP ,没用 HTTPS

    @vivisidea
    #10 In 和 Out 占比 1 : 1.2 吧,Out 的流量使用确实不取决于我们,目前在考虑节省 In 的流量。阿里 200Mbps 不收费这个确定吗?那我多扯几根,每个都不超过 200M ,阿里不得亏死。。。

    情况补充:
    1. 纯接口请求响应流量费用,不包含前端静态资源。
    2. 目前只用到了 HTTP ,没用 HTTPS 。
    3. 业务是 ADX 平台,出口和入口流量都比较大。
    wdhwg001
        30
    wdhwg001  
       186 天前 via iPhone   ❤️ 1
    不要用 protobuf ,用无需自解释的协议,比如 flatbuffer 或者 capnproto ,可以省去一大波结构描述类的开销。

    另外 graphql 真的省带宽,按需给字段很重要的。

    还有你需要 zstd 。
    wdhwg001
        31
    wdhwg001  
       186 天前 via iPhone
    补充一条,合理的缓存策略也很重要,很多请求是不需要疯狂刷查询的,oauth 之后给每个 token 做一下 rate limit 很重要。
    vivisidea
        32
    vivisidea  
       186 天前
    @yuandj #29 你找阿里云确认下呢,应该也有个总带宽上限,并不是无上限的,注意需要 Ecs 绑定公网 IP ,流量不要走网关,网关好像是 max(in, out) 计费的,原理就是实际上阿里云上的业务大多数是 Out 多,所以运营商跟阿里云结算也是以 Out 结算的,In 实际上不收费

    我们的业务也是 In 流量大,之前调研方案的时候找阿里云了解到这个信息,不确定是否通用

    另外你们 In:Out 比例 1:1.2 的话,按带宽计费的话,我记得是 Max(In, Out) 哪个大计哪个的( 95 峰值),不应该 In/Out 都分别计费啊?
    teaegglove
        34
    teaegglove  
       186 天前 via Android
    用 hetzner ,每台 20T 免费流量。然后用 DNS load balancing 做集群,把分散流量到每台机器。
    Nicklove
        35
    Nicklove  
       186 天前
    网络的提速降费...
    hongfs
        36
    hongfs  
       186 天前
    @Nicklove 网络的成本总需要有人来承担,家用带宽白菜价,商用带宽大幅下降不太现实。
    EthanLau
        37
    EthanLau  
       186 天前
    我们也有类似问题,量级比你们多一些,目前也没啥优化的空间了,如果双方都是阿里云的话,同一地域的能直接建一个对等连接走内网,对方肯定也乐意。

    再怎么优化,不如商务谈一个低的折扣来的香
    kaf
        38
    kaf  
       186 天前
    有试过 95 带宽计费吗,既然带宽和按量差不多,95 带宽服务侧再优化一下流量峰值,应该能薅出一点羊毛
    Nicklove
        39
    Nicklove  
       185 天前
    @hongfs "家用带宽白菜价",难道你想说家用带宽都是亏本在卖?以腾讯云为例,1mbps 带宽的月费是 20 元,50mbps 带宽的月费是 4165 元,那你就觉得商用带宽这样就现实了?网络的成本当然需要有人来承担,我不能既承担了成本,还要理解运营商吧。
    Nicklove
        40
    Nicklove  
       185 天前
    补充一下,包月带宽如此,按流量计费是¥0.80/GB
    voidmnwzp
        41
    voidmnwzp  
       183 天前
    哥们,你耳聋好了没
    yuandj
        42
    yuandj  
    OP
       183 天前
    @voidmnwzp 高频听不到,不影响正常生活。但耳鸣常在,休息好的时候减轻些,熬夜的时候加重些
    voidmnwzp
        43
    voidmnwzp  
       177 天前 via iPhone
    @yuandj 头部检查了没 有无异常?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2580 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 04:26 · PVG 12:26 · LAX 20:26 · JFK 23:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.