@
leiuu #33 架构设计上都不是绝对的，而且随着一个项目的发展，系统架构会发生变化，一个组件的定位也可能会改变，叫法也随之改变。
叫啥取决于你们现在觉得它更贴近哪种功能，比如：
应用 BFF 的场景通常是这样的：一套后端服务同时被多个前端产品对接（如 QQ 和 TIM ），如果将多个前端产品的后端 API 都混合在一起，会增加接口的复杂度和管理难度，而且针对一个前端产品的修改会有更大的可能影响其他产品；那么就可以引入 BFF ，后端开发团队负责提供统一且灵活的 API ，由各个前端产品的开发团队负责在这些 API 的基础上针对前端产品对 API 进行组合、转换，同时添加一些仅本前端产品会用到的一些专用 API 。
应用 API 网关的场景通常是这样的：产品由多个后端服务提供功能，但每个服务都需要做相同的处理，如安全、认证与鉴权、监控，或仅仅希望使用统一的域提供这些 API 来简单解决一些浏览器的安全限制，这时候就可以引入 API 网关，主要作用是聚合多个服务的 API ，以及应用统一的中间件。
上一段提到了中间件，恩，这个地方也可能是个中间件，当然中间件这个概念的定义是有些争议或迁移引申的，这个主题里就不进行讨论了。我所遇到的情况通常是有个组件不大关心业务逻辑，提供可以用于任何服务的一些基本能力，比如你的前端是成千上万个智能硬件，每隔一段时间上报状态数据，为了削峰填谷可以在前后端之间放个消息队列中间件（可以是现成的产品也可以是自己实现的），后端匀速消费这些消息来处理业务。
还有一种情况，就是后端本身是可以分层的，比如多个业务的服务都可能调用同一个短信网关服务来给用户发短信，这个短信服务就在其他服务的底层。这种情况下都可以叫后端服务。
当然，也可能会存在一个组件同时具备多项功能的情况，或者多种组件排列的情况，又或者是由于项目本身特殊性而存在的特殊功能和特殊名称的组件。
