前端网关的思考

在微服务体系结构中，客户端应用通常需要使用来自多个微服务的功能，在小型应用程序中，通常会使用客户端到微服务直接通信的方式：

在此种模式下，每个 Microservice 可能有一个不同的 TCP 端口，或者配置了不同的 URL 地址。

在一个基于微服务的小型应用程序中，它能基本满足，尤其是在客户端应用为服务器端 Web 应用程序（如 ASP.NET MVC 应用）的情况下。但是，若要生成基于微服务的大型复杂应用程序（例如处理大量微服务类型），尤其是客户端应用是远程移动应用或 SPA Web 应用程序时，该方法将面临一些问题：

强耦合：各 App 与内部微服务之间强偶合，任何一边变换都可能对另外一边造成影响。
安全性问题：微服务暴露在「外部世界」中，相较于不直接使用内部微服务，这种情况下攻击面更大。攻击面越小，意味着应用程序越安全。
过多的请求：可能某个功能需要调用几个后端接口请求进行组合后展示。
没有专为移动应用适配：多个微服务的 API 设计可能无法满足不同客户端应用程序的需求。如，移动应用的需求不同于 Web 应用，它需要进一步的优化，以便数据响应能更有效。

BFF 架构的诞生

在 Sam NewMan 的一篇文章 Pattern: Backends For Frontends 中，最早提出 BFF 概念，认为 BFF 是复杂应用的自然产物。BFF 即是用户体验适配层，根据不同的设备类型，来返回不同的结果。

根据业务边界和客户端应用划分的 BFF 层，能提供诸如反向代理、接口聚会、裁剪等功能，除此之外，BFF 层的出现让领域模型与页面数据更好的解耦，让彼此更高效。

理想情况下，前端页面与 BFF 层由不同的同学开发，前端人员专注于页面数据；开发 BFF 的同学，则按需聚合、裁剪数据返回给前端。但是现实往往是 BFF 以及页面数据都由前端人员来开发，尤其是对于做中后台的系统来说，一个前端同学既要写复杂的业务逻辑，同时又负责 BFF 层的开发，久而久之，BFF 层的存在，退化到仅仅是一层代理，如同虚设。

我们也在寻找一种适合于我们自己业务模型的架构模式。