V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Recommended Services
Amazon Web Services
LeanCloud
New Relic
ClearDB
ShuWei
V2EX  ›  云计算

吐槽两句阿里云函数计算

  •  
  •   ShuWei · 2022-11-15 22:06:14 +08:00 · 1564 次点击
    这是一个创建于 750 天前的主题,其中的信息可能已经有所发展或是发生改变。

    一直对类似服务心生好感,正好准备部署一个新的服务,就拿阿里云函数计算试试手,结果发现,这玩意儿就是个半成品嘛,吐槽几个细节,仅代表个人观点哈

    1 、http 函数,居然在 response head 里面附加一堆乱七八糟的东西,连我函数的执行时间、消耗内存数量、函数实例 ID 都要爆出来,重点是还不给删,脑袋被门夹了吧,谁想看到这些东西了。真实影响不太大,看着很闹心,想锤负责设计的那个人

    2 、冷启动效率,一般情况下几百毫秒到一两秒,勉强能接受吧,但是有时候会飙到四十秒或更长,提交工单,说是因为我开了 vpc ,所以冷启动效率就这么差,心里一大堆草泥马奔腾

    3 、没有函数间直接访问的方式,假如我把一个处理流水分成 A 、B 、C 三个函数,他们之间是没办法分别相互访问的,除非调用外网的 openAPI 。

    4 、延时,挂载 vpc 之后,函数去访问 vpc 内其他服务,比我从 ecs 去访问,是有明显的延时增长的,而且延时很不稳定,测试的时候,我去访问 redis ,一次连接的延时增加,有时候增加 1-2 毫米,有时候增加几十毫秒,跟我函数单独的负载似乎没有关系,是因为底层服务太过于超售?就跟冷启动效率不稳定一样,可重点是你很贵啊,为啥要超售这么严重呢?

    5 、用 ecs 的价格来大概预估,函数计算的 vCPU 价格大概是 ecs 的 2.6 倍,内存价格大概是 ecs 的 2 倍

    我想拿来试手的服务,大概就是接受 http 请求,做完鉴权之后,需要新建或修改一条记录,这个时候记录的 id 需要从 redis 取一下(为了避免并发时出现重复,redis 里面数据由发号器定时写入),最终数据需要写入数据库,成功之后,调用另一个函数处理接下来的业务流程。本意是想分成四个函数部署,鉴权函数、业务函数、发号器函数,然后,就发现不能互访,冷启动很慢,内网延时增加且不稳定,最终测试下来,糟心得很,基本就告别了

    其实我还大概测试过 cpu 性能表现,那就也很呵呵了,鉴于我忘记保存一下测试结果,就不多说了

    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1024 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 21:03 · PVG 05:03 · LAX 13:03 · JFK 16:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.