前言

由于项目在开发初期为了赶进度，快速上线，没有很好的规划和设计，导致现在随着需求的变化和功能的扩展，代码逐渐变得非常复杂和难以维护。为了保持代码的质量和可读性，我们需要进行代码重构。代码重构是一种对现有代码进行重新组织和优化的过程，旨在提高代码的质量和可读性，同时不改变其功能。代码重构的目标是使代码更加清晰、易于理解和维护，以便在未来的开发中更加高效地进行修改和扩展。

这里重构我们采用了通用的微服务架构模型，如图：

架构思考

在项目开发中，通常我们由一个域名绑定一个或多个ip，服务到我们系统部署的门户网关[流量网关]，这类型的网关负责对整个服务集群的负载均衡功能和统一入口，毕竟再复杂的系统对用户来说应该都只有一个统一访问路径，这样的统一访问路径通常对用户来说是一个域名。对于一个域名而言它的功能就是映射到某个ip，而这个ip再转发给我们的内部服务。

系统重构

依据上面的架构思考和公司的主要业务线，我们把系统拆分为三大块，阅读应用，短视频应用和交易应用，架构如图：

阅读应用，短视频应用和交易应用 差距很大，所以比较合适的方案就是独立部署，开发各自的业务网关 和 聚合服务，比如：今日头条，抖音，抖音商城也是采用独立部署的。

流量网关

流量网关,顾名思义就是控制流量进入集群的网关,有很多工作需要在这一步做,对于一个服务集群,势必有很多非法的请求或者无效的请求,这时候要将请求拒之门外,降低集群的流量压力。

定义全局性的、跟具体的后端业务应用和服务完全无关的策略网关就是上图所示的架构模型——流量网关。流量网关通常只专注于全局的Api管理策略，比如全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等，有点类似防火墙。这里我们采用 Nginx 做流量网关。

业务网关

当一个单体应用被拆分成许许多多的微服务应用后，也带来了一些问题。一些与业务非强相关的功能，比如权限控制、日志输出、数据加密、熔断限流等，每个微服务应用都需要，因此存在着大量重复的代码实现。而且由于系统的迭代、人员的更替，各个微服务中这些功能的实现细节出现了较大的差异，导致维护成本变高。另一方面，原先单体应用下非常容易做的接口管理，在服务拆分后没有了一个集中管理的地方，无法统计已存在哪些接口、接口定义是什么、运行状态如何。

网关就是为了解决上述问题。作为微服务体系中的核心基础设施，一般需要具备接口管理、协议适配、熔断限流、安全防护等功能，各种开源的网关产品（比如 Spring Cloud Gateway）都提供了优秀高可扩展性的架构、可以很方便的实现我们需要的一些功能、比如鉴权、日志监控、熔断限流等。

什么是BFF？

BFF：Backends For Frontends（服务于前端的后端）。

BFF是一种Web架构，微服务设计系列丛书的作者 Sam Newman曾在他的博客中写了一篇相关文章《Pattern: Backends For Frontends》。

BFF（Backends For Frontends）设计是一种Web架构，旨在通过为前端应用程序提供单独的API网关来优化用户体验和性能。

BFF架构设计的核心思想是为前端应用程序提供一个专门的API网关，该网关专门服务于前端，处理路由、聚合操作等，从而使前端应用程序能够更加专注于用户体验和交互逻辑。这种架构模式有助于提高性能和用户体验，降低前后端的耦合度，简化前端开发，并提高系统的安全性。BFF适用于各种规模的应用程序，尤其适用于需要处理大量用户请求、提供高性能和高可用性的场景。