[Cloud Native] Service Industry Case - Solutions for Unpredictable Concurrency Scenarios

1. Customer Scenario

With the development of the sharing model, the shared power bank is developing rapidly. The shared power bank is an important branch of my country's energy supply system and an important part of new energy.
There are many doubts about the needs of the first container cloud customers, which can meet the customers' irregular high concurrency scenarios and ensure stable business expansion, which brings greater difficulties from the perspective of code adaptation and deployment.

2. Business challenges

1. The business peaks and valleys are uncertain. The business peaks are much higher than the daily business peaks, and the low peaks are also significantly reduced. The demand for flexibility in computing resources is very high.
2. The database has high performance requirements, and the proportion of read requests is high. With the advent of business peaks, there are also great demands on the elastic scaling of the database.
3. There are semi-transactional message requirements. Asynchronous decoupling capabilities are required for orders in progress, unpaid orders, and order completion.

3. Solutions

1. Serverless application engine SAE: In the combination of ECS and elastic scaling, it takes a few minutes to successfully pop up the computing power and wait for the application to start, and the flexibility is low. It is recommended to deploy front-end PHP applications through SAE, the deployment method is simple,The elastic scaling efficiency is increased to the 30-second level, the sensitivity is enhanced, the resource control is more flexible, and it is easier to cope with traffic peaks.
2. Relational database RDS: It supports read-write separation and vertical elastic scaling of the instance dimension. However, due to the architectural disadvantage of RDS, it takes a long time (half an hour) to expand the capacity of read-only nodes. It is often necessary to prepare resources in advance, and the waste of resources is obvious;It is recommended to migrate to PolarDB for MySQL. Based on the cloud-native product architecture, the expansion time of read-only nodes can reach the level of 5-10 minutes, and it also supports the ability to achieve vertical elastic scaling of the instance dimension together with DAS.
3. Message Queue RocketMQ version of distributed transaction messages can not only achieve decoupling between applications, but also ensure the final consistency of data.At the same time, traditional large transactions can be split into small transactions, which not only improves efficiency, but also prevents the overall rollback due to the unavailability of a related application, thus ensuring the availability of the core system to the greatest extent.

4. Customer Value

1. Deploying services through the serverless architecture improves the flexibility and flexibility of computing resources and increases the elastic efficiency by 80%.
2. Alibaba Cloud's leading elastic scaling technology and self-developed cloud-native database solution are used for database resources. The elastic scaling capability saves more than 70% of costs, and the efficiency of read-only nodes increases by more than 60%.
3. RocketMQ single-machine throughput of 100,000, supports 1 billion message accumulation, 0 messages are lost, and distributed architecture will not cause performance degradation due to accumulation

5. Knowledge points

1. For users with large differences in business peaks and valleys, the ECS+ESS product combination solution can meet the needs of basic elastic scenarios; if the customer's technology stack is suitable, the serverless architecture of SAE is more cost-effective and highly recommended.
2. The elastic capabilities of RDS and PolarDB are currently leading in technology. All the conveniences brought by the excellent architecture of PolarDB have fully supported users' business upgrades. It is recommended to choose PolarDB first.
3. RocketMQ is a self-developed product of Alibaba, which ensures that the message will be decoupled from the application without losing data, and at the same time, it will bring about the problem of data consistency, which is solved by the final consistency method of transaction characteristics.

6. Architecture diagram