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

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

暂不考虑的方案

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

有想法还未实现的方案

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

请教

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

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

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

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

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

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

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

蹲一个解决方案。

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

如果你们技术过硬， 可以考虑修改服务使用 HTTPP3/QUIC 协议， 要考虑云商的各个组件是否支持（尤其是负载均衡）。HTTP3 复用 比 HTTP2 更好，也更加节省流量。其他很多方面，托管云是做不了太多的， 看是否能够对 linux 内核参数做一些调整

是 In 流量 还是 Out 流量？我记得阿里云 ECS 绑定 外网 IP 的话，200Mbps 的 In 带宽是不收费的Out 流量没啥办法，gzip 可以看下数据都是怎样的，测算下压缩比，有多少收益威胁不给优惠就迁移去友商，谈优惠
1 、使用 snappy/gzip 实时压缩；2 、使用枚举 ID 代替不必要的文本传输，减少类似描述信息等文本内容的传输，数值类型参数不要使用字符串，键值也可以使用 id 替代；3 、使用字节流类型接收和返回数据，根据二进制位自定义传入和返回数据协议（最好统一封装 http 请求和解析工具类给交互方）；了解一下我的开源项目： github.com/xl-xueling/xl-lighthouse 实时监控接口数据传输量，便于衡量优化效果。

腾讯的张彦飞的《深入理解 Linux 网络》可以看看， 他写的文章很有深度， 这里给一个链接 mp.weixin.qq.com/s/-xiWjPRiRsPcxODnJ3921Q

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

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

这种量级，考虑一下，HTTPS 能否降级成 HTTP ，光证书流量就节约非常多。如果计划响应结构变为 protobuf ，那么 gzip 的效果就很一般了。

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

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

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

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

楼主说请求都是实时的，估计用 br 很难，这算法太慢了。zstd 可以，gzip 也可以。

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

1. 如果接口的内容是 HTML 类型的文本 br 压缩能比 gzip 高 17~30%的压缩率。 [推荐使用] www.thebyte.com.cn/http/compress.html＃_2-%E4%BD%BF%E7%94%A8-brotli-%E5%8E%8B%E7%BC%A92. protobuf 比 JSON 会一点点，但影响不大 [花大力气，换来少收益] www.thebyte.com.cn/http/protobuf.html3. 优化一下 SSL 的证书 [花大力气，换来少收益] www.thebyte.com.cn/http/ssl.html

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

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

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

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

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

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

＃27 这个方案云商提过，找出最大的流量方，直接跟他家的服务器扯根网线，前提是对方要同意。 ＃15 目前用的就是 HTTP ，没用 HTTPS ＃10 In 和 Out 占比 1 : 1.2 吧，Out 的流量使用确实不取决于我们，目前在考虑节省 In 的流量。阿里 200Mbps 不收费这个确定吗？那我多扯几根，每个都不超过 200M ，阿里不得亏死。。。情况补充：1. 纯接口请求响应流量费用，不包含前端静态资源。2. 目前只用到了 HTTP ，没用 HTTPS 。3. 业务是 ADX 平台，出口和入口流量都比较大。

不要用 protobuf ，用无需自解释的协议，比如 flatbuffer 或者 capnproto ，可以省去一大波结构描述类的开销。另外 graphql 真的省带宽，按需给字段很重要的。还有你需要 zstd 。

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

＃29 你找阿里云确认下呢，应该也有个总带宽上限，并不是无上限的，注意需要 Ecs 绑定公网 IP ，流量不要走网关，网关好像是 max(in, out) 计费的，原理就是实际上阿里云上的业务大多数是 Out 多，所以运营商跟阿里云结算也是以 Out 结算的，In 实际上不收费我们的业务也是 In 流量大，之前调研方案的时候找阿里云了解到这个信息，不确定是否通用另外你们 In：Out 比例 1:1.2 的话，按带宽计费的话，我记得是 Max(In, Out) 哪个大计哪个的（ 95 峰值），不应该 In/Out 都分别计费啊？

＃29 help.aliyun.com/zh/ecs/product-overview/public-bandwidth
用 hetzner ，每台 20T 免费流量。然后用 DNS load balancing 做集群，把分散流量到每台机器。

网络的提速降费...

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

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

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