Micro-service containerization and cloudization architecture construction method and related equipment thereof

Abstract

The invention provides a micro-service containerization and cloudization architecture construction method and related equipment thereof, an efficient and stable micro-service architecture capable of realizing efficient expansion can be constructed, and the micro-service architecture constructed by the embodiment of the invention has comprehensive micro-service management capability. Creation, deployment, monitoring, operation and maintenance and service management of micro-service applications can be supported, and a one-stop micro-service management solution is provided; the system has efficient application development and deployment functions, can support the functions of automatic construction, testing, deployment and the like, greatly shortens the software development and delivery cycle, and improves the development efficiency; the method has flexible resource configuration and expansibility functions, can support elastic scaling and dynamic resource scheduling, can flexibly adjust resource configuration according to service requirements, and meets different service scene requirements; furthermore, the system has powerful monitoring and alarming functions, and stable operation of the system is guaranteed.

Description

Technical Field

[0001] The present application relates to the technical field of microservice architecture construction, and in particular to a method for constructing a microservice containerized and cloudified architecture and related equipment. Background Art

[0002] In today's digital age, enterprises have a growing demand for information platforms. Traditional enterprise information architectures often face many challenges, such as insufficient stability, poor security, and difficulty adapting to rapid business changes and expansions. In order to meet the needs of the company's continuous development, it is crucial to build a stable, secure, and sustainable enterprise-level information platform.

[0003] Some existing information platforms have limitations in their technical architecture and cannot fully meet the complex needs of enterprises. For example, some platform functions lack flexibility, making it difficult to provide sufficient possibilities for product function expansion and effectively adapting to the future business growth and adjustments of enterprises; in terms of business document processing, it is impossible to achieve online customization of various complex documents, making it difficult to meet the diverse needs of different enterprises; business process configuration is not visual and flexible enough, resulting in a large amount of manpower and time costs in the adjustment process, and unable to provide stable and efficient support for business processes. There is an urgent need for an efficient and stable enterprise-level microservice architecture to provide enterprises with a solid technical foundation and help them build an efficient, flexible and sustainable information system. Summary of the invention

[0004] The present application aims to solve at least one of the above-mentioned technical defects. In view of this, the present application provides a microservice containerization and cloud architecture construction method and related equipment, which are used to solve the technical defect in the prior art that the microservice architecture cannot meet business needs.

[0005] A method for constructing a microservice containerized and cloudified architecture, comprising: constructing a common support framework of a microservice architecture to obtain a first microservice architecture; based on the first microservice architecture, constructing a public service component of the first microservice architecture to obtain a second microservice architecture; constructing a specific entity object service of the second microservice architecture to obtain a third microservice architecture; based on the third microservice architecture, constructing an extension module of the third microservice architecture to obtain a target microservice architecture.

[0006] Preferably, the common support framework for constructing the microservice architecture obtains the first microservice architecture, including:

[0007] Construct a database connection management mechanism for a microservice architecture, a first sub-service architecture; set a unified data return format for the first sub-service architecture to obtain a second sub-service architecture; set a unified return code and description information for the second sub-service architecture to obtain the first microservice architecture.

[0008] Preferably, based on the first microservice architecture, the public service component of the first microservice architecture is constructed to obtain the second microservice architecture, including: based on the first microservice architecture, the load balancing component of the first microservice architecture is constructed to obtain the third sub-service architecture, wherein the load balancing component is responsible for distributing multiple requests to different microservice instances; constructing the service registration and service discovery framework of the third sub-service architecture to realize the dynamic registration and discovery functions of its services to obtain the fourth sub-service architecture; constructing the transaction management function of the fourth sub-service architecture to realize its service management and ensure the transaction consistency across services to obtain the second microservice architecture.

[0009] Preferably, the specific entity object service of constructing the second microservice architecture to obtain the third microservice architecture includes: constructing the front-end service of the second microservice architecture to obtain the fifth sub-service architecture, wherein the front-end service of the second microservice architecture is responsible for interacting with the user, forwarding the user request to the back-end service of the second microservice architecture, and presenting the data returned by the back-end service of the second microservice architecture to the user; constructing the back-end service of the fifth sub-service architecture to obtain the third microservice architecture, wherein the back-end service of the fifth sub-service architecture is responsible for processing business logic and data operations.

[0010] Preferably, the back-end service of constructing the fifth sub-service architecture includes: constructing a business control layer framework of the fifth sub-service architecture to obtain a sixth sub-service architecture, wherein the business control layer framework of the fifth sub-service architecture is responsible for receiving requests from front-end services and verifying and converting them, and calling the corresponding business service layer for processing; constructing a business service layer framework of the sixth sub-service architecture to obtain a seventh sub-service architecture, wherein the business service layer framework of the sixth sub-service architecture is responsible for defining and implementing business logic interfaces; constructing a business persistence layer framework of the seventh sub-service framework to obtain the third microservice architecture, wherein the business persistence layer framework of the seventh sub-service framework is responsible for data interaction with the database to implement operations of adding, deleting, checking and modifying data.

[0011] Preferably, based on the third microservice architecture, an extension module of the third microservice architecture is constructed to obtain a target microservice architecture, including: constructing an application program interface for all external requests on the third microservice architecture to obtain an eighth sub-service architecture; constructing a configuration center on the eighth sub-service architecture to centrally manage the configuration information of all microservices to obtain a ninth sub-service architecture; constructing a log management framework of the ninth sub-service architecture to realize the functions of collecting and analyzing logs, and monitoring and analyzing the running status of microservices in real time to obtain a tenth sub-service framework; constructing a monitoring and alarm framework of the tenth sub-service framework to realize the functions of real-time monitoring of the performance indicators and health status of microservices and real-time alarming to obtain the target microservice framework.

[0012] Preferably, based on the third microservice architecture, constructing an extension module of the third microservice architecture to obtain a target microservice architecture includes: analyzing the business needs of users and determining functional modules corresponding to the business needs of users; and constructing functional modules corresponding to the business needs of users on the third microservice architecture to obtain the target microservice architecture.

[0013] A device for constructing a microservice containerization and cloudification architecture, comprising: a public support framework construction unit, used to construct a public support framework of a microservice architecture to obtain a first microservice architecture; a public service component construction unit, used to construct a public service component of the first microservice architecture based on the first microservice architecture to obtain a second microservice architecture; an entity object service construction unit, used to construct a specific entity object service of the second microservice architecture to obtain a third microservice architecture; an extension module construction unit, used to construct an extension module of the third microservice architecture based on the third microservice architecture to obtain a target microservice architecture.

[0014] A microservice containerization and cloudification architecture construction device includes: one or more processors, and a memory; the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the one or more processors, the steps of the microservice containerization and cloudification architecture construction method as described in any of the above introductions are implemented.

[0015] A readable storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors implement the steps of the microservice containerization and cloud architecture construction method as described in any of the above introductions.

[0016] It can be seen from the technical solutions introduced above that when it is necessary to build an efficient, stable microservice architecture that can be expanded in real time according to business needs, the method provided in the embodiment of the present application can construct a public support framework of the microservice architecture to obtain a first microservice architecture; wherein, the public support framework of the microservice architecture is the foundation of the microservice architecture and guarantees the public support capabilities of the microservice architecture. Therefore, after constructing the public support framework of the microservice architecture to obtain the first microservice architecture, the public service component of the first microservice architecture can be further constructed based on the first microservice architecture to obtain a second microservice architecture; the public service component is a module that can provide common functions for each microservice system architecture and can be shared and used by multiple microservices. Furthermore, in the microservice architecture, each entity object usually corresponds to Therefore, after constructing the public service component of the microservice architecture to obtain the second microservice architecture, the specific entity object service of the second microservice architecture can be further constructed so that it can have the service function of the specific entity object, thereby obtaining the third microservice architecture; further, in the actual application process, the microservice architecture of different platforms or units may be different. Therefore, after constructing a microservice architecture with public support capabilities, modules that can provide general functions, and service functions of entity objects, it is also possible to construct an extension module of the third microservice architecture based on the third microservice architecture, so that the constructed microservice architecture can also expand the required business modules according to the actual application scenarios and actual application needs, thereby obtaining an efficient, stable and scalable target microservice architecture.

[0017] It can be seen from the technical solutions introduced above that when it is necessary to build an efficient, stable and efficiently scalable microservice architecture, an efficient, stable and efficiently scalable microservice architecture can be built through the method provided in the embodiment of the present application. The microservice architecture constructed by the embodiment of the present application has comprehensive microservice management capabilities, which can support the creation, deployment, monitoring, operation and maintenance, and service governance of microservice applications, and provide a one-stop microservice management solution; it has efficient application development and deployment functions, can support automated construction, testing, deployment and other functions, greatly shortens the software development and delivery cycle, and improves development efficiency; it has flexible resource configuration and scalability functions, can support elastic scaling and dynamic resource scheduling, and can flexibly adjust resource configuration according to business needs to meet the needs of different business scenarios; further, it can also have powerful monitoring and alarm functions, such as providing real-time application performance monitoring and alarm functions, which can timely discover and handle potential problems and ensure the stable operation of the system; it can also have comprehensive security protection performance, such as providing security authentication, data encryption, access control and other security measures to ensure the security of applications and data. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor. Figure 1 A flowchart of a method for building a microservice containerized and cloud-based architecture provided in this application; Figure 2-Figure 5 Some effect diagrams provided for this application; Figure 6 A schematic diagram of a device structure for building a microservice containerized and cloudified architecture for an example of this application; Figure 7 This is a hardware structure block diagram of a microservice containerization and cloudification architecture construction device disclosed in this application. DETAILED DESCRIPTION

[0019] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0020] The method provided in the embodiments of the present application can be used in many general or special computing device environments or configurations. For example: personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor devices, distributed computing environments including any of the above devices or devices, etc. The embodiments of the present application provide a method for constructing a microservice containerization and cloud architecture, which can be applied to various microservice management systems, and can also be applied to various computer terminals or smart terminals, and its execution subject can be a processor or server of a computer terminal or smart terminal.

[0021] Combine the following Figure 1 , introduces the process of the microservice containerization and cloud architecture construction method given in the embodiment of the present application, such as Figure 1 As shown, the process can include the following steps:

[0022] Step S101, constructing a common support framework of a microservice architecture to obtain a first microservice architecture.

[0023] Specifically, the public support framework of the microservice architecture provides a series of common functional modules and tool classes, such as database access, cache management, message queues, etc. Developers can directly call these existing codes, avoiding the need to repeatedly write the same functional code, greatly saving development time. The public support framework of the microservice architecture has formulated unified development specifications and standards, including code style, interface design, data format, etc., so that different microservice development teams can develop according to the same specifications, reducing the communication cost and code integration difficulty caused by inconsistent specifications, and improving the overall development efficiency. The public support framework of the microservice architecture can uniformly monitor and manage microservices, monitor the running status and performance indicators of services in real time, promptly discover and solve potential problems, and improve the stability and reliability of services. The public support framework of the microservice architecture provides fault tolerance and degradation mechanisms. When a microservice fails, it can automatically perform fault tolerance processing, such as calling backup services, returning default data, etc., to avoid the entire system from crashing due to single point failures and improve user experience. The public support framework of the microservice architecture centrally manages the configuration information of each microservice, which facilitates the operation and maintenance personnel to make unified modifications and deployments, avoids the tedious operation of modifying the configuration separately in each microservice, and improves the efficiency and accuracy of configuration management. The public support framework of the microservice architecture provides service governance functions such as service registration and discovery, load balancing, and circuit breaking. Operation and maintenance personnel can easily manage and schedule microservices to achieve elastic scaling and high availability of services. The public support framework of the microservice architecture determines a unified technology selection and technology stack, avoids communication barriers and technical integration problems caused by large differences in technology selection between different teams, enables team members to better collaborate and share technical experience, and also defines clear interface specifications. Each microservice communicates through a standardized interface. When developing microservices, different teams only need to focus on the implementation of the interface without having to understand the internal details of other microservices, which reduces the coupling between teams and improves the efficiency of team collaboration. The microservice architecture itself is flexible and scalable, and the public support framework further reduces the cost and difficulty of developing new microservices, enabling enterprises to quickly respond to market demand, launch new business functions and services, and accelerate the pace of business innovation. It is also conducive to building a microservice ecosystem within the enterprise. Different microservices can be integrated and collaborated through a public support framework to form an organic whole, providing strong support for the business expansion and diversified development of the enterprise.

[0024] Therefore, when it is necessary to build an efficient, stable and scalable microservice architecture, a common support framework of the microservice architecture can be built first, so as to obtain a first microservice architecture. Among them, the common support framework of the microservice architecture can ensure that each microservice of the microservice architecture can run efficiently and stably. The process of building a common support framework of the microservice architecture can include the following steps:

[0025] (1) Build a database connection management mechanism for the microservice architecture, the first sub-service architecture.

[0026] Specifically, in the process of constructing actual applications, microservices usually interact with the database frequently. If each microservice creates and manages database connections, it will lead to frequent creation and destruction of a large number of connections, which will consume a lot of system resources and time. In order to achieve efficient use of available resources, when building a public support framework for the microservice architecture, a database connection management mechanism for the microservice architecture can be constructed. Through the database connection management mechanism, unified management of the connection pool can be achieved, existing database connections can be reused, the overhead of connection creation and destruction can be reduced, and the utilization efficiency of system resources can be improved. In addition, database connection resources can be reasonably allocated. According to the business needs and load conditions of the microservices, the number of connections available for each microservice can be dynamically adjusted, which can avoid performance problems of some microservices due to insufficient number of connections, and prevent individual microservices from occupying too many connections and causing resource waste, ensuring that the resource allocation of the entire system is more reasonable and balanced. The database connection management mechanism of the microservice framework can optimize the configuration of database connections, such as setting appropriate connection timeouts, adjusting the maximum idle time of connections, etc., reducing performance problems caused by connection waiting or long idle time, and improving the response speed and throughput of database operations, thereby improving the performance of the entire microservice architecture. By monitoring and managing database connections, abnormal connection situations, such as connection leakage and database failure, can be discovered and handled in a timely manner, avoiding microservice failures or unavailability due to database connection problems, and enhancing the stability and reliability of the system. In the common support framework of the microservice framework, the database connection management mechanism can centrally manage the database connection configuration of all microservices, including the database address, port, user name, password and other information, which is convenient for unified modification and deployment, and improves the efficiency and accuracy of configuration management. It can monitor the connection between each microservice and the database in real time, such as the number of connections, connection status, execution time of database operations, etc., and provide detailed monitoring data and statistical information for operation and maintenance personnel, so as to timely discover potential performance bottlenecks and problems, so as to take corresponding optimization measures. In addition, the database connection management mechanism can also integrate security authentication and authorization functions, authenticate and control the connection between microservices and databases, ensure that only authorized microservices can access the corresponding database resources, prevent illegal access and data leakage, and improve the security of the system. During the database connection process, the transmitted data can be encrypted to ensure the security and integrity of the data during network transmission, prevent the data from being stolen or tampered with, and further enhance the security protection capabilities of the system. In the microservice architecture, different microservices may need to connect to different databases, or in some cases need to access multiple data sources at the same time. The database connection management mechanism built into the microservice architecture can easily implement the management and switching of multiple data sources, provide a unified multi-data source access interface for microservices, and reduce the complexity of multi-data source operations.When there are cross-service data interactions and transaction operations between microservices, data consistency and integrity need to be guaranteed. The database connection management mechanism can be integrated with the distributed transaction coordinator to achieve the management and control of distributed transactions, ensuring that data consistency is effectively guaranteed in complex business scenarios.

[0027] For example, in actual application, you can use a database connection pool management tool such as Druid to optimize the use of database connections and improve system performance and stability.

[0028] (2) Setting a unified data return format for the first sub-service architecture to obtain a second sub-service architecture.

[0029] Specifically, in the actual application process, the front-end and back-end of the microservice architecture often collaborate. In order to improve the efficiency of front-end and back-end collaboration and improve the convenience of front-end development, when building the public support framework of the microservice architecture, after building its database connection management mechanism to obtain the first sub-service framework, the unified data return format of the first sub-service architecture can be further set. Setting a unified data return format can enable front-end developers to process and display data more conveniently. There is no need to write different parsing and processing logic for different return formats of each microservice, which reduces the complexity and workload of the front-end code and improves the efficiency of front-end development. Setting a unified data return format can clarify the return data structure of the interface. Both front-end and back-end developers can develop independently based on this specification. As long as the data returned by the interface conforms to the unified format, the front-end can correctly render and interact with the data, reducing the difficulty and cost of front-end and back-end joint debugging and improving the collaboration efficiency of the entire project. In the application process of the microservice architecture, there may be mutual calls between the various microservices. Setting a unified data return format can make the communication between microservices more standardized and standardized. The calling microservice does not need to understand the specific implementation details of the called microservice. It only needs to parse the returned data in a unified format, which reduces the coupling between microservices and improves the maintainability and scalability of the system. In the actual application process, when multiple microservices need to be integrated or combined into new business functions, the unified data return format can easily integrate and process the data returned by different microservices, avoiding the additional conversion and adaptation work caused by inconsistent data formats, and speeding up the service integration. In the actual application process, in order to enhance the maintainability of the system, a unified data return format is set. A unified error code and error message specification can be defined in the unified data return format. When an error occurs in a microservice, the error message is returned in a unified format, so that operation and maintenance personnel and developers can quickly locate and handle the problem, improving the maintainability of the system and the efficiency of troubleshooting. If the data return format needs to be modified or upgraded, it only needs to be adjusted uniformly in the public support framework. All microservices follow this specification to return, avoiding the omissions and inconsistencies that may be caused by modifying the data format of each microservice, and reducing the difficulty of system maintenance.

[0030] Furthermore, setting a unified data return format can also improve the stability and reliability of the system, ensure the consistency of the format of the data returned by different microservices, avoid problems such as front-end data rendering errors or data processing exceptions caused by data format confusion, improve the stability and reliability of the system, and enhance the user experience. When the system is upgraded or the microservice is replaced, as long as the new microservice follows the unified data return format, it can be seamlessly connected with the existing system, ensuring the compatibility of the system and reducing the risks that may be caused by version upgrades or service replacements. Furthermore, the unified data return format can facilitate data analysis and monitoring. Data can be collected and stored according to a unified structure, which is convenient for data statistics, analysis and mining, and provides strong support for system performance optimization and business decision-making. Furthermore, if the system has monitoring and alarm functions and sets a unified data return format, the operation and maintenance personnel can more conveniently monitor the operating status of the system based on the unified data return format, set corresponding monitoring indicators and alarm rules, and promptly discover and handle abnormal situations in the system to ensure the stable operation of the system.

[0031] For example, setting a unified data return format can ensure that all microservices follow the same format (such as JSON) when returning data, which facilitates data interaction and parsing between the front-end and back-end.

[0032] (3) Setting a unified return code and description information of the second sub-service architecture to obtain the first microservice architecture.

[0033] Specifically, in the actual application process, when an exception or error occurs in a microservice, if there is a unified return code, the caller can quickly identify the error type and cause. For example, a unified "400" code may indicate that the client request parameter is wrong. Developers and operation and maintenance personnel can quickly focus on checking the request parameters when seeing this code, without having to analyze the lengthy error description or log in detail, thereby greatly improving the speed of problem location. Therefore, in order to efficiently manage each microservice, after setting a unified data return format to obtain the second sub-service architecture, the unified return code and its description information of the second sub-service architecture can be further set, so that the first microservice architecture can be obtained. After setting the unified return code and its description information of the microservice architecture, the public support framework can centrally manage and maintain all return codes and their descriptions. When a new error type occurs or the existing error information needs to be modified, it only needs to be updated in a unified place, avoiding the inconsistency and omission problems caused by the scattered processing of error information in each microservice, and improving the overall efficiency of error handling. The unified return code and its description information make the communication between microservices more standardized. The calling microservice does not need to understand the specific internal implementation of the called microservice. It only needs to obtain enough information to perform corresponding processing based on the unified return code, which reduces the coupling between microservices and improves the maintainability and scalability of the system. In the code of microservices, the use of unified return codes and their descriptions can make the error handling logic in the code clearer and easier to understand. When developers read and modify the code, they can more easily understand the meaning of each return code and the processing measures that should be taken, reducing the difficulty of code maintenance.

[0034] Furthermore, for clients, whether they are Web applications, mobile applications, or other types of clients, unified return codes and their description information enable them to use a unified approach to process the results returned by the server. For example, the client can display corresponding friendly prompt information to the user based on the unified return code, without having to process the different return formats and error codes of each microservice separately, thereby improving the reusability and maintainability of the client code. When a user operation triggers a microservice to return an error, the client can obtain accurate description information based on the unified return code and display it to the user in an easy-to-understand manner, so that the user can clearly understand the problem, thereby improving the user experience and reducing the confusion and dissatisfaction caused by unexplained errors. The unified return code can also be easily integrated with the monitoring system. The monitoring system can perform statistics and analysis based on different return codes, understand the frequency and distribution of various errors in the system in real time, and promptly discover the weak links and potential problems of the system. For example, by monitoring the "500" internal server error code, you can quickly locate which microservices in the system have frequent internal errors, so that they can be optimized and adjusted in a timely manner. When performing data analysis, the unified return code and its description information can be used as an important data dimension. By analyzing the number of occurrences and time distribution of different return codes, we can gain in-depth insights into user behavior, system performance, and other aspects, providing strong data support for system optimization and business decision-making. In microservice architecture, service upgrades and replacements are relatively common. Unified return codes and their description information can ensure that during service upgrades or replacements, as long as the return codes and their meanings remain unchanged, clients and other caller microservices do not need to make a lot of modifications, ensuring system compatibility and consistency and reducing the risk of system upgrades and replacements. In large-scale microservice architecture projects, multiple different development teams are often involved. Unified return codes and their description information provide unified specifications and standards for cross-team collaboration, avoiding communication costs and collaboration barriers caused by different understandings and processing methods of return results between different teams, and ensuring the coordination and consistency of the entire system.

[0035] For example, by defining a unified set of return codes and description information, the data returned by microservices can be easily processed and parsed, improving the maintainability and scalability of the system.

[0036] Step S102: construct a public service component of the first microservice architecture based on the first microservice architecture to obtain a second microservice architecture.

[0037] Specifically, in a microservice architecture, different microservices may have some identical or similar functional requirements, such as data caching, logging, configuration management, etc. By constructing a public service component, these common functions can be encapsulated in the component for reuse by each microservice, avoiding the repeated development of the same code in each microservice, improving development efficiency, and reducing the amount of code. The public service component can also provide a unified technical implementation method for different microservices to ensure consistency in the processing of the same function throughout the microservice architecture. For example, for data encryption and decryption functions, the public service component can provide a unified encryption algorithm and key management mechanism, so that each microservice adopts the same security standard when processing sensitive data, reducing the risks caused by inconsistent technical implementation. Therefore, in the actual application process, after constructing the public support framework of the microservice architecture to obtain the first microservice architecture, the public service component of the first microservice architecture can be further constructed based on the first microservice architecture, so that the second microservice architecture can provide a module of common functions to the outside world, so as to realize the provision of public services by multiple microservices.

[0038] The public service components of the microservice architecture can be centrally managed. When a public function needs to be modified or upgraded, it only needs to be operated at the component level, without modifying each microservice that uses the function one by one. This greatly reduces the difficulty and cost of system maintenance and improves the maintainability and stability of the system. Microservices themselves focus on implementing specific business functions, and some non-core public functions are stripped into public service components, making the code of microservices more concise and clear, reducing the complexity of microservices and making it easier for developers to understand and maintain. Public service components can be developed, optimized and tested by dedicated teams that have richer experience and expertise in the corresponding technical fields. Through professional development and strict testing processes, the quality and stability of public service components can be effectively guaranteed, thereby improving the stability and reliability of the entire microservice architecture. Public service components can implement a unified exception handling mechanism and monitoring function internally, and monitor and log the operation status of the components in real time. When an exception occurs, it can be processed and alarmed in a timely manner, which facilitates operation and maintenance personnel to quickly locate and solve the problem, improving the stability and reliability of the system. Building public service components helps to clarify the division of labor and responsibilities of different teams. Some teams can focus on the development and maintenance of public service components, while other teams focus on the business logic development of microservices. This can improve the work efficiency of teams and reduce the collaboration costs and communication barriers between teams. Building public service components of microservice architecture can provide a platform for technology sharing and communication for different teams. Each team can carry out technical innovation and optimization based on the components, share experiences and best practices, and promote technical exchanges and common progress between teams.

[0039] Public service components have good pluggability and replaceability. When the system needs to introduce new technologies or upgrade existing functions, public service components can be easily replaced or expanded without having much impact on the business logic of microservices.

[0040] As the business develops and changes, the microservice architecture needs to be constantly adjusted and evolved. Public service components can serve as a stable basic support, quickly respond to changes in business needs, and provide strong support for the flexible expansion and evolution of the microservice architecture.

[0041] Among them, based on the first microservice architecture, the process of building a public service component of the first microservice architecture may include the following:

[0042] (1) Based on the first microservice architecture, a load balancing component of the first microservice architecture is constructed to obtain a third sub-service architecture, wherein the load balancing component is responsible for distributing multiple requests to different microservice instances.

[0043] Specifically, as the volume of business in the microservice architecture continues to grow, the request pressure on each microservice instance may be unbalanced. The load balancing component can evenly distribute client requests to multiple available microservice instances based on preset algorithms, such as polling, weighted polling, random, etc., to avoid performance bottlenecks in some instances due to excessive load while other instances are idle, thereby achieving reasonable utilization of resources and improving the throughput and response speed of the entire system.

[0044] In the microservice architecture, cache is one of the important means to improve system performance. The load balancing component can direct client requests with the same or similar request characteristics to the same group of microservice instances, which can improve the cache hit rate on these instances, reduce repeated data queries and processing, and further improve the performance and response efficiency of the system. Therefore, when constructing the public service component of the microservice architecture, the load balancing component of the first microservice architecture can be constructed based on the first microservice architecture to obtain the third sub-service architecture, in which the constructed load balancing component is responsible for distributing multiple requests to different microservice instances.

[0045] In a microservice architecture, a single microservice instance may fail due to hardware failure, software vulnerabilities, network problems, etc. The load balancing component can monitor the health status of each microservice instance in real time. When an instance is found to be unavailable, it automatically forwards the request to other healthy instances to achieve failover, ensure the continuity and availability of the system, and avoid paralysis of the entire system due to a single point of failure. By distributing requests to multiple microservice instances, the load balancing component can avoid the system's excessive reliance on a single instance and reduce the impact of a single point of failure on the system. Even if some instances fail, the system can continue to provide services through other normal instances, thereby improving the overall reliability and stability of the system.

[0046] During business peaks or business growth phases, microservices sometimes need to be dynamically expanded to meet the increasing request demands. The load balancing component combined with the automatic expansion mechanism of microservices can automatically sense newly added microservice instances and reasonably distribute request traffic to these newly added instances, achieving seamless expansion of the system without manual intervention, improving the flexibility and scalability of the system.

[0047] In actual application, according to the changes in business load, operation and maintenance personnel can easily adjust the weight or allocation strategy of each microservice instance through the load balancing component to achieve flexible resource allocation. For example, for instances with strong processing capabilities, more request weights can be allocated to enable them to bear more business loads, while for instances with slightly poorer performance, their loads can be appropriately reduced, thereby optimizing the overall performance of the system. By reasonably allocating request traffic, the load balancing component can ensure that each request can be processed in a timely manner, reduce the client's waiting time, and optimize the request response time. For users, they can get a faster and smoother system interaction experience, which improves user satisfaction and loyalty.

[0048] In some large distributed systems, microservices may be deployed in multiple different regions or data centers. The load balancing component can route requests to the microservice instance closest to the user or with the best network condition based on the user's geographic location or network condition, further optimizing response time and improving user experience.

[0049] For example, in actual application, requests can be distributed to multiple microservice instances through a load balancer (such as Nginx, HAProxy, etc.) to improve the throughput and reliability of the system.

[0050] (2) constructing a service registration and service discovery framework of the third sub-service architecture to implement dynamic registration and discovery functions of its services, thereby obtaining a fourth sub-service architecture;

[0051] Specifically, in a microservice architecture, the number and instances of services may change as the business develops. New services may be created, and old services may be updated or taken offline. The service registration and service discovery framework allows microservices to automatically register their information with the registry when they start, including service name, IP address, port number, health status, etc. At the same time, other microservices can obtain the latest information of these services in real time through the service discovery mechanism, thereby realizing automatic registration and discovery of services without manual intervention, greatly improving the manageability and operation and maintenance efficiency of the system.

[0052] Therefore, after constructing the load balancing component of the first microservice architecture and obtaining the third sub-service architecture, the service registration and service discovery framework of the third sub-service architecture can be further constructed to realize the dynamic registration and discovery functions of its services, thereby obtaining the fourth sub-service architecture.

[0053] The service registration and service discovery framework can monitor the status changes of each microservice in real time, such as service launch, offline, failure, etc. When the service status changes, the registration center will promptly notify other microservices that depend on the service, so that they can dynamically adjust the service call strategy, realize automatic service switching and failover, and ensure the stability and availability of the system.

[0054] From the above introduction, we can know that the third sub-service architecture includes a load balancing component. In actual application, the load balancing component needs to know the list of currently available microservice instances and their status information in order to effectively distribute requests. The service registration and service discovery framework can provide an accurate service list for the load balancing component. The load balancing component can obtain the status of each microservice instance in real time based on the information of the registration center, such as availability, load status, etc., so as to reasonably distribute requests to different instances according to the preset algorithm, realize load balancing, and improve the performance and reliability of the system.

[0055] Through the service registration and service discovery framework, the system can formulate flexible traffic scheduling strategies according to business needs and service status. For example, the traffic distribution ratio can be dynamically adjusted according to the load of the service, and more traffic can be distributed to service instances with lighter loads; or traffic can be distributed to key business services first according to the priority of the service to ensure the response speed and availability of important businesses.

[0056] In actual application, when business growth requires the expansion of microservices, new microservice instances can be easily registered with the registration center, and other microservices can automatically sense the addition of new instances through the service discovery mechanism and distribute request traffic to the new instances, thus achieving seamless expansion of services. At the same time, if a microservice needs to be upgraded or replaced, only the new service instance needs to be registered with the registration center, and the old instance is offline. The whole process is transparent to other microservices and will not affect the normal operation of the system, thus improving the scalability and flexibility of the system.

[0057] In a complex enterprise-level application, multiple programming languages ​​and technical frameworks may be used to implement different microservices. The service registration and service discovery framework provides a unified service management mechanism that is independent of the specific technical implementation, allowing microservices in different languages ​​and heterogeneous systems to be easily integrated and collaborated. Each microservice only needs to register itself to the registration center according to unified specifications and obtain information about other services through the service discovery mechanism to achieve mutual calling and integration, breaking down technical barriers and promoting system integration and development.

[0058] As a centralized service management platform, the service registration and service discovery framework stores all microservice related information, including basic service information, instance information, status information, etc. Operation and maintenance personnel can intuitively view the operation status of all services in the system through the registration center, which is convenient for monitoring and management. For example, the number of instances, load conditions, health status, etc. of each service can be viewed in real time to identify potential problems and handle them in a timely manner.

[0059] When a system fails, the service registration and service discovery framework can provide rich service information to help operation and maintenance personnel quickly troubleshoot and locate the fault. By viewing the service registration information and status change records, the time of the fault, the scope of impact, and the possible causes can be determined, so that the fault can be repaired more specifically and the system's fault recovery time can be shortened.

[0060] For example, in actual application, using a service registry (such as Eureka, Consul, Nacos, etc.) to manage and discover microservice instances can achieve dynamic registration and discovery of services, which can improve the flexibility and scalability of the system.

[0061] (3) Constructing the transaction management function of the fourth sub-service architecture to implement its service management and ensure transaction consistency across services, thereby obtaining the second microservice architecture.

[0062] Specifically, in a microservice architecture, a business operation often involves the collaboration of multiple microservices. For example, in an e-commerce system, an order operation may involve multiple microservices such as order service creating an order, inventory service deducting inventory, and payment service processing payment. If there is no effective transaction management, when one of the microservices fails or performs abnormally, data inconsistency may occur, such as the order is successfully created but the inventory is not deducted, or the payment is successful but the order status is not updated. The transaction management function coordinates the operations of multiple microservices to ensure that they are either all executed successfully or all rolled back, thereby ensuring the data integrity of cross-microservice operations. Multiple microservices may read and write the same data at the same time. If there is no transaction management function, data conflicts may occur. For example, if two users place orders for the same product at the same time, it may cause oversold inventory. The concurrency control mechanism in transaction management can effectively control concurrent operations through locking mechanisms, optimistic locking, etc., to avoid data conflicts and ensure data consistency.

[0063] In a microservice architecture, calls between microservices may be abnormal due to network delays, service failures, etc. The transaction management function can provide a fault recovery and compensation mechanism. When an exception occurs, it can automatically roll back the system to the state before the transaction started, avoiding data in an inconsistent intermediate state. At the same time, you can also reverse the partially successful operation by compensating for the transaction to achieve final data consistency.

[0064] The transaction management function can effectively monitor and manage microservice calls. When a microservice fails, it can sense and take corresponding measures in time, such as automatically switching to backup services and retrying, thereby enhancing the fault tolerance of the system and improving the reliability and stability of the system. Without the transaction management function, developers need to handle the start, commit, rollback and other operations of transactions in each microservice, and need to consider the handling of various abnormal situations, which makes the business logic complicated and error-prone. The transaction management function provides a unified transaction management and coordination mechanism. Developers only need to mark the business operations that require transaction management, and the transaction management component will automatically handle the relevant operations of the transaction, which greatly simplifies the implementation of business logic and improves development efficiency. The transaction management function separates the transaction processing logic from the business logic, making the business logic clearer and easier to maintain. Developers can focus on the implementation of business functions without paying too much attention to the specific processing details of transactions. When business requirements change or transaction processing needs to be adjusted, they only need to modify the configuration or code related to transaction management without affecting the core part of the business logic, which improves the maintainability and scalability of the code.

[0065] Microservice architecture is usually distributed, and different microservices may be deployed in different servers or containers, or even distributed in different data centers. Traditional single-machine transaction management mechanisms cannot meet the transaction requirements in such a distributed environment. The transaction management function can support distributed transactions. By adopting distributed transaction protocols such as two-phase commit (2PC), three-phase commit (3PC), TCC, etc., it can effectively manage and coordinate distributed transactions between multiple microservices, ensuring data consistency and system reliability in a distributed environment.

[0066] In a microservice architecture, different microservices may use different databases. When a business operation involves multiple microservices and multiple databases, transaction management is required to implement cross-database transactions. The transaction management function can use technologies such as distributed transaction coordinators to perform unified transaction management for cross-database operations, ensure data consistency between different databases, and meet the needs of complex business scenarios.

[0067] Therefore, after constructing the service registration and service discovery framework of the third sub-service architecture and obtaining the fourth sub-service architecture, the transaction management function of the fourth sub-service architecture can be further constructed to realize its service management and ensure transaction consistency across services, thereby obtaining the second microservice architecture.

[0068] For example, in a microservice architecture, transaction management usually involves collaboration between multiple services. By using distributed transaction management tools (such as Seata, etc.), transaction consistency across services can be ensured.

[0069] For example, Figure 2 As shown, based on the microservice architecture provided by this application, the online configuration center based on Spring Cloud Eureka, Spring Cloud Consul, and Nacos Serrver can configure multiple operating environments, generally for development, testing, and production environments, for centralized configuration. The configuration center allows all applications to share one or more system parameter configurations. Through real-time modification, various application switch parameter controls can be performed on all micro-applications. The three open source components Eureka, Consul, and Nacos themselves have the functions of registering and discovering services. Use it directly to register the configuration information, and the application program can directly read the application. Figure 3 As shown in the figure, Nacos can act as the service discovery and service registration center for all microservices, and concurrently manage all system-level or application-level system parameter configurations of the platform.

[0070] Step S103: construct a specific entity object service of the second microservice architecture to obtain a third microservice architecture.

[0071] Specifically, in actual application, specific entity object services focus on processing specific business entities or business processes, such as order management, user management, inventory management, etc. By building these services, complex business systems can be decomposed into multiple small and precise business units, each of which can deeply focus on the business area it is responsible for, achieve high specialization of business functions, and better meet business needs.

[0072] Therefore, after constructing the public service components of the first microservice architecture based on the first microservice architecture to obtain the second microservice architecture, the specific entity object services of the second microservice architecture can be further constructed to implement services related to each entity object, thereby obtaining the third microservice architecture.

[0073] Different business scenarios and user needs have different requirements for data and operations. Building specific entity object services can provide customized service interfaces and functional implementations for different business objects based on these differences. For example, in an e-commerce system, the order service can provide a variety of operations such as creating orders, querying orders, and canceling orders based on different order statuses and user roles to meet the various needs of users during the shopping process.

[0074] As the business develops, the load and demand changes of different business functions may be different. The independence of specific entity object services allows them to be independently expanded according to their respective business growth, such as increasing server resources, optimizing database queries, etc., without affecting other services. This independent expansion capability can better cope with the uncertainty and rapid changes of the business and improve the overall scalability of the system. The microservice architecture emphasizes the flexible combination and orchestration of services to meet the needs of different business processes. As a basic building block, specific entity object services can be flexibly combined and adjusted according to changes in business processes. For example, in a complex business process, a complete business operation can be completed by calling multiple specific entity object services. For example, in the order processing process, the user service is called in turn to verify the user's identity, the inventory service is called to check the inventory, and the order service is called to create an order. This flexible combination method can quickly respond to the adjustment and optimization of business processes.

[0075] Distributing business logic to specific entity object services can make the business logic of each service relatively simple and clear. Developers can focus more on the implementation and maintenance of specific business functions, reduce the complexity of the overall business logic, and improve the readability and maintainability of the code. When a business function needs to be modified or optimized, it only needs to be operated in the corresponding specific entity object service without affecting other unrelated services. The clear boundaries and responsibilities of specific entity object services make it easier to monitor and govern them. Independent monitoring indicators and alarm rules can be set for each service to understand the operating status and performance of the service in real time. At the same time, in terms of service governance, such as service registration and discovery, load balancing, circuit breaker degradation, etc., it can also be configured and managed more specifically, improving the manageability and stability of the system. Building specific entity object services can help clarify the responsibilities and scope of work of different development teams. Each team can be responsible for the development and maintenance of one or more specific entity object services, so that team members can focus more on the technical implementation of specific business areas and improve work efficiency and quality. At the same time, clear division of responsibilities also reduces the collaboration cost and communication barriers between teams, and facilitates coordination and cooperation between teams. Different specific entity object services can try different technology selections and architecture designs according to their business characteristics and technical requirements. This diversified technical practice provides soil for technological innovation. The team can explore and apply new technologies, frameworks and design patterns in the services they are responsible for, accumulate experience through practice, and promote technological progress and innovation of the entire system. Specific entity object services can also reasonably allocate system resources according to the importance and load of the business. For business services with high concurrency and high performance requirements, more resources can be allocated to ensure their operating efficiency; while for some low-frequency access services, resource occupation can be appropriately reduced. Through this refined resource allocation, the utilization rate of system resources can be improved and the overall performance can be improved. Each specific entity object service can be designed and optimized for stability according to its own business characteristics, such as adopting appropriate caching strategies, database connection pool management, error handling mechanisms, etc. Through these optimization measures, the probability of service failure is reduced and the availability and reliability of the service are improved. At the same time, when a service fails, mechanisms such as fuse downgrade can be used to prevent the failure from spreading to other services and ensure the stable operation of the entire system.

[0076] Among them, the process of constructing the specific entity object service of the second microservice architecture to obtain the third microservice architecture may include the following steps:

[0077] (1) Build the front-end service of the second microservice architecture to obtain the fifth sub-service architecture.

[0078] Specifically, in a microservice architecture, each entity object usually corresponds to a set of related services. These services can be divided into front-end services and back-end services. Therefore, when constructing a specific entity object service of the second microservice architecture, the front-end service of the second microservice architecture can be constructed first, so that the fifth sub-service architecture can be obtained, wherein the front-end service of the second microservice architecture is responsible for interacting with the user, forwarding the user request to the back-end service of the second microservice architecture, and presenting the data returned by the back-end service of the second microservice architecture to the user.

[0079] (2) Constructing the backend service of the fifth sub-service architecture to obtain the third microservice architecture, wherein the backend service of the fifth sub-service architecture is responsible for processing business logic and data operations.

[0080] Specifically, after constructing the front-end service of the second microservice architecture to obtain the fifth sub-service architecture, the back-end service of the fifth sub-service architecture can be further constructed, thereby obtaining the third microservice architecture.

[0081] The process of constructing the backend service of the fifth sub-service architecture may include the following:

[0082] 1) Construct a business control layer framework of the fifth sub-service architecture to obtain the sixth sub-service architecture.

[0083] Specifically, in the microservice architecture, the backend service is mainly responsible for processing business logic and data operations. The backend service can be further subdivided into the business control layer, the business interface service layer and the business persistence layer. Therefore, when building the backend service of the fifth sub-service architecture, the business control layer framework of the fifth sub-service architecture can be constructed.

[0084] Among them, the business control layer framework of the fifth sub-service architecture is responsible for receiving requests from front-end services, verifying and converting them, and calling the corresponding business service layer for processing;

[0085] 2) Constructing the business service layer framework of the sixth sub-service architecture to obtain the seventh sub-service architecture.

[0086] Specifically, from the above introduction, it can be seen that the back-end service includes the business service layer. Therefore, after constructing the business control layer framework of the fifth sub-service architecture and obtaining the sixth sub-service architecture, the business service layer framework of the sixth sub-service architecture can be further constructed to obtain the seventh sub-service architecture, wherein the business service layer framework of the sixth sub-service architecture is mainly responsible for defining and implementing the business logic interface.

[0087] 3) Build a business persistence layer framework of the seventh sub-service framework to obtain the third microservice architecture.

[0088] Specifically, from the above introduction, it can be seen that the back-end service includes a business persistence layer. Therefore, after constructing the business service layer framework of the sixth sub-service architecture and obtaining the seventh sub-service architecture, the business persistence layer framework of the seventh sub-service framework can be further constructed to obtain the third microservice architecture. Among them, the business persistence layer framework of the seventh sub-service framework is responsible for data interaction with the database to realize the addition, deletion, query and modification operations of data.

[0089] In the actual application process, the backend service provided by this application adopts a unified and standardized application development, and provides a unified RESTful API to support the development of various applications of front-end services. The third microservice architecture built by this application provides various basic components, which can be used to build various backend applications through Maven references. The architecture level is as follows: Figure 4 As shown. Figure 4 From bottom to top, it can be divided into storage layer, service layer, middle layer and front end. Their functions are as follows:

[0090] (1) Storage layer - data persistence storage: The storage layer is responsible for interacting with various data sources (such as databases, caches, etc.) and providing a unified data access interface for the upper layer. It is the key to data storage and management. It covers a variety of storage forms, such as row storage of relational databases, emerging column storage, graph storage, key-value storage, etc., to meet the storage needs of different types of data and ensure the effective storage and reading of data.

[0091] (2) Service layer - a bridge for communication between systems: The service layer aims to reduce the complexity of the interconnections between systems, and plays a role such as the configuration center managing configuration files in a unified manner, and the service center solving configuration and scheduling problems of cross-system dependencies. At the same time, it uses message queues to implement asynchronous processing, application decoupling, traffic peak shaving and other functions, promoting efficient collaboration and information flow between systems.

[0092] (3) Middle layer - the key link between the upper and lower layers: The middle layer often plays the role of connecting the upper and lower layers, and has different manifestations in different scenarios. For example, in the organizational structure, it is a bridge between the upper and lower layers. In the software architecture, it is the part that coordinates the interaction between business logic and the presentation layer and data layer, and plays an important role in information transmission, resource allocation, and assisting decision-making execution.

[0093] (4) Front-end - user interaction interface: The front-end is the core skill for building web pages and mobile application interfaces. By using technologies such as HTML, CSS, and JavaScript, the design is converted into an interactive user interface. It is responsible for implementing the appearance layout and interactive experience of the website or application, allowing users to interact with the website or application conveniently, giving users an intuitive user experience and affecting user satisfaction with the entire system.

[0094] In the actual application process, the backend application adopts the standard application development of SpringBoot, that is, a multi-layer application is implemented, as shown below:

[0095] (1) Interface layer: Provides a unified interface for front-end applications, generally a standard RESTful API.

[0096] (2) Business layer: manages the platform’s business applications, implements business logic operations, and provides service application components for the interface layer to call.

[0097] (3) Persistence layer: implements the read and write interface management of the database, generally the original native Sql call of Mybatis or JDBC.

[0098] (4) Basic components: Basic components are unified components provided by the platform. They only need to be introduced and used. Each independent application only needs to build the business layer and interface, which greatly simplifies the difficulty of developing and building new applications.

[0099] Step S104: Based on the third microservice architecture, an extension module of the third microservice architecture is constructed to obtain a target microservice architecture.

[0100] Specifically, in the actual application process, different application scenarios and different users may have different business needs. After building a basic microservice framework with a public support framework, public service components and service functions of specific entity objects, in order to efficiently utilize the constructed basic microservice architecture, you can further build an extension module of the third microservice architecture based on the third microservice architecture, so as to obtain the target microservice architecture.

[0101] For example, after building an application program interface for all external requests on the third microservice architecture to obtain the eighth sub-service architecture, a configuration center is built on the eighth sub-service architecture to centrally manage the configuration information of all microservices to obtain the ninth sub-service architecture; a log management framework of the ninth sub-service architecture is built to realize the functions of collecting and analyzing logs, and real-time monitoring and analyzing the running status of microservices to obtain the tenth sub-service framework; a monitoring and alarm framework of the tenth sub-service framework is built to realize the functions of real-time monitoring of the performance indicators and health status of microservices and real-time alarms, so as to obtain the target microservice framework.

[0102] It is also possible to analyze the user's business needs and determine the functional modules corresponding to the user's business needs; and to build the functional modules corresponding to the user's business needs on the third microservice architecture, and to obtain the target microservice architecture.

[0103] For example, as the business continues to develop and change, after building the public support framework, public service components, and services for specific entity objects of the microservice architecture, the microservice architecture may need to add new modules or services to meet new needs. These extension modules may include the following:

[0104] (1) API Gateway: As the entry point for all external requests, the API Gateway can perform operations such as authentication, authorization, rate limiting, and monitoring on requests to protect the security of internal microservices.

[0105] (2) Configuration center: used to centrally manage the configuration information of microservices and facilitate dynamic updates and rollbacks of configurations.

[0106] (3) Log collection and analysis: Log collection and analysis tools (such as ELKStadk, Splunk, etc.) can be used to monitor and analyze the operating status of microservices in real time, and problems can be discovered and solved in a timely manner.

[0107] (4) Monitoring and alarm: Use monitoring and alarm systems (such as Prometheus, Grafana, etc.) to monitor the performance indicators and health status of microservices and issue alarm information in a timely manner.

[0108] For example, through the microservice architecture provided in the embodiment of the present application, based on the needs of the user, the following can be generated: Figure 5 The front-end service function shown has the function of automatically generating source code.

[0109] For example, when building a microservice architecture or application ecosystem, the microservice architecture provided by this application can integrate multiple front-end applications (such as PP, applets, enterprise communication applications, WEB applications, etc.) with back-end services. These services usually require authentication and authorization protocols such as OAuth2 to achieve secure and efficient access control.

[0110] For example, in the actual application process, a unified security authentication mechanism can be constructed based on the microservice architecture of this application. The unified authentication mechanism is generally a basic requirement for heterogeneous system integration, which can realize one-time login with the same account and seamless access switching between different systems, reducing the need for users to remember multiple different passwords and log in to different business systems when using the platform. To achieve this goal, the prerequisite requirement is to use the same account system or connect to the same user system data in each business system, and use the service integration service capability that provides single sign-on. The authentication center is a service application that provides unified identity authentication capabilities for other systems on the platform. Other users who access the authentication need to follow the following interface specifications:

[0111] (1) Register the accessed application, and the platform provides the application ID and key;

[0112] (2) Provide unified user login, including login methods such as account + password, mobile phone number + SMS login, USB Key login (optional), email + password, etc.

[0113] (3) Provide an interface for obtaining user identity information after login;

[0114] (4) Record the audit login log.

[0115] The microservice architecture provided by this application can support multiple security authentication modes: URL-level permission control, support for four modes of OAuth2.0 login, support for username, password plus graphic verification code login, support for mobile phone number plus password login, support for Openld login, and support for single sign-on of third-party systems.

[0116] For example, based on the microservice architecture provided by this application, the general steps for some applications to register and obtain access rights through OAuth2 are as follows:

[0117] 1. Prepare OAuth2 authorization server

[0118] (1) Build an authorization server: First, you need to build an OAuth2 authorization server to handle authentication and authorization requests and issue access tokens and refresh tokens.

[0119] (2) Configure client information: Register each front-end application as a client on the authorization server, assign them a unique client ID (ClientID) and client secret (ClientSecret), and define the resources and scopes they can access.

[0120] 2. Front-end application configuration

[0121] (1) Integrate OAuth2 client libraries: Integrate OAuth2 client libraries in various front-end applications. These libraries provide functions such as initiating authentication and authorization requests, processing responses, and storing access tokens.

[0122] (2) Configure authorization server information: Configure the authorization server URL, client ID, client key and other information in the front-end application.

[0123] 3. User authentication process

[0124] (1) Initiate an authentication request: When a user attempts to access a resource that requires authorization, the front-end application initiates an authentication request to the authorization server, usually a request that redirects to the authorization server's login page.

[0125] (2) User login: The user logs in on the login page of the authorization server. If the login is successful, the authorization server will ask the user whether he agrees to authorize the front-end application to access specific resources.

[0126] (3) Authorization consent: After the user agrees to the authorization, the authorization server will issue an access token to the front-end application. This token is usually passed as a query parameter or fragment identifier by redirecting back to the callback URL of the front-end application.

[0127] 4. Using the Access Token

[0128] (1) Storing the access token: After the front-end application receives the access token, it needs to store it securely for use in subsequent requests.

[0129] (2) Initiate API request: The front-end application uses the stored access token as the authentication credential and initiates an API request to the back-end service through the HTTP request header (such as Authorization: Bearer <token>).

[0130] (3) Backend service verifies the token: After receiving the request, the backend service verifies the validity of the access token. If the token is valid, the backend service processes the request and returns the corresponding resources or data.

[0131] 5. Token Refresh and Renewal

[0132] (1) Token validity period: Access tokens usually have a limited validity period and need to be refreshed after expiration.

[0133] (2) Refresh token: The front-end application can use the stored refresh token to initiate a refresh request to the authorization server to obtain a new access token and refresh token.

[0134] (3) Handling token expiration: If the access token or refresh token is invalid (such as being revoked or expired), the front-end application needs to guide the user to re-authenticate and re-authorize.

[0135] 6. Safety precautions

[0136] (1) HTTPS: Ensure that all network communications involving authentication and authorization use the HTTP protocol to protect data security.

[0137] (2) Token storage: Securely store access tokens and refresh tokens in the front-end application to prevent them from being leaked to unauthorized users or third parties.

[0138] (3) Scope control: Assign the minimum necessary scope to the front-end application to reduce potential security risks. By following the above steps and precautions, front-end applications such as PP, mini-programs, enterprise communication applications, and WEB applications can be effectively integrated and authenticated with Hourui services through OAuth2.

[0139] The microservice architecture provided in this application can provide basic built-in management applications and meet the needs of other application expansion, mainly including the following aspects:

[0140] (1) Organizational structure: Provides all the functions of the organizational structure, including institutions, organizational dimensions, organizational departments, organizational personnel, organizational authorization, reporting relationship management, organizational structure integration, etc.

[0141] (2) Document management: It provides data sources, document modeling, online document design and generation, data lists, calendar views, data permissions, third-party interfaces, custom dialog boxes, custom queries, code generation, inter-table formulas, serial numbers, digital dictionaries, etc. For example, the form tool can provide a variety of form fields and attributes, and can flexibly define business rules based on business scenarios and logic to build application scenarios that meet the needs of the enterprise: MIS systems such as customer relations, purchase and sales inventory, and asset management.

[0142] (3) Process management: Provides online process definition, version management, process-document association, process-organizer and employee relationship, process-external interface association, process instance management, process task management, process message notification, etc. Process nodes can be customized in the process, and a person in charge can be added for each process. Combined with to-do message reminders, it is easy to realize business scenarios of various complex processes: such as invoice application, payment collection processing, etc.

[0143] (4) Portal management: Provides online portal column templates, column definitions, news bulletins, common applications, portal definitions, custom columns, etc. Provides a variety of charts and components to analyze the collected data and display the data in multiple dimensions and in real time to assist decision-making management. Data linkage can be achieved between components.

[0144] (5) System management: Provides online application and menu management, API gateway management, system parameter management, system classification, system cache, system audit log, system error log, classification authorization, watermark setting, time zone setting, multi-language setting, file storage setting, access blacklist and whitelist setting, etc.

[0145] (6) Task Scheduling: Provides online task scheduling reports, task management, task scheduling logs, task executor management, and background task addition management.

[0146] (7) Large screen application: Provides online business model management, online large screen design and authorization management, large screen sharing access management, and supports online design of various charts. It provides large screen design that can support most charts, maps, data linkage, and data screening, making it easier for users to analyze business data and provide decisions.

[0147] (8) Report application: Provides online design, online preview, permission setting and other functions of various reports based on JDBC data source.

[0148] For example, the microservice architecture provided by this application can provide support for low-code development, such as the ability to naturally support DevOps, and can achieve the integration and management of development, deployment, and operation and maintenance. If combined with the distributed Git code hosting, multiple people can collaborate on development at the same time, while meeting the development, automatic compilation, automatic packaging, automatic deployment, automatic testing, and automatic release of automated process development.

[0149] For example, if it can support development pipelines, the development pipeline operations can be combined with the above development tools + Git to achieve multi-person collaborative development. After submitting to the Git repository, it automatically triggers the online build task to achieve the overall compilation and packaging management of the application platform.

[0150] For example, it can support automated deployment: With the increasing number of microservice applications, enterprises can follow certain development specifications and connect different sub-applications to the platform, which can realize automatic code submission, automatic deployment, automatic testing, and automatic release to the production environment, realizing truly agile development. The platform provides Jenkins-based pipeline job script configuration, which can realize the platform's automated packaging and deployment pipeline operations.

[0151] By integrating Skywalking / Druid / ELK / Promethenus+Granfana, it is also possible to manage the operation monitoring of microservices.

[0152] It can be seen from the technical solutions introduced above that the microservice architecture provided by this application is a PaaS technology platform centered around applications and microservices. It can provide functions such as application full life cycle management, data-based operations, three-dimensional monitoring and service governance, aiming to help enterprise customers solve the difficulties of traditional centralized architecture transformation, build a large-scale, highly available distributed system architecture, and realize the rapid implementation of business and products. By providing a wealth of components and pre-built templates, the development threshold is lowered, so that the business personnel of the enterprise can also quickly build and deploy multi-platform applications. According to statistics, the efficiency of low-code development platforms in the application of internal enterprise informationization is improved by about 67%, which is equivalent to 1 person being able to play the human efficiency of 2 to 3 people. The development efficiency under the microservice architecture can be improved by more than 30% compared with the traditional monolithic architecture. The microservice architecture enables each service to be independently automated. Practical data shows that the coverage of automated tests under the microservice architecture can usually reach more than 90%, which is much higher than the monolithic architecture. It reduces dependence on professional developers and reduces labor costs. At the same time, due to the shortened development cycle, the time cost is also reduced. If rapid iteration and deployment are allowed, each microservice can be independently versioned and released. According to project practice data, the iteration cycle of projects using microservice architecture can usually be shortened by 20% to 50%; it enables business personnel to participate more directly in the software development process, promotes the deep integration of business and technology, supports rapid iteration and deployment, and the low-code platform further simplifies the development process. It can significantly accelerate the development process, allowing enterprises to respond to market changes more quickly. It supports independent deployment and expansion of functional modules, is easy to expand and modify, and improves the flexibility and maintainability of the system. It can make more optimized use of development resources and improve overall development efficiency. It can support complex business scenarios, provide powerful service governance and monitoring functions, ensure the stability and reliability of the system, and provide strong support for the digital transformation of enterprises. It enables enterprises to build and deploy digital applications faster and promote business innovation and development. It has natural fault isolation capabilities, and the failure of one service will not affect the normal operation of other services. According to project practice data, the fault recovery time under the microservice architecture can usually be controlled within a few minutes to a few hours; the availability of the system is improved through technical means such as distributed deployment and load balancing. Practical data shows that the system availability under the microservice architecture can usually reach more than 99.9%. It allows dynamic adjustment of server resources according to business needs, improving resource utilization. According to project practice data, server resource utilization under the microservice architecture can usually reach more than 80%, which is much higher than the monolithic architecture;

[0153] The following is a description of the microservice containerization and cloudification architecture construction device provided in the embodiment of the present application. The microservice containerization and cloudification architecture construction device described below and the microservice containerization and cloudification architecture construction method described above can be referenced to each other. Figure 6 , Figure 6 This is a schematic diagram of a microservice containerization and cloudification architecture construction device disclosed in an embodiment of the present application. Figure 6 As shown, the microservice containerization and cloudification architecture construction device may include: a public support framework construction unit 101, which is used to construct a public support framework of a microservice architecture to obtain a first microservice architecture; a public service component construction unit 102, which is used to construct a public service component of the first microservice architecture based on the first microservice architecture to obtain a second microservice architecture; an entity object service construction unit 103, which is used to construct a specific entity object service of the second microservice architecture to obtain a third microservice architecture; an extension module construction unit 104, which is used to construct an extension module of the third microservice architecture based on the third microservice architecture to obtain a target microservice architecture.

[0154] Among them, the specific processing flow of each unit included in the above-mentioned microservice containerization and cloudification architecture construction device can refer to the relevant introduction of the microservice containerization and cloudification architecture construction method in the previous text, and will not be repeated here.

[0155] The microservice containerization and cloudification architecture construction device provided in the embodiment of the present application can be applied to microservice containerization and cloudification architecture construction devices, such as terminals: mobile phones, computers, etc. Optionally, Figure 7 The hardware structure diagram of the microservice containerization and cloud architecture construction equipment is shown. Figure 7, the hardware structure of the microservice containerization and cloudification architecture construction device may include: at least one processor 1, at least one communication interface 2, at least one memory 3 and at least one communication bus 4. In the embodiment of the present application, the number of processor 1, communication interface 2, memory 3 and communication bus 4 is at least one, and the processor 1, communication interface 2 and memory 3 complete mutual communication through the communication bus 4. Processor 1 may be a central processing unit CPU, or a specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiment of the present application; memory 3 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory; wherein the memory stores a program, and the processor can call the program stored in the memory, and the program is used to: implement the various processing flows in the aforementioned terminal microservice containerization and cloudification architecture construction solution. The embodiment of the present application also provides a readable storage medium, which can store a program suitable for execution by a processor, and the program is used to: implement the various processing flows of the aforementioned terminal in the microservice containerization and cloudification architecture construction solution.

[0156] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or equipment. In the absence of more restrictions, the elements defined by the sentence "comprise one..." do not exclude the existence of other identical elements in the process, method, article or equipment including the elements. In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same and similar parts between the embodiments can be referred to each other.

[0157] The above description of the disclosed embodiments enables professionals and technicians in the field to implement or use the present application. Various modifications to these embodiments will be apparent to professionals and technicians in the field, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. The various embodiments can be combined with each other. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for constructing a microservice containerized and cloudified architecture, characterized in that: include: Build a common support framework for the microservice architecture to obtain the first microservice architecture; Based on the first microservice architecture, construct a public service component of the first microservice architecture to obtain a second microservice architecture; Constructing a specific entity object service of the second microservice architecture to obtain a third microservice architecture; Based on the third microservice architecture, an extension module of the third microservice architecture is constructed to obtain a target microservice architecture.

2. The method according to claim 1, characterized in that The common support framework for constructing the microservice architecture obtains a first microservice architecture, including: Build a database connection management mechanism for the microservice architecture, the first sub-service architecture; Setting a unified return format for data of the first sub-service architecture to obtain a second sub-service architecture; A unified return code and description information of the second sub-service architecture are set to obtain the first microservice architecture.

3. The method according to claim 1, characterized in that The step of constructing a public service component of the first microservice architecture based on the first microservice architecture to obtain a second microservice architecture includes: Based on the first microservice architecture, a load balancing component of the first microservice architecture is constructed to obtain a third sub-service architecture, wherein the load balancing component is responsible for distributing multiple requests to different microservice instances; Constructing a service registration and service discovery framework of the third sub-service architecture to realize the dynamic registration and discovery functions of its services, thereby obtaining a fourth sub-service architecture; The transaction management function of the fourth sub-service architecture is constructed to realize its service management and ensure the transaction consistency across services, thereby obtaining the second microservice architecture.

4. The method according to claim 1, characterized in that: The specific entity object service of constructing the second microservice architecture to obtain the third microservice architecture includes: Constructing the front-end service of the second microservice architecture to obtain a fifth sub-service architecture, wherein the front-end service of the second microservice architecture is responsible for interacting with the user, forwarding the user request to the back-end service of the second microservice architecture, and presenting the data returned by the back-end service of the second microservice architecture to the user; The backend service of the fifth sub-service architecture is constructed to obtain the third microservice architecture, wherein the backend service of the fifth sub-service architecture is responsible for processing business logic and data operations.

5. The method according to claim 4, characterized in that The backend service for constructing the fifth sub-service architecture includes: Constructing the business control layer framework of the fifth sub-service architecture to obtain the sixth sub-service architecture, wherein the business control layer framework of the fifth sub-service architecture is responsible for receiving the request of the front-end service, verifying and converting it, and calling the corresponding business service layer for processing; Constructing a business service layer framework of the sixth sub-service architecture to obtain a seventh sub-service architecture, wherein the business service layer framework of the sixth sub-service architecture is responsible for defining and implementing a business logic interface; The business persistence layer framework of the seventh sub-service framework is constructed to obtain the third microservice architecture, wherein the business persistence layer framework of the seventh sub-service framework is responsible for data interaction with the database to implement data addition, deletion, query and modification operations.

6. The method according to claim 1, characterized in that The step of constructing an extension module of the third microservice architecture based on the third microservice architecture to obtain a target microservice architecture includes: Building application program interfaces for all external requests on the third microservice architecture to obtain an eighth sub-service architecture; Building a configuration center on the eighth sub-service architecture to centrally manage configuration information of all microservices, thereby obtaining a ninth sub-service architecture; Constructing a log management framework of the ninth sub-service architecture to realize the functions of collecting and analyzing logs, and monitoring and analyzing the running status of microservices in real time, thereby obtaining a tenth sub-service framework; A monitoring and alarm framework of the tenth sub-service framework is constructed to realize the functions of real-time monitoring of the performance indicators and health status of microservices and real-time alarm, thereby obtaining the target microservice framework.

7. The method according to claim 1, characterized in that The step of constructing an extension module of the third microservice architecture based on the third microservice architecture to obtain a target microservice architecture includes: Analyze the user's business needs and determine the functional modules corresponding to the user's business needs; Functional modules corresponding to the user's business needs are constructed on the third microservice architecture to obtain the target microservice architecture.

8. A device for constructing a microservice containerized and cloudified architecture, characterized in that: include: A public support framework construction unit, used to construct a public support framework of a microservice architecture to obtain a first microservice architecture; A public service component construction unit, configured to construct a public service component of the first microservice architecture based on the first microservice architecture to obtain a second microservice architecture; An entity object service construction unit, used to construct a specific entity object service of the second microservice architecture to obtain a third microservice architecture; The extension module construction unit is used to construct the extension module of the third microservice architecture based on the third microservice architecture to obtain the target microservice architecture.

9. A microservice containerization and cloud architecture construction device, characterized in that: include: one or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, implement the steps of the method for building a microservice containerization and cloud architecture as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by one or more processors, the one or more processors implement the steps of the microservice containerization and cloud architecture construction method as described in any one of claims 1 to 7.

Images