为什么我不使用Serverless
如果现在别人问你知道什么是Serverless吗？你回答说不知道，那一定会被别人说你不够潮，都1202年了，还不知道Serverless。好吧，如果你真的不知道什么是Serverless也没有关系，这篇文章我不是来科普Serverless的，要学Serverless的自行去Google学习一把。
这篇文章我主要想谈一谈Serverless现阶段存在的一些问题，以及我为什么不推荐现阶段在生产环境中使用Serverless架构的原因
如果面试有人问你什么是Serverless，这样回答就可以了：Serverless是一种架构模式，中文翻译过来是无服务器的意思，但并不是说真的不存在服务器了，只是不需要购买、管理服务器，只需要关注代码逻辑，执行结果。它最大的优势就是按需付费，毫秒级计费，以及无限扩容。
嗯，这样的回答基本上就没错了。但是，事实真的是这样吗？
我不推荐现阶段在生产环境使用Serverless架构的原因
开发者的学习负担
虽然Serverless的理念很好，让我们只关心代码的编写，只需要编写一个个函数就可以了，但其实你想将Serverless用在生产环境，有一大堆的概念等着你学习，以腾讯云云函数为例，你需要掌握了解：什么是触发器？什么是别名？什么是冷启动？什么是Web函数？什么是层？什么是容器镜像？怎么部署一个Serverless应用？等等
当你学完这些概念，算是对Serverless云函数有一个开发级别的大概了解了，你觉得这个成本高吗？真的像宣传一样只用关注代码逻辑吗？当你使用一项新技术的时候，如果它带来的收益不能远远Cover住你的成本时，我觉得这是不划算的，投入产出比很低。没关系，你说我花了时间学了新技术，还用Serverless按量付费省钱，以及无限扩容提高性能啊。
那好，接下来我就一条一条说。
传统的Serverless函数接入HTTP需要一层适配器转换
Serverless函数是由触发器触发的，你在函数内部接收到的只有一个事件（Event），这意味着，你想在函数内获取请求路径、参数都需要额外的转换，当然，这难不倒我们程序员，我们在本地还是通过HTTP访问开发，当函数需要上传到云端时，通过打包构建流程，自动在代码中加入一段适配器Proxy，帮我们做 事件-> HTTP 的转换。看起来很美好，但这无疑加重了我们的心智负担，还隐隐的埋了一个坑，当程序出现Bug时，你想调试代码，一堆很乱的堆栈会让你排查Bug无从下手。现在有一些云厂商明白了这个道理，在平台层面帮我们做了这个适配。下图是腾讯云的做法：
这样，你在本地开发和远程云端的代码就是一致的。当然，多一层抽象就意味着性能会差一点。
开发工具问题 每次上传代码要10多秒
我们每次开发完一个函数，想在云端集成测试一下，需要将函数打包上传到云厂商平台上面测试一下，这时候，烦恼来了，将代码以及依赖库全部打包成压缩包，这个体积就很大，更别说我们Node.js的npm hole，随便打包一下，代码包就超过了100MB。
上传速度可想而知，当你频繁调试代码频繁上传代码时，这感觉，贼爽，可以光明正大的喝咖啡了。
可能你会说你可以用层部署啊！
层是万能的吗？
用层，相当于我们把代码和依赖抽成两部分上传，把不频繁改动的大体积依赖抽离出来，需要改动的函数逻辑则相对体积小上传速度会快很多，这在我看来都是曲线救国，我们应该在上传前就判断出哪些文件有改动，只更新有改动的这些代码，当然，这个技术可能难度比较高，这也是为什么云厂商没有推出这个功能的原因。另外，多出一个层的概念，意味着你要随时关注层的更新，可能哪里你本地的依赖库更新了，但层忘记更新了，这时，找Bug的痛苦会让你永生难忘。多出的概念意味着你的心智模型要考虑的事情更多了。
冷启动问题
当你的函数首次运行时，云厂商需要初始化平台配置，配置弹性网络，拉取镜像，拉取用户代码，初始化运行时，执行函数。 总共的耗时没有你想像得那么快，极端情况可能达到10秒。
如果用户访问的是一个接口，会不会觉得你的系统挂了。如何避免函数的冷启动是一门学问，要对函数资源，以及云厂商的特性了解十分到位，比如腾讯云的解决方法是预置并发，阿里云是预留实例，所以，当你用了一些优化方案后，你可能就被某一云提供商绑定死了。而且，这些方案都是有成本的，成本就是你要用预留实例，你的费用就上来了。
函数费用问题
我们知道，使用虚拟机的费用是确定的，而函数嘛，是按量付费的，意味着你只能估算出一个月大概多少费用，函数的收费的公式是：
费用 = 函数内存配置大小*运行时间
的确是按次收费，但根据实际测试，当你的虚拟机利用率达到一定程度时，费用就比使用函数少了，随你的虚拟机利用率的提升，这个差额会越来越大，所以，想办法提升你虚拟机的利用率吧，用不了那么高的配置就降低一点，这成本不就降下来了吗。
其实函数费用这里还有一点特别要说的就是，想把函数费用降下来，你需要对你的函数划分的颗粒度有很好的规划，比如你有10个函数，其中只有一个函数需要用到大内存，那如果你将10个函数一起打包上传，那收费就是按这个最大内存来收取的了，拆成10个函数也不好，颗粒度太细，不利用维护。理想的方式是拆成两个函数，即使用相近内存的函数拆分在一起。但，这无疑又加重了我们的心智负担。
性能问题
理论上是无限弹性扩容，但实际上各云厂商都有自己的并发上限，也就是说并不是无限扩容。
以腾讯云为例：
在地域维度，每个账号的弹性并发的扩容速度默认限制为500个/分钟，即在1分钟内，最多可以启动500个新的并发实例。
不仅支持的请求是有上限的，包括函数的个数，触发器的个数等等都是有上限的。当然，这样也是有好处的，当你被攻击时，函数的费用不致于让你直接破产。有时间可以用你的应用测算一下，支持同等并发的虚拟机的费用是多少。
你以为的Serverless只是计算 其实我们需要的是一系列的生产可用工具
把函数上传到云平台就万事大吉了吗？这可不是大学做项目，应用挂了重启下就解决了，反正没什么用户。真正的商业应用，宕机一分钟，那损失的可是真金白银和我们的口碑啊，所以一定要保证生产就绪，我们需要好用的开发工具，测试，在线调试，跑性能，看日志，查监控，调用链，限流，熔断等一系统生态，而这些功能，云平台只提供一个非常简陋的解决方案，单这里面的任何一个节点，都可以拿出来做一个超大项目了。所以云函数想走得更远，怎么提供这一系列的生产可用工具是个大问题。
其它一些小问题
Serverless 依赖安装要和线上环境一样，当你需要安装一些和系统相关的依赖时，你需要和云平台保持一致，这无疑又是一大难题，虽然云平台内置了一些主流依赖，但版本比较旧。如果你使用自定义镜像部署，那你最好把你的镜像大小优化好，不然镜像上传时间够你喝一壶了。
对Java，PHP这类重运行时的语言支持不好，如下腾讯云描述：
Java 语言由于需要编译后才可以在 JVM 虚拟机中运行。因此在 SCF 中的使用方式，和 Python、Node.js 这类脚本型语言不同，有如下限制：
- 不支持上传代码：使用 Java 语言，仅支持上传已经开发完成，编译打包后的 zip/jar 包。SCF 环境不提供 Java 的编译能力。
- 不支持在线编辑：不能上传代码，所以不支持在线编辑代码。Java 运行时的函数，在代码页面仅能看到再次通过页面上传或 COS 提交代码的方法。
Node.js，Python是云函数的重点语言，但这两个语言都有自己的局限性，很大程度也限制了云函数的边界。
BasS层，Serverless数据库靠谱吗？不靠谱，现阶段很不靠谱，我自己试用了一下，数据库也按量付费是非常好的理念，但如果遇到冷启动，数据库启动时间可以长达1分钟，这我实在没法接受。
你会用Serverless吗
说了这么多，你会用Serverless吗?
我觉得现阶段去了解它，学习它，拓宽自己的知识面，是非常不错的，但是用到生产环境，我是不推荐的。
玩玩可以，千万别认真。
我承认我是有在用Serverless的，但仅限于一些简单的应用，现阶段Serverless在一些旁路需求还是很有价值的，比如视频转码，直播录制，文件处理，跑跑离线数据，搭搭个人博客。如果你有这方面的需求，用Serverless是可以节约很多成本的。
期待Serverless生产可用的一天早日到来。
Serverless Go Go Go.