Thinking on multi system architecture design

The first consideration is that there are many downstream application systems .

This method assumes that users have a unique id, Its access rights in each system need to be configured , When are permissions assigned ？
The first time a user registers with the platform , Need to produce its default permissions ( Platform wide default permissions ), When its registration is completed, it logs in to a platform for the first time A You may need to get some personal information , At this time, the platform A How to obtain these necessary personal information ？ When some information is updated , platform A You may also need to get updated information , How should he get this information at this time ？ Therefore, only user login and update information may cause concurrency problems . So we should take the initiative to inform , When a user registers / When the central system updates personal information, it will push the user's information to other systems for update , When all systems need to update the user's master information, they call a central information update interface .
It can be used rabitMq To narrate these thoughts ：

To avoid the pressure of modifying the server , You can consider setting the modification time limit or frequency limit for the modification of the center information , At present, wechat 、 douban 、csdn They have time limit or frequency limit for modifying important information like , I don't know what they are thinking .
When the user logs in , It's not just about login password verification , At the same time, it also involves the return of login permission , So that the front end can display the interface module according to different permissions .
Suppose a user tries to access the platform A, But the user is on the platform A I haven't logged in , Will jump to the login page , When jumping, we can set a hidden parameter param1 Take it to the login page , When the user logs in, the authority is queried according to param1 To return users to the platform A Permission list on , Then navigate to the corresponding page through redirection , Such a platform A The login function of is completed .

Because the authority center of the system is a center , So we can achieve something similar to sso Single sign on function .
From this design framework , When evolving from a single system to a multi system, it is necessary to separate the user authority database from the business database at the early stage of design , At present, the system has not introduced the function of logging , Consider the following ways to introduce .

You can set all log data tables as one type of data table , This method can realize code reuse by introducing the log module , At the same time, the query system can also use code reuse to view the operation log . Maybe you can also generate and process logs in another way .

All system log operations are sent to a queue in a certain format , Then the log processing system records the log information into a certain kind of database , The log processing system can distinguish query logs according to different systems .
I think that when designing database logs in the early single architecture, we can refer to some necessary fields of the log platform to collect logs , This provides convenience for future conversion to the logging platform .

The above is the thinking of low concurrency multi system architecture , Next, consider the multi concurrent multi system architecture .
As the name suggests , The application itself also needs to be split , Authentication forward can also be regarded as application splitting .
From the perspective of architecture , The authentication center will also become a system bottleneck , At this time, we can start from the perspective of accessing different systems , Different systems have a corresponding authentication center , The architecture diagram can evolve as follows .

If there are still bottlenecks , You can consider according to different users id Map to different data tables , That is to split the table horizontally .
Through the above, I have such an idea , The user information table 、 Permission related tables 、 Business related table 、 Split the log related table , In this way, the code of the complete permission module can be completely reused in all future projects ( Because the user permission can only pass through the user id Locate with other associated tables ), If you can abstract enough , User information table can also be completely abstract , For example, only store users id、 User name 、 User ID number 、 You phone 、 Information such as user email .
In this way, the authentication pressure can be relieved , The next step is how to deal with downstream systems with high concurrency ？
If the traffic is low , We can solve the problem of data consistency by adding optimistic lock to the data table , But in the case of concurrency ,mysql Because of transactions, it will become a system bottleneck , What should be done at this time ？
1) Use redis Locking mechanism , The specific process is as follows

My idea is to have two fields , A quantity variable used to store in sales A, The other is used to store the actual quantity B. The two fields are locked respectively , When the user places an order , Only observe variables A, Ensure variables A The atomicity of , When cutting data , You need to modify the data B And subtraction data A.
1)a The business calls b Business , But he doesn't care b What has the business done , For example, the logging system , It belongs to this way , You can split the log system ;
2)a The business calls b Business , Users care about the end result , however a and b Data consistency will not be involved , At this time, the message queue can also be used ;
The architecture diagram and some summaries will be added tomorrow , It's too late today .