这是一个创建于 526 天前的主题，其中的信息可能已经有所发展或是发生改变。
一直对类似服务心生好感，正好准备部署一个新的服务，就拿阿里云函数计算试试手，结果发现，这玩意儿就是个半成品嘛，吐槽几个细节，仅代表个人观点哈
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 性能表现，那就也很呵呵了，鉴于我忘记保存一下测试结果，就不多说了
目前尚无回复
Select Language