开发者学堂课程【Serverless 常见架构模式：常见 Serverless 架构模式】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/842/detail/14010
常见 Serverless 架构模式
内容简介：
1．介绍 Serverless 的基本思想
2．静态站点
3．单体和微服务
4．事件触发
5．服务编排
6 . 总结
1、介绍 Serverless 的基本思想
首先是 Serverless 架构是运用 Faas 函数级和 Baas 后端服务解决问题的设计，这个定义会让我们清楚一些，但也造成了争论。
首先是随着需求和技术的发展，业界出现了 Fass 以外的其他形态的 Serverless 服务，比如谷歌的 CloudRun、阿里云面向应用的 Serverless 应用引擎服务，设计服务也提供了弹性伸缩能力和按使用时间形式收费的 Serveless 形态，进一步扩大了Serverless 计算的阵营。
第二是为了解决能启动 Fass 类服务（如阿里云的函数计算、AWS 的 Lambda 也相继推出了预留功能）。
第三是一些基于后台服务器的 Serverless 形态的产品（比如 AWS 的 run 推出了service run，阿里云的HBS服务推出了 Service HBS 服务）。
因此 Serverless 服务是模糊的，因为技术是不断前进的，昨天可能还是 Serveful 基于服务器的服务，今天可能会变成 Serverless。如何让模糊的 Serverless 应用到我们的问题？
Serverless 有一个根本的理念是不变的，那就是用户最大化的算出业务逻辑，其他的特征是弹性伸缩，使用计费等等都是为了实现这个理念而服务的。
在实现 Serverless 架构时，我们最重要的心思不是去选择流行的服务，解决哪些难题，而是应该把计算业务逻辑铭记在心，这样更容易选择合适的计算和服务。
Serverless 原生心智
1.我的业务是什么？
2.做这件事情能不能让我的业务出类拔萃？
3.如果不能，我为什么要做这件事情而不是让别人来解决这个问题？
4.在解决业务问题之前没有必要解决技术问题。
ByServerless 实践者 BenKehoe
人的精力是有限的，所处的资源也是有限的。Serverless 理念是让我们用有限的资源投入到真正需要解决的业务问题中来，正是少了一些事情，比如服务器管理；让别人做一些事情，比如云服务商，一些 Sass平台，这样才能在业务上做的更多。
.我们会使用计算、存储、消息通讯等技术来实现 Serverless 架构，也会从可运维性、安全性、可靠性、可扩展性、成本等衡量维度。
2、静态站点：
业务需求：信息展示站点
展示信息
更新不频繁
不确定访问量
架构的演进：
首先会买一台服务器，把它放到 IDC 机房中托管，运行这个产品；然后我们考虑高可用性，可能会去买负载均衡、买云服务器，通过多台负载均衡来解决高可用问题；我们也可以采用静态存储方式，这样能直接将站点有静态存储服务到对象存储，并选用 CDN 做缓存。这三种方式是采用云上到云下，有管理服务器到无需管理服务器。
前两个方案需要我们不断的做运算做扩算，实现高可用自行监控等这些是业务逻辑。
Serverless 理念是是让人最大化的专注业务逻辑，而第三种方式是采用 Serverless架构来构建一个静态站点。
具有无法比拟的一些优势，无需管理服务器，甚至找不到服务器的位置。无需对资源的预估和未来的拓展。还有就是实际使用付费。
对上述架构的延伸，静态是一个很好的属性，缓存也是静态开发经常用到的技术。
缓存是十分重要的，只要利用得当，是能够大大提升性能。CDN 不仅能够回延到静态存储，还能够回延到后端如API,函数计算，负载均衡等，另外，也不止有 CDN 使用这种缓存。
3、单体和微服务：
静态页面站点适用于内容少，频率低的场景，反之会需要动态站点。比如淘宝的商品页面采用静态的方式页面管理商品，是不限时的因为商品的数量较多，商品下架的信息是更新频繁的商品信息及其复杂，包括基本信息、价格、运费、销量、库存、评论等
业务需求:商品详情页
海量商品
更新频繁
动态信息来源广泛，如基本信息、价格、运费、销量、库存、评论等。
首先前面基于服务器的方案也可以继续演进这种场景，所有的应用逻辑都在一个应用中完成，结合数据库这种分层架构，也可以快速实现复杂度较低的应用，这是一种单体的架构。
随着业务量发展，访问量增多，功能增加，团队变大，这时候需要将单体的应用逻辑拆分成多个单元，比如，评论信息，价格信息，售卖信息等，都可以单独的服务。
同时 serverless 架构的引进，看到静态资源还是由 CDN 和对象存储服务管理，客户端下载静态资源发起动态请求，动态请求通过 API 网关将请求发到函数计算或Serverless 引擎服务，后面通过云数据库和表格存储存放商品信息。Serverless 架构可以化繁为简。
通过展示系统内部各种微服务的交互，通过提供一个商品聚合的服务将内部的多个微服务统一呈现给外部，这里的微服务主要通过 Serverless 引擎服务和函数来实现。另一个延伸是开始的业务需求没有提到是不是要支持不同客户端的访问。
现实这种需求是常见的，不同的客户端要的信息不同。如何让不同的客户端来使用Serverless 架构，这就有需要用到 Backend For Frontend 即为前端定做的后端。
4、事件触发：
还有一种场景，其中处理请求需要较长时间或较多资源，比如用户评论中的图片和视频内容会出现上传图片和处理图片的方式，需要我们实现像淘宝评价的功能，需要对图片缩放，加水印，审核，需要对视频做多种格式转换，审核要适应各种客户端和显示的需求
业务需求:买家秀
发表图片和视频评论
需要对图片缩放，加水印，审核
需要对视频做多种格式转换，审核
这种场景下的技术架构演进：首先看单体结构多媒体上传到服务器，由服务器处理，对服务器的显示处理来完成；第二个架构下面图片右下角多媒体文件上传到服务器，由服务器处理加入到消息队列，有另一个组件去处理转存到 oss 对多媒体的显示由 CDN 和 OSS 来完成，优点是可以通过消息队列来将 web 应用服务器和处理应用服务器连接；第三个架构：图片左下角的 Serverless 架构，多媒体直接将文件上传到 oss 中而不是自己的服务器，对多媒体的显示也是 有 OSS 和 CDN 共同完成的。
这个事件触发能力是 Pub/Sub 事件驱动能力的实现，Pub/Sub 事件驱动模式不是一个新的概念，但是在 Serverless 流行之前，事件的消费者生产者以及中间连接的枢纽，都是由用户负责的。Serverless 架构中让生产者的发送事件以及维护枢纽都是由用户来完成的都省略掉了，用户只需要关注使用价值，函数计算服务还集成了其他云服务事件源；中间的事件流模式是拉取有序的事件在事件中传递给函数计算；EventSourcing 模式中往表格中存储的操作可以在函数计算中处理。
5、服务编排：
业务需求:订单流程
完成多步骤订单流程，包括预留库存、确认支付、安排配送、邮件短信通知等
可能持续数天
需要对失败步骤重试
最终失败，需要对已完成步骤回滚
架构演进：
现在面临分布式较难的问题，这是引入微服务架构最麻烦的问题，单体应用在一定程度上可以解决，一般单体应用一个数据库，可以使用数据库的适用保持一致性，在现实上会不得不与web服务相关联，因此还是需要一定的机制保持前进和回退来保证完成，用事件驱动的模式来完成，在架构中会有一个消息总线，各种服务监听这种事件，也可以使用服务器或函数。
基于工作流的 Sage 模式，在这个架构中各个服务间都是独立的，他们不通过事件传递信息
而是由一个集中的服务来调用单个的服务，而业务逻辑和状态有集中的协调者。这种工作流的实现需要编写大量的代码来实现编排逻辑，代码维护和错误处理等功能；维护运行和编排的基础设施的高可用性和可伸缩性；考虑状态持久性，意思是多步骤长时间完成来确保事务的实现性，这些都是用工作流系统额外的负担，右图是关于流程的介绍，减少流程的复杂度，可以清楚看到进行的操作
6、总结：
Serverless 是专注于业务逻辑，也能帮助解决许多问题；第二个是 Serverless 架构覆盖很多业务场景，这里由web网站的前端后端、微服务，服务编排，事态处理等。
