Spring Cloud experience sharing in Cloud computing SaaS

The traditional software mode is that after the software product is developed, it needs to go to the customer site for implementation, usually deployed on the LOCAL area network, so the cost of development, deployment and maintenance is relatively high.

Now with the rapid development of cloud service technology, SaaS model appears. The SaaS model is where the product is deployed on a cloud server, and the former customer becomes a “tenant”, and we charge the tenant for the function and time of use. The advantage of this is that users can purchase the functionality and time according to their own needs, and they do not need to maintain the server themselves, and we as a SaaS provider do not have to go to the customer’s site to implement the trouble, the operation and maintenance risk is mainly borne by the IaaS provider.

At present, there are three mainstream SaaS multi-tenant database solutions:

Fully isolated: Independent database, which has the advantage of high isolation, but also high occupancy costs, and low resource sharing.

Sharing + Isolation: Databases can be shared, but with separate schemas. In this way, its indicators are relatively average.

Full sharing: Sharing databases and tables. I personally don’t recommend this approach because while it is highly shared, there is little isolation and development complexity increases as the business grows.

A Schema in a database is a collection of database objects. In Oracle, for example, there is usually one Schema for each user.

For MySQL, Schema is not a child of Database, but equivalent to Database. For example, create Schema test is the same as createDatabase test.

The database level mapping between Oracle and MySQL is as follows:

Advantages of the standalone Schema:

High independence: Each tenant has its own library and is isolated from other tenants;

High scalability: it is convenient for horizontal expansion and data migration;

Simple business development: only the business logic of single tenant needs to be considered during development, and the effect of multi-tenant can be achieved by switching the Schema, with fewer joint tables;

Customized services: Users can customize services without affecting other tenants.

Problems with the standalone Schema:

1. How to deal with more and more databases? If you have 100,000 tenants, you have 100,000 libraries, which a single server can’t handle.

2, so many databases, how to update and maintain the table?

3. Tenants’ data are isolated. What should we do when conducting overall data analysis?

To solve the first problem, we used a distributed multi-tenant database cluster. Assuming that there are 100,000 tenants, they can be distributed on different servers. The number of tenants on each server is not fixed, and they can be distributed according to the service volume. If necessary, tenants can be migrated.

After tenants are distributed, you can use the following methods to locate tenants:

The second and third problems can be solved using data microservices:

Data microservices can be dedicated to new schemas, updating data structures, bulk SQL execution, and statistical analysis.

As for the timeliness of statistical analysis, tenants usually only pay attention to the statistical analysis of their own business. Therefore, we can only conduct real-time statistical analysis on a single business library when facing tenants, and the data volume is generally not large. However, our background statistical analysis of global data usually has low timeliness requirements, so asynchronous or scheduled task processing can be used. In this case, it is recommended to use multiple data microservices to partition and process data before summarizing. When the total amount of data is large enough, Hadoop and other big data processing frameworks can be introduced.

Microservices generally have a split of two scenarios. The first is to split according to business functions. Microservices themselves should be highly cohesive, with low coupling between microservices, and microservices should be single.

The other is to break it down by architectural design, from the perspective of base components, performance balancing, and resource allocation.

In general, we can split many common business microservices and infrastructure microservices. Now suppose we have such a common business service pool and infrastructure service pool. First of all, we may have many different systems, some of which have common businesses in the common business pool, but they also have some separate special businesses themselves. Then we can either call the apis in the common business service pool directly, or we can call the apis of other business microservices when processing a particular business, and these business microservices can also call the microservices in the common business pool.

Products are not made up of services, they are made up of apis. A service is a service, and we don’t necessarily want it to belong to one product, but rather to combine apis from different services into one product.

Here is an example of a service topology using Spring Cloud:

Front and back end collaboration

Problems with the usual Swagger approach:

A large number of annotations unrelated to business pollute the Controller code, resulting in maintenance difficulties;

Poor flexibility, it is troublesome to expose a specific interface to a specific person (such as a third party);

Special treatment is required to close swagger when releasing production;

Swagger sometimes conflicts with other JAR packages (e.g. Springfox-swagger2.6.0 causes registering Eureka exceptions).

Development is not moving, document first. Prior to formal development, independent Swagger microservices should be written for the reference of developers, so that Swagger can return to the essence of documentation.

At the beginning of the project, Swagger microservice directly returns formatted fake data for front-end debugging, facilitating the parallel development of the front and back ends;

When the front end and back end are connected, the front end can continue to call the back end service through Feign to check the data, or directly connect the back end service to debug the real business logic;

According to the needs of different third parties, we can provide different external Swagger micro-services for each other to debug and flexibly expose the interface.

The back-end service does not introduce any Swagger code at all to keep the code pure and avoid the Swagger conflict. The Swagger service can be directly turned off when it is released and produced.

Matters needing attention:

The paths and parameters of Swagger interfaces must be consistent with the actual service interfaces and strictly comply with specifications to facilitate unified modification when the front end is directly connected to the back end.

There needs to be a corresponding VO in Swagger microservices, something that can be written once and copied everywhere. So it doesn’t add to the workload.

Technology is not the whole story

That’s all for today’s sharing, thank you!