乐趣区

关于后端:Reactor-第九篇-WebFlux重构个人中心效果显著

jiezi

1 重构背景

原有的开发人员早已到职，代码细节没人晓得，通过了一段时间的保护，发现有以下问题：

集体核心零碎的特色就是组装各个业务的接口，输入集体核心业务须要的数据，整个零碎调用了几十个第三方业务线的接口，如果编排不合理，可能会导致响应工夫急剧上涨，尤其是弹窗业务，新的弹窗会一直接入，整个接口可能会不可用。

2 整体架构

service：是最小的业务编排单元，request 办法对 infrastructure 第三方接口进行编排调用；apply 办法对第三方接口调用的后果进行组装，后果是 service 的业务返回；

infrastructure：是对第三方的异步非阻塞调用，不蕴含业务逻辑。一个 service 外部依据理论业务能够编排 0 个或者多个 infrastructure 服务。

在理论优化过程中咱们形象了 30 多个 infrastructure 第三方调用，40 多个 service。他们都是小而且独立的类，加重了开发同学尤其是新同学相熟的老本。边界也比拟清晰，逻辑内聚。

2 编排举例

每个 service 外部都是由一个或者多个 infrastructure 第三方调用组装编排的业务单元，外部解决能异步解决的全是应用异步解决，切实不能异步解决的应用串行 + 并行的形式。

2.1 串行

须要串行的能够应用 flatMap 办法，能够参考以下格局。

这种形式会执行 S1，而后 S2。

伪代码如下：

Mono.from(service1.func())
                .flatMap(service1Res-> {return service2.func();
        })

2.2 并行

zip 和 zipWith，zipWith 一次组装一个 Mono，zip 一次能够组装多个 Mono。

示例代码如下：

service1.zipWith(service2)

Mono.zip(service1, service2, service3)

一个应用 zip 组装多个 service 的示例代码，并行执行 service1, service2, ……, service6，应用 doOnError 处理错误，onErrorReturn 解决异样返回，doOnFinally 监控整个接口调用量、耗时状况。

Mono.zip(service1, service2, service3, service4, service5, service6)
                .map(t -> {String service1Ret = t.getT1();
                    String service2Ret = t.getT2();
          // ....
                    return "组合后果";
                })
        // 异样返回
                .onErrorReturn(new DTO())
                .doOnError(e -> {// 异样详情日志；异样申请量监控})
                .doFinally(e -> {// 申请量、耗时监控});

2.3 并行 - 但只取第一个有数据的后果

弹窗类业务与个别 service 不通，它须要调用很多的业务的数据出不同的弹窗，然而每次都只能给用户展现确定的一个。然而如果串行的话，随着上线的弹窗越来越多，整个弹窗接口的耗时会越来越长。

然而如果改成异步的话，又无法控制弹窗之间的优先级，优先级对于公司整体业务来说是必要的，把重要的业务放在高优的地位上，做到资源最大利用，能力实现利润的最大化，从而做到基业长青。

Flux 有个 flatMapSequential 办法，它能完满解决这个问题，看看它的正文：

Transform the elements emitted by this Flux asynchronously into Publishers, then flatten these inner publishers into a single Flux, but merge them in the order of their source element.

将此 Flux 收回的元素异步地转换为 publisher，而后将这些外部 publisher 扁平化为单个 Flux，但 依照源元素的程序 合并它们。

如上图所示，总共有 S1、S2、S3、S4 按程序的四个弹窗，会并行执行 S1 到 S4，如果 S1 和 S2 没有数据，S3 有数据，则会返回 S3。

伪代码如下：

Flux<Map<String, Object>> monoFlux = Flux.fromIterable(serviceList)
                .flatMapSequential(serviceName -> {})
                            .onErrorContinue((err, i) -> {// 某个 service 异样或者无数据，继续执行});
                })
                .onErrorContinue((err, i) -> {// 服务异样，继续执行});
Mono<Map<String, Object>> mono = monoFlux.elementAt(0, Maps.newHashMap());

这里就是异步执行所有弹窗 service，运行过程中某个弹窗异样或者无数据返回，则持续下一个。通过 monoFlux.elementAt(0, Maps.newHashMap()) 获取第一个有数据的弹窗。

4 重构成果

4.1 后端指标

相比于原来的后端系统，所有接口耗时都有大幅度降低，：

  • 头部身份信息接口响应速度晋升：26%。
  • 卡片各业务线入口接口响应速度晋升：87%。
  • 弹窗和浮标接口响应速度晋升：146%。

通过 flatMapSequential 编排弹窗之后，耗时从 220ms，降到 160ms，绝对值降落了 60ms，降落了 28%；

4.2 新需要开发和保护

新需要开发更快，QA 测试更快。

原来开发一个弹窗，须要思考的事件很多：

  1. 开发的时候须要思考代码放在哪个层级上，是否与其余弹窗有耦合，
  2. 弹窗优先级须要通过 if-else 实现，很容易出错；
  3. 弹窗自测很麻烦，须要正文调其余弹窗；
  4. QA 须要测试所有弹窗的优先级是否有问题；

当初开发一个弹窗，只须要减少一个 service 类，而后把 service 配置再优先级列表中即可。

4.3 其余

框架应用了响应式框架 Spring WebFlux，也反对本地启动，编写了 service 层和基础设施层的单测 case，晋升开发效率。

删除了原来的业务网关层，应用公司层面的网关零碎，配置即失效；删除了原来业务网关中的业务逻辑代码，把相干逻辑挪动到业务层中，解除了原来的多层之间的耦合关系。

当初各个 service 之前互相独立，异样不会相互影响。

退出移动版