V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
颜值和功能齐聚的跨平台SSH工具
Xterminal 是一款强大的开发工具,不止是 SSH 与 Terminal,还集成了 Note、拥有快捷动作、命令提示等特性
Promoted by Moyyyyyyyyyyye
yuandj
V2EX  ›  程序员

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

  •  
  •   yuandj · 2024-05-28 16:17:25 +08:00 · 3705 次点击
    这是一个创建于 423 天前的主题,其中的信息可能已经有所发展或是发生改变。

    当下情况

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

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

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

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

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

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

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

    zstd 可以,gzip 也可以。
    northbrunv
        21
    northbrunv  
       2024-05-28 18:17:11 +08:00 via Android
    机房托管,1g 带宽 5000-8000 左右,单线 bgp 价格不同
    isno
        22
    isno  
       2024-05-28 18:23:36 +08:00   ❤️ 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  
       2024-05-28 18:51:08 +08:00
    找云商谈优惠 这个最实际。
    milzero
        24
    milzero  
       2024-05-28 19:04:23 +08:00
    @mightybruce #12 等看完,再实践,OP 可能都被裁了!
    cjd6568358
        25
    cjd6568358  
       2024-05-28 19:38:56 +08:00
    1.通用方案
    前端底层使用 websocket 代理业务层接口,传输使用 gzip 压缩。
    2.业务层改造
    参考 osi 模型协议,用 bit 位来表示业务减少传输数据体积。
    seth19960929
        26
    seth19960929  
       2024-05-28 21:08:57 +08:00


    上 rpc 吧, HTTP header 还是占用挺多的. 看你的使用商能不能接受了.
    可以再补充具体一点业务
    hongfs
        27
    hongfs  
       2024-05-28 21:14:35 +08:00
    某家上市云商是谁,可以参考下拼多多,走内网来链接,费用会降低些。
    zizon
        28
    zizon  
       2024-05-28 22:43:19 +08:00
    看 request/response 的大小是什么区间了.
    如果不大的话相比可能 HTTP 协议本身的 overhead 就很冗余,可以考虑换协议.
    yuandj
        29
    yuandj  
    OP
       2024-05-28 22:56:06 +08:00
    @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  
       2024-05-28 23:03:55 +08:00 via iPhone   ❤️ 1
    不要用 protobuf ,用无需自解释的协议,比如 flatbuffer 或者 capnproto ,可以省去一大波结构描述类的开销。

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

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

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

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

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