1、从一个MyShop开始提及
为了讲清BFF是个啥，这里引用我在波波老师的课程《Spring Boot与K8s云原生应用开发》中学到的一个案例，来跟你们分享一下，并尽力说清楚BFF是啥，又是如何演化出来的。前端
假设咱们在一个开发团队中，开发了一个叫作MyShop的电商项目，它采用的是微服务的架构风格。它经历过几回架构调整，咱们就跟着它的调整来看看BFF是怎么演化出来的。程序员
假设v1版本在七八年以前，MyShop已经采用了服务化的架构，它的客户端也主要仍是以传统的Web应用为主。在当时，它的SOA架构已经算是跟上了潮流。面试
转眼之间，来到了四五年前，MyShop升级为了v2版本，它的架构以下图所示：后端
能够看到，这个时候已经进入了移动互联网时代，MyShop为了紧跟时代，也推出了本身的无线应用App。为了可以尽快上线，MyShop团队的架构师设计了v2架构，它为App端新增了一个Nginx反向代理，可使App入口直接访问API微服务。安全
可是，这个急于求成的v2架构存在如下问题：架构
（1）App端和内部的API微服务存在一个强耦合的关系（包括接口耦合和域名耦合），任何一边的变化都会对另一边形成必定影响。app
（2）每一个对外暴露的服务，都须要新的域名，而域名是须要买的，是须要承担成本的。负载均衡
（3）内部的API微服务一股脑地暴露在了公网上面，存在很大的安全风险。框架
（4）App客户端须要开发大量的聚合裁剪的逻辑，客户端很重且重复劳动。（所谓聚合裁剪，解释一下，聚合就是一次须要从多个微服务获取数据进行整合使用，而裁剪就是须要对微服务返回的数据进行过滤，可能只会用到其中一部分的字段数据）前后端分离
2、引入BFF的MyShop v2.5
因为v2版本存在的问题太多，因而架构团队决定在Nginx和内部API微服务之间引入一层无线BFF（英文全称：Backend For Frontend，指为前端应用开发的后端服务）来解决这个问题，也就有了下面的v2.5版本的架构。
咱们能够将BFF看作是一个后端微服务的代理服务，它主要作聚合和裁剪的逻辑，方便客户端接入和访问。能够看到，引入了BFF以后，下降了App端与后端微服务之间的耦合，从而避免了v2版本提到的强耦合问题。此外，App端只须要知道BFF的域名便可，内部微服务也躲在BFF以后不须要暴露在公网之上。
因为v2.5版本解决了不少问题，所以成功上线，也为MyShop无线业务的发展作了很大的支持。
可是，随着业务的不断快速发展，单块的无线BFF堆积了大量的不一样业务线的逻辑变得愈来愈臃肿，升级维护也变得愈来愈困难。此外，根据康威法则，单块的无线BFF和多团队也出现了不匹配的问题，即团队之间沟通成本变低，交付成本也就会变高。最后，无线BFF里面除了多业务线的聚合裁剪逻辑，还引入了Cross-Cutting（跨横切面）的逻辑，好比安全认证、日志监控、限流熔断等等。随着时间的推移，代码变得愈来愈复杂，技术栈越堆越多，开发效率也不断降低。（固然，还有单点问题等等，这里就很少赘述了）
3、网关+BFF模式的MyShop v3
为了解决v2.5版本存在的问题，架构团队通过进一步思考，一方面决定将单块的无线BFF进行解耦拆分，针对不一样的业务线引入独立的微服务集群。另外一方面，决定在无线BFF和Nginx之间再引入一个新的角色：API网关，并将Cross-Cutting的职责转移到API网关上。自此，v3架构出炉，以下图所示：
v3架构下，BFF按照团队或业务线的边界进行划分，每一个业务线团队能够并行各自开发和交付BFF。而网关则由单独的中间件或框架团队进行开发和维护，它专一于路由转发和Cross-Cutting层面的功能建设，让业务线团队专一于业务逻辑的开发。咱们.NET程序员所熟知的Ocelot网关项目（对，就是张队参与贡献的那个网关项目），就帮助咱们实现了路由转发和Cross-Cutting的功能，例如限流熔断、集中鉴权（例如集成IdentityServer）、负载均衡、调用追踪等。
4、乘风破浪的MyShop v4
最近一两年呢，MyShop团队迎来了新的业务和技术的发展需求，要开放内部的企业级能力建设OpenAPI开放平台，还想要借助第三方的力量在MyShop平台上进行创新打造生态从而丰富MyShop的应用形态。此外，SPA单页应用、H5先后端分离应用等多类型的应用客户端也须要接入。架构团队设计了一个以下图所示的v4架构，从而知足快速发展的已有和将来可能的需求：
在v4架构下，移除了原来偏运维层面的Nginx反向代理，转而统一使用可变成型较强的网关做为客户端应用入口，固然这里引入了一些其余的LB服务作了网关层的负载均衡。这里的网关也进行解耦拆分，针对不一样的客户端应用场景，分为了四个类型，如开放平台网关、H5网关、无线网关和Web应用网关。而BFF层面，也根据业务线拆分为了无线BFF、H5 BFF及开放平台BFF。整个架构层次清晰，职责分明，是一种灵活的、方便支持MyShop业务快速发展的架构。相信看到这里，你大概应该明白了BFF是个啥，它在微服务架构中的位置和做用，以及它是如何演化出来的。
画外音：若是还没明白，那就再看一遍！
5、我司还处于v3阶段
刚刚经过MyShop的案例架构演化，讲解了BFF和网关是如何演化出来的。那么，你可能会问，我司的架构处在哪一个阶段。这里，回答一下，还在v3阶段。
能够从这个技术体系图中看到，做为应用服务层的API服务就是BFF，他们会从基础业务服务如客户服务、订单服务、产品服务等微服务中获取数据，进行必定的聚合和裁剪返回个某个具体业务线的前端应用，前端应用多是SPA也多是H5应用。
BFF层的API服务，咱们在实践中大部分都使用了ASP.NET Core进行开发，同时也在尝试使用Go进行开发，也让前端有兴趣的同事引入进来用Go进行BFF的开发。可是，在基础服务层面即前面所说的业务中台层，仍是由后端同事使用ASP.NET Core开发，确保质量。
API网关层面，咱们使用的是Ocelot，集成了鉴权认证等工做，前端统一只须要记住网关的域名便可，带上合法的token访问便可获取数据返回。不少人说Ocelot性能低建议使用Kong，可是我司业务量小啊，因此目前没啥问题，用得好好的。
内部微服务之间的相互调用，咱们目前也是走了API网关（区别于外部应用访问的网关，这里我称之为内部网关），不过为了方便（实际上是懒），咱们对于内部信任的服务间调用，没有走JWT认证，固然也能够选择Client Credentials（客户端凭证）模式。
对于现阶段的咱们的架构来讲，只能说是够用，由于业务量真的不大，也不必为了上所谓的高性能高可用架构作过多的设计，对传统家居装饰行业的企业来讲，IT先知足业务支持业务快速发展吧。数字化转型，也并非一次就吃个胖子，慢慢演进吧。最后，想着是快答，竟然也洋洋洒洒写了这么多，但愿对你有所帮助吧！
推荐阅读：
牛皮了，马士兵老师全网首播阿里P8级技术、实现大型淘宝实战落
面试美团被JVM惨虐？阿里P9架构师用500分钟把JVM从入门讲到实战#合集
清华启蒙架构师马士兵针对应届生到开发十年的Java程序员作职业把脉