BFF 项目设计

July 1, 2023

参加工作的头一年，主要在电商业务下负责 BFF 层项目的开发。接触了电商中比较核心的交易链路，平时业务繁多，淡季的 QPS 也有几百左右。

什么是交易链路h2

bff-flow.png

什么是 BFFh2

BFF（Backend for Frontend) 一种在微服务架构下衍生的设计模式，是 API 网关模式的一个变种，BFF 作为各个微服务和端上的中间层。

目的是减少各端与繁杂的微服务之间的交互难度，BFF 的职责也是为了保证全流程稳定的情况下，组织、聚合、编排各服务的数据。

交易链路聚合系统h2

bff-framwork.png

交易链路，作为电商 GMV 的核心部分。做这方面的上层业务，在引入新功能时，要合理控制耗时的增加，同时保证系统的稳定。

我在从零搭建这个系统时，采用了 Sentinel 流量控制中间件。

Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量控制、流量路由、熔断降级、系统自适应保护等多个维度来帮助用户保障微服务的稳定性。

可以从官网的介绍中了解到 Sentinel 的职责就是保证各微服务接口的稳定，中间件本身通过采用责任链模式和滑动窗口严格控制打入的流量。

官方其实提供了一套监控页面，我们为了减少引入的外部依赖，采用手动编写规则来控制 Sentinel 管控的资源。

三方接口的统一封装h3

sentinel-resource.png

将每个三方接口封装为 Sentinel 资源，方便 Sentinel 管理。搭配 Nacos 动态配置处理降级逻辑。

Nacos 动态配置降级熔断h3

resourcePolicy=
[
    {
        "resourceName": "XXResource", //资源名称
        "type": 1, //降级方式，默认关闭；0-关闭，不启用降级；1-手动降级，直接关闭资源访问；2-自动降级，根据规则配置降级 ;
        "blockRules": [  //降级规则，支持限流、熔断
            {
                "degrade": 1, //降级方式：1-限流，限制qps；2-熔断；
                "threshold": 20//规则生效阀值，degrade=1时，表示限制qps的最大值；degrade=2时，表示服务异常比例
            },
            {
                "degrade": 2, //降级方式：1-限流，限制qps；2-熔断；
                "threshold": 24,
//规则生效阀值，degrade=1时，表示限制qps的最大值；degrade=2时，表示服务异常比例
                "minQps": 21 //degrade=2时生效，表示触发熔断的最小qps
            }
        ]
    }
]

个人中心h2

电商的个人中心需要展示包括订单信息、活动信息、收藏、历史记录等模块。

设计思路是采用 Java 8 的 CompletableFuture 将每个抽象的楼层并行处理，然后统一聚合出个人中心页。

concurrency.png

为每个 CompletableFuture::get() 设定超时展示兜底数据。接入日志报警来监控流量波动导致的超时变化从而发现问题寻找优化的可能。

在双十一的零点状态，有心观察一下，可以发现淘宝的做法是在零点到来之前手动降级个人中心页的个性化数据如 浏览数、订单数等。需要将资源更多的给到活动页和交易链路。

总结h2

在电商业务接触了很多高并发的场景，也经历了大促的通宵压测和盯盘。技术方面实践了 Java 并发的 API 和线程池。

cd ~