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

查看 246|回复 25
作者:yuandj   
当下情况
有个项目,部署在某家上市云商中,接口大概每天 20 亿左右的请求响应,流量费用在服务器架构中占比较高,目前已经实施了 2 种优化方案,请问有没有更好的优化方案推荐?
目前已经做过的优化方案
[ol]
  • 找云商谈优惠
  • 要求调用接口的合作商加上 gzip 压缩
    [/ol]
    暂不考虑的方案
    [ol]
  • 按带宽计费(目前业务量级,按量计费/按带宽计费消耗差不多)
    [/ol]
    有想法还未实现的方案
    [ol]
  • 使用 Protocol Buffers 替代 json ,和 gzip 同时使用。
    [/ol]
    请教
    [ol]
  • 有没有推荐的优化方案? PS: 可以是服务部署方面 或者 流量优化方面
    [/ol]
  • Ipsum   
    日 20 亿,恕我直言,已经打败了 99.99999%的群友了。
    dragonfsky1   
    日 20 亿 还需要考虑流量费用吗,这种直接升级按口子计费的
    javalaw2010   
    如果场景允许的话,先上个限流,避免下游无节制调用接口。
    如果是收费接口,提高费用,下游会自己想办法做缓存。
    如果场景允许静态化,那改成生成 json 文件分发到 CDN ,CDN 一般价格好谈一点。
    yuandj
    OP
      
    @dragonfsky1
    盈利不是靠请求次数多少决定的,技术侧只能尽力减少服务成本了。
    运营侧在做业务时,也得算着请求量级的营收比。
    如果技术侧把服务成本做得更低,运营就有更多的施展空间。
    yuandj
    OP
      
    @javalaw2010
    1. 业务层的限流已经做了,目前接口调用频次都在可控范围内。
    2. 必须实时调用接口,在业务逻辑中,调用侧和接收侧都不允许缓存。
    northbrunv   
    使用按带宽计费(不限流量)的服务器。如果你使用按流量计费的,成本很高
    supersadmin   
    蹲一个解决方案。
    supersadmin   
    日均 2 亿请求,之前测试使用按量计费比包月贵,现在直接包月了。
    mightybruce   
    如果你们技术过硬, 可以考虑修改服务使用 HTTPP3/QUIC 协议, 要考虑云商的各个组件是否支持(尤其是负载均衡)。
    HTTP3 复用 比 HTTP2 更好,也更加节省流量。
    其他很多方面,托管云是做不了太多的, 看是否能够对 linux 内核参数做一些调整
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部