这两天在了解serverless，所以大概看了不少的文章，主要了解了一些概念性的知识。这里简单的记录一下。
介绍
Serverless是一种新兴起的架构模式。它是指明显或充分地依赖第三方应用或服务来管理服务器端逻辑和状态，可以让你在服务部署级别而不是服务器部署级别来管理你的应用部署，甚至可以让你管理某个具体功能或端口地部署，能够让开发者快速迭代，更快速地开发软件。
总结下来，不需要处理运维方面的事了，只需要关注业务代码部分即可。
Serverless架构分为两种类型，分别为“Backend as a Service”和“Functions as a service”。
“Backend as a Service”即BaaS,是一种新型的云服务,指在为移动和Web应用提供后端云服务,实现对逻辑和状态进行管理,包括云端数据/文件存储、消息推送(例如极光推送、个推)、应用数据分析等等。可以说BaaS是诞生于移动互联网,为了加速移动应用开发和降低成本而形成的开发架构。
“Functions as a Service”即FaaS,指这样的应用,一部分服务逻辑由应用实现,但是跟传统架构不同在于,他们运行于无状态的容器中,可以由事件触发,短暂的,完全被第三方管理,功能上FaaS就是不需要关心后台服务器或者应用服务,只需关心自己的代码即可。其中AWS
Lambda是目前最佳的FaaS实现之一。
我们将关注点聚焦在FaaS上。首先Serverless架构的主要目的是简化运维（甚至对于开发人员来说，无需运维），节约成本。
优点
我们先看简化运维，在FaaS中，开发人员只需编写目标Function代码即可，设置好所需的cpu和内存等关键信息后，就无需任何额外操作了，可以说完全远离了底层硬件及运维，并且一般在使用serverless时，都有一系列其他配套的第三方服务，如登陆鉴权，消息队列，云数据库等等。最后就将所有关注点聚焦到核心业务的开发上。
接着是节约成本，传统模式上，我们要不需要自己维护服务器，要不需要在云服务厂商购买云服务器实例。而使用serverless架构之后，我们就可以不需要购买服务器这种基础设施，而是购买网络，硬盘，cpu等计算资源，它按量计费，如果无访问量则不会计费，相较于之前的购买云服务器，可以有效节约成本。
另外，基于它的本身优势，更加有助于进行快速扩容，弹性伸缩，应对突发流量等，提高可维护性。
弊端
当然，它也不是没有弊端，所向披靡。由于按量计费，所以就会在调用的时候启动对应的function，这就需要一定的启动时间，成为冷启动，虽然时间可以控制在ms级别，但是也会造成一定的延时；另外，由于每次部署的function内容不多，无状态，只是关注一部分的业务逻辑等，所以目前还无法适用于复杂的业务场景；并且目前该架构尚不成熟，而且存在厂商平台绑定的现象（使用周边配套产品，如网关，消息队列，云数据库，登陆鉴权等等），所以需要谨慎对待。
适用场景：
- 低频请求场景，比如物联网行业中，设备传输数据量小，且往往是固定时间间隔进行数据传输，如程序每分钟仅运行一次，每次运行50ms，意味着CPU使用率不到0.1%/分。在Serverless架构下，用户可以购买每分钟100ms的资源来满足计算需求，即能解决效率问题，同时降低使用成本。定时任务也是同理。
- 流量突发场景，例如：移动应用的通常流量情况是QPS 20，但每隔五分钟会有一个持续10s的QPS 200流量（10倍于通常流量），传统架构下企业必须扩展QPS 200的硬件能力来应对业务高峰，即使高峰时间仅占整个运行时间的4%；而在Serverless架构下，用户可以利用弹性扩展特性，快速构建新的计算能力来满足当前需求，当业务高峰后，资源能够自动释放，有效节省成本。
上述内容参考文章：
https://www.cnblogs.com/Leo_wl/p/6055252.html
https://www.aliyun.com/jiaocheng/525961.html
阿里云对应serverless的产品为函数计算，不过本人并没有进行相关测试，只是简单的看了一下帮助文档。
倒是试用了一下最近公测的EDAS Serverless服务，简单来说，只需将相关服务代码打包/做成镜像，然后进行相应的简单创建流程，如帮助文档，一个服务就部署完成了，无需购买ecs实例，也不用进行任何与运维相关的复杂操作，并且服务资源是按分钟计算，可以实现快速扩容/缩容。总的来说，可以无需关心运维方面的东西了。