后台即服务
---

> BaaS（Backend as a Service）是一种新型的云服务，旨在为移动和Web应用提供后端云服务，包括云端数据/文件存储、账户管理、消息推送、社交媒体整合等。

产生这种服务的主要原因之一是因为移动应用的流行。在移动应用中，我们实际上只需要一个API接口来连接数据库，并作一些相应的业务逻辑处理。对于不同的应用产商来说，他们打造API的方式可能稍有不同，然而他们都只是将后台作为一个服务。

在一些更特殊的例子里，即有网页版和移动应用端，他们也开始使用同一个API。前端作为一个单页面的应用，或者有后台渲染的应用。其架构如下图所示：

![Backend As A Service](chapters/images/baas-diagram.png)

###API演进史

在早期的工作中，我们会发现我们会将大量的业务逻辑放置到View层——如迭代出某个结果。

而在今天，当我们有大量的逻辑一致时，我们怎么办，重复实现三次？

如下所示是笔者之前重构的系统的一个架构缩略图：

![重复逻辑的系统架构](chapters/chapter2/duplicate-business-logic.png)

上面系统产生的主要原因是：技术本身的演进所造成的，并非是系统在一开始没有考虑到这个问题。

![API演进史](chapters/chapter2/api-history.png)

从早期到现在的互联网公司都有这样的问题，也会有同样的过程：

第一阶段： 因为创始人对于某个领域的看好，他们就创建了这样的一个桌面网站。这个时间点，大概可以在2000年左右。

第二阶段： 前“智能手机”出现了，人们需要开发移动版本的网站来适用用户的需要。这时由于当时的开发环境，以及技术条件所限，当时的网站只会是桌面模板的简化。这时还没有普及Ajax请求、SPA这些事物。

第三阶段： 手机应用的制作开始流行起来了。由于需要制作手机应用，人们就需要在网站上创建API。由于当时的业务或者项目需求，这个API是直接耦合在系统中的。

第四阶段： 由于手机性能的不断提高，并且移动网络速度不断提升，人们便开始在手机上制作单页面应用。

由于他们使用的是相同业务逻辑、代码逻辑相同而**技术栈不同**的代码，当有一个新的需求出现时，他们需要重复多次实现，如下图所示：

![重复业务逻辑的系统架构](chapters/chapter2/duplicate-business-logic-with-domain.png)

随后——也就是今天，各种新的解决方案出现了，如React、混合应用、原生+Web的混合式应用、他们的目的就是解决上述的问题。不过，这些解决方案只是为了解决在前端中可能出现的问题，详细的内容可以见《前端演进史》。

而人们也借此机会在统一后台——因为我们可以借助于混合应用或混合式应用（即原生+内嵌WebView，可以同时解决性能和跨平台问题）统一移动端，借助于响应式设计的理念可以统一桌面、平板和手机端。

因此，我们需要的就只是这样的一个API：

![One API](chapters/chapter2/one-api.png)

###后台即服务

现在，让我们来看看一个采用后台即服务的网站架构会是怎样的？
