FaaS将增加额外的开销来连接和访问传统数据库。我们可以利用数据编排的思想，将数据库操作转化为RESTfulAPI。顺着这个思路，我介绍了后端应用的BaaS。总之，后端应用BaaS就是将后端应用转化为NoOps数据接口。那么如何理解这句话呢？对于之前的“待办任务”web应用，本项目前端为单页面应用，中间采用FaaS作为SFF数据网关，后端数据接口需要为BaaS。这个案例会贯穿Servless的探索，所以一定要跑起来。这种架构的优点是什么？让我们把这张图变成一个形状，这样你会更容易理解。从左到右看上面的图片。当用户从浏览器打开我们的网站时，前端应用响应并返回index.html；然后浏览器去CDN下载我们的静态资源，完成页面静态资源的加载；同时浏览器也向前端应用发起数据请求；前端应用安全签名后，向SFF发送数据请求；SFF根据数据请求调用后端接口或服务，最后整理结果并返回。从图中可以看出，除了数据库是Stateful，其他节点都变成了Stateless。如果你公司的业务量不大，其实这个结构就足够了。就像传统的MVC架构一样，单点数据库承载基本的并发不是问题，也可以通过主从结构和客户端读写分离来优化数据。但是MVC架构最大的问题就是积累。当应用MVC架构时，经过长期的迭代和运行，数据库肯定会变得臃肿，这会大大降低数据库的读写性能。而且，当高并发到一定程度，Stateful数据库还是会成为瓶颈。那我们是不是也可以把自己的数据库也变成BaaS呢？解决数据库问题，也可以选择我上节课给大家提到的云服务商提供的BaaS服务，比如DynamoDB。但是云服务商BaaS服务是怎么做到的呢？如果BaaS服务能力不够完善，不能满足我们的需求怎么办？看一看传统MVC应用中的数据库如何改造为BaaS。当然，BaaS的流程有点复杂，这是需要我们后面慢慢摸索的；后端应用的BaaS就是NoOps的微服务。在我看来，后端应用的BaaS和微服务有很大的重叠，微服务几乎涵盖了我们在BaaS中需要做的一切。微服务的概念微服务的概念对于很多后端同学，尤其是Java同学来说并不陌生，因为早年Java就提出了SOA面向服务的架构。微服务可以看作是SOA的一个子集，它是由ThoughtWorks的MartinFowler在2014年提出的。微服务最初是为了拆解单体应用而设计的。单体应用是指那些生命周期较长，积累了大量高耦合服务和冗余代码的企业应用。Serverless专栏无意向大家详细讲解微服务，但希望大家能够对微服务有一定的了解。FaaS和微服务架构几乎同时诞生。他们的很多想法都来自于12元素（Twelve-FactorApp），所以微服务的概念和FaaS的概念高度相似，很多公司都使用FaaS来实现微服务架构。;不同的是ThoughtWorks和NetFlix这两家微服务的龙头企业，到处宣扬他们微服务架构的好处，他们提出了一整套的方法论，包括如何设计微服务架构，如何拆解微服务，尤其是数据库如何设计等等，我们的后端应用BaaS，首先要将复杂的业务逻辑拆解成职责单一的微服务。因为职责单一，服务端运维成本会更低。而拆分就像治理洪水时的分流，可以减轻各个微服务的压力。这里简单说一下微服务主要是想介绍一下微服务拆解业务的分流思路和微服务对数据库的解耦方式。微服务的10大要素说起微服务，很多人都会谈到12大要素，认为微服务也应该满足12大要素。这12个元素最初是为SaaS设计的，目的是提高Web应用程序的适用性和可移植性。早期做微服务的时候也学过12要素，但是发现这只能提供理论上的理解。其实经验可以概括为微服务的10个要素：API、服务调用、服务发现；日志，链接跟踪；灾难恢复、监控、扩展和收缩；发布管道；验证。-用户无需关心服务器端的事情（容错、容灾、安全验证、自动伸缩、日志调试等）。-按用量付费（通话次数、时长等），低成本和高性能并行，在大多数场景下都省钱。-快速迭代&试错能力（多版本控制、灰度、CI&CD等）你可能会发现与微服务的元素有很多重叠。API是一个RESTfulHTTP数据接口；您可以将服务调用理解为HTTP请求；服务发现可以理解为我们只能使用域名来调用我们的HTTP请求，不能使用IP；日志、容灾、监控不难理解；链接跟踪是微服务的重要组成部分，因为相对于传统的MVC架构，后端一个请求的调用链增加了。为了快速定位问题，我们需要打印整个调用环节的异常栈；releasepipeline和authentication权限对于我们的FaaS来说也是非常重要的。通过前面的案例，我们主要看看微服务是如何解耦数据库的。让我们从分析“ToDo”Web服务开始。我上节课最后的作业其实已经给你准备好了。我们来看一下index.js文件，它是MVC架构的一个典型应用。View层是index.html和静态资源文件；Model层，我们引入lowdb，用一个db.json文件代替数据库；Control层是app.METHOD，处理/api/*的数据逻辑。微服务是面向后端应用的，所以我们只需要关注控制层。API的数据处理方式主要有两种，一种是/api/rule处理待办任务，一种是/api/user处理用户登录状态，也是我们“待办任务”的主要数据模型就是待办任务和用户这两个。那么我们可以将后端拆分成两个微服务：待办任务微服务和用户微服务。这里我要强调的是，我这样做只是为了给大家演示微服务。在实际业务中，没有必要过早拆分这么简单的功能。最初的拆解，我们去掉了index.js中的数据库，拆分之后，每个微服务的数据库都比原来简单了很多，也更容易维护。user.js负责用户相关的业务逻辑，只维护用户信息的数据库，暴露RESTfulHTTP方法；rule.js负责待办任务的增删改查，只维护待办任务的数据库，暴露RESTfulHTTP方法；index.js只需要负责将请求HTTP返回给数据编排即可。为了HTTP协议满足我们的服务调用和发现，发布的user.js和rule.js必须使用域名，比如api.jike-serverless.online/user和api.jike-serverless.online/rule。这样新扩容的机器IP只需要注册到这个域名下就可以被服务发现和调用了。总结为了避免在FaaS中直接操作数据库，我们将数据库操作变成了BaaS服务。为了理解BaaS的具体工作，我们引入微服务的概念。微服务首先将业务拆解成职责单一、功能单一的小模块，独立运维，再将小模块组装成复杂的大型应用。这一点和我们要做的后端应用的BaaS很相似。所以提到微服务，我们首先将MVC架构的后端分解成两个微服务，然后通过微服务来解耦数据库的操作。一个副本，从而将数据变成无状态的。下面我们来回顾一下本课的重要知识点。微服务的概念：就是把一个复杂的大型应用拆解成一个个职责单一的小功能模块。每个模块的数据模型相互独立。模块通过API接口将自己提供的服务暴露给外界，然后通过这些API接口组合成大型应用。这个小功能模块就是一个微服务。微服务10大要素：API、服务调用、服务发现；日志，链接跟踪；灾难恢复、监控、扩展和收缩；发布管道；验证。这个和我们要做的BaaS重合度很高，可以用微服务来实现我们的BaaS。数据库解耦：通过额外的进程，数据库和副本直接通过消息队列同步，所以对于微服务应用来说，只需要关注自己的专属数据库即可。微服务通过数据库解耦，将后端应用解耦成Stateless，但是对于后端应用本身来说，数据库还是Stateful的。基础篇：FaaS的拆解与编排-阿里借集团之力深挖Serverless。它能解决什么问题？-通过一个Serverless的案例，理解FaaS的运行逻辑-深入浅出地讲解FaaS的两种流程模型-深入浅出地讲解FaaS的应用场景：数据整理
