SAAS Architecture Design

Ideal for SaaS application Scalability: as the number of users increases, the system architecture does not need to be adjusted, but only needs to increase/enhance the corresponding hardware devices (application servers and database servers) you can. Generally, the application architecture is scalable. It generally refers to the implementation of "scale out", that is, horizontal scaling or outward scaling. "Scale up" is usually used for vertical or upward scaling, that is, to enhance hardware devices. This method is applicable to almost any application architecture, but usually faces high costs.

1. horizontal scaling of the application server layer.Server Load balancer at the application server layer is the most important way to achieve horizontal scaling of application servers. There are two specific load balancing policies:
A. Load Balancing is implemented based on Hardware load balancing devices, such as F5 devices.
B. Implement Load Balancing Based on Software, for example, by configuring Apache HTTP server.

Apache can achieve load balancing and distribute each user request to different application servers based on the pressure on the server. However, most application users are stateful (session is generally used to record the user status ). In this case, how to maintain the user status between multiple application servers is the key to achieving horizontal scaling of the application server layer.
A. session replication.The implementation of session replication technology is very complex. It is not very practical in large-scale clusters. A large number of session replication between servers will seriously affect the performance of these servers. As the number of servers increases, this performance impact will become more prominent and even unacceptable. Session replication is rarely used in most Internet applications.
B. Session sticky.To avoid the performance impact of session replication, session sticky is a simpler and more efficient method. This method forwards requests from the same user to a specific JBoss server, avoiding session replication in the cluster. The implementation of session sticky is very simple, but this method cannot meet the requirements of fail-over. That is, when an application server is down, the sessions of all users being accessed on this server fail, and all users have to log on again. In addition, this method may also lead to insufficient load balancing.
C. cache-based centralized session.This solution usually uses centralized cache instead of local sessions. The centralized session server uses memcached, which also supports horizontal scaling. When the number of sessions is as high as that of a cache server, we only need to add the corresponding cache server.

Comparison of Three horizontal scaling modes:

Implementation Method	Advantages	Disadvantage
Session replication	Server load can be well balanced, and fail-over support can be ensured.	Session replication puts a lot of pressure on the server network environment, especially when the number of application servers is large, it is basically not applicable to large Internet, and requires the corresponding application server support.
Session sticky	The implementation is relatively simple. You can configure the load balance layer to avoid network environment pressure caused by session replication.	Load Balancing cannot be fully implemented. In some cases, the load is unbalanced and fail-over cannot be implemented.
Cache-based centralized session	The application server layer is stateless and can achieve full load balancing without the network environment pressure caused by session replication.	The implementation is relatively complicated, and the reliability of the cache itself cannot be absolutely guaranteed, which may cause loss of some sessions.

2. horizontal scaling of the database layer.Compared with horizontal scaling of the application server layer, horizontal scaling of the database layer is more difficult to implement. There are also several ways to achieve horizontal scaling of databases:
A. vertical database Segmentation: Divides the tables involved in different functional modules into different physical databases, so as to share the access pressure on these tables into multiple physical databases.
B. read/write separation of databases: The same database has multiple copies on multiple physical servers and is synchronized with each other. Then write operations on the database are unified to one master server, while read operations are distributed to multiple slave servers. Database Access pressure is shared through read/write separation.
C. Horizontal database Segmentation: Split the data originally stored in a data table into multiple physical databases according to certain rules. The data structure of each database is identical, but the data is different. In the end, the access to business data will be located in a database for query based on the database where the data is located.

2.1 Vertical Split of databases.Although vertical splitting of databases is the easiest way to think of, for most applications, it is not easy to achieve vertical splitting unless there are few associations between modules:
A. Possible Table connections should be removed.
B. Transaction operations in the same database may become cross-database transactions. It can be seen that vertical segmentation of databases is a database layer extension technology that can be used appropriately but is difficult to widely use.

2.2. read/write splitting technology for databases.The read/write splitting technology is widely used for Internet applications with more reads and fewer writes. Although the number of slave database servers can be linearly expanded, the number of slave database servers is not as good as possible for the following two reasons.
A. if the application read/write ratio is not very wide, simply increasing the slave database server does not play a special role in improving the application performance. Generally, the number of slave servers corresponds to the read/write ratio.
B. Too many Server Load balancer databases may reduce the synchronization performance between master and slave databases.

2.3 horizontal split of databases.Whether vertical database splitting or read/write splitting, horizontal scaling of the database layer is narrow. There are usually two ways to split the database horizontally:
A. Use the hash algorithm. The hash algorithm is simpler to implement and has high performance, but has poor scalability. The hash algorithm is determined at the beginning. If it is changed later, data migration will be involved.
B. The other is to store the corresponding physical database as a relational table in a centralized tenant database. This method is more common. When a user logs on, the user can query the corresponding relational table to determine which physical database the business data of the corresponding rental room is stored in.

Comparison of horizontal scaling solutions for the three database layers:

Implementation Method	Advantages	Insufficient
Vertical Split	Easy to implement	Limited scalability, and highly correlated applications cannot be split vertically.
Read/write Separation	It can effectively share the read pressure, mainly at the database layer expansion, with less application modification.	Applications with a low read ratio have Limited scalability. Depends on the synchronization capability of the database itself
Horizontal segmentation	SAAS applications are widely used, with high scalability and almost unlimited scalability.	The implementation is complicated, and the application generally needs to be transformed. Load planning is required in advance, making it difficult to migrate data later.