Serverless（无服务器架构）指的是由开发者实现的服务端逻辑运行在无状态的计算容器中，（它并不是说没有服务器）它由事件触发， 完全被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录，无服务器架构的核心思想是让作为计算资源的服务器不再成为用户所关注的一种资源。无服务器架构通常包含了两个领域有状态存储BaaS（Backend as a Service）和无状态的FaaS（Function as a Service）
BaaS
BaaS（Backend as a Service）后端即服务，我在知乎上面看到是这样描述的:
一般是一个个的API调用后端或别人已经实现好的程序逻辑
指我们不需要在编写或管理服务端的组件，和登录认证一样，大多数的系统都需要认证这一个模块，这些功能往往是差不多的，那么我们就可以把这些功能抽出来，做一个额外的服务，Auth2就是这样的例子
FaaS
FaaS（Functions as a Service）函数即服务，FaaS是无服务器计算的另外一种形式，现在使用最广泛的应该是AWS的Lambada。Faas是一种由事件驱动消息触发的服务，供应商集成各种同步和异步的事件源，通过订阅这些事件源，可以突发或者定期的触发函数运行，Fass的一大特点就是它可以只有在用户需要时候被触发创建
实现Fass基础设施有这样几种方式：
- 使用系统或者硬件级别的VM，比如AWS Firecracker,这种方式的好处是为应用提供了较好的隔离性和安全性，但是比较慢，管理复杂
- 使用容器，如Docker，容器会采用如k8s一样的容器编排方案进行管理
- 使用应用程序特定的VM，提供较高级别的抽象，不需要引导自己的编译系统或者软件栈，执行编译好的字节码应用
Serverless定义
和微服务一样Serverless是一种软件系统设计架构思想和方法，并不是一个开发框架或者工具。如果说SpringCloud是微服务的一种实现方式，那么Serverless的实现有Serverless Framework ，通过Serverless Compont用yaml文件来编排整个Serverless应用架构，他的出现是为了让开发者更加关注业务的开发，而将繁杂的运维和部署交给云厂商，无服务架构将复杂的基础架构抽象化，让开发人员可以把更多的开发放在逻辑上
特色
- 使用触发器执行事件驱动，函数在 FaaS 平台中，需要通过一系列的事件来驱动函数执行
- 平台处理所有的启动、停止和缩放任务
- 无状态，每次函数执行，可能使用的都是不同的容器，无法进行内存或数据共享。如果要共享数据，则只能通过第三方服务，比如 Redis等
- 无运维，不需要关心服务器，也不需要关心运维，这也是serverles思想的核心（主要是降低成本哈哈哈）
无服务架构开发 vs 传统开发
无服务应用
- 采用事件驱动，真正做到按需按次计费
- 开发人员只需要编写业务逻辑代码，可将所有的服务器操作交给平台
- 随业务需求的变化而变化，不需要额外关心服务的扩容，伸缩，自动扩容
Traditional application(传统应用)
传统的Web服务是一种SOA的技术，通过标准的WEB协议提供服务，保证不同平台的应用服务可以互相操作，部署流程通常需要将项目代码部署到服务器上，启动服务进程，监听服务器的相关端口，然后等待客户端请求，从而响应返回处理结果。而这个服务进程是常驻的，就算没有客户端请求，也会占用相应服务器资源。
- 需要不停的维护一些基础设施，基础设施的扩展不够动态，有些浪费资源
- 开发人员需要编写集成代码来处理消息传递平台、HTTP请求/响应等。
Spring Cloud给函数提供适配器，这样就可以在最常见的Faas服务上运行函数，这些服务包括Amazon Lambda、Apache OpenWhisk、Microsoft Azure和Project Riff
Serverless 局限性
即使无服务架构有那么多的优点，但是小弗雷德里克-布鲁克斯在《人月神话》中说的没有银弹仍然是不变的真理，无服务架构顺应现代云计算出现的同时不仅带来了许多的优点和新理念也存在着局限性
由小带来的缺点
无服务架构通常会把一个复杂的架构抽象为一个个的函数，随着业务逻辑被拆分为多个函数
-
复杂性增加我们使用应用程序越精细，它就越复杂。每个函数的代码可能会变得更简单，但整个应用程序将变得更加复杂。比如说，我们将应用程序分解为10个不同的微服务。我们必须管理10个不同的应用程序，而在单个应用程序中，它只是一个必须管理的应用程序。
-
缺乏工具支持 假设我们将单片应用程序分解为50种不同的功能。仍然有各种各样的流程和工具来管理，记录，监视和部署整体应用程序。由于无服务器是市场上的新产品，因此监控或记录运行几秒钟的应用程序是有限的并且具有挑战性，但是随着时间的推移，将会有许多有效的方法来实现这一点。
-
与体系结构的复杂性很难决定函数的粒度，并且评估，实现和测试以检查我们的首选项是耗时的。
-
管理太多功能会很麻烦，而且集成测试会很难
快速开始
FASS 函数计算
环境准备
我这里使用的idea开发，我们可以先下载插件Alibaba Cloud Toolkit
下载完成重启一下idea,注册
下载阿里云的调试工具fun,等下我们需要fun初始项目，利用npm下载
npm install @alicloud/fun -g
输入fun,出现命令行信息即为成功
我们这里初始化一个node项目，他的运行环境为nodejs
fun init helloword
fun local start // 使用将服务跑起来，访问url ps:我在本地跑不起来，只能发布出去，好像是因为没有docker的原因
发布
这个url是我的远程实例
Serverless
安装Serverless
Windows 系统我通过 npm 来进行安装，安装慢的可以使用淘宝的镜像 cnpm
npm install -g serverless
serverless -v
出现版本号即安装成功，继续
serverless
执行完成之后，进入我们的本地文件可以serverless为我们创建的demo项目
其中有一个serverless.yml文件和 .env文件，内容如下，在部署时，Serverless Components 会在当前目录寻找 .env 文件。部署过程中，如果 .env 文件存在，Serverless Components 会将其作为环境变量上传。如果是使用的云厂商提供的 secretId 和 secretKey 字段一致的环境变量名，Serverless Components 在部署期间会自动将其注入到需要该秘钥的组件中，用来创建基础设施服务。我这里使用了腾讯云，我在授权后中，Serverless会将我的信息生成的临时秘钥文件，最长可以支持 30 天有效期授权，过期需要重新授权，（ps:这里我扫码扫了半天没有反应，我是访问链接进去授权的😀）
.env
TENCENT_APP_ID=****
TENCENT_SECRET_ID=****
TENCENT_SECRET_KEY=****
TENCENT_TOKEN=****
serverless.yml
component: website // 注册中心的组件名称
name: websiteDemo // 组件实例的名称
app: demo
inputs: // 对应的组件配置
src: // 代码路径，在此处代码路径指定为 src
src: ./src
index: index.html
error: index.html
region: ap-guangzhou
bucketName: my-website-starter
protocol: https
部署成功之后还可以通过控制台进行观察
最后copy一下辛波斯卡的诗
🍾 我偏爱电影。
🍾 我偏爱猫。
🍾 我偏爱华尔塔河沿岸的橡树。
🍾 我偏爱狄更斯胜过陀思妥耶夫斯基。
🍾 我偏爱我对人群的喜欢胜过我对人类的爱。
🍾 我偏爱在手边摆放针线，以备不时之需。
🍾 我偏爱绿色。
🍾 我偏爱不把一切都归咎于理性的想法。
🍾 我偏爱例外。
🍾 我偏爱及早离去。
🍾 我偏爱和医生聊些别的话题。
🍾 我偏爱线条细致的老式插画。
🍾 我偏爱写诗的荒谬胜过不写诗的荒谬。
🍾 我偏爱，就爱情而言，可以天天庆祝不特定纪念日。
🍾 我偏爱不向我做任何承诺的道德家。
🍾 我偏爱狡猾的仁慈胜过过度可信的那种。
🍾 我偏爱穿便服的地球。
🍾 我偏爱被征服的国家胜过征服者。
🍾 我偏爱有些保留。
🍾 我偏爱混乱的地狱胜过秩序井然的地狱。
🍾 我偏爱格林童话胜过报纸头版。
🍾 我偏爱不开花的叶子胜过不长叶子的花。
🍾 我偏爱尾巴没被截短的狗。
🍾 我偏爱淡色的眼睛，因为我是黑眼珠。
🍾 我偏爱书桌的抽屉。
🍾 我偏爱许多此处未提及的事物胜过许多我也没有说到的事物。
🍾 我偏爱自由无拘的零胜过排列在阿拉伯数字后面的零。
🍾 我偏爱昆虫的时间胜过星星的时间。
🍾 我偏爱敲击木头。
🍾 我偏爱不去问还要多久或什么时候。
🍾 我偏爱牢记此一可能—— 存在的理由不假外求。
📕 标题小山文模仿小晏的《小山词》
PS:参考资料太多了，就没有写上来，由于鄙人太菜了，存在问题的还请各位大佬多多指教
