当下情况
有个项目,部署在某家上市云商中,接口大概每天 20 亿左右的请求响应,流量费用在服务器架构中占比较高,目前已经实施了 2 种优化方案,请问有没有更好的优化方案推荐?
目前已经做过的优化方案
暂不考虑的方案
有想法还未实现的方案
请教
1
Ipsum 216 天前
日 20 亿,恕我直言,已经打败了 99.99999%的群友了。
|
2
dragonfsky1 216 天前
日 20 亿 还需要考虑流量费用吗,这种直接升级按口子计费的
|
3
javalaw2010 216 天前 1
如果场景允许的话,先上个限流,避免下游无节制调用接口。
如果是收费接口,提高费用,下游会自己想办法做缓存。 如果场景允许静态化,那改成生成 json 文件分发到 CDN ,CDN 一般价格好谈一点。 |
4
yuandj OP |
5
yuandj OP |
6
northbrunv 216 天前 via Android
使用按带宽计费(不限流量)的服务器。如果你使用按流量计费的,成本很高
|
7
supersadmin 216 天前
蹲一个解决方案。
|
8
supersadmin 216 天前
日均 2 亿请求,之前测试使用按量计费比包月贵,现在直接包月了。
|
9
mightybruce 216 天前
如果你们技术过硬, 可以考虑修改服务使用 HTTPP3/QUIC 协议, 要考虑云商的各个组件是否支持(尤其是负载均衡)。
HTTP3 复用 比 HTTP2 更好,也更加节省流量。 其他很多方面,托管云是做不了太多的, 看是否能够对 linux 内核参数做一些调整 |
10
vivisidea 216 天前
|
11
xueling 216 天前
1 、使用 snappy/gzip 实时压缩;
2 、使用枚举 ID 代替不必要的文本传输,减少类似描述信息等文本内容的传输,数值类型参数不要使用字符串,键值也可以使用 id 替代; 3 、使用字节流类型接收和返回数据,根据二进制位自定义传入和返回数据协议(最好统一封装 http 请求和解析工具类给交互方); 了解一下我的开源项目: https://github.com/xl-xueling/xl-lighthouse 实时监控接口数据传输量,便于衡量优化效果。 |
12
mightybruce 216 天前
|
13
Kinnice 216 天前
1. 首先看看你们流量峰值和流量模型
2. 可以开低带宽计费机器来和流量计费负载均衡一下,流量计费基本是 95 ,这样负载一下可能要便宜不少 3. 接口可以改 json => grpc 4. gzip => br |
14
matrix1010 216 天前
要不你先说说业务是什么类型? No Silver Bullet 和 XY problem 大家都懂。具体问题具体分析,说不定直接 client side cache 一下都不用发请求
|
15
gam2046 216 天前
这种量级,考虑一下,HTTPS 能否降级成 HTTP ,光证书流量就节约非常多。
如果计划响应结构变为 protobuf ,那么 gzip 的效果就很一般了。 |
16
duan602728596 216 天前
什么,居然没开 gzip 吗? https 也可以尝试 br 压缩,效果更好
|
17
GeekGao 216 天前
思路:
使用 Protocol Buffers 代替 JSON ,以减少数据传输量。 使用 CDN ,将静态资源和 API 响应缓存并且靠近用户交付,以降低延迟和提高响应时间。 在 API 层集成缓存机制,快速提供缓存数据,减轻后端系统负担,改善响应时间。 采用现代网络协议,如 HTTP/2 ,减少建立新连接的开销,提高网络效率。 优化数据库查询,避免检索不必要的数据,减少网络流量,提高性能。 优化日志收集,仅收集和保留必要的日志数据,优化日志分析成本。 考虑其他压缩算法,如 lz4 、snappy 或 zstd ,以提高压缩性能。 |
18
zeusho871 216 天前
买那种大宽带机房 我这每天 20e 可能没有 几千万还是有
就那种大宽带服务器 500m 上下行拉满的 比阿里云便宜 然后作为缓存层通你你现在阿里云的服务 这样流量基本不计 如果还想便宜就移动大带宽的比电信便宜更多 |
20
tool2dx 216 天前
|
21
northbrunv 216 天前 via Android
机房托管,1g 带宽 5000-8000 左右,单线 bgp 价格不同
|
22
isno 216 天前 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 |
23
scys 216 天前
找云商谈优惠 这个最实际。
|
24
milzero 216 天前
@mightybruce #12 等看完,再实践,OP 可能都被裁了!
|
25
cjd6568358 216 天前
1.通用方案
前端底层使用 websocket 代理业务层接口,传输使用 gzip 压缩。 2.业务层改造 参考 osi 模型协议,用 bit 位来表示业务减少传输数据体积。 |
26
seth19960929 216 天前
|
27
hongfs 216 天前
某家上市云商是谁,可以参考下拼多多,走内网来链接,费用会降低些。
|
28
zizon 216 天前
看 request/response 的大小是什么区间了.
如果不大的话相比可能 HTTP 协议本身的 overhead 就很冗余,可以考虑换协议. |
29
yuandj OP |
30
wdhwg001 216 天前 via iPhone 1
不要用 protobuf ,用无需自解释的协议,比如 flatbuffer 或者 capnproto ,可以省去一大波结构描述类的开销。
另外 graphql 真的省带宽,按需给字段很重要的。 还有你需要 zstd 。 |
31
wdhwg001 216 天前 via iPhone
补充一条,合理的缓存策略也很重要,很多请求是不需要疯狂刷查询的,oauth 之后给每个 token 做一下 rate limit 很重要。
|
32
vivisidea 216 天前
@yuandj #29 你找阿里云确认下呢,应该也有个总带宽上限,并不是无上限的,注意需要 Ecs 绑定公网 IP ,流量不要走网关,网关好像是 max(in, out) 计费的,原理就是实际上阿里云上的业务大多数是 Out 多,所以运营商跟阿里云结算也是以 Out 结算的,In 实际上不收费
我们的业务也是 In 流量大,之前调研方案的时候找阿里云了解到这个信息,不确定是否通用 另外你们 In:Out 比例 1:1.2 的话,按带宽计费的话,我记得是 Max(In, Out) 哪个大计哪个的( 95 峰值),不应该 In/Out 都分别计费啊? |
34
teaegglove 216 天前 via Android
用 hetzner ,每台 20T 免费流量。然后用 DNS load balancing 做集群,把分散流量到每台机器。
|
35
Nicklove 215 天前
网络的提速降费...
|
37
EthanLau 215 天前
我们也有类似问题,量级比你们多一些,目前也没啥优化的空间了,如果双方都是阿里云的话,同一地域的能直接建一个对等连接走内网,对方肯定也乐意。
再怎么优化,不如商务谈一个低的折扣来的香 |
38
kaf 215 天前
有试过 95 带宽计费吗,既然带宽和按量差不多,95 带宽服务侧再优化一下流量峰值,应该能薅出一点羊毛
|
39
Nicklove 214 天前
@hongfs "家用带宽白菜价",难道你想说家用带宽都是亏本在卖?以腾讯云为例,1mbps 带宽的月费是 20 元,50mbps 带宽的月费是 4165 元,那你就觉得商用带宽这样就现实了?网络的成本当然需要有人来承担,我不能既承担了成本,还要理解运营商吧。
|
40
Nicklove 214 天前
补充一下,包月带宽如此,按流量计费是¥0.80/GB
|
41
voidmnwzp 213 天前
哥们,你耳聋好了没
|