One, foreword

Today, most Java backend development is familiar with frameworks like SpringCloud/Dubbo and ecology, with “microservices” and “high concurrency” being a regular feature on JD. But in retrospect, why do we need them, and under what circumstances did they come into being?

Second, architecture evolution

Monomer architecture

Robben is the backend leader of a company, and one day his boss puts him in charge of a new product line. Robben was full of spirit and keyboards, and a single SpringBoot Backend was built. He was skilled in modeling orders, products, users, and marketing modules and assigned them to team members for development. With the team working overtime, the system was soon put online. The feedback from the management on the new product was good, and the boss was happy and said, “You’re a real fucking talent.” The system architecture is shown as follows:

Horizontal application capacity expansion

With the efforts of the operation students, the company’s performance is thriving, and the system is also facing the test of increased traffic. Robben looked at the monitoring data of operation and maintenance and said: Small problem, just cluster it. So Robben starts deploying back-end services multiple times and exposes the API through load balancing. In this way, the application layer can handle massive concurrency through horizontal expansion. You can also introduce caching here to relieve database stress. The system architecture is shown as follows:

At this point, the system faces two problems

  • Cluster load balancing: this can be done using Nginx. Other solutions include DNS or F5 hard load balancing.
  • Distributed Session: This can be done by using Redis as a distributed Session. Other schemes such as JwtToken can also be used.
  • Need cache to share database load: Redis also done.

Database read/write separation

With the expansion of the service layer, the pressure of data will naturally increase, and the scene read is obviously more than write, so obviously Robben thought of using read/write separation to solve this problem. Search engines can also be introduced here, essentially a search engine is a read library.Problems:

  • Multiple data source configuration support: dynamic data source + custom annotations done.
  • ES data synchronization: Binlog synchronization, full synchronization + MQ incremental synchronization.

Database vertical split

As the business continues to grow, even with read-write separation, a single Master can no longer support the system’s traffic. Operation and maintenance frequently complained to Robben that the database CPU was often over 90% and whispered whether there was a problem with the code written by your development team. After checking the slow SQL again and again, with the diagnostic report of the database, Robben finally applied for the funds to do the vertical repository of the database.

Problems brought about

  • Multiple data source Configuration Support: Configure multiple data sources.
  • Distributed transactions: message compensation. There are also XA two-phase commit, etc., and cloud providers also provide mature solutions.
  • Associated query: global tables, data synchronization, or join at the application layer.

Horizontal split of data

When a certain business causes the data volume of a table to exceed the bottleneck of a single table, for example, according to Alibaba RDS, a table should not exceed 500W data, the table can be split into two or more tables in the same library, in fact, it is hoped that the bottom layer can be stored in two files. If a single table exceeds a single database bottleneck, the table needs to be split into two or more databases. For example, when the order reaches 100 million level, as shown in the figure:

Problems:

  • SQL routing processing, because the same table is stored in different places: data middleware rewriting SQL, like mycat, sharing-JDBC.
  • Primary key problem: primary key need distributed environment unique, ordered, high performance generation, snowflake algorithm to fix.
  • Paging problem: merge sort.

Application split microservices

With the iteration of the version, the endless business makes the original single architecture more and more complex, and it is more and more difficult to support the development of the business system. There are always conflicts in submitting codes, serious direct coupling of modules, and a small requirement release involves multiple module responsible teams. Major and secondary businesses are together, and horizontal expansion of a single business is complicated. Amid frequent complaints from team members, Robben decided to split the single application into several vertical applications by modules. In this way, some of the business expansion problems faced by a single architecture application can be solved. Traffic can be distributed to each subsystem, and each subsystem has a separate software development cycle, and the cost of collaboration and maintenance between different module development members is reduced. Robben thinks: this code won’t be overwritten. The structure is as follows:

Problems:

  • Service calls prior to different modules are no longer internal method calls, but require remote service calls (RPC)
  • Governance of services becomes a challenge: service governance frameworks, configuration centers, gateways.

Third, summary

Looking at this, it is easy to see that as the architecture evolves to the point where microservices need to be split, it naturally needs frameworks to meet the needs of the service layer and data layer. The SpringCloud/Dubbo frameworks were created for the service layer. Frameworks like MyCat/ Sharding-JDBC were created for the data layer. Other middleware, such as Mq and caching, are essential for a large distributed backend.

Of course, when the relational database can not handle, the concept of data warehouse comes, like Hadoop family bucket /Es and other big data technology to meet the business needs of massive data. Forget about this series. Next, I will write some technical principles and usage points of service layer and data layer middleware.