My Iot Project (13th) 2.0 platform architecture system, 2.0 Architecture
To be precise, the single application architecture of the 1.0 platform does not have an Internet project architecture. The traditional MVC development model and simple small workshop operation process, for every developer, you only need to focus on the implementation of functional modules of the business. During the six months of operating the 1.0 platform, in addition to the explosive growth of the business needs, the development iteration is required to be rapid, and each upgrade should not be broken, it's just a modular accumulation or partial updates in the original framework. In addition, we also see that the basic operation supporting facilities of the 1.0 platform are urgently needed, to improve the operational efficiency of the platform, such as the log platform, monitoring platform, scheduling platform, report platform, and even the permissions and single sign-on, therefore, the overall planning for the 2.0 platform should be included.
1. Overall platform capability Planning
It mainly removes all public items from the original business layer and operates in a platform-based software package.
1. the unified scheduling platform is often used by many businesses in the project. However, the 1.0 platform combines all scheduling and business execution work in the code, which makes the maintenance of a large number of scheduling jobs inconvenient, moreover, scheduling cannot monitor the currently running scheduling and the scheduling to be executed next time. The unified scheduling platform can solve this problem and effectively maintain all the scheduling work of the platform through the management interface. From the design point of view, the scheduling work is classified into the scheduling platform, the execution of services belongs to their respective business platforms (microservices ).
2. The unified interface platform is used to obtain data from the front-end application system through the unified interface platform and does not directly deal with external system interfaces. The unified interface platform connects to the external system to obtain data and provides various data format packages to the front-end application systems, effectively isolating the external system from the business system. The external interfaces requested by the front-end application system must be registered and opened on the unified interface platform. Each access will be effectively recorded and monitored. In the frontend and backend separation architecture system (in fact, microservices are like this), the unified interface platform also serves as a cross-domain, and load balancing function.
3. in the early stage, the central log platform mainly solved the trouble of logging on to the linux server and enabling various account permissions to view log logs. developers can manage logs and view logs through the management interface to improve work efficiency, ELK log analysis will be introduced to the platform in the middle and late stages.
4. the unified permission platform manages permissions on a variety of platforms (such as the preceding scheduling platform, interface platform, and log platform). This platform is used with SSO single-point logon, if an account is assigned to each platform in the traditional way, it is difficult to perform operations. The unified permission Platform + SSO Single Sign-On means assigning an account and assigning permissions, and you can access the major platforms.
5. the unified messaging platform manages the internal business system's MQ middleware platform. Similar to the unified scheduling platform, the business is executed by the Business. MQ is only responsible for Asynchronous Transfer and can be accessed through multiple protocols, such as http, the access is more robust and fast, and the maintenance is more convenient.
6. SSO single-point Logon: you only need to log on once to access all mutually trusted application systems without having to log on again.
More platforms are still under planning, and subsequent articles will also be involved, sharing some pitfalls and optimizations encountered.
Business split
2.0 business splitting of the architecture system is a headache. To be honest, according to the current project team and server planning, neither the Team nor the team can be split too carefully, optimization can only be performed in stages, so my plan is to split it slightly according to the business functions. After the overall process of the microservice Framework Platform is stable, the splitting will be refined for each business function.
Once the business domain is split, it also requires database sharding. The original single database is split into multiple databases.
In terms of the database architecture, considering the server cost, the standalone is still highly available in the early stage, and the sharded cluster will be created later.
Tri-Service Architecture
The overall process from the frontend request to the backend (subject to the actual project ):
1. Access the html front-end page (each page introduces checkCookie. js). If the cookie is invalid, the sso Single Sign-On page is displayed.
2. After sso authenticates the user and password, the token is generated and written to redis and cookie.
3. sso redirects to the html front-end page to be accessed (checkAuth is introduced for each page. js), html front-end page request (post request) Unified permission platform, the permission platform obtains tokens from cookies, and obtains user information from tokens, query the permissions of user roles and resource menus and return them to the html front-end.
4.html front-end displays different div Blocks Based on the Resource menu of the current user role (if the page layout is troublesome, you can also do not change the original page, you only need to block the content of the div block with no permission or display it without permission)
5.html content display in the front-end div block. The uniform interface platform API is requested to request specific java service platform API interfaces (microservices) and API Network Management interception, verify whether the token exists in redis and is valid. If the token is allowed, obtain the specific data through the Client Server Load balancer to a specific microservice, return the html front-end, and display the data.