集思广益,上司提了个需求要短时间可以扛住 200 万 req/s

2023-12-14 10:37:03 +08:00
 owen800q

先说下背景,跨境电商,主要是 tiktok 直播带货,我们是下游平台,平台技术架构是用 aws serverless lambda, api gateway 和 dynamodb

一开始 aws 是给了 3000 的 concurrency quota, 后来业务爆发性增长,年中时我们向 aws 申请加到了 5 万 lambda 并发数,本来以为应该可以应付一切了,但上星期日志出现了大量 500 internal server error, 原来是达到 5 万+了,我们问了下 aws 技术支持,说我们当天的峰值到达了 12 万+ req/s

导致大量商家无法创建下游订单, 大老板直接提了个要求是不允许再发生这种情况, 要求要扛住至少 200 万 请求

Api gateway 和 dynamodb 是没性应限制的,主要是 lambda 并发数提不上去, aws 那边说最多只能把 lambda 最大并发只能提到 100k

23833 次点击
所在节点    程序员
159 条回复
swulling
2023-12-14 14:20:13 +08:00
这个规模的请求量,不可能都是交易请求。根据#54 可以看到有很多是非交易请求。且先假设都是真实流量。

限制你的只是 AWS Lambda 的技术限制而已,这就是 Vendor Lock ,当你的用量超过了云服务商的能力,你无能为力。

解决办法也很简单,就是拆分。把你的部分服务从 Lambda 拆分到 EC2 虚拟机上就完了。
matrix1010
2023-12-14 14:21:42 +08:00
看上去 google cloud function 可以无限扩展 https://cloud.google.com/functions/docs/configuring/max-instances?hl=zh-cn
whileFalse
2023-12-14 14:22:14 +08:00
套 waf 清洗流量。
你们这么大流量 可以考虑改用 ec2/ecs 之类的架构了。
bitmin
2023-12-14 14:28:35 +08:00
@owen800q #52 分流的前提是最外层得有个东西可以接住 12 万+ 请求吧,然後再做分流?


萌新说个想法,不需要最外层有东西接住 12 万+ 请求

一种是不同 API 域名解析指向不同的服务

另一种更进一步,分发给不同调用方的相同 API 配置不同地址解析到不同的服务

在源头就分流了
XSDo
2023-12-14 14:47:26 +08:00
假设 12W 并发都是真实的,12W 并发之后瓶颈在什么地方?数据库 IO ,网络 IO ,业务逻辑计算耗时?

先定位到瓶颈在什么地方才好做,如果都没有瓶颈,无状态服务,直接无脑横向扩展服务。
dko
2023-12-14 14:50:06 +08:00
@owen800q #52 是的,一般都用 API 网关来解决,同时 API 网关也会补多套来做 LB 及调度,可以这样简单的理解:不同区域的流量进不同机房,但是这种需要拆分某些单节点的情况。
看起来你们的流量只是瞬时,并且对数据同步的要求并不是特别的高,那用分流这种方案还是比较适合的。
bthulu
2023-12-14 14:52:22 +08:00
@lbp0200 不是 128 台, 是得开 128 万台
v2orz
2023-12-14 14:53:24 +08:00
12w qps 最外层负载均衡能接的吧,LVS+Haproxy 。
不行就终极方法上 F5 ,我这里的 12w 就是这么接下来的
@owen800q
v2orz
2023-12-14 14:56:42 +08:00
额,漏了 200 万,200 万单入口感觉撑不下,从 dns 方面估计要想想办法,分线路分区域解析,然后再分接口
salmon5
2023-12-14 15:15:27 +08:00
我比较关心,你们 AWS 消费大概什么级别?¥ 9 位数/年 有了吧
GeekGao
2023-12-14 15:26:53 +08:00
你们 GMV 难道几百亿吗? 先排查是不是被攻击了
ChadGPT
2023-12-14 15:32:15 +08:00
mark 一下,围观大佬回答
shellcodecow
2023-12-14 15:32:38 +08:00
对着老板说,抬起右手,伸出中指 ,大声喊:你来做! 200w req/s ? 你来做做看
Huelse
2023-12-14 15:36:59 +08:00
这个量级没有业务问题直接加机器吧,没什么更有效的方法了
sumarker
2023-12-14 15:49:22 +08:00
既然是下游业务平台 ,200w 的 qps 完全可以做业务拆分自己维护,而不是托管在 serverless 上,然后上一套削峰限流异步处理 防止直接打到机器上……
zouywx86
2023-12-14 15:49:41 +08:00
12W 请求峰值,我感觉这个有 2 方面是可以考虑去排查下的:
1 、被攻击了;做电商被攻击太正常的,不知道是否做了这方面的处理;
2 、系统层面有无脑疯狂重试的代码;就是其中一个接口爆了之后,引发的系统级崩溃,然后有请求不断做重试,最终累积了 12w 最高请求的峰值;

至于你们老板要求的 200w 支持能力,在他的角度来说,还不算疯狂,听听就好。我当年面上过一个初创企业( 16 年),面试官上来就说我们的系统是做广告业的,要随时做好上亿请求的准备,我投去了很敬佩的目光,不知道现在他们的人数超过 10 个了没。
enihcam
2023-12-14 15:55:59 +08:00
套面试题的?
Hider5
2023-12-14 15:59:08 +08:00
关注下,我司一小时 4w 单,下单最高 tps 也就 200,12w 这得多少单啊
codersdp1
2023-12-14 16:06:39 +08:00
@enihcam 面试也不会造这么大的火箭
codersdp1
2023-12-14 16:07:38 +08:00
查看过往历史监控~是不是如果只是最近流量指数暴涨,那肯定是被攻击了。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1000267

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX