Saas system architecture operation experience summary

In the past year, I had the honor to build a Crm saas system. Over the past few months, I was quite satisfied with various aspects. Throughout the system creation process, many pitfalls have been made and many gains have been made. Summarize the features of the Saas system architecture

 
1. Hierarchical design

Saas system layering is probably:

Tenant identification> Application layer> data access layer> cache layer> database

 

Business code is written at the application layer.

Tenant identification can be implemented using the spring interceptor and then transmitted to the backend using ThreadLocal.

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

 
2. Data isolation should be transparent

The saas system is very simple, and any system seems to have become a saas system by adding a tenant_id (tenant id. For example, the original user logon is:

Select username, password from users where email = 'ABC @ qq.com'

 

Change

Select username, password from users where email = 'ABC @ qq.com 'and tenant_id = 1;


For saas systems with complex services, this approach is very dangerous, and the development efficiency is very low. Think about it. If the programmer forgot to add "and tenant_id = 1" when writing SQL, the result would be unimaginable.

It is better to rewrite the SQL statement at the database access layer.

TenantContext.exe c ("select username, password from users where email = 'ABC @ qq.com '");

 
Rewrite the SQL statement based on TenatnContext in the connection pool.

In this way, programmers can put the system down at most, and the information will not be leaked to each other. Second, it will be very convenient to perform Database Sharding for table sharding in the future, and the upper-layer applications do not need to be modified.

3. Tenant identification solution

It is better to identify tenants through URLs. The system generates a random third-level domain name for the tenant, such as abc.crm.baidu.com. If you want to use your own domain name, you can go to the third-level domain name generated by cname and bind it to the management system.

In this way, a tenant can have two domain names, access saas, one randomly generated third-level domain name, and the other tenant's own domain name. the code identifies the tenant based on the domain name and initializes TenantContext.

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

4. Smart DNS


5. Tenant management system (billing, ordering, customization, recharge, and reminder)

The billing system and tenant control system must be considered for the Saas system. This system must be independently designed. For example, how much is a month when a tenant buys those modules. The maximum number of users that a tenant can create. Billing expiration email reminder and other functions.

There are two billing methods: periodic billing, similar to the monthly rent scheme, and usage billing. Periodic billing is relatively simple. You can also combine the two.

6. Customized development

The advantage of SAAS is that it is used by many people in a set of systems and seems to be in conflict with customized development. For example, if customer A wants function A, Customer B does not. However, customized development cannot be avoided. For example, a complicated system such as a CRM system cannot meet the requirements of all companies. Customized development should be implemented in sub-modules as much as possible. Then, configure different tenants in the console to order different modules, which can be displayed on the front-end page. Different subsystems must be deployed separately. The front-end can be distributed by url through nginx, such as abc.crm.baidu.com/bi/xxx/xx, which will be distributed to the Bizi system. Don't try OSGI to implement modularization. This is a big pitfall.

There are also development and products, and the existing needs must be clearly analyzed. Do not discover endless problems when going online. New features can be configured independently as much as possible.

7. Grayscale upgrade

SAAS paying enterprise customers are especially sensitive to system problems. In order to reduce the impact scope of possible upgrade problems, gray upgrade policies are generally used. If the url is used to differentiate different tenants, it is very convenient to perform grayscale upgrade configuration. You can configure nginx for distribution based on the domain name, for example, from tenant A (aaa.com) to instance 1 (version 1.0), from tenant B (bbb.com) to instance 2 (version ). when many domain name configurations are required, the nginx configuration document will be messy. In this case, you can consider using Nginx to write some extension modules.

5 years' experience in SaaS operations

Not a high-tech company, but a company that makes customers feel awesome.

Customers will not purchase products because you have excellent programming skills and Nginx configuration, but if you sell them to save time, money, and energy for them, then they will be happy to pay for the purchase. Your job is to make the customer's life and work very impressive, so every decision on products and businesses should be closely focused on this purpose.

Do not promise the release time of the feature

Believe me in this regard and do not make a commitment to the release time of a product feature. When a feature is ready, people will ask you all the schedules. The best way to answer this question is (if you want to answer): "In future versions, we will consider this feature, however, at present, I cannot give a definite time point when to prepare it." That is to say, be honest with consumers-if you don't know when to "Ready ".

Investment in areas that can help you maintain efficiency

In this regard, we can clearly see the results of some investment, such as a good laptop (often upgraded), comfortable tables and seats, etc, and other seemingly less obvious investments, including software that allows you to focus on developing application functions rather than simply configuring servers.

Do not overload

Overload yourself is actually the first step towards failure, because you will not be in a good state when the load is full. For example, do not check emails at night, if your team only has 1 ~ 2 people, there is no need to provide 7 × 24 support, the customer will understand. Your company does not die for exhaustion. Your health, family, and social life should be more important than 5 minutes of support response and 100% of normal operation.

Don't trust hype

People are very excited and very good at promoting new technologies, architectures, programming languages, and configuration methods. They may tell you what to do and how to plan, in fact, you should extend it to millions of users for evaluation. The fact is that you should be more pragmatic-your goal is to run your business and use relatively mature technologies. In addition, you need to make necessary optimizations, including writing less code, wider test coverage, and concentrated efforts to make long-term profits for the enterprise.