Serverless AI训练营：课时3：函数粘合云服务提供端到端解决方案
课时3：函数粘合云服务提供端到端解决方案
一、单体应用中最常见的两种编程模型
1、UI 驱动
客户端可能不那么智能，主要是因为比如像一些业务逻辑、认证服务、搜索服务、交易等等都需要是现在服务状态应用程序中随着业务的复杂度不断增加，服务端的应用会越发的膨胀和难以维护。
2、消息驱动
需要用户实现一个常驻的消费者服务去消费消息，同时消费者的可用性也需要用户去保证。
从以上两个例子可以看出，假设单体应用不断膨胀，对一个庞大的单体应用进行拆解，充分利用云服务的体系结构是一个非常好的解决方案。最大的关键是如何为应用程序的每个组件选择和使用云服务，而通过函数作为粘合剂将云服务串联起来，是一个非常好的解决方案。
目前很多人将 Fass 等同于 Serverless，所谓的 Fass 就是
Serverless ，既函数既服务，但是像阿里云的函数计算和 AWSM ，
但实际上有许多其他的服务也是 Serverless,比如他们和函数计算一
起构成完整的 Serverles s应用，比如说使用 API 网关可以让用户
从 API网关的限流、建前等繁琐的配置中解放出来；
*使用表格存储和对象存储来持久化数据，可以取代用户去管理数据库实例；
*使用日志服务或者 DataHub 这种外部数据源收集数据；
*使用 MNS 去管理自己的消息。
用户可以使用一个函数将这些服务给串联起来，从而能达到构建具体的应用和复杂业务逻辑的目标，同时用户也可以使用 Serverless 工作流来编排函数和其他云服务，让用户更加聚焦于具体业务逻辑的开发和流程的编排；用户也可以使用阿里云提供的开发工具链来简化自动化部署和持续集成，使用这些开箱即用的工具可以帮助用户快速达到想要的目标和效果；
如果一个庞大的单体应用或者是一个面向服务的体系结构，开发者需要负责所有的事情，包括代码的编写、管理和部署数据库以及其他后端相关服务等。切换到 Serverless 架构以后，可以看到特定的模块交由特定的云服务处理，之后再使用具体的业务逻辑，再使用实现的具体业务代码的函数将他们串联起来，也就实现了解耦。
为了使这种架构运转的更有效率。事件驱动是一个不可缺少的特性。比如说用户尝试往 OSS 上传一个文件，这个上传事件可以自动触发一个函数，对这个文件进行处理，比如用户变更一个表格存储的数据，也会自动触发一个编写的逻辑，这就可以引出一个例子：
用户上传一张图片到对象存储 OSS 触发一个函数，这个函数对这张图片生成缩略图并把缩略图并保存回 OSS ，之后这个 OSS 触发了另外一个函数，这个函数会把刚刚生成的缩略图的信息写入Serverless 数据库表格存储，之后表格存储又触发另外一个函数，将这个缩略图的信息更新到搜索模块，这样可以看到数据的上传、存储、原信息的入库以及搜索模块的更新被这三个函数粘合成了具体的业务逻辑。
再回到最开始提出的单体应用的实例，UI驱动的话可以转化成Serverless架构， 比如说第三方Serverless 认证服务可以取代服务端中的认证逻辑，而后一些页面显示的内容可以直接读取Serverless 数据库，这样会导致用户端很多业务逻辑可以慢慢移到客户端，同时对一些像搜索的 CPU 密集型或者大量数据可以放在服务端实现，配合 API 网关；而对于涉及到支付的安全方面的购买函数也可以放在服务端；这样就充分利用了云服务保证了一些逻辑，更专注于具体的业务逻辑，比如在这里业务逻辑是购买和搜索；对于消息驱动这种模式，可以看到之前常驻的消费者服务交由 Fass 进行实现，同时消费的并行等等都交给了云平台。
