共计 3275 个字符，预计需要花费 9 分钟才能阅读完成。
FaaS 连贯并拜访传统数据库会减少额定的开销，咱们能够采纳数据编排的思维，将数据库操作转为 RESTful API。顺着这个思路，我引出了后端利用的 BaaS 化，一句话总结，后端利用 BaaS 化就是将后端利用转换成 NoOps 的数据接口。那怎么了解这句话呢？
后面的“待办工作”Web 利用，这个我的项目前端是单页利用，两头用了 FaaS 做 SFF 数据网关，后端数据接口还要 BaaS 化。这个案例会贯通对于 Servless 的摸索，所以你肯定要入手 run 一下。
这个架构的劣势是什么呢？咱们将这个图变个形，你就更容易了解了。
从左往右看下面这张图。用户从浏览器关上咱们网站时，前端利用响应返回 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 的一个子集，2014 年由 ThoughtWorks 的 Martin Fowler 提出。微服务设计之初是为了拆解巨石利用，巨石利用就是指那些生命周期较长的，累计了大量业务高度耦合和冗余代码的企业应用。
Serverless 专栏并不打算给你具体地解说微服务，然而心愿你能肯定水平上理解微服务。FaaS 和微服务架构的诞生简直是在同一期间，它俩的很多理念都是来自 12 因素（Twelve-Factor App），所以微服务概念和 FaaS 概念高度类似，也有不少公司用 FaaS 实现微服务架构；不同的是，微服务的领军公司 ThoughtWorks 和 NetFlix 到处鼓吹他们的微服务架构带来的益处，而且他们提出了一整套方法论，包含微服务架构如何设计，如何拆解微服务，尤其是数据库如何设计等等
咱们后端利用 BaaS 化，首先要将简单的业务逻辑拆开，拆成职责繁多的微服务。 因为职责繁多，所以服务端运维的老本会更低 。而且拆分就像治理洪水时的分流一样，它能加重每个微服务上接受的压力。
这里简略说微服务次要就是想引入微服务拆解业务的分流思维和微服务对数据库的解耦形式。
微服务 10 因素
谈起微服务，很多人都要说 12 因素，认为微服务也应该满足 12 因素。12 因素当初是为了 SaaS 设计的，用来晋升 Web 利用的适用性和可移植性。我在做微服务初期也学习过 12 因素，但我发现这个只能提供实践意识。
其实能够演绎经验总结为微服务的 10 因素：API、服务调用、服务发现；日志、链路追踪；容灾性、监控、扩缩容；公布管道；鉴权 。
– 无需用户关怀服务端的事件（容错、容灾、平安验证、主动扩缩容、日志调试等等 )。
– 按使用量（调用次数、时长等）付费，低费用和高性能并行，大多数场景下节省开支。
– 疾速迭代 & 试错能力（多版本控制，灰度，CI&CD 等等）
你可能发现跟微服务的因素有大量的重合。API 就是 RESTful 的 HTTP 数据接口；服务调用你能够了解为就是 HTTP 申请；服务发现你能够了解为咱们只能用域名调用咱们的 HTTP 申请，不能用 IP；日志、容灾、监控都不难理解；链路追踪，是微服务重要的一环，因为绝对传统 MVC 架构，咱们一个申请在后端的调用链增长了，为了疾速定位问题，咱们都须要打印整个调用链路的异样栈；公布管道和鉴权，和咱们的 FaaS 也有很重要的关联。
通过后面的案例上面次要看看微服务如何让数据库解耦。
咱们先剖析一下“待办工作”Web 服务。上一讲开端我的作业其实曾经为你筹备好了，咱们一起看看 index.js 文件，这是一个典型的 MVC 架构的利用。View 层就是 index.html 和动态资源文件；Model 层，咱们引入 lowdb 用一个 db.json 文件代替数据库；Control 层，就是 app.METHOD，解决 /api/* 的数据逻辑。微服务是解决后端利用的，所以咱们只须要关注 Control 层。
API 的数据处理，次要有两个，一个是 /api/rule 解决待办工作的，一个是 /api/user 负责用户登录态，而且咱们“待办工作”次要的数据模型也就是待办工作和用户这两个。那咱们能够将后端拆分出两个微服务：待办工作微服务和用户微服务。这里我要强调下，我只是为了向你演示微服务才这样做，在理论业务中，这么简略的性能，没必要过早地拆分。
初步拆解，咱们将 index.js 中的数据库移走了，而且拆分后各微服务的数据库比原来混淆在一起简略且容易保护多了。user.js 负责用户相干业务逻辑，只保护用户信息的数据库，并且裸露 RESTful 的 HTTP 办法；rule.js 负责待办工作的增删改查，只保护待办工作的数据库，并且裸露 RESTful 的 HTTP 办法；index.js 只须要负责将申请 HTTP 返回给数据编排。
HTTP 协定要满足咱们的服务调用与发现，公布的 user.js 和 rule.js 必须应用域名，例如 api.jike-serverless.online/user 和 api.jike-serverless.online/rule。这样新扩容的机器 IP，只须要注册到这个域名下就能够被服务发现 IP 并调用了。
总结
咱们为了防止在 FaaS 中间接操作数据库，而将数据库操作变成 BaaS 服务。为了了解 BaaS 化具体的工作，咱们引入了微服务的概念。微服务先将业务拆解成繁多职责和性能的小模块便于独立运维，再将小模块组装成简单的大型应用程序。这一点上跟咱们要做的后端利用 BaaS 化类似度十分高。所以参考微服务，咱们先将 MVC 架构的后端解成了两个微服务，再用微服务解耦数据库的操作，先将数据库拆解成职责繁多的小数据库，再用音讯队列同步数据库和正本，从而将数据变成了 Stateless。
当初咱们再来回顾一下这节课的重要知识点。
微服务的概念：它就是将一个简单的大型利用拆解成职责繁多的小功能模块，各模块之间数据模型互相独立，模块采纳 API 接口裸露本人对外提供的服务，而后再通过这些 API 接口组合成大型利用。这个小功能模块，就是微服务。
微服务 10 因素：API、服务调用、服务发现；日志、链路追踪；容灾性、监控、扩缩容；公布管道；鉴权。这跟咱们要做的 BaaS 化高度重合，咱们能够借助微服务来实现咱们的 BaaS 化。
解耦数据库：通过额定过程让数据库与正本间接通过音讯队列进行同步，所以对于微服务利用来说，只须要关注本身独享的数据库就能够了。微服务通过数据库解耦，将后端利用变成 Stateless 的了，但对后端利用自身而言，数据库还是 Stateful 的。
根底篇：FaaS 的拆解和编排
– 阿里举团体之力趟坑 Serverless, 到底它能解决什么问题？
– 通过一个 Serverless 案例，了解 FaaS 的运行逻辑
– 深入浅出 FaaS 的两种过程模型
– 深入浅出 FaaS 利用场景：数据编排