Background

Under the distributed application architecture based on microservices, business requires multiple services to be completed through a series of services and middleware calls. The pressure testing of a single service can no longer reflect the real scenario.

In the test environment, if you rebuild a complete set of pressure test environment similar to the production environment, the cost is too high. It is usually impossible to simulate the scale and complexity of the production environment.

In this scenario, industry usually chooses the full-link pressure test method, that is, pressure test in the production environment. So the test results obtained can more accurately reflect the real capacity level and performance of the system.

Challenges

Full-link pressure testing is a complex and huge task. Coordination and adjustments between microservices and middleware required to cope with the transparent transmission of different flow rates and pressure test marks. Usually we will build a complete set of pressure testing platform for different test plans.

Data isolation have to be done at the database-level, in order to ensure the reliability and integrity of the production data, the data generated by pressure testing routed to the test database. Prevent test data from polluting the real data in the production database.

This requires business applications to perform data classification based on the transparently transmitted pressure test identification before executing SQL, and route the corresponding SQL to the corresponding data source.

Goal

Apache ShardingSphere focuses on database-level solutions in full-link pressure testing scenarios.

Kernel-based SQL analysis capabilities and a pluggable platform architecture realize the isolation of pressure test data and production data, help application automatic routing, and support full-link pressure testing.

It is the main design goal of the Apache ShardingSphere shadow DB module.