问题复现
3月17日早上，发现unicloud阿里云的服务空间，全部停止服务了，一看原因是欠费了，又看了一下消费账单，天塌了，平时消费日均0.4元，17号账单4元，消费翻了10倍。
第一感觉就是又被人攻击产生了额外的消耗，紧急报障后才知道，阿里云服务空间云函数计费规则调整了，公告如下：【公告】uniCloud阿里云服务空间云函数计费规则调整通知。
核心意思就是：新增⼩时级最低消费规则
这个公告主要介绍的是云函数资源使用量（GBs）的调整，云函数调用次数、流量等没有变化，有些小伙伴对资源使用量（GBs）不了解，看一下官方的介绍。
资源使用量（GBs）
资源使用量 GBs = 函数配置内存 GB × 运行计费时长 s。 例如，配置为 256MB 的函数，单次运行了 1760ms，计费时长为 1760ms，则单次运行的资源使用量为(256 / 1024) × (1760 / 1000) = 0.44GBs
原来时候，按照天算，如果你创建的是一个低频调用的云函数/云对象，一天内只要有一次调用，保底低消也就0.01元，按照上面的公式调用个几十次，只要在90GBs之内，那一天就是0.01元，所以之前根本就无感知，就觉得太便宜了。
但是调整之后是1小时统计一次了，这样在一小时内被调用一次，那就产生0.01元的低消，0.01*24 = 0.24，这样一个云函数一天就可能产生0.24元的低消，如果你服务空间中有10几个这样的函数，那一天就2块钱，一年下来就600块钱，比常规配置的轻量云服务器都要贵很多。
所以在公告评论区怨声载道，本来选择unicloud云开发就是冲着便宜去的，做个小项目可以用最小的成本上线测试项目成果，现在上线的程序的公告费收入都抵不上服务空间的开支，有些小伙伴到阿里云官方投诉、黑猫投诉等，收效甚微。
解决方案
有不少小伙伴入手uniCloud是看过我的教程入手的，阿里云搞这么一出我也是比较头疼，有很多小伙伴来问我有没有办法；
毕竟阿里云是商业公司肯定是以盈利为目的，像原来那样白嫖的时代已经过去了，所以和官方大佬一直保持沟通，最后有这么几种方法，大家可以尝试进行修改，看一下是否能够降到你可以接受的价位区间。
1.删除或降低云函数定时任务
官方的uni-admin及uni-starter内置定时任务如下：
uni-stat-cron：uni 统计，每小时运行 1 次，删除可节省 1 天的保底费用 0.24 元（2160Gbs）
uni-analyse-searchhot：热点搜索，每 2 小时运行 1 次，删除可节省 1 天的保底费用 0.12 元（1080Gbs）
就是因为有定时触发的函数存在，所以有些小伙伴就反馈，我项目没上线没有用户访问为什么每天还消耗这么多资源那，罪魁祸首就是他俩，如果你不想要如下数据统计的话，完全是可以删掉这两个函数的定时触发器的。
如果你业务中之前就设置了定时触发，看一下频率是否从原来的1个小时，换到时间更长一些。
有小伙伴会问，我原来是10分钟定时触发一次，改成1小时触发一次会不会省钱，其实这个就不需要改了，1小时触发6次和1小时触发1次，都会触发低消了，就没必要改了。
* 2.合并云函数/云对象
这个方法是最推荐最实际的了，无非就是花点时间，但是收效最明显的，以我自己的"咸虾米壁纸"项目为例：
原来的思路是为了业务清晰好维护，将如下云对象"xxm-bizhi-client-picture（壁纸列表及详情逻辑）"、"xxm-client-user-action（用户下载评分逻辑）"、"xxm-bizhi-client-quick（排行榜逻辑）"、"xxm-bizhi-client-subject（专题页逻辑）"，原来是独立在不同云对象中的，现在直接将这4个合并成1个云对象了，如果你原来开发的时候思路是一致的，合并起来用不了多久就能完成，主要是测试一下有没有bug。
合并完成之后，单服务空间，由原来的日均1.8元，降到了日均1.3元，后续再合并一下其他业务类似的云对象，我觉得单服务空间降到1元以内是我可以接受的，不知道大家对这个方案有什么建议。
有小伙伴可以会觉得，把很多的函数都放到一个大云对象中，会不会存在问题那？
问题是肯定存在的，总结三点：
- 1.函数太多不宜读，这是显而易见的问题，不过现在有了AI写代码之后这个问题反而成了优势，因为在所有的函数都在一个云对象中了，AI在读上下问的时候更方便，更能了解你的写法习惯，生成的代码更适合于你。
- 2.如果云对象中出现一个函数出错，可能影响整个项目的运行，有点类似单体项目和微服务的概念了，原来分开多个云对象的时候，某一个出错，不影响其他的，现在一蹦全崩，好处是出了错也好定位到哪一块代码了，也不算坏事。
- 3.对一些请求差异比较大的函数，可以在_before钩子里面做很多额外的判断，所以基于这个问题，就不要将差异过大的函数放在一起了，尽量合并功能类似的函数进行合并。
3.从阿里云转到支付宝云
这个方案的成本有点大，而且支付宝云的bug也很多，同样一个查询，在阿里云可以运行，支付宝云就无法执行，最关键的是提交的bug之后，修复周期太长，可以看我之前发的帖子就知道了，24年提的bug貌似26年还没修复，支付宝云为什么不支持JQL常用运算方法？，支付宝云虽然很优秀，基于这种情况所以我放弃了使用支付宝云。
所以你说从阿里云这个坑再跳到另一个坑去，有这个必要吗，而且你还无法保证搬家完了之后，支付宝云是不是也要涨价，毕竟都属于阿里旗下。
如果你执意要搬还想省力的话，可以从插件市场搜一下vk大佬的一键搬家迁移工具，不过是收费的也不是很贵，起码省事啊。
4.修改云函数执行内存
在最上面给大家看GBs计算公式了， 资源使用量 GBs = 函数配置内存 GB × 运行计费时长 s
可以在云函数的环境信息中，修改函数执行内存，一般默认是512MB，如果调用量不是很大的云函数，这个方案也是可以省钱的，但是收效不大，可以尝试。
不建议的方案
有小伙伴抖机灵的认为，既然创建的云函数有低消，那么我直接从客户端查询数据库不就完了，直接跳过云函数，朋友，你想到的人家厂商早就想到了，所以在你的云函数列表中增加了一个"DCloud-clientDB"，不支持修改和删除。
这个函数是干嘛的那，客户端调用数据库走的是DCloud-clientDB这个云函数，所以不要想着绕过云函数的计费，直接在客户端调用数据库，这种也是要有低消的，所以还不如将之前写在客户端内的请求，统一放到一个大云对象中。
结语
如果有更好的方案，给我留言哈，继续给大家进行分享。