1. I saw the background system architecture of a small company for the first time during my internship. I don’t know. I thought it was really cool at first.

This is the typical stand-alone architecture where you have Tomcat and mysql on top of it. All access will be directly directed to mysql, standalone mysql is the biggest performance bottleneck. Also, Tomcat and mysql compete for system resources. Suffice it to say that this applies to very small initial projects. I tested it on a 2-core 8GB machine with 50MB bandwidth (combined with the business at the time) and found it was a pathetic 17qps/s. Let’s just say there weren’t enough users.

2. When I was still working as an intern in the company, the load of the database became larger and larger as the number of users gradually increased. It’s not unusual for the CPU to reach 100% at some point. So the decision was made to upgrade.

This architecture just adds caches on top of the previous one, while putting mysql and caches on other machines. After this upgrade, QPS got a nice boost. After the previous sample test from 17qps/s->62qps/s. Got a really nice promotion. However, there is a bottleneck, and the pressure on Tomcat is increasing.

3. After graduation, I went to a financial company, where they introduced a new system architecture micro-service.

The architecture diagram above shows the browser going to access the gateway. Access one of these services through the gateway. A service can be clustered to balance load and improve performance. On the database side, the use of read/write separation can reduce the IO impact on the main library. A cache is also used to cache some hot data. Through my simple test, QPS can fluctuate in the range of 100Qps /s-200qps/s roughly, because it is not the same as the previous business, so there is no comparison. The bottleneck to this architecture, however, is in the database. Because over time the table will become very large, query efficiency will be reduced.

4. Small scale upgrade of financial company, transformation of database.

As mentioned earlier, after running for more than half a year, the table becomes very large and the efficiency of the query becomes a little slow. Because the database needs some modification.

Upgrading the database from a single master slave to one database per business allows the load to be distributed across different databases. While there may be some business repositories that are still under a lot of pressure, you can take the stress out of the rest of the business. However, this architecture also has a bottleneck in the gateway, which can greatly improve performance.