BaaS

FaaS 连接并访问传统数据库会增加额外的开销，可以采用数据编排的思想，将数据库操作转为 RESTful API。顺着这个思路，引出后端应用的 BaaS 化，就是将后端应用转换成 NoOps 的数据接口。

BaaS化

换个角度看：

BaaS化架构图

用户访问的整个过程：

1. 用户从浏览器打开网站时，前端应用响应返回 index.html；

2. 然后浏览器去 CDN 下载我们的静态资源，完成页面静态资源的加载；

3. 与此同时，浏览器也向前端应用发起数据请求；

4. 前端应用经过安全签名后，再将数据请求发送给 SFF；

5. SFF 再根据数据请求，调用后端接口或服务，最终将结果编排后返回。

除了数据库是 Stateful 的，其它节点都已经变成了 Stateless。整个简单的Serverless架构与传统的MVC架构很像，应对简单的业务足够了。

但 MVC 架构最大的问题就是累积，当一个 MVC 架构的应用，在经历长期迭代和运营后，数据库一定会变得臃肿，极大降低数据库的读写性能。而且在高并发达到一定量级，Stateful 的数据库还是会成为瓶颈。要解决数据库的问题，就需要BaaS化。

后端应用 BaaS 化，就是 NoOps 的微服务。后端应用 BaaS 化，跟微服务高度重合，微服务几乎涵盖了 BaaS 化要做的所有内容。

微服务

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成，这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。

微服务就是先拆后合，将一个复杂的大型应用拆解成职责单一的小功能模块，各模块之间的数据模型相互独立，模块采用 API 接口暴露自己对外提供服务，然后再通过这些接口组合出原先的大型应用。

拆解的好处是，小模块便于维护，可以快速迭代，跨应用复用。

FaaS 和微服务架构的诞生几乎是在同一时期，它俩的很多理念都是来自 12 要素（Twelve-Factor App），所以微服务概念和 FaaS 概念高度相似，也有不少公司用 FaaS 实现微服务架构。

后端应用 BaaS 化，首先要将复杂的业务逻辑拆开，拆成职责单一的微服务。因为职责单一，所以服务端运维的成本会更低。

为了 SaaS 设计的而提出的12要素，用来提升 Web 应用的适用性和可移植性。只能提供理论认识，微服务架构落地需要的微服务的 10 要素：API、服务调用、服务发现；日志、链路追踪；容灾性、监控、扩缩容；发布管道；鉴权。

解耦数据库

让数据库节点扩容时数据都保持同步更新，要解决这个问题，就要引入一个关键的Stateful对象，消息队列（Kafka、RocketMQ）。它是一个稳定的绝对值得信赖的 Stateful 节点，而且对应用来说消息队列是全局唯一的。

解耦数据库的思路就是，通过消息队列解决数据库和副本之间的同步问题，有了消息队列，剩下的就简单了。通过额外的进程将 MySQL的 binary log 变更同步到消息队列，并监听消息队列将 binary log 更新在本地执行，修改 MySQL。数据库和副本之间会有短暂的同步延迟问题，但问题其实也不大，因为通常对数据库进行写操作时也会锁表。

对于微服务来说，它本身的数据库还是 Stateful 的，但在微服务外部看来，这个微服务是 Stateless 的。跟传统的主从数据库方式不同的是，每个微服务的单点实例都是独享一个数据库的，这个微服务单点可以对外提供所有的 RESTful API 接口。

消息队列，例如 RocketMQ 的可靠性是 99.99999999%，而常用的虚拟机 ECS 的可靠性也只不过 99.95%。在高并发架构的设计中，通常会要求 Stateful 节点一定要稳定，而且越少越好，所以消息队列，对于微服务和 FaaS 来说，都是可以作为支撑业务的核心。依赖消息队列，会让整个架构更稳定。

领域驱动设计

BaaS 化的核心其实就是把后端应用封装成 RESTful API，然后对外提供服务，而为了后端应用更容易维护，要将后端应用拆解成免运维的微服务。

领域驱动设计是一套方法论：通过对业务分层抽象，分析定义出领域模型，用领域模型驱动我们设计系统，最终将复杂的业务模型拆解为独立运维的领域模型。

实际在使用微服务开发的过程，微服务整体应该是一个动态网络结构，随着业务的发展，这个网络结构也会发生变化。DDD 能帮助我们前期分析出一个较好的网络结构，但实际上，更应该思考的是如何整体优化动态网络：减少核心节点，保护核心节点，降低网络深度等等。

怎么理解动态网络优化呢？

做个思维实验：假设将所有的功能都拆解成微服务，任意的微服务节点之间都可以相互调用，调用越频繁它们之间的距离就越近。那么考虑一下，当网站的访问请求流量稳定后，整个微服务节点组成的网络状态是怎么样的？

1. 首先网络节点的相互制约总会让那些相互之间强依赖的、高耦合的节点，越走越近，最后聚集成一团节点。

2. 其次那些跟业务逻辑无关的节点，逐渐被边缘化，甚至消失。

看这些聚集成团的节点，如果团里的点聚合太近了，其实是不适合拆分的，它们整体应该作成一个微服务。等这些节点太近的团合并成一个微服务节点后，再看那些聚集在一起、又不太近的节点就是一个个微服务了。

所以，在启动项目时，不用太过纠结应该如何去拆解微服务。而应该持续关注，并思考每个微服务节点的合理性。就像看待动态网络一样，持续地调整优化，去除核心节点。最终它会伴随业务的发展阶段，达到各个阶段的稳定动态网络结构。

拆分完成的微服务就需要合并起来完成复杂的业务逻辑了，也就是将所有的容器进行编排。

• 像 SFF 那样通过传统的函数，将每个 HTTP 数据的请求结果通过数组或对象加工处理，再将这些结果返回是可以的。

• 另外一种编排思路，工作流，也就是用一个个事件去串联FaaS或微服务。（Serverless工作流，以阿里云为例。）