Between different industries, there will be some gaps in business attributes. For application software in the financial field, because it involves factors such as money, it will have the following unique attributes in the business:

Stability. The financial sector is related to the strength of money, which has very strict requirements for business stability, and once there is a problem with stability, it will affect the success or failure of the entire trading system.

Strong regulation. Strong regulation is generally targeted at the biomedical, medical, and financial sectors, as they present content that is related to human life. Therefore, the strong regulatory requirements at a higher level are bound to affect the selection and architecture presentation of some business levels.

Accuracy and validity. Because it is related to the strength of money, the presentation at the digital level requires zero deviation. Just like stock prices, its digital presentation is accurate to every minute and every second and fixed digits.

Based on the above characteristics, when the software system of the financial industry is designed for system design, machine room topology and middleware selection, there will be some differences with other general industries.

Java has been loved by developers since its inception. Nearly 50% of developers in China use Java as a development language. This is not only because of the advantages of its language, but also because the Java-related ecology is very large, especially many domestic financial systems are based on Java, which led to a period of time when everyone mistakenly thought that all systems were made in Java.

In the past 15 to 20 years, most financial systems have basically chosen the Java technology stack, and the reason for this is that we believe that it is mainly because the Java technology stack has the following advantages.

It is in this way that Java has gradually gained the favor of financial software systems.

With the rapid development of the technology industry, monolithic architectures are gradually being eliminated, and the era of microservices and cloud natives is taking the world by storm. However, in the technical environment of recent years, as an object-oriented high-level language, Java has also begun to be slightly tired in some business scenarios:

First, Java performance is low, as you can see by comparing it to the C-related technology stacks. Java is based on virtual machines, and its memory management is left to the virtual machine to solve, so when faced with some high-performance or dynamically changing business scenarios, the Java language is not so strong in processing.

Second, the Java language requires more resources. Building an architecture without considering the cost, many problems are easy to solve, but in the cloud-native era, all resource computing is becoming more and more detailed and more granular. Java consumes a lot of resources to run, and due to the heavy weight of Java and the underlying characteristics that require a restart, the language is more prone to problems in scenarios with high QPS or high business continuity requirements.

Finally, there is the problem of pointer variables. Students who are accustomed to writing C/C++ know that pointers are a very good resource. But Java is based on virtual machines, which gives memory management to the GC (Garbage Collection) rather than by manual programs, so the actual performance of Java may be slightly insufficient for some specific situations or scenarios with high concurrency, high access, and high performance.

Shuhe Technology is a service platform that provides intelligent finance, and its main products are repayment, repayment, and enjoy flowers. Huibei APP is a multi-scenario installment service platform based on consumption, which provides personal consumer credit services for the public and provides loan financial support for small and micro business owners through cooperation with licensed financial institutions. At the business architecture level, the product implementation has always relied on the Java technology stack.

Spring Cloud Gateway is a gateway project born under the Spring Cloud ecosystem to better manage microservices, and Spring Cloud Gateway is usually a good API gateway choice for companies with Java as the main development language. However, during the recent API Gateway iteration, the long-used Spring Cloud Gateway was abandoned in favor of the Apache APISIX.

At the architectural level, the changes shown in the following figure are also presented before and after using APISIX.

In the pre-use architecture on the left, a total of three gateway systems are used, and the gateways are divided into two categories: ingress gateways and egress gateways. Spring Cloud Gateway is used as the gateway in both the Operating System Gateway and the Egreg System Gateway, and OpenRestry is used as the Business System Gateway in the Business System Gateway.

For the initial use of Spring Cloud Gateway as an operation and export system gateway, mainly because of the huge ecosystem of Spring Cloud and the distributed system development framework that is easy to deploy and maintain, so in the early stage of business architecture deployment, in order to build a business faster, Spring Cloud Family Bucket was chosen.

However, with the slow development of the business, the gateway in the original architecture began to have some stability problems, such as memory overflow and high CPU usage. In order to upgrade gateway performance and unify multiple gateways, all gateways in the architecture are unified with Apache APISIX.

In the new gateway architecture, the service system gateway will preferentially forward the request traffic directly to the service system through service discovery. If the backend application does not have a healthy pod in Consul or the backend application does not support service discovery, etc., the traffic will be forwarded to the previous intranet K8s Ingress for use as the upstream of the bottom.

The new architecture also unifies the two applications of the egress gateway, and the new egress gateway is deployed in the outreach zone outside the K8s cluster. At the same time, an SLB is added before the egress gateway cluster, which can unify the ingress of the egress gateway and facilitate system calls in applications or other VPCs that do not have service discovery capabilities.

In actual business cases, because there are already multiple gateway architectures inside, there is no way to directly use Apache APISIX, so some modifications and builds have been made based on APISIX.

When developing in-house, the APISIX Gateway’s code and custom code are housed in different paths, and the two work together and can be iterated independently. During deployment, Docker image is used to deploy the base, build a base image of the specified version of APISIX, and then package the custom code into a new image.

Instead of using lua_package_path to specify the code directory when customizing code packaging, the base image apisix source directory is directly overwritten, and if there is a file with the same name, the source code file is overwritten. Dockerfile is as follows:

APISIX’s logs are stored locally by default (also through plugins such as Syslog), and you can decide whether the logs are stored locally or in FLUENTD via Syslog by adjusting the nginx configuration template and determining the enabled profile. Also replace the FLUENTD_HOST variable in the template when building the image. This is shown below:

In the nginx configuration template, not only modified the log store, but also adjusted the loop to add ENV environment variables, loop to add lua_shared_dicts configuration, and write some other NGINX tuning parameters.

Because the company is divided into multiple gateways according to business traffic, the basic functions of these gateways are similar, so it has also adopted the “one code to deploy multiple gateway applications” scheme internally. When configuring the config-xxx.yaml file for each gateway through the Profile function, and then building an image through the company’s DEVOPS platform, you can build a Docker image of a different gateway based on the application name.

When you access the operating system page internally, you call many backend APIs to get data, and these APIs need to configure the corresponding whitelist in the API Gateway. The scope of APIs that can be accessed varies depending on the role of the user who logs in to the operating system on the page, so the permission system also needs to maintain a list of relevant APIs. Whenever a new backend API call is added to the page, the developer needs to configure it twice on the gateway page and the permission system page, and the work is redundant and repetitive.

To this end, the gateway configuration and the permission system configuration are also connected, only the configuration portal of the permission configuration system is retained, and the gateway configuration management system regularly pulls the permission API, and then converts it to the gateway API whitelist configuration. This not only reduces the user’s one-time configuration operation, but also assists the permission system in exercising permission control. You can guarantee that the backend API called on the operation page must have the relevant permissions configured in the permission system.

In the actual business of the company, it is often encountered that the native plug-in can not meet the actual needs, and it is necessary to customize the development. Fortunately, APISIX provides a lot of tool classes, which can be easily implemented by referring to native plugins, and the development process is very simple. Here are some other custom plugins based on APISIX internally:

The K8s container that was used before was OpenShift (now upgraded to an ACK cluster), where Ingress was built by Haproxy. Since the Haproxy of public K8s Ingress cannot forward traffic from one domain name to two Namespace routes, consider deploying the new gateway under the same Namespace as the old gateway. That is, multiple services are attached under the route of the domain name, and then the traffic ratio can be adjusted through the route to control whether the traffic goes to the new gateway or the old gateway.

The specific implementation process is shown in the following figure, and the new c and d groups are added under the namespace of the old gateway for deploying the new gateway, and the traffic ratio of the new and old gateways is controlled through the route.

Many Java engineers choose Spring Cloud in a microservices architecture, mainly language binding, and put it in code in the form of class libraries. However, in practice, there may be difficult upgrade situations, if the team is multilingual, it needs to maintain multiple class libraries, assuming there are 10 versions and 10 languages, it is necessary to maintain 100 class libraries.

At this point, you can easily solve the problem of multiple versions and languages through the proxy method (that is, API Gateway). What are the benefits of Java Technology Stack Company after choosing APIsix as API Gateway? Based on the practical experience of Hoan Bei, we summarized it from the following two perspectives.

1. Features and performance

Also using 4-core virtual machines internally without plug-ins to run the QPS of APISIX can reach 80K, which is a good solution to the performance problems of Spring Cloud Gateway when undertaking C-side traffic, and in the production environment, APISIX is found to be more than 30% better than the previous gateway performance.

Second, thanks to cloud-native attributes, APISIX can fully meet the needs of companies in actual testing, such as authentication authentication, observability, service discovery, flow throttling, and Layer 4 and Layer 7 traffic forwarding. In terms of functional extensions, APISIX also supports more than 70 plugins, and most businesses can use its native plugins, which greatly reduces development work.

2. Lower operating expense costs

Before using APISIX, if there was a performance bottleneck, the company could only solve the problem by constantly adding servers, so the corresponding hardware cost would be very high.

When doing the cost calculation, it was found that after using APISIX, the number of servers was reduced by about 60%. After the technology stack is unified, it is also easy to extend the functions based on the APISIX native framework, saving development costs and speeding up the time to launch the project.

1. Meet business needs

The software or technology used in the business should be to serve the needs. Judging from the actual test results and survey data, the stability, observability and scalability of APISIX will be better.

Software ultimately serves the business. If the business needs to conserve resources for the company, then no matter what the company’s technology stack is, it will use the components that best match the company’s business.

2. Reduce maintenance costs

Compared to the previous OpenResty, APISIX has a relatively low learning cost and is less important to maintain. At the same time, APISIX’s rich plugins simplify the implementation and deployment of some common functions, which greatly saves the time of project launch.

At the same time, with APISIX’s powerful logging and dynamic debugging capabilities, services can easily troubleshoot fault points, so as to quickly locate and save time.

In the past decade, Internet finance has gradually changed from “barbaric growth” to “intensive cultivation” mode, which mainly involves the transformation of the system.

In the barbaric growth stage, the business is about efficiency. In order to build the business more quickly, when choosing the infrastructure, the person in charge is more likely to choose the language architecture he is familiar with. Different principals will choose to use different technology stacks, so they leave a lot of technical debt. Since 2017, most of the still active financial companies or service companies will face the same technological status, that is, the existence of multiple sets of technical components. This is where the unification of infrastructure is required.

When it comes to intensive farming, enterprises need to split the system vertically, from the previous chimney split into front-end, middle-office and back-office modes. When the system reaches a stable stage, it needs to lay something down.

The fundamental purpose of system construction is actually to share. The more repetitive the use, the lower the operation and maintenance cost of the system. Therefore, many companies have reached the stage of intensive cultivation, either to carry out vertical splitting of the system, or to sink the basic components, and then control the operation and maintenance costs.

As a company, cost priority is still a principle that needs to be considered. The savage growth phase may only need to be realized as soon as possible, and in the current environment, the budget is definitely a priority within the budget. In this case, efficiency and cost can only be preserved in one way. Therefore, in the case of limited costs, enterprises will talk less about the advanced nature of technology. In the process of selection, technicians will not consider how much impact the current technology will have on the team, how much benefit it will bring to the existing operation and maintenance and architecture, etc., but more from the cost perspective.

– END –

8 years of experience in Internet development, good at microservices, distribution, architecture design. Currently working on infrastructure and performance optimization at a large public company.

InfoQ Contracted Author, Blue Bridge Contracted Author, Alibaba Cloud Expert Blogger, 51CTO Celebrity.

Welcome to add my friends, provide technical answers, resume modification, technical exchange groups.

Goku’s multiple technical topics:

33 SpringCloud Practical Questions, Reply PDF Acquisition.

8 distributed algorithm articles, reply to distributed acquisition.

7 JVM special training, reply to JVM acquisition.

The information necessary for the interview can be obtained by paying attention. ↓↓