SaaS System Architecture Experience Summary

The 2 B SaaS system has been very hot in recent years. Many start-up companies are trying to create enterprise-grade CRM, HR, sales, and Desk SaaS systems. Many SaaS startups are also taking large VCs. After all, the advantages of SaaS relative to traditional software are obvious.

In the last year, we have had the privilege of architecting a CRM SaaS system that has been online for several months and is more than satisfactory. The whole system creation process, tread a lot of pits, harvest also more. Summarize some of the features of the SaaS system architecture:

1. Layered Design

The SaaS system hierarchy is probably:

Tenant identification > Application layer > Data Access Layer > Slow storage Layer > Database

Business code is written in the application layer.

Tenant identification can be implemented with spring interceptors and then passed to the backend using threadlocal

The database and cache tiers should be transparent to the application layer. When writing code, programmers only care about business logic and should not worry about multi-tenancy issues.

2. Data isolation to be transparent

The SaaS system is simple to say, and any system that seems to add a tenant_id (tenant ID) becomes a SaaS system. For example, the original user login is:

Select  from where email='[email protected]'

Change into

Select  from where email='[email protected]'and= 1;

　　

This is a risky and inefficient development for SaaS systems with complex business. Think of it if the programmer forgot to add "and tenant_id = 1" when he wrote SQL. The results were disastrous.

It is a good practice to overwrite SQL at the database access layer.

Tenantcontext.exec ("Select Username,password from Users where email= ' [email protected] '");

Overwrite SQL on the connection pool based on Tenatncontext.

The advantage of this is that the program ape has the most system down, and not the information string to reveal each other. Secondly, it is very convenient to do sub-tables in the future, the upper application without modification.

3. Tenant Identification Scheme

A good practice is to identify tenants through URLs.   The system is to generate a random three-level domain name for the tenant, such as abc.crm.baidu.com. If customers want to use their own domain name, can be in the CNAME to our generated level three domain name, and in the management system to do the binding.

Such a tenant can have two domain names, access to SaaS, a randomly generated three-level domain name, and another tenant's own domain name. The code can be based on the domain name, judge the tenant and then initialize the Tenantcontext.

If you do not want to use the domain name to do, you can also use the login name to determine. This approach involves tenant switching issues.

4. Intelligent DNS

Added later.

5. Tenant Management System (billing, ordering, customization, recharge, reminder)

The SaaS system must consider the billing system and the tenant control system. This system needs to be designed independently. For example, the tenant bought those modules, one months how much money. The maximum number of users a tenant can create. Billing due to email reminders and other functions.

There are generally two types of billing, recurring billing, similar to the monthly rental plan, and the use of the amount of billing, how much to pay. Recurring billing is relatively straightforward. You can also combine them.

6. Customized development

The advantage of SaaS is that there is a system of multi-person use that seems to conflict with custom development. For example a customer wants a function, B customers do not want to. However, custom development is unavoidable, such as a complex system such as a CRM system, and it is impossible to set up a system to meet the requirements of all companies. Customized development as far as possible sub-system, sub-module to do. Then you can order different modules from the console by configuring different tenants, and those modules will be displayed on the front page. Different subsystems need to be deployed separately. The front end can be distributed to the BI subsystem by using Nginx to distribute it according to the URL, such as the ABC.CRM.BAIDU.COM/BI/XXX/XX address. Don't try OSGi to do modularity, this is a big hole.

There are development and products, the existing needs must be analyzed clearly, do not find endless on the line. The new features can be configured independently as far as possible.

7. Grayscale Upgrade

SaaS paid enterprise customers are particularly sensitive to system issues. In order to reduce the scope of the problem that may occur in the upgrade, a grayscale upgrade strategy is generally used. If you use URLs to differentiate between tenants, grayscale upgrade configuration is convenient. Nginx can be configured to distribute according to the domain name, such as tenant A (aaa.com) to Instance 1 (version 1.0), tenant B (bbb.com) to instance 2 (version). Nginx configuration documentation can be confusing when there is a lot of domain configuration required. This is a time to consider using Nignx_lua to write some extension modules.

8. Capacity estimation

For the time being, write so much first. Have time to add.

----------

http://www.cnblogs.com/codemind/

SaaS System Architecture Experience Summary