Serverless所存在的问题有哪些呢？

1 不适合长时间运行应用 Serverless 在请求到来时才运行。这意味着，当应用不运行的时候就会进入 “休眠状态”，下次当请求来临时，应用将会需要一个启动时间，即冷启动时间。如果你的应用需要一直长期不间断的运行、处理大量的请求，那么你可能就不适合采用 Serverless 架构。如果你通过 CRON 的方式或者 CloudWatch 来定期唤醒应用，又会比较消耗资源。这就需要我们对它做优化，如果频繁调用，这个资源将会常驻内存，第一次冷启之后，就可以一直服务，直到一段时间内没有新的调用请求进来，则会转入“休眠”状态，甚至被回收，从而不消耗任何资源。

2 完全依赖于第三方服务 当你所在的企业云环境已经有大量的基础设施的时候，Serverless 对于你来说，并不是一个好东西。当我们采用某云服务厂商的 Serverless 架构时，我们就和该服务供应商绑定了，那么我们再将服务迁到别的云服务商上就没有那么容易了。

我们需要修改一下系列的底层代码，能采取的应对方案，便是建立隔离层。这意味着，在设计应用的时候，就需要隔离 API 网关、隔离数据库层，考虑到市面上还没有成熟的 ORM 工具，让你既支持Firebase，又支持 DynamoDB等等。这些也将带给我们一些额外的成本，可能带来的问题会比解决的问题多。

3 缺乏调试和开发工具 当我使用 Serverless Framework 的时候，遇到了这样的问题：缺乏调试和开发工具。后来，我发现了 serverless-offline、dynamodb-local 等一系列插件之后，问题有一些改善。然而，对于日志系统来说，这仍然是一个艰巨的挑战。

每次你调试的时候，你需要一遍又一遍地上传代码。而每次上传的时候，你就好像是在部署服务器，并不能总是快速地定位出问题在哪。后来，找了一个类似于 log4j 这样的可以分级别记录日志的 Node.js 库 winston。它可以支持 error、warn、info、verbose、debug、silly 六个不同级别的日志，再结合大数据进行日志分析过滤，才能快速定位问题。

4 构建复杂 Serverless 很便宜，但是这并不意味着它很简单。AWS Lambda的 CloudFormation配置是如此的复杂，并且难以阅读及编写（JSON 格式），虽然CloudFomation提供了Template模板，但想要使用它的话，需要创建一个Stack，在Stack中指定你要使用的Template,然后aws才会按照Template中的定义来创建及初始化资源。

而Serverless Framework的配置更加简单，采用的是 YAML 格式。在部署的时候，Serverless Framework 会根据我们的配置生成 CloudFormation 配置。然而这也并非是一个真正用于生产的配置,真实的应用场景远远比这复杂。