1.0版本

直接将服务穿透到外网。

API层只是套了壳，加了鉴权、中间件而已。具体返回值由服务定。

客户端到微服务直接通信，强耦合。根本不敢重构，一改结构客户端就崩了。
需要多次请求，客户端聚合数据，工作量巨大，延迟高。
- 缺乏统一的文档。
- 如果一个页面由多个服务组成，比如商品、优惠券、相关推荐、评价。客户端要请求多个接口，命名规则还不一样。
- 有的接口成功，有的接口失败，需要客户端自己做降级。
协议不利于统一，各个部门间有差异，需要客户端端来兼容。
面向“端”的API适配，耦合到了内部服务。
- 每个服务都要为不同的设备做适配代码。
多终端兼容逻辑复杂，每个服务都需要处理。
统一逻辑无法收敛，比如安全认证、限流。

这样就导致了客户端、服务端都累得要死，谁都不讨好。

而我们的架构设计应该前轻后重的，面向业务场景设计接口，而不是面向数据资源。（不要让客户端做组装）

2.0版本

架构就是一层加一层。

添加了一个BFF层，backend for forntend，专门做适配。

我们新增了一个 app-interface 用于统一的协议出口，在服务内进行大量的 dataset join，按照业务场景来设计粗粒度的 API，给后续服务的演进带来的很多优势：

对接：

大前端---网关，只用对接数据结构。面向业务场景提供接口。

网关---服务，只需要对接服务接口。

BFF可以认为是一种适配服务，将后端的微服务进行适配(主要包括聚合裁剪和格式适配等逻辑)，向无线端设备暴露友好和统一的 API，方便无线设备接入访问后端服务。

针对页面提供接口，比如商品页面，就一个接口，然后BFF层去调用多个服务，在这里做降级，比如优惠券服务没有返回就不显示就完了。

客户端只用和BFF层沟通，什么适配、协议、兼容、定制都是这一层来做。客户端感觉很爽。

服务端也只用提供基础数据，不用关心业务逻辑，不用管适配，返回的接口是什么结构。服务端也很爽。

BFF层只做了数据裁剪，兼容之类的逻辑，轻不轻松？也很轻松。

将BFF根据业务拆分，比如查看商品一个，订单页面一个。这样一个挂不会影响全局。

有没有发现：

分久必合、合久必分。

分开了就有不能统一的地方，合并了就会单点故障。

跨横切面(Cross-Cutting Concerns)的功能，需要协调更新框架升级发版(路由、认证、限流、安全)，因此全部上沉，引入了 API Gateway，把业务集成度高的 BFF 层和通用功能服务层 API Gateway 进行了分层处理。

在新的架构中，网关承担了重要的角色，它是解耦拆分和后续升级迁移的利器。

在网关的配合下，单块 BFF 实现了解耦拆分，各业务线团队可以独立开发和交付各自的微服务，研发效率大大提升。

BFF的划分：

另外，把跨横切面逻辑从 BFF 剥离到网关上去以后，BFF 的开发人员可以更加专注业务逻辑交付，实现了架构上的关注分离(Separation of Concerns)。

我们业务流量实际为：

移动端 -> API Gateway -> BFF -> Mircoservice

在 FE Web业务中，BFF 可以是 nodejs 来做服务端渲染(SSR，Server-Side Rendering)，注意这里忽略了上游的 CDN、4/7层负载均衡(ELB)。

将通用逻辑做到了API网关层，BFF层专注于业务逻辑。

API层采用Nginx这种高可用的软件，基本不会挂，挂了重启即可，限流、负载等逻辑用模块实现，方便部署。

这一层完全和业务无关。

当耦合性太高的时候，就加一层，作为缓冲。

当合并有单点的时候，就分开。当分开有不能统一的时候，就合并。

尽量让专门的人做专门的事情。减少业务对技术的耦合。