1
opengps 2020-04-16 12:45:23 +08:00
函数是按次数收费,用的少显然用他更合适
服务器是自己的资源,按时长预付费或者后付费,访问多建议选这个 另外,你用处要是想拓展到函数级别之外,比如装个数据库,装个缓存,装个其他东西等等,那么毫无疑问回到具备独立系统的服务器路线上去 |
3
binux 2020-04-16 13:19:14 +08:00 via Android
你自己算
|
4
opengps 2020-04-16 13:20:14 +08:00 via Android 1
@bonfy 这种问题的临界点比较难确定,因为直接受到定价规则影响,及时确定了也只能是个模糊范围,你刚开始用就照着函数方向去做吧,等你的支出费用,等于养一台服务器费用时候,就到了临界范围内科
|
5
neoblackcap 2020-04-16 13:24:49 +08:00 1
函数是有固定单次的运行时间的,如果太长了就需要额外收费或者被干掉。你在上之前,最好先压测一下自己的程序,看看 lambda 能不能满足
|
6
aec4d 2020-04-16 15:15:04 +08:00 1
在美区上我有一个 lambda 服务,具体是请求的时候把 s3 的图片转码成 webp
千万不要想着这东西能节约成本!!!从成本上来说并不比部署一个 ec2 便宜(aws 最便宜的 lightsail 五刀一月能满足需求) 但是省去了运维成本。部署运行了两年没管过 它适合无状态短时间运行的任务 另外这东西强绑定,你适应 lambda 写了一套程序,不能无缝转到别的提供商上面,写常规程序就不会有这个问题 |
7
nrtEBH 2020-04-16 15:17:26 +08:00 1
比较推荐是用 API Gateway+Lambda
是否要上 EC2 看你业务的复杂程度是否超出 Lambda 限制 |
8
xiaket 2020-04-16 17:13:53 +08:00 1
如果是 Cloudformation 部署的话我都要推荐 ALB + lambda 了, APIGW 的 Cloudformation API 实在是恶心人. 当然费用方面会有区别.
|
9
xiaket 2020-04-16 17:16:12 +08:00
你这个属于没好好看过价格表就来问问题, 因为 lambda 的计费是和内存大小, 运行时间长短直接相关的, 不了解你的业务情景完全没法回答.
|
10
bonfy OP @xiaket 谢谢
内存 就选最小的就可以了, 很简单的逻辑,担心的是一个是 高并发下 concurrency 会不会不够? 然后导致服务延迟, 另外就是每天多少访问量的时候 其实 就整台 EC2(配置凑合就行) 还可能便宜点? 因为现在是估算,如果已经这么大并发我看看实际 cost 心里就清楚了,估的话 心里没有底,服务都还没开始用了 |
11
lzuntalented 2020-04-16 17:25:01 +08:00 1
正在薅 aws 免费一年的 ec2,不知道一年后价格如何
|
12
fredcc 2020-04-16 17:25:12 +08:00 1
都试试看最简单了
|
14
bonfy OP |
15
xiaket 2020-04-16 17:28:58 +08:00
如果这么有自信, 直接先上 lambda 跑一两个月看看效果, 高并发 concurrency 不由你管, AWS 会负责多起几个实例, 如果你实在不放心, 还可以设置 ReservedConcurrentExecutions, 比如至少有 1 个或两三个 lambda 实例一直在那儿.
因为云服务的好处在于你不用想着绑定, 觉得不开心觉得不划算, 切到另外一种也行, 反正试错成本低 |
16
xiaket 2020-04-16 17:31:04 +08:00
@bonfy 如果是做方案, 也可以拿负载过来, 两边都搭好, 都跑几天, 看看成本. Cost Explorer 里面都看得到的.
另外, 不是用两台 EC2, 而是用一个 ASG, 而且正常的话, 前面放一个 ALB 比较好(除非成本控制要求真的很高). |
17
xiaket 2020-04-16 17:32:15 +08:00
另外, EC2 里面的选择题也不少, 实例用 t 还是用 m 还是用 c, 都可以玩好久...(逃)
|
18
bonfy OP @xiaket 担心的是 每个账号的 concurrency 好像默认是 1000 而且不是就跑一个服务,应该是 已经有很多服务都跑在那个账号了, 所以担心并发高的时候 真有可能会耗完
而且 1 个 lambda 实例同时能处理几个 request ? 是一个么?? 我没理解错吧? |
19
bonfy OP |
20
xiaket 2020-04-16 17:37:58 +08:00
那个 concurrency 是单独对 lambda 而言的, 其他服务也是用 lambda 的话会有影响, 不过这个 limit 是可以找客服调的, 客服也很乐意帮你调. 就我的理解, 这个 limit 更多是避免新手犯错误导致接到一个很大金额的账单而设置的.
一个 lambda 实例的确只能处理一个 request, 不过可以不用太考虑 scaling 的问题, 因为从服务设计来说, 这不是你需要操心的问题. :) |
21
xiaket 2020-04-16 17:40:54 +08:00
@bonfy 我理解的, 这种提方案不能做决策实际上挺恶心人的. 另外建议方案里面提下后面的维护成本的区别. 前面有位同学说过, lambda 基本上是不需要运维成本的.
老实说我觉得更好的方案是 EKS/ECS 跑容器, 前面接 ALB... 这样能够在运维成本和运营成本之间有一个平衡 |
24
hotsymbol 2020-04-17 00:39:42 +08:00 1
AWS Fargate(Spot) + AWS API Gateway
|
25
vcfvct 2020-04-17 01:53:05 +08:00 via iPhone 1
还应该考虑 lamdab 的 cold start time (尤其 jvm 之类) nodejs/python 稍微好些。为了保持 hot 还得用 cloudwatch 或者 alb 之类去 ping 它,这样也只能保持一个 instance hot 。对于要求 low lantency 和 high concurrency 的服务来说,lambda 不太适合. 尤其如果你的 lambda 在 vpc 里面(要连 rds/redis 之类)还得考虑 ENI 的 creation/attach time, 就更要命了!
不过一般的 api 用 lambda 确实超级省心,不用维护 runtime !费用也是无敌! |
26
lihongming 2020-04-17 01:55:55 +08:00 via iPhone 1
我玩了 10 年 PHP 后,彻底转向了 Serverless,虽然管理服务器对我来说轻车熟路,但仍然觉得浪费时间,有那时间还不如写点业务代码或者美化一下 UI 更有价值。
更何况 Node 开发速度比 PHP 快,进一步节约了时间。 |