初识BFF架构设计

BFF是（Backends For Frontends）单词的缩写，主要是用于服务前端的后台应用程序，来解决多访问终端业务耦合问题。

最近在公司的微服务架构中遇到了一些多终端访问接口的问题，不一样的终端拥有不一样的接口服务，有不一样的操做数据的能力，针对这种业务场景作出了调研，咱们是否能够在不一样的访问层进行业务逻辑处理，获取不一样的数据内容呢？

早在微服务出现的初期就已经存在相似的业务需求出现，并且衍生出了一套成熟的解决方案，那就是BFF，能够针对不用业务场景来提供对应的服务接口，每一种业务场景之间彻底独立。

演进过程

在传统的应用程序中，咱们通常只将接口提供给一种类型的终端使用。

单端调用基础服务

传统的应用程序内提供的接口是有业务针对性的，这种类型的接口若是独立出来再提供给别的系统再次使用是一件比较麻烦的事情，设计初期的高耦合就决定了这一点。

多端直接调用基础服务

若是咱们的接口同时提供给web、移动端使用，移动端仅用来采集数据以及数据的展现，而web端大多数场景是用来管理数据，由于不一样端点的业务有所不一样每个端的接口复用度不会过高。

多端共用一个BFF

针对多端共用服务接口的场景，咱们将基础的数据服务与BFF进行了分离，数据服务仅提供数据的增删改查，并不过多涉及业务的判断处理，全部业务判断处理都交给BFF来把控，遇到的一些业务逻辑异常也一样由BFF格式化处理后展现给访问端点。

这种设计方式一样存在必定的问题，虽然基础服务与BFF进行了分离，咱们只须要在BFF层面进行业务判断处理，可是多个端共用一个BFF，也会致使代码编写复杂度增高、代码可阅读性下降、多端业务耦合。

每一个端提供一个BFF

若是咱们为每个端点都提供一个BFF，每一个端点的BFF处理自身的业务逻辑，须要数据时从基础服务内获取，而后在接口返回以前进行组装数据用于实例化返回对象。

这样基础服务若是有新功能添加，BFF几乎不会受到影响，而咱们若是后期把App端点进行拆分红Android、IOS时咱们只须要将app-bff进行拆分为android-bff、ios-bff，基础服务一样也不会受到影响

这样每当新增一个访问端点时，咱们须要修改的地方也只有网关的转发以及添加一个BFF便可，基础服务内提供的服务接口咱们彻底能够复用，由于基础服务提供的接口都是没有业务针对性的！！！

总结

在微服务架构设计中，BFF起到了一个业务聚合的关键做用，能够 经过openfeign、restTemplate调用基础服务来获取数据，将获取到的数据进行组装返回结果对象，BFF解决了业务场景问题，也一样带来了一些问题，以下所示：

• 响应时间延迟（服务若是是内网之间访问，延迟时间较低）
• 编写起来较为浪费时间（由于在基础服务上添加的一层转发，因此会多写一部分代码）
• 业务异常处理（统一格式化业务异常的返回内容）
• 分布式事务（微服务的通病）