ibegyourpardon

作为主功能来说确实不是很适合，但作为非主业务的补充，一些边缘化的事情，写进主单体或者部署个微服务反而头疼，如果正好用量占比又不大，云函数我觉得非常合适，我自己就有大概二三十个类似的云函数。

它们有一些共同特征，本身逻辑简单，没太多状态，放进哪个仓库或者服务都觉得不是很符合语义或者模块划分，单起个又恶心，这个云函数的服务本身甚至可有可无，也许只是个实验特性，这一类我现在优先会选择用个简单的云函数快速跑起来，先满足了业务需求再说。

当然云函数也有一些问题，本身写起来如果依赖的东西多，放云函数里跑限制一堆，很麻烦，数量也很容易暴涨。但数量保障我觉得就是没规划好，说明不是一些适合放到这里面的服务。

我大概二三十个，有的一两年前的我都快忘了代码了，真要更新迭代我十有八九不会去修改这个云函数，而是去直接快速重写一个，很大可能一天内就搞定了。这也是我会把云函数用的地方，有一些属于不需要长期更新迭代，但会长期使用的轻量级业务，我都会扔进去。

而一个足够大型的系统，十有八九总能找到这样一些类似的边缘的业务。当然要不要上云函数那是见仁见智。

我这周才刚又写了一个近似于采集系统的东西，非典型业务，不适合抽象起来放进现有架构，又急需，以后又基本没什么更新，用量不大，一天目测就几百次调用，这种我就是一天写完，一天测试，丢上去完事。

过几个月也许有迭代了再说，大迭代就重写拉倒。