后台即服务

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

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

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

Backend As A Service

API 演进史

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

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

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

重复逻辑的系统架构

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

API 演进史

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

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

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

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

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

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

重复业务逻辑的系统架构

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

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

因此,我们需要的就只是这样的一个 API:

One API

后台即服务

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