The practice of visual service orchestration in financial APP

This paper focuses on the problems encountered in the BFF layer practice of Jingdong Financial APP, and leads to the implementation of visual service orchestration in financial APP, which focuses on the core functions and implementation of the visual service orchestration system. The visual service orchestration system has stably supported all the release iterations of the financial APP from 618 last year to the present, which has significantly helped improve human efficiency. I hope it can be a reference for everyone's practice in BFF. Through this article, readers can learn about the problems and challenges encountered in realizing business requirements based on traditional coding methods, and how to avoid and solve previously encountered problems through "visual service orchestration".

01
foreword

In this year's agile team building, I implemented one-click automated unit testing through the Suite executor. What other executors does Juint have in addition to the Suite executor? This is where my Runner exploration journey begins!

With the proposal of SOA architecture and the implementation of microservice architecture, the business originally running in the same system has been split into different systems or services. In this way, while increasing the flexibility of the business architecture, it also brings more complexity to the call on the side. For example, a business that can be processed with one request may now require multiple requests to complete. In order to reduce the complexity of the logic on the end and improve the efficiency of front-end and back-end interaction, the BFF layer came into being.

As the front-end and back-end proxy layer, BFF provides a business interface aggregation layer for the application on the end, which shields the complex service invocation relationship, so that the application on the end can focus on the required data without caring about the specific services that provide the data. . However, in the process of BFF practice, there are also many problems and challenges. For example, the requirements of the BFF layer are often relatively simple, but through hard coding, the process is very cumbersome and inefficient. How to improve the delivery efficiency of the BFF layer requirements? It is a problem that needs to be focused on solving at present.

02
Problems in BFF Practice

Understand, first of all, MCube will judge whether the latest template needs to be obtained from the network according to the template cache status. When the template is obtained, the template will be loaded. In the loading stage, the product will be converted into the structure of the view tree. After the conversion is completed, the expression will be parsed by the expression engine and Obtain the correct value, parse the user-defined event through the event parsing engine and complete the event binding, complete the parsing assignment and event binding, and then render the view, and finally display the target page on the screen

BFF (Backend For Frontend), the back end serving the front end, can be regarded as a proxy layer for the back end service, which mainly does interface aggregation and response data tailoring. It should be pointed out here that BFF is only a concept introduced in architectural layering, not a technology.

The core responsibility of the BFF layer is to adapt to different business scenarios for the front end (including native, applet, H5, etc.), reduce the coupling between the client and the business end, and implement the requirements of the BFF layer by hard-coding in the early stage. direct way. However, with the increase of business requirements undertaken by the BFF layer, some problems are gradually exposed through the coding method, such as low coding efficiency, difficult to standardize coding details, low debugging and testing efficiency, and weak service governance capabilities.

2.1 Low coding efficiency

When a new business requirement is received, in addition to the preliminary requirement communication, some preparatory work is usually required before starting coding. For Java applications, the process is roughly as follows:

In the whole process, there are too many steps that require manual processing and waiting, which will greatly reduce the efficiency of the entire R&D process. Although there are some CI/CD tools that can reduce part of the waiting time, the overall coding experience and efficiency are not good. The problem is still not fundamentally resolved.

2.2 Encoding details are difficult to standardize

Determined by the characteristics of the BFF layer, most of the requirements it undertakes are to integrate and output business interfaces, including calling multiple interfaces, trimming, sorting, and formatting returned data. Just looking at the calling methods of the interface, there are many implementations, such as parallel calling, serial calling, etc. In order to reduce the response time of the service and improve the system performance and throughput, we usually use the method of parallel calling for multiple interfaces without dependencies. accomplish. Parallel calls can be implemented through thread pools or event callbacks. Compared with thread pool implementations, event callbacks will have higher performance and stability, but the implementation will be more complicated. R&D students usually Choose a simpler thread pool implementation.

2.3 The efficiency of debugging and testing is low

Although there are many tools and frameworks for unit testing on the market, configuration and coding are indispensable for use. As long as a function is added or modified, we have to write the corresponding unit test code. In addition, most of the unit test code needs to start the entire application, and the application startup is usually in minutes, which further reduces our research and development efficiency.

In addition, in the development environment, the business interfaces we rely on are usually deployed in the test environment, but the test environment often has deployment and restart operations, and even some interfaces do not have a test environment, which brings more inconvenience to our R&D and debugging. .

2.4 Weak service governance capability

The code is essentially unstructured text data. It is difficult for us to make statistics based on the code. Especially before the big promotion preparation, we need to know which services or which pages the interface of a business party is referenced by. At this time, the interface and The dependencies between services are particularly important, but it is difficult for us to achieve accurate statistics based on the coding method. Although there are some call chain tracking tools that can help, they are still not direct enough, and further identification is still required.

03Visual service orchestration

Understand, first of all, MCube will judge whether the latest template needs to be obtained from the network according to the template cache status. When the template is obtained, the template will be loaded. In the loading stage, the product will be converted into the structure of the view tree. After the conversion is completed, the expression will be parsed by the expression engine and Obtain the correct value, parse the user-defined event through the event parsing engine, complete the event binding, complete the parsing assignment and event binding, and then render the view, and finally display the target page on the screen.

The proposal of visual service orchestration is to solve the problems mentioned above. The original intention of visual service orchestration is to abandon the code as much as possible, and complete the development, debugging, testing and launch of functions through online visual drag and drop. We can complete the delivery of business requirements without writing code or writing a small amount of code. There is no code. It eliminates most of the problems mentioned above, which greatly improves the delivery efficiency of R&D and the happiness of coding. The orchestration effect of the entire service is shown in the following figure:

We can complete the arrangement of interface invocation relationships through online drag and drop, such as serial, parallel and exclusive invocation of interfaces, and complete the customization of different business requirements through simple scripts, such as cutting, sorting, and formatting of data returned by the interface. operations, etc. After arranging, you can directly test the choreographed service through the online test function, and verify the correctness of the function in seconds in real time, which can minimize the waiting time of coding, compiling and packaging, and improve the overall delivery efficiency of the business.

3.1 Core functions

The core functions of the visual service orchestration system are the abstraction of the daily needs of BFF and the R&D process, which are completed from several dimensions, such as the calling method of the interface, the processing of the input and output parameters, the processing of the abnormal situation of the interface, the debugging and testing of the service, and the online process of the service. The design of the overall function of the system.

interface call

The calling relationship between interfaces can be abstracted into: serial calls, parallel calls, and exclusive calls. When there is no dependency between the dependent interfaces, we can initiate requests to all at the same time in a parallel manner, which can reduce the response time of the service and improve the overall throughput of the system.

When the interface on which the service depends has dependencies, such as the input parameters of interface A need to be obtained by calling interface B, then interface A and interface B must be called in a serial manner, that is, interface B needs to be called first, and then the interface B needs to be called. Only the response result of interface B can call interface A.

An exclusive call is like if...else in the code, either A or B. This scenario is mainly used to judge whether to call interface A or interface B according to conditions, or to execute other business logic.

According to different business requirements and scenarios, serial, parallel and exclusive invocation methods may exist simultaneously in a service, so the implementation of functions must support the combination and nesting of different invocation methods.

parameter handling

The input parameters of the interface are mainly in two forms: static and dynamic. For static input parameters, you only need to provide the input box configuration on the interface. For dynamic parameters, the value may come from the return result of other interfaces, or it may come from dynamically generated, such as random numbers, UUID, etc., so the orchestration system provides the way to obtain or generate values through expressions or scripts to suit the needs of the users. With flexible business scenarios.

exception handling

The exception of the interface is usually judged by two dimensions. One is whether the interface call is successful. If the interface throws an exception or times out, it can be considered as a failure of the interface call. The other case is whether the returned data of the interface meets all expectations. , but the returned data is not expected. If the key field is not returned or the returned data format is incorrect, the interface call also needs to be judged as failure.

When the interface call fails, the processing strategy in different scenarios may be different, because some interfaces are not strongly dependent on the business, even if there is a problem with this interface, it will not affect the response of the entire service. However, some interfaces are strongly dependent on services. If the request fails, it is required to return the bottom line data or return an error directly.

Therefore, specific functions are designed for the exception judgment and exception handling of the interface, namely "exception assertion", "exception handling strategy" and "exception handler".

The exception assertion requires the user to fill in an expression to determine whether the returned result of the interface meets the expectations. When the exception assertion returns True, the interface call is considered to have failed.

The exception handling strategy is divided into "ignore" and "interrupt". For weakly dependent interfaces, the "ignore" processing strategy can be used. At this time, if the interface call is judged to be failed, the corresponding "exception handler" will be executed to be used according to the The actual business needs return the corresponding bottom-line data. For strongly dependent interfaces, the "interrupt" processing strategy can be used to directly return an error.

The debugging and testing requirements are changed from the previous hard coding to the online visual arrangement method. The original coding habits and related functions of debugging and testing need to be reflected online. In order to facilitate the debugging and testing of services, the orchestration system adds debugging control. The function of the station and interface data Mock.

The debugging console can view the logs of service execution output online in real time, which is convenient for R&D students to troubleshoot and locate problems in the service debugging process.

In order to facilitate R&D students to self-test services based on use cases, the orchestration system has added the function of interface response Mock, which can match according to the input parameters and return specific data, so that R&D students can return without relying on the interface of the business side, and pass the data Mock. The way to complete the self-test of the service, so as to improve the efficiency of research and development. The function of the interface Mock is shown in the following figure:

Service deployment

Based on the traditional coding method, after the requirement development is completed, except for some approval and verification processes, the online process can be summarized into the following three core steps: code submission -> compilation and packaging -> online deployment, the most critical step is "online deployment" ” link, we need to restart the application or container, the time required for application restart is mostly minutes, usually it takes 3-5 minutes to complete the deployment of a machine, and as the number of machines increases, the time required for the entire online process will also be increase. For the services implemented through orchestration, the entire online process does not require restarting the application. The core deployment task is to refresh the memory data. It only needs to select the machine to be deployed online, and the service deployment can be completed in seconds.

3.2 Function realization

There are two core functions of the visual service orchestration system, one is the front-end orchestration canvas, and the other is the back-end service execution engine. The orchestration canvas is used to implement the visual operation part, and its core function is to define operable functions and generate a DSL that can be parsed and executed by the backend according to the user's intention.

Regarding the choice of DSL, there are two main directions. One is to define a new set of description specifications according to functional requirements, and the other is to expand based on existing standards. By considering the complexity and time cost of front-end and back-end implementation, it is finally decided to tailor and expand based on the BPMN specification to realize the overall DSL specification definition for orchestration.

BPMN (Business Process Modeling Notation), that is, business process modeling notation, is a general and standard language for process modeling, and is usually used to draw business process diagrams, such as OA approval flow. Service orchestration is essentially process orchestration. In the BFF scenario, all the functions defined by BPMN are not required, so we only need to tailor the standard BPMN.

Orchestration Canvas

After the modeling language is determined, what we need to do is to determine how to implement the choreography canvas. By investigating open source BPMN modeling tools, considering the ease of use, openness, and activity, it was finally decided to complete the implementation of the entire front-end orchestration canvas based on the secondary development of bpmn.js. bpmn.js is a rendering engine and modeling tool based on BPMN2.0, based on Web and written in JavaScript.

Because the bpmn.js native sketchpad and property panel are implemented based on the standard BPMN specification, in the BFF scenario, many of the configurations and properties are redundant. The property panel in .js has been refactored based on VUE, the properties that are not very concerned in BFF are cropped, and the unique configuration items in BFF are added. The effect of the whole arrangement canvas is as follows:

execution engine

The execution engine is the core function of the orchestration system, which is responsible for executing the services from the orchestration. During the development process of the execution engine, we investigated the existing tools on the market, but in terms of performance, flexibility and maintainability, they could not meet our requirements. In addition, we did secondary development based on the existing engine. The time cost and subsequent maintenance cost are also high, so we finally decided to complete the implementation of the execution engine through self-research.

IO selection

Because the core function of BFF is to call the interface and process the data returned by the interface, the network IO uses full-link asynchronous IO, which is implemented based on event callbacks, which can bring two direct benefits:

1. High performance: After IO is asynchronous, a large number of concurrent requests can be processed with very few threads, which can significantly reduce the extra performance loss caused by CPU context switching in high concurrency scenarios;
2. High stability: Asynchronous IO eliminates the situation that its own thread pool is full due to the response delay of the upstream interface, and has a better guarantee for service stability;

preprocessing

Compared with the traditional execution engine's interpretation and execution method, the self-developed engine will preprocess the entire process into "execution units" in advance during the initialization process, that is, "unitization", and different execution units are nested and combined to complete the entire process. The advantage of this is that the system can complete the pre-compilation of the entire process before execution, and advance some unnecessary judgment and inspection logic at runtime to the preprocessing link, thereby reducing the logic at runtime and improving the overall engine performance. Execution performance. The core functions of the execution engine are shown in the following figure:

04 Operational results

4.1 Delivery efficiency
After the business requirements of BFF were changed from the original hard-coded method to online visual arrangement, all the processes that needed to be processed offline were converted to online operations, which avoided the waiting time of most compilation, construction and testing, and significantly improved human efficiency. Some requirements have been upgraded from the original hour level to the minute level.

4.2 Service Governance Capability

After the business requirements are realized through orchestration, the system can manage the services and interfaces in a unified manner, so that the metadata of the interfaces and services are naturally structured, and the reference dependencies of the interfaces and services can be clearly seen at a glance. After the interface and service are managed by the system, more dimension labels can be added, such as the business line to which the interface belongs, and the page to which the service belongs, etc., which can provide more dimensions of statistical data for daily management.

4.3 Troubleshooting efficiency

Based on the requirements of service orchestration, it naturally has the attribute of flow chart. As shown in the figure below, compared with the coding method, we can clearly understand the functional logic of the service, the dependencies before and after the interface, and the calling relationship, and provide our daily troubleshooting. powerful help.

05Summary

This paper focuses on the problems encountered in the BFF layer practice of Jingdong Financial APP, and leads to the implementation of visual service orchestration in financial APP, which focuses on the core functions and implementation of the visual service orchestration system. The visual service orchestration system has stably supported all the release iterations of the financial APP from 618 last year to the present, which has significantly helped improve human efficiency. I hope it can be a reference for everyone's practice in BFF.