后台即服务

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

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

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

API 演进史

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

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

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

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

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

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

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

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

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

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

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

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

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

后台即服务

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