服务部署流程中，如何节省流量费用？

[yuandj]

当下情况

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

目前已经做过的优化方案

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

暂不考虑的方案

1. 按带宽计费（目前业务量级，按量计费/按带宽计费消耗差不多）

有想法还未实现的方案

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

请教

1. 有没有推荐的优化方案？ PS: 可以是服务部署方面 或者 流量优化方面

[Ipsum]

日 20 亿，恕我直言，已经打败了 99.99999%的群友了。

[dragonfsky1]

日 20 亿 还需要考虑流量费用吗，这种直接升级按口子计费的

[javalaw2010]

如果场景允许的话，先上个限流，避免下游无节制调用接口。
如果是收费接口，提高费用，下游会自己想办法做缓存。
如果场景允许静态化，那改成生成 json 文件分发到 CDN ，CDN 一般价格好谈一点。

[yuandj]

@dragonfsky1
盈利不是靠请求次数多少决定的，技术侧只能尽力减少服务成本了。
运营侧在做业务时，也得算着请求量级的营收比。
如果技术侧把服务成本做得更低，运营就有更多的施展空间。

[yuandj]

@javalaw2010
1. 业务层的限流已经做了，目前接口调用频次都在可控范围内。
2. 必须实时调用接口，在业务逻辑中，调用侧和接收侧都不允许缓存。

[northbrunv]

使用按带宽计费（不限流量）的服务器。如果你使用按流量计费的，成本很高

[supersadmin]

蹲一个解决方案。

[supersadmin]

日均 2 亿请求，之前测试使用按量计费比包月贵，现在直接包月了。

[mightybruce]

如果你们技术过硬， 可以考虑修改服务使用 HTTPP3/QUIC 协议， 要考虑云商的各个组件是否支持（尤其是负载均衡）。
HTTP3 复用 比 HTTP2 更好，也更加节省流量。

其他很多方面，托管云是做不了太多的， 看是否能够对 linux 内核参数做一些调整

[vivisidea]

是 In 流量 还是 Out 流量？我记得阿里云 ECS 绑定 外网 IP 的话，200Mbps 的 In 带宽是不收费的

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

威胁不给优惠就迁移去友商，谈优惠

[xueling]

1 、使用 snappy/gzip 实时压缩；
2 、使用枚举 ID 代替不必要的文本传输，减少类似描述信息等文本内容的传输，数值类型参数不要使用字符串，键值也可以使用 id 替代；
3 、使用字节流类型接收和返回数据，根据二进制位自定义传入和返回数据协议（最好统一封装 http 请求和解析工具类给交互方）；

了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse 实时监控接口数据传输量，便于衡量优化效果。

[mightybruce]

腾讯的张彦飞的《深入理解 Linux 网络》可以看看， 他写的文章很有深度， 这里给一个链接

https://mp.weixin.qq.com/s/-xiWjPRiRsPcxODnJ3921Q

[Kinnice]

1. 首先看看你们流量峰值和流量模型
2. 可以开低带宽计费机器来和流量计费负载均衡一下，流量计费基本是 95 ，这样负载一下可能要便宜不少
3. 接口可以改 json => grpc
4. gzip => br

[matrix1010]

要不你先说说业务是什么类型? No Silver Bullet 和 XY problem 大家都懂。具体问题具体分析，说不定直接 client side cache 一下都不用发请求

[gam2046]

这种量级，考虑一下，HTTPS 能否降级成 HTTP ，光证书流量就节约非常多。

如果计划响应结构变为 protobuf ，那么 gzip 的效果就很一般了。

[duan602728596]

什么，居然没开 gzip 吗？ https 也可以尝试 br 压缩，效果更好

[R4rvZ6agNVWr56V0]

思路：
使用 Protocol Buffers 代替 JSON ，以减少数据传输量。
使用 CDN ，将静态资源和 API 响应缓存并且靠近用户交付，以降低延迟和提高响应时间。
在 API 层集成缓存机制，快速提供缓存数据，减轻后端系统负担，改善响应时间。
采用现代网络协议，如 HTTP/2 ，减少建立新连接的开销，提高网络效率。
优化数据库查询，避免检索不必要的数据，减少网络流量，提高性能。
优化日志收集，仅收集和保留必要的日志数据，优化日志分析成本。
考虑其他压缩算法，如 lz4 、snappy 或 zstd ，以提高压缩性能。

[zeusho871]

买那种大宽带机房 我这每天 20e 可能没有 几千万还是有
就那种大宽带服务器 500m 上下行拉满的 比阿里云便宜 然后作为缓存层通你你现在阿里云的服务 这样流量基本不计
如果还想便宜就移动大带宽的比电信便宜更多

[zeusho871]

@zeusho871 没看到楼下的补充。。。如果不能缓存最简单的便宜的是买 5m 的阿里云 几十台堆起来 20 台 5m 的阿里云比一台 100m 的便宜很多

[tool2dx]

@duan602728596 楼主说请求都是实时的，估计用 br 很难，这算法太慢了。

zstd 可以，gzip 也可以。

[northbrunv]

机房托管，1g 带宽 5000-8000 左右，单线 bgp 价格不同

[isno]

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]

找云商谈优惠 这个最实际。

[milzero]

@mightybruce #12 等看完，再实践，OP 可能都被裁了！

[cjd6568358]

1.通用方案
前端底层使用 websocket 代理业务层接口，传输使用 gzip 压缩。
2.业务层改造
参考 osi 模型协议，用 bit 位来表示业务减少传输数据体积。

[seth19960929]

上 rpc 吧, HTTP header 还是占用挺多的. 看你的使用商能不能接受了.
可以再补充具体一点业务

[hongfs]

某家上市云商是谁，可以参考下拼多多，走内网来链接，费用会降低些。

[zizon]

看 request/response 的大小是什么区间了.
如果不大的话相比可能 HTTP 协议本身的 overhead 就很冗余,可以考虑换协议.

[yuandj]

@hongfs
#27 这个方案云商提过，找出最大的流量方，直接跟他家的服务器扯根网线，前提是对方要同意。

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

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

情况补充：
1. 纯接口请求响应流量费用，不包含前端静态资源。
2. 目前只用到了 HTTP ，没用 HTTPS 。
3. 业务是 ADX 平台，出口和入口流量都比较大。

[wdhwg001]

不要用 protobuf ，用无需自解释的协议，比如 flatbuffer 或者 capnproto ，可以省去一大波结构描述类的开销。

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

还有你需要 zstd 。

[wdhwg001]

补充一条，合理的缓存策略也很重要，很多请求是不需要疯狂刷查询的，oauth 之后给每个 token 做一下 rate limit 很重要。

[vivisidea]

@yuandj #29 你找阿里云确认下呢，应该也有个总带宽上限，并不是无上限的，注意需要 Ecs 绑定公网 IP ，流量不要走网关，网关好像是 max(in, out) 计费的，原理就是实际上阿里云上的业务大多数是 Out 多，所以运营商跟阿里云结算也是以 Out 结算的，In 实际上不收费

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

另外你们 In：Out 比例 1:1.2 的话，按带宽计费的话，我记得是 Max(In, Out) 哪个大计哪个的（ 95 峰值），不应该 In/Out 都分别计费啊？

[vivisidea]

@yuandj #29
https://help.aliyun.com/zh/ecs/product-overview/public-bandwidth

[teaegglove]

用 hetzner ，每台 20T 免费流量。然后用 DNS load balancing 做集群，把分散流量到每台机器。

[Nicklove]

网络的提速降费...

[hongfs]

@Nicklove 网络的成本总需要有人来承担，家用带宽白菜价，商用带宽大幅下降不太现实。

[EthanLau]

我们也有类似问题，量级比你们多一些，目前也没啥优化的空间了，如果双方都是阿里云的话，同一地域的能直接建一个对等连接走内网，对方肯定也乐意。

再怎么优化，不如商务谈一个低的折扣来的香

[kaf]

有试过 95 带宽计费吗，既然带宽和按量差不多，95 带宽服务侧再优化一下流量峰值，应该能薅出一点羊毛

[Nicklove]

@hongfs "家用带宽白菜价"，难道你想说家用带宽都是亏本在卖？以腾讯云为例，1mbps 带宽的月费是 20 元，50mbps 带宽的月费是 4165 元，那你就觉得商用带宽这样就现实了？网络的成本当然需要有人来承担，我不能既承担了成本，还要理解运营商吧。

[Nicklove]

补充一下，包月带宽如此，按流量计费是¥0.80/GB

[voidmnwzp]

哥们，你耳聋好了没

[yuandj]

@voidmnwzp 高频听不到，不影响正常生活。但耳鸣常在，休息好的时候减轻些，熬夜的时候加重些

[voidmnwzp]

@yuandj 头部检查了没 有无异常？