关于可视化:可视化服务编排在金融APP中的实践

本文重点介绍了京东金融 APP 在 BFF 层实际过程中遇到的问题，并引出可视化服务编排在金融 APP 中的落地实际，其中重点介绍了可视化服务编排零碎的外围性能及实现。可视化服务编排零碎曾经稳固反对了金融 APP 从去年 618 到当初的所有发版迭代，对人效晋升帮忙显著，心愿可能对大家在 BFF 的实际有参考意义。读者通过这篇文章能够理解到基于传统编码方式来实现业务需要时遇到的问题和挑战，以及通过“可视化服务编排”如何躲避及解决之前遇到的问题。

01
前言

在往年的麻利团队建设中，我通过 Suite 执行器实现了一键自动化单元测试。Juint 除了 Suite 执行器还有哪些执行器呢？由此我的 Runner 探索之旅开始了！

随着 SOA 架构的提出到微服务架构的落地实际，本来在同一个零碎内运行的业务被拆分到了不同的零碎或服务中。这样做，在减少业务架构灵活性的同时，也给端上的调用带来了更多的复杂性，如：本来一次申请即可解决实现的业务，当初可能须要屡次申请能力实现。为了升高端上逻辑的复杂性并进步前后端交互效率，BFF 层应运而生。

BFF 作为前后端的代理层，为端上的利用提供了一个业务接口聚合层，它屏蔽了简单的服务调用关系，让端上利用能够聚焦在所须要的数据上，而不必关怀提供数据的具体服务。但 BFF 实际的过程中，也遇到了很多问题和挑战，如 BFF 层的需要往往比较简单，但通过硬编码的形式实现，流程十分繁琐且效率低，那如何进步 BFF 层需要的交付效率，便是目前须要重点关注解决的问题。

02
BFF 实际中的问题

了解，首先 MCube 会根据模板缓存状态判断是否须要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的构造，转换实现后将通过表达式引擎解析表达式并获得正确的值，通过事件解析引擎解析用户自定义事件并实现事件的绑定，实现解析赋值以及事件绑定后进行视图的渲染，最终将指标页面展现到屏幕

BFF（Backend For Frontend）, 即服务于前端的后端，可看做是一个后端服务的代理层，它次要做接口聚合和响应数据裁剪。这里须要指出的是：BFF 只是架构分层中引入的一个概念，而非一种技术。

BFF 层的外围职责是为前端（包含原生、小程序、H5 等）适配不同的业务场景，升高客户端与业务端的耦合，后期通过硬编码的形式来实现 BFF 层的需要，是最简略最间接的形式。但随着 BFF 层承接业务需要的增多，通过编码的形式也逐步暴露出一些问题，如编码效率低、编码细节难以标准、调试测试效率低和服务治理能力弱等。

2.1 编码效率低

在接到一个新的业务需要，除了后期的需要沟通外，开始编码前，通常还须要做一些筹备工作，对于 Java 利用来说，流程大略是这样的：

整个流程中，有太多须要人工解决及期待的步骤，这将会大大降低整个研发流程的效率，尽管当初有一些 CI/CD 的工具能够缩小局部等待时间，但整体的编码体验及效率上的问题还是得不到基本的解决。

2.2 编码细节难以标准

由 BFF 层的特点决定，其承接的需要大多是对业务接口进行整合输入，包含对多个接口的调用、对返回数据进行裁剪、排序、格式化等操作。单看接口的调用形式就有多种实现，如并行调用、串行调用等，为了升高服务的响应工夫和进步零碎性能及吞吐量，多个无依赖关系的接口咱们通常会采纳并行调用的形式实现。并行调用，咱们能够通过线程池实现，也能够通过事件回调的形式实现，通过事件回调绝对于线程池的实现会有更高的性能和稳定性，但实现起来也会更简单，研发同学通常都会抉择更简略线程池实现。

2.3 调试测试效率低

尽管市面上目前有很多单元测试的工具和框架，但应用起来都少不了配置和编码环节。只有有性能增加或批改，咱们就要编写对应的单元测试代码，另外单元测试代码运行大多须要启动整个利用，而利用的启动通常都是分钟级的，这就导致咱们研发效率进一步升高。

此外，开发环境中，咱们依赖的业务接口通常是部署测试环境的，但测试环境常常会有部署、重启的操作，甚至有些接口都没有测试环境，这就对咱们研发调试带来了更多不便。

2.4 服务治理能力弱

代码实质上是非结构化的文本数据，咱们很难基于代码进行统计，尤其是大促备战前，咱们须要晓得某个业务方的接口都被哪些服务援用或被哪些页面调用了，此时接口和服务间的依赖关系就显得尤为重要，但基于编码的形式咱们是很难做到精准统计，尽管有一些调用链追踪工具能够提供帮忙，但还是不够间接，还是须要人肉的去做进一步的辨认。

03 可视化服务编排

了解，首先 MCube 会根据模板缓存状态判断是否须要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的构造，转换实现后将通过表达式引擎解析表达式并获得正确的值，通过事件解析引擎解析用户自定义事件并实现事件的绑定，实现解析赋值以及事件绑定后进行视图的渲染，最终将指标页面展现到屏幕。

可视化服务编排的提出，就是为了解决下面提到的问题。可视化服务编排的初衷是心愿尽可能地摈弃代码，通过线上可视化拖拽的形式实现性能的开发、调试、测试和上线，咱们不写代码或写大量代码就能实现业务需要的交付，没有代码就打消了后面提到的大多问题，这样极大进步研发的交付效率及编码幸福感。整个服务的编排成果如下图所示：

咱们能够通过线上拖拽的形式实现接口调用关系的编排，如接口的串行、并行和排他调用等，通过简略的脚本实现不同业务需要的定制，如对接口返回数据的裁剪、排序、格式化等操作。编排后可通过在线测试的性能，间接对编排的服务进行测试，实时秒级验证性能的正确性，能够最大水平升高编码及编译打包的等待时间，进步业务整体的交付效率。

3.1 外围性能

可视化服务编排零碎的外围性能都是对 BFF 日常需要及研发流程的形象，从接口的调用形式、出入参的解决、接口异常情况的解决、服务的调试测试、服务的上线流程等几个维度实现零碎整体性能的设计。

接口调用

接口间调用关系能够形象为：串行调用、并行调用、排他调用。当依赖的接口间没有依赖关系时，咱们能够通过并行的形式，对所有所有同时发动申请，这样能够缩小服务的响应工夫，从而进步零碎整体的吞吐量。

当服务依赖的接口有依赖关系时，如接口 A 的入参须要通过调用接口 B 来获取，那接口 A 和接口 B 之间就必须通过串行的形式调用，即须要先调用接口 B，拿到接口 B 的响应后果能力才调用接口 A。

排他调用就好比代码中的 if…else，非 A 即 B，这种场景次要用于依据条件判断调用接口 A 还是调用接口 B，或是执行其余的业务逻辑。

依据不同的业务需要和场景，串行、并行和排他的调用形式可能在一个服务中同时存在，所以性能的实现中必须反对不同调用形式的组合及嵌套。

参数解决

接口的入参次要有动态和动静两种模式，针对动态的入参，只须要在界面上提供输入框配置即可。针对动静的参数，值可能来自于其余接口的返回后果，也可能来自动静生成的，如随机数、UUID 等，所以编排零碎提供了通过表达式或脚本的形式来取值或生成值，以适配灵便的业务场景。

异样解决

接口的异样通常由两个维度进行断定，一是接口是否调用胜利，如果接口抛出异样或超时都能够认为是接口调用失败，另一种状况是接口返回数据是否符全预期，如果接口调用胜利，但返回的数据不是预期的，如关键字段没有返回或返回的数据格式不正确，同样须要将接口调用断定为失败。

接口调用失败的状况下，不同场景下的解决策略可能也会不一样，因为有的接口并不是业务强依赖的，即使此接口呈现问题也不会影响整个服务的响应。但有些接口则是服务强依赖的，如果申请失败则要求返回兜底数据或间接返回谬误。

所以对接口的异样断定和异样的解决形式设计了针对性的性能，即“异样断言”、“异样解决策略”和“异样处理器”。

异样断言须要用户填写表达式，用于判断接口返回后果是否合乎预期，当异样断言返回 True 时，则认为接口的调用是失败的。

异样解决策略则分为“疏忽”和“中断”，针对弱依赖接口能够应用“疏忽”解决策略，此时如果接口调用被断定为失败，则会执行对应的“异样处理器”，用于依据理论业务需要返回对应的兜底数据。针对强依赖的接口能够应用“中断”解决策略，间接返回谬误。

调试测试将需要从之前硬编码改为线上可视化编排的形式来实现，本来的编码习惯及调试测试的相干性能就须要在线上失去体现，为了不便服务的调试及测试，编排零碎增加了调试控制台和接口数据 Mock 的性能。

调试控制台能够在线实时查看服务执行输入的日志，不便研发同学对服务调试过程中的问题进行排查和定位。

为不便研发同学依据用例自测服务，编排零碎增加了接口响应 Mock 的性能，可依据入参进行匹配并返回特定的数据，这样研发同学就能够不依赖业务方的接口返回，本人通过数据 Mock 的形式实现服务的自测，从而进步研发效率。接口 Mock 的性能如下图所示：

服务部署

基于传统编码的形式，当需要开发实现后，除去一些审批和验证流程，上线过程能够概括为以下 3 个外围步骤：代码提交 -> 编译打包 -> 上线部署，其中最要害的步骤为“上线部署”环节，咱们须要重启利用或容器，利用重启须要的工夫大多是分钟级的，通常实现一台机器的部署须要 3 - 5 分钟，且随着机器的增多，整个上线过程所需的工夫也会增多。而通过编排实现的服务，整个上线过程都不须要重启利用，其外围部署工作就是刷新内存数据，只须要线上抉择要部署的机器，即可在秒级内实现服务的部署。

3.2 性能实现

可视化服务编排零碎的外围性能有两个，一个是前端编排画布，一个是后端服务执行引擎。编排画布用于实现可视化操作局部，其外围性能是定义可操作的性能并依据用户的用意生成后端可解析执行的 DSL。

对于 DSL 的抉择，方向次要有两个，一种是依据性能需要，定义一套全新的形容标准，另一种是基于已有的规范进行扩大。通过对前后端实现的复杂度及工夫老本的思考，最终决定基于 BPMN 标准进行裁剪和扩大，以实现编排整体的 DSL 标准定义。

BPMN（Business Process Modeling Notation），即业务流程建模符号，是一种流程建模的通用、规范语言，通常用来绘制业务流程图，如 OA 审批流等。服务编排实质上也是流程编排，在 BFF 场景下，并不需要 BPMN 定义的所有性能，所以咱们只须要对规范的 BPMN 进行裁剪即可。

编排画布

建模语言确定后，咱们须要做的是确定如何实现编排画布。通过调研开源 BPMN 建模工具，从易用性、开放性、活跃度等几个方面思考，最初决定基于 bpmn.js 二次开发来实现前端整个编排画布的实现。bpmn.js 是一个基于 BPMN2.0 渲染引擎和建模工具，基于 Web，应用 JavaScript 编写。

因为 bpmn.js 原生画板及属性面板是基于规范的 BPMN 的标准来实现的，在 BFF 场景下，其中很多配置和属性是冗余的，为了优化用户的操作体验及升高实现复杂度，咱们对 bpmn.js 中的属性面板基于 VUE 进行了重构，裁剪了 BFF 中不太关注的属性，增加了 BFF 中特有的配置项，整个编排画布成果如下：

执行引擎

执行引擎是编排零碎最外围的性能，其负责执行编排进去的服务。在执行引擎的研发过程中，调研了市面上已有的工具，但不论是从性能、灵活性还是可维护性上，都达不到咱们的要求，另外基于已有的引擎做二次开发，工夫老本及后续的保护老本也很高，所以最初决定通过自研的形式实现执行引擎的实现。

IO 抉择

因为 BFF 的外围性能是接口调用及对接口返回的数据进行解决，所以网络 IO 这块采纳的是全链路异步 IO，基于事件回调的形式实现，这样做能够带来两个间接益处：

1. 高性能：IO 异步化后，应用极少的线程即可实现大量并发申请的解决，可显著缩小高并发场景下 CPU 上下文切换带来的额定性能损耗；
2. 高稳定性：异步 IO 打消了因上游接口响应提早导致本身线程池打满的状况，对服务稳定性有更好的保障；

预处理

相较于传统执行引擎解释执行的形式，自研引擎在初始化的过程中会将整个流程提前预处理为一个个“执行单元”，即“单元化”，不同执行单元进行嵌套组合实现整个流程的执行，这样做的益处是，零碎能够在执行前实现整个流程的预编译，将一些没必要在运行期的判断、查看逻辑提前到预处理环节，从而缩小运行期的逻辑，进步引擎的整体执行性能。执行引擎外围性能参见下图：

04 运行功效

4.1 交付效率
BFF 的业务需要由本来硬编码的形式改为线上可视化编排后，原来须要线下解决的流程全副转为线上操作，躲避掉了大多编译构建及测试的等待时间，对人效晋升显著，有些需要从原来的小时级晋升为分钟级。

4.2 服务治理能力

通过编排实现业务需要后，能够由零碎对立治理服务和接口，这样接口和服务的元数据人造就是结构化的，接口和服务的援用依赖关系能够做到高深莫测。由系统管理接口和服务后，能够增加更多维度的标签，如接口归属的业务线、服务归属的页面等，可为日常的治理提供更多维度的统计数据。

4.3 问题排查效率

基于服务编排实现的需要，人造具备流程图属性，如下图所示，和编码的形式相比，咱们对服务的性能逻辑、接口前后依赖关系、调用关系都能高深莫测，对咱们日常的问题排查提供了无力帮忙。

05 总结

本文重点介绍了京东金融 APP 在 BFF 层实际过程中遇到的问题，并引出可视化服务编排在金融 APP 中的落地实际，其中重点介绍了可视化服务编排零碎的外围性能及实现。可视化服务编排零碎曾经稳固反对了金融 APP 从去年 618 到当初的所有发版迭代，对人效晋升帮忙显著，心愿可能对大家在 BFF 的实际有参考意义。