在 AWS 上建 Restful API 选择 Lambda 还是 EC2 呢？

• 資深大佬 : opengps

  函数是按次数收费，用的少显然用他更合适
  服务器是自己的资源，按时长预付费或者后付费，访问多建议选这个

  另外，你用处要是想拓展到函数级别之外，比如装个数据库，装个缓存，装个其他东西等等，那么毫无疑问回到具备独立系统的服务器路线上去

• 主 資深大佬 : bonfy

  @opengps 谢谢

  数据库 缓存 其它东西都不考虑 每天大概多少次访问量 是零界点？ 有研究过么？ 假设访问是平均的

• 資深大佬 : binux

  你自己算

• 資深大佬 : opengps

  @bonfy 这种问题的临界点比较难确定，因为直接受到定价规则影响，及时确定了也只能是个模糊范围，你刚开始用就照着函数方向去做吧，等你的支出费用，等于养一台服务器费用时候，就到了临界范围内科

• 資深大佬 : neoblackcap

  函数是有固定单次的运行时间的，如果太长了就需要额外收费或者被干掉。你在上之前，最好先压测一下自己的程序，看看 lambda 能不能满足

• 資深大佬 : aec4d

  在美区上我有一个 lambda 服务，具体是请求的时候把 s3 的图片转码成 webp
  千万不要想着这东西能节约成本！！！从成本上来说并不比部署一个 ec2 便宜(aws 最便宜的 lightsail 五刀一月能满足需求)
  但是省去了运维成本。部署运行了两年没管过
  它适合无状态短时间运行的任务
  另外这东西强绑定，你适应 lambda 写了一套程序，不能无缝转到别的提供商上面，写常规程序就不会有这个问题

• 資深大佬 : nrtEBH

  比较推荐是用 API Gateway+Lambda
  是否要上 EC2 看你业务的复杂程度是否超出 Lambda 限制

• 資深大佬 : xiaket

  如果是 Cloudformation 部署的话我都要推荐 ALB + lambda 了, APIGW 的 Cloudformation API 实在是恶心人. 当然费用方面会有区别.

• 資深大佬 : xiaket

  你这个属于没好好看过价格表就来问问题, 因为 lambda 的计费是和内存大小, 运行时间长短直接相关的, 不了解你的业务情景完全没法回答.

• 主 資深大佬 : bonfy

  @xiaket 谢谢

  内存 就选最小的就可以了， 很简单的逻辑，担心的是一个是 高并发下 concurrency 会不会不够？ 然后导致服务延迟， 另外就是每天多少访问量的时候 其实 就整台 EC2(配置凑合就行） 还可能便宜点？

  因为现在是估算，如果已经这么大并发我看看实际 cost 心里就清楚了，估的话 心里没有底，服务都还没开始用了

• 資深大佬 : lzuntalented

  正在薅 aws 免费一年的 ec2，不知道一年后价格如何

• 資深大佬 : fredcc

  都试试看最简单了

• 主 資深大佬 : bonfy

  @xiaket 当然要整 多台 EC2 （至少 2 台） 怕宕

• 主 資深大佬 : bonfy

  @fredcc

  自己的也就算了，一个月差这么点也无所谓， 就是 帮人家做方案 才麻烦啊 （算多了也不是 算少了也不是 还要对比）

• 資深大佬 : xiaket

  如果这么有自信, 直接先上 lambda 跑一两个月看看效果, 高并发 concurrency 不由你管, AWS 会负责多起几个实例, 如果你实在不放心, 还可以设置 ReservedConcurrentExecutions, 比如至少有 1 个或两三个 lambda 实例一直在那儿.

  因为云服务的好处在于你不用想着绑定, 觉得不开心觉得不划算, 切到另外一种也行, 反正试错成本低

• 資深大佬 : xiaket

  @bonfy 如果是做方案, 也可以拿负载过来, 两边都搭好, 都跑几天, 看看成本. Cost Explorer 里面都看得到的.

  另外, 不是用两台 EC2, 而是用一个 ASG, 而且正常的话, 前面放一个 ALB 比较好(除非成本控制要求真的很高).

• 資深大佬 : xiaket

  另外, EC2 里面的选择题也不少, 实例用 t 还是用 m 还是用 c, 都可以玩好久…(逃)

• 主 資深大佬 : bonfy

  @xiaket 担心的是 每个账号的 concurrency 好像默认是 1000 而且不是就跑一个服务，应该是 已经有很多服务都跑在那个账号了， 所以担心并发高的时候 真有可能会耗完

  而且 1 个 lambda 实例同时能处理几个 request ？ 是一个么？？ 我没理解错吧?

• 主 資深大佬 : bonfy

  @xiaket #16

  这个是最好的方法 但是对于 部署这样的对比方案 其实没有最终的拍板权 （没权）

  现在就是在啥都不知道的时候 出个方案 给别人做选择 就是这么卑微

• 資深大佬 : xiaket

  那个 concurrency 是单独对 lambda 而言的, 其他服务也是用 lambda 的话会有影响, 不过这个 limit 是可以找客服调的, 客服也很乐意帮你调. 就我的理解, 这个 limit 更多是避免新手犯错误导致接到一个很大金额的账单而设置的.

  一个 lambda 实例的确只能处理一个 request, 不过可以不用太考虑 scaling 的问题, 因为从服务设计来说, 这不是你需要操心的问题. 🙂

• 資深大佬 : xiaket

  @bonfy 我理解的, 这种提方案不能做决策实际上挺恶心人的. 另外建议方案里面提下后面的维护成本的区别. 前面有位同学说过, lambda 基本上是不需要运维成本的.

  老实说我觉得更好的方案是 EKS/ECS 跑容器, 前面接 ALB… 这样能够在运维成本和运营成本之间有一个平衡

• 主 資深大佬 : bonfy

  @xiaket #21

  对，这个 EKS 或者 自建 k8s 在方案里已经列为长远方案了，暂时先不搞，所以先不考虑

• 資深大佬 : fredcc

  @bonfy 帮人家做方案更加得实测啊

• 資深大佬 : hotsymbol

  AWS Fargate(Spot) + AWS API Gateway

• 資深大佬 : vcfvct

  还应该考虑 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 ！费用也是无敌！

• 資深大佬 : lihongming

  我玩了 10 年 PHP 后，彻底转向了 Serverless，虽然管理服务器对我来说轻车熟路，但仍然觉得浪费时间，有那时间还不如写点业务代码或者美化一下 UI 更有价值。

  更何况 Node 开发速度比 PHP 快，进一步节约了时间。

• 主 資深大佬 : bonfy

  @fredcc

  我也想实测，但是 事实就是 有些东西就只有概念 但需要你什么都要估