了解BFF架构

参考文章：
     - http://samnewman.io/patterns/architectural/bff/
     - https://os.alipayobjects.com/rmsportal/WtUmBLJSmqtDHkvJzuzM.pdf
     - http://www.ouchangjian.com/article/58c5f48c887279691018ec66
     - http://coolhfei.blog.163.com/blog/static/221440652016931101647644/
     - https://www.thoughtworks.com/insights/blog/bff-soundcloud

BFF全称是Backends For Frontends(服务于前端的后端)，Sam Newman曾在他的博客中写了一篇相关的文章——Pattern: Backends For Frontends，在文章中Sam Newman详细地说明了BFF。本文参考了几篇不一样博客和文章，简单阐述一下本身对BFF的认识。

---

简而言之，BFF就是服务器设计API时会考虑到不一样设备的需求，也就是为不一样的设备提供不一样的API接口，虽然它们多是实现相同的功能，但由于不一样设备的特殊性，它们对服务端的API访问也各有其特色，须要区别处理。所以出现了相似下图一种设计方式。

以上两张图有类似点，也有不一样之处。客户端都不是直接访问服务器的公共接口，而是调用BFF层提供的接口，BFF层再调用基层的公共服务，不一样的客户端拥有不一样的BFF层，它们定制客户端须要的API。图一和图二的不一样之处在因而否须要为类似的设备人，如IOS和android分别提供一个BFF，这个须要根据现实状况决定，不一样的项目环境解决手段不同。

---

那么采用BFF架构与多端公用、单一的API有什么优势了？最重要的一点在上文中已经提到了，它可以知足因不一样客户端特殊的交互引发的对新接口的要求，因此一开始就会针对相应的设备设计好对应的接口。若是使用单1、通用的API，咱们一开始并无考虑到特殊需求，那么有新的请求须要出现时，可能会出现如下问题：

(1)若是添加新的接口，这样容易形成接口的不稳定；
   (2)若是考虑在原有的接口上进行修改，可能须要会产生一些的耦合，破坏单一职责。

考虑这样一个简单例子，由于移动APP的屏幕限制，在某一个列表页咱们只须要展现一些关键的信息，可是因为调用的是服务端提供统一的API，服务端在设计的时候只考虑到了web端，返回全部的字段信息，但这些对于移动端而言都是无用的。在优化性能时处理这样的问题时，服务器端就须要新增接口或者经过引入相关耦合来解决这样的问题。而使用BFF在很大程度能避免这样的问题。
使用BFF的另外一个优势就是当因为某一客户端须要调用调用多个不一样的服务端接口来实现某一功能时，能够直接在对应的BFF层编写相应的API，而不会影响到基层的公共服务，且客户端不用直接向多个后台发起调用，能够优化性能。

---

固然，凡事有利有弊，BFF带来便利好处的同时也会引发一些问题，如代码重复，加大开发工做量等。因此在使用时须要结合现实状况仔细斟酌，符合项目的应用开发背景。例如蚂蚁财富使用BFF的场景以下。(没有具体分析，有兴趣的能够经过上面提供的连接和查阅相关资料进行研究)