前端网关的思考

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

在此种模式下，每一个 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 层的存在，退化到仅仅是一层代理，如同虚设。

咱们也在寻找一种适合于咱们本身业务模型的架构模式。

API 网关的介入

实践事后，咱们决定去掉 BFF 层，而引入更为通用的从属于前端的 API 网关层（注：BFF 是 API 网关模式的一个特例）：

在这个 API 网关层中，咱们再也不作数据的聚合与裁剪，由于这些对于一个中后台的内部系统来讲，并不重要。

使用 API 网关，也着实解决了咱们的一些痛点：

• 解耦合，API 网关有一个重要的功能，就是将用户的请求转发给后端的服务器，微服务进行重构时，只须要改 API 网关中的映射关系便可，无需修改前端代码。
• 前端代码易于维护。引入 API 网关之后，全部的前端接口都请求至 API 网关，由网关负责具体请求的服务器，而无需维护大量的 URL。
• 日志，全部的请求都是由网关处理，日志比较完善，好比接口耗时、请求方式、请求 IP、参数等。同时，还可使用 traceId，追踪整个链路的调用，方便排查问题。
• 其余一些，好比限流和缓存等，在 API Gateway 也能够实现。

固然，咱们也有一些 2C 的产品，这些产品中，有一部分咱们是使用 Vue/React SSR 技术，

在这个 Vue/React SSR 中，必定程度上，也充当着 BFF 层的做用。

总结

咱们并无使用传统的 Client->API网关->BFF->微服务 架构模式，面对特殊的业务场景（大量的中后台应用），咱们取消了 BFF 层，使用了 Client->API网关->微服务，而对于 2C 的应用使用 Clent(SSR)->API网关->微服务 这样架构模式。

固然，咱们也在尝试、探索基于 Serverless 的 Gateway 架构：

（图片来自：github.com/nodejh/node…

Serverless 在更多、更复杂领域的实践值得期待。

---

更多文章，请关注公众号：