To be precise, the monolithic application architecture of the 1.0 platform does not have the Internet project architecture. The traditional MVC development model and simple small workshop operation process, for each developer, only need to pay attention to the realization of business functional modules. In the six months of operation of the 1.0 platform, in addition to the explosive growth of the business needs, the development iterations are required to be rapid, and each upgrade should not hurt the bones, just the accumulation of modularity or partial updates in the original framework In addition to these, we have also seen that the basic operating facilities of the 1.0 platform itself are also urgently needed to improve the operating efficiency of the platform, such as the log platform, monitoring platform, scheduling platform, reporting platform, and even permissions and single sign-on. Very necessary, so the overall plan for the 2.0 platform should be included in it.
One platform overall capacity planning
It mainly removes some public things from the original business layer and operates in a platform-based software package model.
1. The unified scheduling platform is often used in many businesses in the project, but the 1.0 platform combines the scheduling work and business execution work in the code, causing a lot of scheduling work to be very inconvenient for the later maintenance, and the scheduling cannot monitor the current operation The schedule and the schedule to be executed next time. The unified scheduling platform can solve this problem, and can effectively maintain all the scheduling work of the platform through the management interface. From a design perspective, the scheduling work belongs to the scheduling platform, and the execution of the business belongs to the respective business platform (microservice) .
2. The unified interface platform mainly solves that the front-end application system obtains data through the unified interface platform and does not directly interact with external system interfaces. The unified interface platform connects with external systems in a variety of ways to obtain data and provides various data format packages to front-end application systems, effectively isolating external systems from business systems. The external interface requested by the front-end application system needs to be registered and opened on the unified interface platform. Every visit will be effectively recorded and monitored. In the front-end and back-end separation architecture system (in fact, microservices are such), the unified interface platform also plays the role of cross-domain and load balancing.
3. The unified log platform in the early stage mainly solves the trouble of logging in to the linux server and opening various account permissions to view log logs. It allows developers to manage logs and view logs through the management interface to improve work efficiency. ELK logs will be analyzed in the middle and later stages. Work is introduced to the platform.
4. The unified authority platform is mainly for the unified management of the authority of many various platforms (such as the above scheduling platform, interface platform, log platform, etc.). This piece is used in conjunction with SSO single sign-on. If one is assigned to each platform according to the tradition Accounts are more troublesome to operate. The unified authority platform + SSO single sign-on is to solve the problem of assigning an account, assigning authority, and entering major platforms for operation.
5. The unified messaging platform is mainly aimed at the management of the MQ middleware platform of the internal business system. It is similar to the unified scheduling platform. The execution of the business belongs to the business. MQ is only responsible for asynchronous transfer. It can be accessed through multiple protocols such as http, which is more firm and faster. , Maintenance is more convenient.
6. SSO single sign-on, you only need to log in once to access all mutually trusted application systems without having to log in repeatedly.
More platforms are still being planned, and the following articles will also cover them one by one, and share some pits encountered and some optimizations made.
Two business areas split
The business splitting of the 2.0 architecture system is a headache. To be honest, according to the current specific project team situation and server planning, neither too detailed nor too coarse, can only be removed and optimized according to the stage. So my plan is to first disassemble it according to the business function slightly, and after the overall process of the microservice framework platform is stable, then refine the split for each business function.
Once the business area is split, it means that the database will also be split, from the original single database to multiple databases.
In terms of database architecture, considering the cost of the server, a single machine is highly available in the early stage, and a shard cluster will be implemented in the later stage.
Three-service architecture
The general process from front-end request to back-end (specifically subject to the actual project):
1. Visit the html front-end page, (each page introduces checkCookie.js), if the cookie fails, jump to the sso single sign-on page.
2. After sso authenticates the user and password successfully, it generates a token and writes it into redis and cookie.
3. sso jumps to the html front-end page that needs to be accessed, (each page introduces checkAuth.js), html front-end page request (post request) unified authority platform, the authority platform obtains the token from the cookie and obtains the user information from the token , Query the user role and the specific permissions of the resource menu and return it to the html front end.
4. The html front end displays different div block displays according to the specific resource menu owned by the current user role (if the page layout is troublesome, you can also not change the original page, just shield the content of the div block without permission or display it without permission to view)
5. The content in the div block of the html front end is displayed, by requesting the unified interface platform API interface, the unified interface platform requests the specific java business platform API interface (microservice), the API network management intercepts, verifies whether the token exists in redis and is legal, and if it is legally released , Through client load balancing to obtain specific data to specific microservices, return to the html front end and display.