微处事架构，这个在几年前还算对照前卫的技术在如今到处开花。得益于开源社区的撑持，我们可以轻松地操作 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