一直对类似服务心生好感,正好准备部署一个新的服务,就拿阿里云函数计算试试手,结果发现,这玩意儿就是个半成品嘛,吐槽几个细节,仅代表个人观点哈
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 性能表现,那就也很呵呵了,鉴于我忘记保存一下测试结果,就不多说了