参考文章：
- 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
- https://segmentfault.com/a/1190000009558309
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有什么优点了？最重要的一点在上文中已经提到了，它能够满足因不同客户端特殊的交互引起的对新接口的要求，所以一开始就会针对相应的设备设计好对应的接口。如果使用单一、通用的API，我们一开始并没有考虑到特殊需求，那么有新的请求需要出现时，可能会出现以下问题：
(1)如果添加新的接口，这样容易造成接口的不稳定；
(2)如果考虑在原有的接口上进行修改，可能需要会产生一些的耦合，破坏单一职责。
考虑这样一个简单例子，因为移动APP的屏幕限制，在某一个列表页我们只需要展示一些关键的信息，但是由于调用的是服务端提供统一的API，服务端在设计的时候只考虑到了web端，返回所有的字段信息，但这些对于移动端而言都是无用的。在优化性能时处理这样的问题时，服务器端就需要新增接口或者通过引入相关耦合来解决这样的问题。而使用BFF在很大程度能避免这样的问题。
使用BFF的另一个优点就是当由于某一客户端需要调用调用多个不同的服务端接口来实现某一功能时，可以直接在对应的BFF层编写相应的API，而不会影响到基层的公共服务，且客户端不用直接向多个后台发起调用，可以优化性能。
当然，凡事有利有弊，BFF带来便利好处的同时也会引起一些问题，如代码重复，加大开发工作量等。所以在使用时需要结合现实情况仔细斟酌，符合项目的应用开发背景。例如蚂蚁财富使用BFF的场景如下。(没有具体分析，有兴趣的可以通过上面提供的链接和查阅相关资料进行研究)
