微服务架构，这个在几年前还算比较前卫的技术在如今遍地开花。得益于开源社区的支持，我们可以轻松地利用 Spring Cloud 以及 Docker 容器化快速搭建一个微服务架构的原型。不管是成熟的互联网公司、创业公司还是个人开发者，对于微服务架构的接纳程度都相当高，微服务架构的广泛应用也自然促进了技术本身更好的发展以及更多的实践。本文将结合项目实践，剖析在微服务的背景下，如何通过前后端分离的方式开发移动应用。

         对于微服务本身，我们可以参考 Martin Fowler 对 Microservice 的阐述。简单说来，微服务是一种架构风格。通过对特定业务领域的分析与建模，将复杂的应用分解成小而专一、耦合度低并且高度自治的一组服务。微服务中的每个服务都是很小的应用，这些应用服务相互独立并且可部署。微服务通过对复杂应用的拆分，达到简化应用的目的，而这些耦合度较低的服务则通过 API 形式进行通信，所以服务之间对外暴露的都是 API，不管是对资源的获取还是修改。

        微服务架构的这种理念，和前后端分离的理念不谋而合，前端应用控制自己所有的 UI 层面的逻辑，而数据层面则通过对微服务系统的 API 调用完成。以 JSP (Java Server Pages) 为代表的前后端交互方式也逐渐退出历史舞台。前后端分离的迅速发展也得益于前端 Web 框架 (Angular, React 等) 的不断涌现，单页面应用(Single Page Application)迅速成为了一种前端开发标准范式。加之移动互联网的发展，不管是 Mobile Native 开发方式，还是 React Native / PhoneGap 之流代表的 Hybrid 应用开发方式，前后端分离让 Web 和移动应用成为了客户端。客户端只需要通过 API 进行资源的查询以及修改即可。

BFF 概况及演进

Backend for Frontends(以下简称BFF) 顾名思义，是为前端而存在的后端(服务)中间层。即传统的前后端分离应用中，前端应用直接调用后端服务，后端服务再根据相关的业务逻辑进行数据的增删查改等。那么引用了 BFF 之后，前端应用将直接和 BFF 通信，BFF 再和后端进行 API 通信，所以本质上来说，BFF 更像是一种“中间层”服务。下图看到没有BFF以及加入BFF的前后端项目上的主要区别。

1. 没有BFF 的前后端架构

   
   

在传统的前后端设计中，通常是 App 或者 Web 端直接访问后端服务，后台微服务之间相互调用，然后返回最终的结果给前端消费。对于客户端（特别是移动端）来说，过多的 HTTP 请求是很昂贵的，所以开发过程中，为了尽量减少请求的次数，前端一般会倾向于把有关联的数据通过一个 API 获取。在微服务模式下，意味着有时为了迎合客户端的需求，服务器常会做一些与UI有关的逻辑处理。

2. 加入了BFF 的前后端架构

加入了BFF的前后端架构中，最大的区别就是前端(Mobile, Web) 不再直接访问后端微服务，而是通过 BFF 层进行访问。并且每种客户端都会有一个BFF服务。从微服务的角度来看，有了 BFF 之后，微服务之间的相互调用更少了。这是因为一些UI的逻辑在 BFF 层进行了处理。

BFF 和 API Gateway

从上文对 BFF 的了解来看，BFF 既然是前后端访问的中间层服务，那么 BFF 和 API Gateway 有什么区别呢？我们首先来看下 API Gateway 常见的实现方式。（API Gateway 的设计方式可能很多，这里只列举如下三种）

1. API Gateway 的第一种实现：一个 API Gateway 对所有客户端提供同一种 API

单个 API Gateway 实例，为多种客户端提供同一种API服务，这种情况下，API Gateway 不对客户端类型做区分。即所有 /api/users的处理都是一致的，API Gateway 不做任何的区分。如下图所示：

2. API Gateway 的第二种实现：一个 API Gateway 对每种客户端提供分别的 API

单个 API Gateway 实例，为多种客户端提供各自不同的API。比如对于 users 列表资源的访问，web 端和 App 端分别通过 /services/mobile/api/users, /services/web/api/users服务。API Gateway 根据不同的 API 判定来自于哪个客户端，然后分别进行处理，返回不同客户端所需的资源。

3. API Gateway 的第三种实现：多个 API Gateway 分别对每种客户端提供分别的 API

在这种实现下，针对每种类型的客户端，都会有一个单独的 API Gateway 响应其 API 请求。所以说 BFF 其实是 API Gateway 的其中一种实现模式。

GraphQL 与 REST

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

GraphQL 作为一种 API 查询语句，于2015年被 Facebook 推出，主要是为了替代传统的 REST 模式，那么对于 GraphQL 和 REST 究竟有哪些异同点呢？我们可以通过下面的例子进行理解。

按照 REST 的设计标准来看，所有的访问都是基于对资源的访问（增删查改）。如果对系统中 users 资源的访问，REST 可能通过下面的方式访问：

Request:

GET http://localhost/api/users

Response:

[

  {

    "id": 1,

    "name": "abc",

    "avatar": "http://cdn.image.com/image_avatar1"

  },

  ...

]

对于同样的请求如果用 GraphQL 来访问，过程如下：

Request:

POST http://localhost/graphql

Body:

query {users { id, name, avatar } }

Response:

{

  "data": {

    "users": [

      {

        "id": 1,

        "name": "abc",

        "avatar": "http://cdn.image.com/image_avatar1"

      },

      ...

    ]

  }

}

关于 GraphQL 更详细的用法，我们可以通过查看文档以及其他文章更加详细的去了解。相比于 REST 风格，GraphQL 具有如下特性：

1. 定义数据模型：按需获取

GraphQL 在服务器实现端，需要定义不同的数据模型。前端的所有访问，最终都是通过 GraphQL 后端定义的数据模型来进行映射和解析。并且这种基于模型的定义，能够做到按需索取。比如对上文 /users资源的获取，如果客户端只关心 user.id, user.name 信息。那么在客户端调用的时候，query 中只需要传入 users {id \n name}即可。后台定义模型，客户端只需要获取自己关心的数据即可。

2. 数据分层

查询一组users数据，可能需要获取 user.friends, user.friends.addr 等信息，所以针对 users 的本次查询，实际上分别涉及到对 user, frind, addr 三类数据。GraphQL 对分层数据的查询，大大减少了客户端请求次数。因为在 REST 模式下，可能意味着每次获取 user 数据之后，需要再次发送 API 去请求 friends 接口。而 GraphQL 通过数据分层，能够让客户端通过一个 API获取所有需要的数据。这也就是 GraphQL（图查询语句 Graph Query Language）名称的由来。

{

  user(id:1001) { // 第一层

    name,

    friends { // 第二层

      name,

      addr { // 第三层

        country,

        city

      }

    }

  }

}

3. 强类型

const Meeting = new GraphQLObjectType({

  name: 'Meeting',

  fields: () => ({

    meetingId: {type: new GraphQLNonNull(GraphQLString)},

    meetingStatus: {type: new GraphQLNonNull(GraphQLString), defaultValue: ''}

  })

})

GraphQL 的类型系统定义了包括 Int, Float, String, Boolean, ID, Object, List, Non-Null 等数据类型。所以在开发过程中，利用强大的强类型检查，能够大大节省开发的时间，同时也很方便前后端进行调试。

4. 协议而非存储

GraphQL 本身并不直接提供后端存储的能力，它不绑定任何的数据库或者存储引擎。它利用已有的代码和技术进行数据源的管理。比如作为在 BFF 层使用 GraphQL, 这一层的 BFF 并不需要任何的数据库或者存储媒介。GraphQL 只是解析客户端请求，知道客户端的“意图”之后，再通过对微服务API的访问获取到数据，对数据进行一系列的组装或者过滤。

5. 无须版本化

const PhotoType = new GraphQLObjectType({

  name: 'Photo',

  fields: () => ({

    photoId: {type: new GraphQLNonNull(GraphQLID)},

    file: {

      type: new GraphQLNonNull(FileType),

      deprecationReason: 'FileModel should be removed after offline app code merged.',

      resolve: (parent) => {

        return parent.file

      }

    },

    fileId: {type: new GraphQLNonNull(GraphQLID)}

  })

})

GraphQL 服务端能够通过添加 deprecationReason，自动将某个字段标注为弃用状态。并且基