serverless中文的含义是 "无服务器"，但是它真正的含义是开发者再也不用过多考虑服务器的问题，但是并不代表完全去除服务器，而是我们依靠第三方资源服务器后端，比如使用 Amazon Web Services(AWS) Lambda. 计算服务来执行代码，那么Serverless架构分为 Backend as a Service(BaaS) 和 Functions as a Service(FaaS) 两种技术，Serverless 它是由开发者实现的服务端逻辑运行在无状态的计算容器中，它是由事件触发，完全被第三方管理的。
在传统开发模式中，开发一个应用程序，从开始到上线需要不同的角色来做不同的事情，沟通成本非常大，并且运维过程中需要考虑到 服务器的负载均衡、事务、集群、缓存、
消息传递和数据冗余等等。开发流程：设计-->开发（前端&后端）-->服务器部署-->联调（前端&后端）-->测试-->上线-->运维
在Serverless架构中，应用业务逻辑是基于FaaS架构形成多个相互独立的功能组件的。并且以API服务的形式向外提供服务，在FaaS中，后端的应用被拆分成为一个个函数，我们只需要编写完成函数后部署到serverless服务即可。后续我们也不用关心任何服务器的操作。那么整个流程就只需要我们一个前端工程师的角色来完成所有的开发工作，那么沟通成本降低了。项目流程：设计-->应用开发-->测试-->上线
前端工程师是居于serverless去写后端服务的，典型的就是居于 AWS Lambda 中编写代码，AWS中支持不同的语言。
Lambda计算服务它能够以大规模并行的方式执行代码来响应事件。通过使用Lambda以及使用各种功能强大的API和Web服务，开发者可以快速的构建松耦合，可扩展性及高效的架构体系。
注意：Lambda是什么？它是一种计算服务，它在AWS基础上执行用javascript、node.js、Python、C#或java编写的代码，源代码将被打包并部署到孤立的容器中，该容器有单独分配的内存、磁盘空间和处理器。代码、配置和依赖项的组合被称作为Lambda函数。
serverless优点
1. 降低创业公司启动成本
2. 减少运营成本
3. 降低开发成本
4. 实现快速上线
5. 系统安全性更高
6. 能适应微服务架构和扩展性能力强
serverless缺点
1. 不适合长时间运行应用
2. 完全会依赖于第三方服务
3. 缺乏调式和开发工具，排查问题困难
4. 无法用于高并发运用
Serverless的应用场景
Serverless 适合构建比较简单的应用，比如上传一张图片，对一段音频/视频进行编码或解码，对请求返回一小段数据等。
Serverless架构主要有以下特点：
1. 实现了细粒度的计算资源分配。
2. 不需要预分配资源。
3. 具备真正意义上的高度扩容和弹性。
4. 按需使用，按需计费。
因此以下应用将可能使用serverless架构：
1. 静态网站的管理。
2. 替代WordPress(Serverless Blog Project)
3. 个人媒体服务器(less!)
4. 物联网Iot或家庭自动框架或项目 (使用 AWS IoT)
具体的应用基本如下：
发送通知：
诸如 PUSH Notification、邮件通知接口、短信，这一类服务来说，他们都需要基础设施来搭建。并且，他们对实时性的要求相对没有那么高。
即使在时间上晚来几秒钟，用户还是能接受的。在我们所见到的短信发送的例子里，一般都会假设用户能在 60 秒内收到短信。因此，在这种时间 1s 的误差，用户也不会恼火的。而对于 APP 的消息推送而言，这种要求就更低了，用户反而不太希望能收到这样的推送。
WebHook
当我们没有服务器，又想要一个 Webhook 来触发我们一系列的操作的时候。我们就可以考虑使用 Serverless，我们不需要一直就这么支付一个服务器的费用。通过 Serverless，我们就可以轻松完成这样的工作，并且节省大量的费用。
数据统计分析
数据统计本身只需要很少的计算量，但是生成图表，则可以定期生成。
在接收数据的时候，我们不需要考虑任何延时带来的问题。50~200 ms 的延时，并不会对我们的系统造成什么影响。
Trigger 及定时任务
对于哪些需要爬虫来抓取和生成的程序来说，Serverless 可能是一个不错的舞台。
尽管，这样的工作也可以由云服务器来做，我们只需要定时的启动一下服务器。通过服务器中的自启动脚本来做相应的事，但是当我们完成了一系列的工作之后。我们需要将数据存储在一个远程的服务器上。而为了让系统中的其它应用，也能直接访问这些数据。那么，我们可能会考虑使用一个云数据库。这个时候，Serverless 应用看上去更具有吸引力。
Chat 机器人
聊天机器人，也是一个相当好的应用场景。
But，由于国内的条件限制（信息监管），这并不是一件容易的事。因此，从渠道（如微信、blabla）上，都在尽可能地降低这方面的可能性。
但是，我们还可以做一个微信公众号的服务。当用户输入一个关键词时，做出相应的回复，这实质上和聊天机器人是差不多的。
一般也会把路由，安全，限流，缓存，日志，监控，重试，熔断等都放到 API 网关来做，然后服务层就完全脱离这些东西，纯粹的做业务，也能够很好的保证业务代码的干净，不用关心安全，压力等方面的问题。
参考地址：
https://blog.csdn.net/qq_41875506/article/details/92021158
https://blog.csdn.net/cc18868876837/article/details/90672971
https://www.jianshu.com/p/92632d6c2269